23 сентября 1999 года NASA потеряло связь с Mars Climate Orbiter за несколько минут до выхода аппарата на орбиту Марса. Цена ошибки — около 125 млн долларов и несколько лет работы. Для IT-аудитории эта история важна не из-за космической драмы, а потому что в ее центре до боли знакомый сбой: две команды сделали одну систему, но договорились о разном формате данных.
Об этом напоминает Habr / Карьера в разборе старой, но до сих пор показательной аварии. Mars Climate Orbiter летел к Марсу девять месяцев после запуска в декабре 1998 года. Аппарат должен был изучать атмосферу и климат планеты, а заодно работать ретранслятором связи для следующей миссии — Mars Polar Lander. На бумаге все выглядело как нормальный инженерный проект конца 90-х: несколько подрядчиков, разделение ответственности, штатные коррекции курса, телеметрия без явных признаков катастрофы. Пока не наступил день, когда аппарат должен был затормозить у Марса и выйти на расчетную орбиту.
Сценарий был стандартный для такой миссии. Зонд заходил за планету, связь на время пропадала, затем аппарат должен был снова появиться в эфире уже после маневра. Но сигнал не вернулся. Инженеры пытались восстановить контакт, однако безуспешно. Позже расследование показало: аппарат прошел слишком низко над Марсом и оказался не там, где его ждали. По одной из версий, он разрушился в верхних слоях атмосферы. Точную судьбу аппарата установить не удалось, но с практической точки зрения это уже ничего не меняло: миссия была потеряна.
Причина звучит почти оскорбительно просто для проекта такого масштаба. Программное обеспечение, за которое отвечала Lockheed Martin, передавало данные об импульсе двигателей в pound-force seconds, то есть в единицах, основанных на фунтах силы. Система навигации NASA и Лаборатории реактивного движения, наоборот, ожидала эти же данные в ньютон-секундах, то есть в системе SI. Не баг уровня «сломался датчик в космосе», не редкая аномалия и не удар микрометеорита, а банальная несостыковка интерфейсов между частями одного проекта. Ошибка не дала мгновенного эффекта, что и сделало ее особенно опасной. Накопленные расхождения постепенно искажали расчеты траектории, пока в критический момент не стало поздно что-либо исправлять.
В этой истории особенно неприятно то, насколько она узнаваема за пределами аэрокосмоса. Один модуль пишет данные в одном формате, другой читает их в другом; контракт между командами будто бы существует, но на практике каждый понимает его по-своему. На тестовом стенде все выглядит приемлемо, система формально работает, отклонения кажутся некритичными. А затем приходит прод, пиковая нагрузка или важный релиз — и выясняется, что проблема не в одной строчке кода, а в том, что никто по-настоящему не контролировал границы между подсистемами. В случае Mars Climate Orbiter такой границей стали единицы измерения. В обычной компании это могут быть валюты, таймзоны, форматы дат, статусы заказов, версии схемы событий или трактовка полей в API.
Поэтому самый важный вывод NASA после аварии был не в жанре «найти виноватого и показательно наказать». Расследование не свело катастрофу к одному некомпетентному инженеру. Наоборот, проблема оказалась системной: ошибка возникла в процессе взаимодействия команд и не была поймана контрольными механизмами до того, как превратилась в потерю миссии. Для бизнеса это, возможно, самый ценный и самый неприятный урок. Высокая квалификация отдельных специалистов не спасает проект, если у него слабая дисциплина интеграции. Талант инженеров не заменяет валидацию единиц, жесткие контракты данных, независимые проверки и культуру, в которой странные отклонения не списывают на шум.
Отсюда и прямой вывод для разработчиков, продактов и IT-руководителей. Риски живут не только в сложной логике, но и в стыках между командами. Если продукт собирается из нескольких доменов, недостаточно просто «распилить» ответственность по ownership-матрице. Нужно заранее определить, где ошибка переживается без паники, а где один нестыкующийся параметр может сжечь деньги, SLA и репутацию. В источнике этот подход описан через карту критичности доменов: условно зеленые зоны, где сбой неприятен, но не смертелен, и красные, где падение требует немедленной реакции. По сути речь о старой доброй инженерной гигиене: классифицировать критичные участки, усиливать проверки там, где цена ошибки максимальна, и не делать вид, что все части системы одинаково безопасны.
У этой истории есть еще один неудобный подтекст. Она случилась не в гаражном стартапе, а в NASA, организации с огромным опытом, процедурами и бюджетами. То есть аргумент «у нас сильная команда, такого не будет» здесь не работает вообще. Будет. Вопрос только в том, поймает ли система ошибку раньше, чем она дойдет до пользователя, до платежа, до базы данных или до точки, где аппарат уже входит в атмосферу слишком низко. История Mars Climate Orbiter пережила эпоху толстых клиентов, монолитов и первых веб-сервисов именно потому, что сама природа сбоя никуда не делась. Чем больше распределенных команд, интеграций и зависимостей, тем выше шанс потерять уже не спутник, а что-то более приземленное, но для бизнеса не менее дорогое.
Поэтому главный вопрос после этой аварии звучит не «как можно было перепутать фунты и ньютоны», а «какие такие же скучные несовпадения уже сидят в наших интерфейсах и ждут своего часа». В 1999 году цена такого несовпадения составила 125 млн долларов. Для большинства компаний счет будет скромнее, но сам механизм ошибки останется тем же: система ломается не там, где инженер чего-то не знал, а там, где команда решила, что договоренностей на словах вполне достаточно.