Первые 30 минут после падения: план, который пишут заранее

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

Без заранее принятых решений первые тридцать минут выглядят одинаково в любой компании. Руководитель каждые две минуты спрашивает у технического директора, что происходит, — и тот тратит на ответы то время, которое мог потратить на восстановление. Маркетинг продолжает откручивать оплаченный трафик на неработающий сайт. Поддержка молчит, потому что не знает, что говорить, и клиенты узнают новости из социальных сетей раньше, чем от компании. Инженеры в чате выясняют, чей коммит виноват, вместо того чтобы откатить релиз.

Всё это — устранимые потери. Регламент реагирования стоит несравнимо дешевле резервной площадки, а в момент аварии экономит сопоставимое время.

Четыре решения, которые принимаются заранее

1. Кто руководит и кто чинит — это разные люди

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

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

Хронология событий — не бюрократия. Через два дня никто не вспомнит, в какой момент перезапустили сервис и когда именно вернулись метрики, а без этого разбор аварии превращается в обмен впечатлениями.

2. Что и когда мы говорим клиентам

Решение о том, при каком пороге компания сообщает о проблеме публично, принимается заранее и не обсуждается в момент аварии. Например: простой критичной функции дольше десяти минут — публикуем сообщение.

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

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

Честное и своевременное сообщение заметно снижает нагрузку на поддержку и число разгневанных обращений — не потому, что клиенты становятся терпимее, а потому, что молчание они трактуют как безразличие.

3. Где лежат аварийные доступы и инструкции

Классический тупик: сервер авторизации недоступен, пароль от резервной площадки хранится в корпоративном мессенджере, а мессенджер развёрнут на той же инфраструктуре.

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

Проверяется это одним вопросом: если сейчас отключится всё разом, с какого устройства и по какой инструкции начинает действовать дежурный?

4. Откат важнее починки

Самая частая ошибка при аварии — искать причину и исправлять её на работающей продуктивной системе. Так простой растягивается с десяти минут на несколько часов.

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

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

Разбор без поиска виновных

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

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

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

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

Как это выглядит на бумаге

Регламент на сорок страниц в момент аварии не откроет никто. Работает одностраничный документ, доступный без основной инфраструктуры:

• Кто координатор инцидента и кто его замещает.
• Порог, при котором объявляется инцидент.
• Запасной канал связи.
• Где лежат аварийные доступы.
• Правило отката и кто принимает решение.
• Кто и по какому шаблону сообщает клиентам.
• Куда пишется хронология.

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

Если нужно составить такой регламент под вашу команду и проверить его на практике — напишите.