Важливість тестового оточення

Привіт друзі! Нещодавно прочитав надзвичайно цікаву статтю про те, як пишуть софт у SpaceX 🚀
Стаття цікава не тільки описом підходу до розробки і тестування, а референсами до катастроф, які ставались, коли баги не були виявлені вчасно і кожного разу змушували інженерів підіймати планку якості.
Серед інших мене особливо вразив один, який я і хочу переказати вам.

14 грудня 1966 року, на тестовому запуску ракета з безпілотним кораблем “Союз” не змогла взлетіти зі стартового майданчику – один з двигунів не загорівся. Автоматика зупинила запуск. Персонал космодрому пішов перевіряти стан ракети. І в цей час не заплановано спрацювала система аврарійного спасіння (САС) “Союзу” (у випадку аварії корабель з екіпажем має вистрілити від ракети та посадити на парашутах на безпечній відстані). Двигуни САС підпалили горючу рідину, що була розлита на землі, сталася пожежа, одна людина загинула.

Розслідування причин аварії встановило, що ракету обладнано інерційною системою відліку, і комп’ютери порівнюють положення ракети за даними системи та згідно запланованої траєкторії. Якщо є різниця – вистрілює САС. Під час розробки системи було закладено, що Земля – нерухома (і ракета на землі теж). В той же час Земля рухається і за приблизно пів години після невдалого старту ракета разом з усією планетою (чималу змінну не врахували) відхилилась від запланованої траєкторії на 8 градусів, що і викликало запуск САС.

До чого це я? Всі ми часто ловимо гейзенбаги, які не можемо відтворити. Але ніякої містики немає – просто ще не всі змінні врахували. Наступного тижня поділюсь свіжою байкою про такий баг на своєму проєкті.
Гарних вихідних!

4 December 2020
Автор: 
Oleksii Ostapov

Leave a comment

Leave a Reply