Starship V3: космическая стройка, где чертежи пишут по ходу полёта

Ракету, которая должна возить людей на Марс, впервые запускают без полезной нагрузки — и это считается успехом. В космической инженерии, как и в IT, есть проекты, где итерация — единственный способ продвинуться, потому что симуляция не покрывает всех граничных условий. Starship V3, судя по отчёту Ars Technica, именно такой случай: полёт прошёл «в основном успешно», но до заявленной цели — выхода на низкую околоземную орбиту — ещё далеко.

Тестовый полёт как proof of concept

SpaceX не скрывает, что V3 — ещё не финальная версия. Первый запуск показал, что связка из 33 двигателей Raptor 3 работает стабильнее, чем в предыдущих итерациях, а теплозащита выдержала вход в атмосферу лучше, чем у V2. Но до орбиты Starship не добрался: верхняя ступень отключилась раньше расчётного времени, и аппарат упал в океан, не набрав нужной скорости.

Для нас здесь интересна не столько ракетная техника, сколько подход к тестированию. В софтверной разработке такую стратегию назвали бы «fail fast, ship often» — и она работает, когда цена ошибки приемлема. В космосе цена ошибки — потеря дорогостоящего железа, но SpaceX сознательно идёт на это, чтобы собрать телеметрию, которую не получить в стендовых испытаниях. Это trade-off между стоимостью одной итерации и скоростью обучения.

Что из этого могут взять IT-команды

Прямая аналогия — запуск сложной распределённой системы в production под канареечным релизом. Вы не знаете наверняка, как поведёт себя новый алгоритм балансировки под реальной нагрузкой, пока не попробуете. Можно годами гонять нагрузочные тесты, а можно выкатить на 5% трафика и смотреть метрики. Первый путь даёт иллюзию контроля, второй — реальные данные.

Но тут есть оговорка: не всякий проект выдержит «ракетный» подход. Если у вас legacy-монолит с uptime SLA 99.99%, а каждый сбой стоит клиенту денег, итерации в production обойдутся дороже, чем тщательное проектирование. SpaceX может позволить себе взрывать прототипы, потому что у неё нет абонентов с контрактом на связь. В B2B-продукте такой роскоши обычно нет.

На нашем опыте граница проходит примерно так: если вы пишете новый сервис с нуля и можете откатиться на стабильную версию за минуту — экспериментируйте в live. Если доработка затрагивает ядро платёжной системы — сначала чертёж, потом стены.

Когда «в основном успешно» — это нормально

Ключевой момент — честность про статус. SpaceX не называет V3 финальной версией и не обещает орбиту с первого раза. В IT мы часто видим обратное: команда выдаёт альфу за релиз, а потом героически фиксит баги в production под обещания «так и было задумано». Лучше сказать «мы проверили гипотезу и получили данные» — это снимает давление и позволяет спокойно анализировать ошибки.

Starship V3 не полетел на орбиту, но полёт дал инженерам тысячи точек телеметрии, которые ускорят следующую итерацию. Если ваш релиз не взлетел до ожидаемой высоты, но вы узнали, где именно отвалилась ступень, — вы не проиграли, вы провели успешный тест.