3 января 2004 года марсоход «Спирит» успешно десантировался в кратер Гусева. Однако спустя всего три недели аппарат перестал реагировать на команды, зациклившись в бесконечной перезагрузке из-за критической ошибки в системном ПО. Этот инцидент стал эталонным кошмаром для инженеров JPL. В материале разберем, как NASA едва не лишилась двух миссий подряд из-за уязвимостей в одной и той же операционной системе.
Бесконечный ребут на Марсе
В начале 2004 года команда Лаборатории реактивного движения праздновала триумф: «Спирит» благополучно выкатился на поверхность, передал первые панорамы и приступил к исследованиям грунта. Казалось, миссия обречена на успех.
Все изменилось 21 января, на 18-й сол. Во время работы спектрометра mini-TES ровер внезапно перешел в безопасный режим, а затем провалился в бесконечную череду перезагрузок. Каждое включение оканчивалось сбоем, который тут же инициировал новую попытку старта. К исходу дня счетчик ошибок перевалил за сотню.
Для команды, инвестировавшей в проект 400 миллионов долларов, ситуация была патовой. Задержка сигнала в 20 минут исключала возможность оперативного вмешательства или полноценной отладки в режиме реального времени.
Никакого SSH или доступа к логам: разработчикам пришлось вслепую искать причину поломки, анализируя обрывки телеметрии.
Память, которая «помнила» слишком много
Сердцем марсохода был процессор IBM RAD6000 под управлением ОС реального времени VxWorks. В распоряжении системы было всего 128 МБ RAM и 256 МБ флэш-памяти. Последняя делилась на загрузочный раздел и хранилище для научных данных.
Проблема крылась в модуле DOS Library, управлявшем файлами. При каждой загрузке система кэшировала дерево каталогов в оперативную память. Однако архитектура была спроектирована крайне нерационально: при удалении файла соответствующая запись в структуре RAM не очищалась, а лишь помечалась как неактуальная. Со временем объем этой «мусорной» структуры разрастался, потребляя критически важную оперативку.
Это означало, что потребление памяти зависело не от текущего количества файлов, а от их общего объема за все время эксплуатации. Обычное удаление данных не решало проблему — требовалось полное форматирование.
Программный детонатор
За время полета к Марсу «Спирит» накопил массу служебной информации, практически заполнив лимит RAM. Ситуация обострилась, когда на 15-й день инженеры попытались отправить утилиту для очистки файловой системы. Из-за проблем со связью пакет данных дошел поврежденным.
Неполная утилита не могла выполниться, а из-за нехватки ресурсов система вместо возврата ошибки переводила задачу в режим ожидания. В условиях отсутствия виртуальной памяти и свопинга ждать освобождения RAM было бессмысленно.
Механизм контроля состояния системы («software health») фиксировал зависший процесс и, согласно протоколу, инициировал жесткую перезагрузку. Возникал бесконечный цикл: старт системы -> попытка монтирования файловой системы -> переполнение памяти -> зависание -> сброс. Батареи марсохода таяли на глазах.
Удаленное «лечение»
Инженеры JPL методом проб и ошибок, анализируя скудные логи, обнаружили корень проблемы. Сначала они применили временный «костыль» — перевод ровера в режим работы исключительно на базе RAM, без использования флэш-памяти. Однако это не решало вопрос сохранения научных данных.
«С самого начала полета стало очевидно, что в ПО есть уязвимые места, — вспоминал инженер Роджер Клемм. — Мы оперативно подготовили и залили на борт обновленный образ системы».
Чтобы окончательно устранить ошибку, потребовалось создать уникальный скрипт, работающий напрямую с файловой системой в обход стандартных библиотек VxWorks. Это позволило удалить «лишний багаж» и освободить память. К началу февраля «Спирит» вернулся в строй.
Позже инженеры внедрили патч, который при инициализации корректно очищал записи о файлах и добавили «предохранители» на случай повторных зависаний.
Старые грабли в космосе
Подобный инцидент случился еще в 1997 году с аппаратом Pathfinder — тоже из-за недочетов в VxWorks. Тогда проблему решили активацией механизма приоритетного наследования (priority inheritance). А в 1999-м NASA потеряла Mars Climate Orbiter из-за тривиальной ошибки перевода единиц измерения (фунт-секунды против ньютон-секунд).
Несмотря на все сложности, «Спирит» проработал почти 6 лет, превзойдя план в 20 раз. Он стал настоящим долгожителем, чья история — наглядный урок важности тщательного тестирования и грамотного управления ресурсами.
Выводы для инженеров
История «Спирита» — это напоминание о том, как дефицит ресурсов (всего 128 МБ RAM) может стать фатальным при неграмотной архитектуре ПО. Будь то утечки памяти в Redis, переполнение логов в микросервисах или «зависшие» поды в Kubernetes — принципы остаются неизменными. Оценка ресурсов и настройка механизмов их вытеснения или ротации — база, без которой любой продакшн рано или поздно превращается в марсианский ребут.
А какие «костыли» приходилось внедрять вам, чтобы спасти систему в самый критический момент? Делитесь своим опытом в комментариях.
© 2026 ООО «МТ ФИНАНС»
