Маргарет Гамильтон, руководившая разработкой бортового ПО для лунных миссий NASA, умерла 30 сентября в возрасте 90 лет. Во время посадки Apollo 11 в 1969 году программные решения её команды позволили компьютеру продолжить работу при перегрузке — и это, пожалуй, самый наглядный ранний пример того, зачем инженерии нужны приоритеты задач, обработка сбоев и право системы отказаться от второстепенной работы. О смерти Маргарет Гамильтон сообщает Ars Technica.
Её чаще всего вспоминают по фотографии 1969 года: молодая Гамильтон стоит рядом с высокой стопкой распечаток кода Apollo. Но этот образ легко превращает инженерную работу в красивую легенду о «гении-одиночке». Реальность интереснее: Гамильтон возглавляла команду в Instrumentation Laboratory Массачусетского технологического института, отвечавшую за программное обеспечение бортовых компьютеров пилотируемых кораблей программы Apollo. Её вклад — не одна удачная строка кода, а подход к разработке систем, которым нельзя позволить упасть в самый неподходящий момент.
Три минуты до посадки и перегруженный компьютер
20 июля 1969 года, примерно за три минуты до посадки лунного модуля Eagle, экипаж увидел программные тревоги 1201 и 1202. Бортовой компьютер получал больше работы, чем мог обработать. Причиной стала конфигурация радара сближения: система передавала лишние данные, пока модуль снижался к поверхности Луны. Для миссии, где цена неверного решения измерялась не простоями сервиса и не сорванным релизом, а жизнью Нила Армстронга и Базза Олдрина, это был очень плохой момент для сообщения об исчерпании ресурсов.
Компьютер не завис и не попытался честно выполнить всё сразу. Архитектура ПО отбрасывала менее важные вычисления, сохраняла критические процессы управления полётом и допускала перезапуск с сохранением нужного состояния. Центр управления решил не прерывать посадку; Eagle сел в Море Спокойствия. Приписывать это решение одному человеку было бы исторически неверно: над Apollo работали большие команды инженеров, а решение в полёте принимали и специалисты NASA. Но принципы, которые развивала команда Гамильтон, сделали такой сценарий возможным.
Для современных разработчиков здесь нет магии из эпохи ламповых ЭВМ. Есть знакомый набор вопросов: что произойдёт, если входных событий внезапно станет больше расчётного; какие операции критичны; может ли сервис деградировать контролируемо; сохраняет ли система согласованное состояние после перезапуска; как команда докажет это до продакшена, а не во время инцидента. Разница лишь в масштабе последствий. У Apollo не было возможности выпустить срочный патч, открыть тикет и переждать деградацию в облаке.
Когда «софт» стал инженерной дисциплиной
Гамильтон также связывают с появлением и популяризацией термина software engineering — «программная инженерия». В 1960-х программирование ещё нередко воспринимали как вспомогательную работу вокруг «настоящей» аппаратной инженерии. Гамильтон настаивала, что создание ПО для критически важных систем требует собственной дисциплины: методов проектирования, строгого тестирования, анализа ошибок и ответственности за полный жизненный цикл. Сейчас это звучит почти очевидно, но привычные нам code review, тестовые контуры, наблюдаемость, SRE-практики и разборы инцидентов выросли из той же простой идеи: код — часть системы, от которой зависит реальный мир.
После работы в MIT Гамильтон основала две софтверные компании. Первая, Higher Order Software, занималась методами предотвращения ошибок на ранних этапах разработки. Позднее она создала Hamilton Technologies, где развивала подход Higher Order Software и инструменты для построения надёжных систем. Это важная деталь её биографии: она не осталась символом «космического прошлого», а пыталась перенести опыт Apollo в прикладную разработку — туда, где сбои также стоят денег, репутации и иногда человеческой безопасности.
В 2016 году Гамильтон получила Президентскую медаль Свободы США. Признание пришло заметно позже её ключевой работы, как часто бывает с инфраструктурным трудом: на обложки попадают экипажи, железо и запуск ракеты, а архитектура отказоустойчивости остаётся в логах, спецификациях и стопках листингов. Для российской IT-аудитории её история особенно полезна как противоядие от культа скорости. Быстро написать прототип — отдельный навык. Спроектировать систему, которая при перегрузке сохраняет главное, честно сообщает об ограничениях и не превращает аварийный сценарий в катастрофу, — другой и куда более редкий.
Наследие Маргарет Гамильтон не сводится к фотографии рядом с кодом и не требует романтизации старого железа. Оно в вопросе, который стоит задавать перед каждым запуском критичной функции: если ресурсов не хватит, что именно наша система решит не делать — и кто заранее доказал, что этот выбор безопасен?