Когда всё лежит: простой план действий при аварии

Авария в маленькой команде обычно выглядит так. Кто-то замечает, что сайт не открывается, пишет в общий чат. Трое одновременно лезут на сервер, один перезапускает базу, пока другой смотрит в неё логи. Клиенты пишут в поддержку, поддержка не знает, что отвечать. Через час всё работает, и никто толком не может сказать, что это было.

Это не от непрофессионализма, а от того, что в стрессе люди действуют по привычке, а привычки на такой случай нет. План на одну страницу, написанный в спокойный день, эту привычку заменяет.

Что написать заранее

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

Роли

Даже если вас двое, роли стоит разделить:

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

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

Порядок действий

Объявить аварию и открыть канал. Ведущий записывает время.
Понять масштаб: что не работает, у всех или у части, с какого момента.
Стабилизировать, а не искать причину. Если что-то выкатывали недавно — откатить. Если есть флаг у новой функции — выключить. Если не хватает ресурсов — добавить. Причину можно найти потом, на работающей системе.
Вести хронологию в канале: что заметили, что попробовали, что изменилось. Через неделю это единственный надёжный источник.
Сообщать пользователям через равные промежутки, даже если новостей нет.
Убедиться, что всё действительно восстановилось, и только потом закрыть аварию.

Как писать пользователям

Молчание во время аварии люди заполняют сами, и обычно худшим вариантом. Короткое сообщение сразу лучше подробного через час. В нём три вещи: что не работает, что работает и когда будет следующее обновление.

Сейчас не проходит оплата подписки. Вход и работа с проектами
доступны, данные в безопасности. Разбираемся, следующее
обновление — в 15:30.

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

Разбор без виноватых

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

В записи разбора:

что произошло и сколько это длилось;
кого затронуло и как;
хронология по записям из канала;
что помогло и что мешало;
два-три действия с ответственными и сроками.

Последний пункт важнее остальных. Длинный список улучшений, из которых не сделано ни одного, хуже короткого, выполненного полностью.

Учения

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

SUBXCAT может помочь написать такой план под твой продукт и провести первые учения вместе с командой.