Как своими руками создать катастрофу

Уже посмотрели мини-сериал Чернобыль от HBO?

Кроме художественной ценности, в нем много интересных деталей. Например, это отличная иллюстрация взаимодействия между главным инженером проекта Легасовым и менеджером Щербиной.  Ну и, конечно же, безопасником - первым замом председателя КГБ.

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

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

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

Как это происходит:

1. Сначала появляются незначительные отклонения, которые остаются без реакции;
2. Затем происходит синергия этих, казалось бы некритичных, отклонений;
3. И в итоге происходит полная потеря контроля над ситуацией

У меня есть один интересный пример на эту тему. 

Однажды мы с командой, назовем ее условно "А", готовили продукт к приемо-сдаточным испытаниям заказчика. При этом действовало правило, что катить обновления на сервер заказчика можно только в технологические окна, в остальное время действовал мораторий. Дальше события развивались следующим:

1. Команда "А" согласовала для себя внеплановое технологическое окно в день перед испытаниями. Причина проста - для прохождения тестов обязательно нужно выкатить дополнительные изменения в продукте.
2. О внеплановом окне узнала команда, назовем ее условно "В". Им необходимо было залить на сервер изменения для следующего этапа приемки. Они тоже получили согласование, но возник один ньюанс: накатить свои изменения они могли только вечером.
3. Слухи множились. О внеплановом окне узнала команда, назовем ее условно "C". Она решила выпустить одну "залежавшуюся" техническую фичу, хотя в рамках испытаний она вообще не требовалась. И ей тоже удалось получить согласование, несмотря на резко возрастающие риски. Заодно добавился еще один ньюанс: накатывать они могли только в ночь перед испытаниями (т.е. буквально за пару часов до начала испытаний). 
4. Ах да, я не упомянул, что перед деплоем команды не могли проверить совместную работу своих новых фич из-за отсутствия настроенного общего тестового сервера. Вопрос с его настройкой затянулся, и во время испытаний работы еще не были завершены.

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

Внимание, черный ящик синергия: 

1. Команда "А" провела весь день в ожидании, когда можно будет приступить к накату своих изменений.
2. Работы начались вечером, "А" и "B" выкатились, но отладка и повторные деплои затянулись до глубокой ночи (напомню, что уже утром должны были начаться испытания с заказчиком).
3. Уже практически под утро выкатилась команда "С". Выкатилась так, что в функционал команды "А" (тот самый, который через несколько часов нужно было показывать заказчику), перестал работать на сервере. Перестал от слова совсем. 
4. Выяснилось, что те, кто может отладить систему или вернуть все в исходное состояние, уже или еще недоступны из-за позднего или раннего времени (тут с какой стороны посмотреть). 

К счастью для компании, проблему удалось решить практически перед стартом испытаний (привет американским фильмам про разминирование бомб), работоспособность сервиса была восстановлена, испытания пройдены. Благодаря стечению обстоятельств, команды отделались бессонной ночью и легкой сединой. Но этот пример наглядно показал, что бывает, если пренебрегать отклонениями и не работать с рисками.

Что же с этим делать?

1. Постоянно мониторить процессы и выявлять даже незначительные отклонения.
2. Устранять отклонения. Причем не только симптомы, но их причины (привет, Теория ограничений), 
3. Оценивать риски, не надеяться исключительно на положительные сценарии.
4. Ну, и, конечно, учитывать негативные сценарии и быть готовым оперативно на них реагировать.