company_banner

Чему меня, как разработчика, научили аварии в космосе

Автор оригинала: Andrey Sitnik
  • Перевод

Оригинал: статья «What I learned as a developer from accidents in space», Андрея Ситника, из блога Evil Martians «Martian Chronicles»

Андрей Ситник, автор PostCSS и Автопрефиксера, сделал подборку историй, связанных с освоением космоса Советским Союзом. Вы узнаете, какие уроки из них извлёк Андрей, чтобы вырасти как разработчик и участник опенсорс-движения. Неудачная стыковка, драматический вход в атмосферу и уникальный переход вдоль поручня между космическими кораблями — какое отношение всё это имеет к современной веб-разработке? Обо все этом читайте в посте!

Исследования космоса интересовали меня, сколько я себя помню. Люди, знавшие меня лично, слышали рассказов о космосе больше, чем им хотелось бы. До того, как присоединиться к Evil Martians, я администрировал русскоязычную версию Википедии, и одним из моих любимых увлечений была редактура связанных с космосом статей. Я ездил наблюдать за запусками на Байконуре и мысе Канаверал, и чем больше я узнавал об усилиях по покорению космоса, тем сильнее эти знания влияли на меня как на разработчика. 

Хотя писать программы не так сложно, как строить ракеты (по большей части), но всё же мы, программные инженеры, часто работаем в больших командах, создающих сложные системы. И как исследователи космоса, иногда мы проигрываем борьбу со сложностью.

«Один аварийный пуск дает нам для познания и улучшения системы гораздо больше, чем десяток благополучных»

Николай Пилюгин, академик, конструктор, специалист в области систем автономного управления ракетными и ракетно-космическими комплексами.

В каждой космической программе случаются ошибки, не все из них трагические. В этой статье я расскажу о примерах из советской и российской истории освоения космоса, которые мало известны вне сообщества энтузиастов (речь идёт про западное сообщество — прим. перев.). Эти истории закончились хорошо.

Первый урок: никогда не обвиняй пользователей*


* …и вноси изменения на каждое их обращение.

В конце 1960-х США и СССР завершили работу над новым поколением космических кораблей. Apollo и Союз стали большим шагом вперёд после экспериментальных Mercury/Gemini и Восток/Восход. Новые корабли были спроектированы для работы не только на околоземных орбитах, но и для полётов на Луну и обратно.

В октябре 1968-го СССР оправился от катастрофы Союза-1 и был готов сделать новую попытку: планировалось впервые выполнить на орбите ручную стыковку двух кораблей. Автоматический Союз-2 должен был отправиться в космос первым. Затем Георгий Береговой на Союзе-3 должен был выйти на ту же орбиту и состыковать корабли.


Пилот Союза-4, Союза-8 и Союза-10 Владимир Шаталов демонстрирует стыковку двух кораблей.

Запуск прошёл хорошо. Всего через 1,5 часа Союз-3 оказался на расстоянии стыковки. Манёвр был запланирован на «ночное» время, в тени Земли. Однако все попытки ручной стыковки закончились безуспешно.

И только когда оба корабля оказались на дневной стороне, Береговой обнаружил ошибку: Союз-2 был повёрнут вдоль продольной оси на 180 градусов.

Поскольку к тому времени все запасы топлива были израсходованы на попытки стыковки, Береговому приказали завершить миссию и вернуться через четыре дня на Землю. Газеты назвали полёт успешным, Береговому присвоили звание Героя Советского Союза и вскоре повысили. Однако из этой истории были извлечены правильные уроки, и для всех последующих стыковок были введены новые правила:

  • Стыковаться только на солнечной стороне.
  • Не планировать стыковку в один день с запуском, чтобы пилоты успели аклиматизироваться на орбите.


Стыковка Союза-4 в фильме «Четверо в космосе».

Вспоминайте об этой истории, когда будете в очередной раз вставлять штекер USB Type-A не той стороной.

Нет плохих пользователей — есть плохой интерфейс.

Легко обвинять пользователей. Однако люди всегда будут ошибаться. Разработчики не исключение. Как участник опенсорс-движения, я понял, что если винить разработчиков за ошибки, то это всё равно не поможет предотвратить ошибки в будущем.

Закрывая issue о проблеме в своём opensource-репозитории грубым ответом в стиле RTFM (или, того хуже, вообще без ответа!), вы не защитите себя от появления такой же issue. Вы будете раз за разом получать одни и те же сообщения.

Как создатель PostCSS и Автопрефиксера, я получаю много сообщений о проблемах. Чтобы в долгосрочной перспективе не тратить время зря, я следую правилу: каждая проблема должна приводить к изменению кода или документации.

Лучше всего улучшать пользовательский опыт, UX (с точки зрения opensource-библиотеки это будет API), чтобы в будущем невозможно было совершить ту же ошибку. На худой конец можете добавить предупреждение.

К примеру, многие пользователи PostCSS забывают об опции parser и пытаются обрабатывать файлы .less и .scss без соответствующих парсеров. Вместо того, чтобы обвинять пользователей, мы добавили маленькое предупреждение:

if (error.name === 'CssSyntaxError' && opts.from.endsWith(‘.scss’)) {
  error.message += '\nYou tried to parse SCSS with ' +
                   'the standard CSS parser; ' +
                   'try again with the postcss-scss parser'
}

Второй урок: во что бы то ни стало сообщайте разработчику о проблемах


Через три месяца после полёта Союза-2 и Союза-3 СССР был готов к новой попытке ручной стыковки, ещё более амбициозной.

Планировалось с разницей в один день запустить два пилотируемых корабля: Союз-4 с одним космонавтом и Союз-5 с тремя. После стыковки инженер-пилот и инженер-исследователь из Союза-5 должны были через открытый космос перейти в Союз-4 и вернуться на Землю. То есть взлетели в одном корабле, прогулялись в космосе, приземлились на другом корабле.


Переход через открытый космос Союза-5 в Союз-4.

Борис Волынов, пилот Союза-5, должен был остаться один и вернуться на Землю день спустя.

В этот раз стыковка прошла успешно, Союз-4 без проблем завершил свою миссию. И 18 января 1969-го пришла пора вернуться домой и Волынову. Союз состоит из трёх отделяемых модулей, и лишь один, центральный, был предназначен для входа обратно в атмосферу.


Схема Союза. Источник: NASA

В ходе возвращения Волынова приборно-агрегатный модуль не отделился штатно. Было уже слишком поздно прерывать посадку. Космический корабль вошёл в атмосферу с неправильной ориентацией в пространстве: носом вперёд. Набегающему потоку противостоял лишь тонкий входной люк, тепловой щит был сзади, между не разделившимися модулями.

Уплотнение вокруг люка начало гореть, посадочная капсула начала заполняться ядовитым дымом. Гравитация и атмосфера выполняли свою работу, беззащитный Волынов был пристёгнут в кресле.


Художественное изображение входа в атмосферу Союза-4.

Однако жар, который мог убить Волынова, неожиданно спас его: взорвались топливные баки приборного модуля, и в результате тот отделился. Посадочная капсула повернулась в правильное положение, теплозащитным экраном вперёд.

Всё это время Волынов, уверенный, что доживает последние минуты, записал вслух всё, что видит и слышит.

На этом проблемы не закончились. Парашютные стропы запутались, а двигатели мягкой посадки не сработали. Капсула с высокой скоростью ударилась о землю далеко от запланированного района. Раненому Волынову пришлось выживать на морозе в −38 °C, пока до него не добрались спасатели.

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

Чему меня научила эта история, достойная голливудской экранизации?

Каждый раз, сталкиваясь с проблемой, связанной с библиотекой или инструментом для разработки, я вспоминаю Бориса Волынова. Если он смог сообщать о проблемах даже на пороге смерти, то я точно смогу выделить несколько минут, чтобы отправить отчёт разработчику.

Даже простой отчёт может быть большим вкладом в проект.

Из-за синдрома самозванца, пронизывающего нашу отрасль, мы слишком часто считаем себя виноватыми в возникающих проблемах. Что-то упустили в документации, или просто не были достаточно умны. Но не забывайте об уроке из первой истории: нет плохих пользователей, есть только плохой интерфейс. И нет плохих разработчиков, есть только плохие инструменты разработки.

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

Вы сделали опечатку, получилось непонятное сообщение об ошибке и в результате вы потратили час на отладку? Это прекрасная возможность улучшить сообщение об ошибке с помощью нового issue или PR. Слишком долго ищете способ обойти библиотеку? Подумайте, какая информация в документации помогла бы вам.

Третий урок: доверяйте автоматизации


Эта история произошла в 1997 с уже не существующей космической станцией Мир

Между советской и американской космической программой было одно важное различие. В СССР корабли создавали те же люди, которые создавали ракеты: они широко использовали автоматику и считали пилотов практически обузой. А в США корабли (в частности, Space Shuttle) создавали люди, которые проектировали самолёты, и они считали компьютеры лишь вспомогательными инструментами для пилотов.

СССР с 1967-го использовал полностью автоматические системы стыковки: сначала Иглу, затем Курс. Эти разработки позволили построить станцию Мир из автоматических модулей, которые действуют как независимые космические аппараты с собственными компьютерами, энергосистемами и двигателями.


Модули станции Мир.

Однако советские стыковочные системы производились на Украине, и после распада СССР Москва и Киев не договорились о ценах. Роскосмос, стараясь уменьшить зависимость от иностранных комплектующих, разработал альтернативу — ТОРУ, которая позволяла оператору на космической станции удалённо управлять кораблём с помощью двух джойстиков.

ТОРУ успешно испытали в космосе. В 1997-м корабль Прогресс М-34 с грузами для станции успешно автоматически пристыковался к Миру. И тут неожиданно последовало указание отстыковать его, и вместо возвращения на Землю заново пристыковать к станции вручную, чтобы опять проверить систему стыковки.


Василий Циблиев управляет кораблём с борта станции Мир.

Экипаж пытался сохранить управление перегруженным Прогрессом (он нёс очередную партию отходов со станции, который нужно было вернуть на Землю), а на передаваемом с корабля видео трудно было обнаружить Мир. Когда космонавты наконец увидели в иллюминаторы приближающийся корабль, тормозить было уже поздно. Корабль повредил солнечную панель модуля Спектр, который обеспечивала 40 % электроэнергии станции, и проделал дыру в корпусе.

Космонавты услышали свист и у них заложило уши. Станция теряла воздух.

Экипажу пришлось отключить кабели, идущие со Спектра, закрыть модуль и оставить его разгерметизированным. А три года спустя станция была затоплена в океане.

В результате от стыковочной системы Курс так и не отказались, сегодня она производится в России. Курс и ТОРУ используются на российских кораблях, ТОРУ является запасной системой.

По сей день не совсем ясны причины первого и пока единственного столкновения в космосе. Центр массы корабля был смещён из-за перегрузки, космонавты были утомлены и плохо владели ТОРУ. Само испытание было организовано в спешке: в тот момент на борту Мира находился американский астронавт, и ни он, ни НАСА не знали об испытании, пока станция не оказалась разгерметизирована.


Повреждения Мира после столкновения с Прогрессом M-34 в 1997-м.

Эта история напомнила мне знаменитый скрипт установки драйверов для видеокарты, который уничтожал Linux-системы. Измученный разработчик библиотеки, работавший ночью, упустил всего один пробел:

 # GIANT BUG... causing /usr to be deleted... so sorry....
- rm -rf /usr /lib/nvidia-current/xorg/xorg
+ rm -rf /usr/lib/nvidia-current/xorg/xorg

Люди ошибаются. Предпочитайте автоматизацию. Машины должны страдать!

Я следую правилу: если дважды видишь в своём исходном коде одну и ту же ошибку, то лучше сделать автоматизированный инструмент, который сможет предотвратить эту ошибку в будущем.

Линтеры исходного кода (вроде ESLint для JavaScript и Stylelint для CSS) очень хорошо находят ошибки, которые могут стоить вам много времени и денег. Вы потратите несколько часов на написание своего плагина для линтеров, но в долгосрочной перспективе это окупится.

Хотите избегать опечаток в документации? Попробуйте yaspeller. Хотите организовать свойства в CSS в каком-то порядке? Добавьте в инструменты разработки stylelint-order.

* * *

Надеюсь, вам понравились мои космические истории. Даже если они показались вам притянутыми за уши, извлечённые уроки остаются полезными для всех разработчиков ПО.

История освоения космоса не только вдохновение для моих рассказов на конференциях и афте-пати, но и служит источником правильных методик. Что лучше напомнит о необходимости отправить отчёт о проблеме, чем горящий космический корабль?
Mail.ru Group
Строим Интернет

Комментарии 29

    +16

    А меня есть тоже пара уроков, вынесенных из аварий в космосе и в самолетостроении. Данные уроки больше для разработчиков электроники, а не только софта:


    • Всегда имей "Черный ящик" — т.е. еще до того, как система или устройство разработано и запущено, предусмотри систему сбора данных на случай сбоев или отказов для возможности пост-анализа. Пусть это будет простой лог файл или буффер — но обязательно предусмотри. Не рассчитывай, что тебе кто-то расскажет, как все было. Когда твое устройство накроется, а ты не будешь знать почему — это поможет.


    • Это тоже из космоса: Никогда не пытайся решить проблему (или фиксить баг) на обум, т.е. пока ты не докопаешься до причины. Потрать 1-2-3 дня на выяснение, даже если ты уверен, что решение займет минуты.
      Слишком часто я видел уверенных программистов, которые смотрят на проблему и говорят мне:
      — А, я догадываюсь в чем проблема, счас пофиксю за 5 минут.



    Прихожу на следующий день:
    — Пофиксил?
    — Нет, не сработало, счас работаю над вторым вариантом
    — Сколько времени надо?
    — Да, не больше 5 минут.


    На следующий день:
    — Пофиксил?
    — Нет. Этот вариант тоже не сработал, но у меня есть…
    — Стоп! Теперь предлагаю я. Что ты сделал, чтобы лучше диагностировать дефект? Ты пробовал его воспроизвести в этой ситуации?
    — Нет.
    — А в этой?
    — Нет, это займет 5 часов на написание теста, а у нас нет времени…
    — Да, но я знаю, что через 5 часов мы будем знать больше о дефекте, чем до этого. Поэтому делай. И я даю тебе еще целый день на то, чтобы ты добавил отладочные порты, а не жду от тебя фикс..


    В итоге ошибка была в совершенно другом месте, чем думал программист...

      +6
      Как же приятно было читать этот комент! Мне уже казалось что я один так считаю. За 10 лет опыта в разработке электроники, я работал всего в одной конторе(из 5), которая вываливала максимум диагностической информации и на это выделялось отдельное время. У всех остальных нет времени на то, чтобы это сделать. и потом тратятся месяцы, на то, что можно было бы пофиксить за часы, если бы предварительно было заложена неделя на добавление хоть какого-то логирования.
      На каждом митинге, где я упоминал про необходимость логов, на меня смотрели как на фрика и крутили пальцем у виска, «да какие логи! на это нету времени! просто не будь рукожопом!» и другие сказки о мифических единорогах-ниженерах, которые делают всё с первого раза и никогда не ошибаются.
        0
        Ну я тоже всегда так делаю. Но я-то как раз по первому образованию — инженер-ракетчик :-)
      +5
      ни НАСА не знали об испытании

      Это вы, простите, гоните. Майкл Фолл был командиром экипажа. Не знать, что происходит на станции он не мог.

        +2
        Это в шестом своём полёте, на МКС в 2003 году, он был командиром экипажа.
        А в 1997 — бортинженер-2 на Мире.
          +1

          Действительно. Что-то я напутал.

      • НЛО прилетело и опубликовало эту надпись здесь
        +2
        Ещё одно правило, почерпнутое «из космоса» — когда работаешь на удалённой системе и вносишь изменения в конфиги, продумай автоматический откат к текущему состоянию в случае, если что-то пойдёт не так
          +1

          И всегда имей реплику удаленной системы под рукой, на которой тестируешь все изменения таким же образом, как это сделал бы на удаленной.

            +4

            Только не забывай её выключать, когда работаешь с удалённой. А то при попытке связи с "Луной-3" ответы имитатора из соседнего здания приняли. Хорошо, время было, и успели его выключить.

              0

              не зря одно из правил админа: через терминал удаленного доступа все сервера кажутся одинаковыми

                +4
                Вот прямо рекомендую цветовую маркировку. В настройках терминала поменять черный дефолтный цвет фона на какой-нибудь другой. И к этому еще расположение терминалов на рабочих столах: на первом столе — боевые сервера, на втором — тестовые, и т.д. Банально, требует некоторой дисциплины — но помогает!
                  +2
                  +100.
                  Как-то раз по-ошибке набрал halt не на локальной машине, а в консоли, подключенной по ssh к удалённому контроллеру.

                  Пришлось ехать на другой конец города, включать.
                    +1

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

                      +1
                      А тут уже, кажется, кашу маслом не испортишь! :-) И в баше цвет, и имя хоста в заголовок окна. И строгая рекомендация иметь открытым только один прод (хочешь другой — закрой тот, открой этот — или хотя бы сверни!). Разные названия БД у разных клиентов. Рекомендация не цепляться к проду через pgadmin, а только через psql (так фон будет разный, а pgadmin везде одинаковый). Но общий смысл один — увеличить дистанцию (цветовую, пространственную, временную) между окнами в разные серверы. А то да, страшновато…
              0
              И не запускать там обновление системы пока там работает архивация.
                +1
                из примет:
                удаленно настраивать фаервол - к дальней дороге.
                +1
                Очень любопытные параллели — спасибо за нестандартный подход.
                  0
                  Спасибо, очень интересно. Из космического добавлю «Фобос»: ни когда не ленись прогнать программу с изменениями на стенде-имитаторе, какими бы ни банальными они ни казались.
                    0
                    Измученный разработчик библиотеки, работавший ночью, пропустил всего один пробел

                    Чего стоило этого бедному разработчику!
                      +4

                      Дожили, уже Ситника переводят. Между прочем, есть оригинальное выступление Андрея:


                        +3
                        Интересно, что Волынов после такого фактически падения смог восстановится и добиться возвращение в отряд космонавтов. И даже полетел в космос ещё раз.
                          +4
                          Лучше пока статью не читать — много фактических ошибок в переводе, которые меняют смысл (переводчик не связывался со мной, как автором для вычитки). Сейчас отправлю список ошибок автору.
                            +1

                            «Люди, ЗНАВШИЕ меня лично»

                              0
                              Они слишком много знали
                              +1
                              Перевод исправили — теперь всё ОК
                              +3

                              Книга Чертока Ракеты и люди очень информативна в этом плане. Как они ракеты испытывали. А еще мемуары Грабина. Про испытания пушек

                                +6
                                Каждый раз, сталкиваясь с проблемой, связанной с библиотекой или инструментом для разработки, я вспоминаю Бориса Волынова. Если он смог сообщать о проблемах даже на пороге смерти, то я точно смогу выделить несколько минут, чтобы отправить отчёт разработчику.


                                Я сомневаюсь, что багрепорт Бориса Волынова висел в трекере годами в состоянии unassigned или merge request от конструкторов висел необработанным месяцы и годы

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое