Ваш production-сайт только что упал. Как вы будете действовать?

Question

Accepted Answer

Главный приоритет — **восстановить сервис, а потом искать причину**: митигация идёт раньше диагностики. Я бы объявил incident, распределил чёткие роли и вёл команду к быстрейшему безопасному восстановлению, постоянно коммуницируя по ходу.

## Сначала стабилизировать

- **Объявить incident** и открыть единый канал (war room / тред в Slack), чтобы координация не была разрозненной.
- **Распределить роли**: **Incident Commander** принимает решения, **ответственный за коммуникацию** обновляет stakeholders, а **responders** ведут расследование. Как Tech Lead я часто беру на себя IC, чтобы инженеры могли сосредоточиться на проблеме.
- **Тянуться к самому быстрому обратимому исправлению.** Если deploy коррелирует с падением, сначала делайте **rollback**, а вопросы задавайте потом — восстановить пользователей важнее, чем быть правым.

## Диагностировать параллельно

- Проверить **очевидные сигналы**: дашборды, частоту ошибок, недавние deploy, изменения инфраструктуры, всплески трафика, истёкшие сертификаты.
- Сформировать гипотезу, проверить сначала самую дешёвую и **не менять пять вещей сразу** — иначе не узнаете, что сработало.

## Коммуницировать непрерывно

Молчание порождает панику. Я отправляю обновления в ровном ритме, даже когда новостей нет:

```
[14:05] Расследуем — checkout не работает, затронуто ~40% пользователей. Следующее обновление в 14:20.
[14:20] Установлено: плохой deploy. Делаем rollback. ETA 10 мин.
[14:35] Сервис восстановлен. Наблюдаем. Postmortem последует.
```

## После восстановления

- Подтвердить полное восстановление, а не просто «стало лучше».
- Провести **blameless postmortem** в течение нескольких дней: таймлайн, корневая причина, что замедлило обнаружение/исправление, и **конкретные action items с ответственными**.
- Результат — системное улучшение (лучшие alerts, защитные ограждения, автоматизация rollback), а не имя для обвинения.

## Подводные камни

- **Дебаг до митигации**, пока страдают пользователи.
- **Нет единого принимающего решения**, и пятеро гадают параллельно.
- **Уход в молчание** со stakeholders.
- **Обвинение конкретных людей**, что убивает честность, на которой держатся будущие incidents.

## Почему это важно

Outages неизбежны; то, как вы их проживаете, определяет доверие команды и уверенность клиентов. Спокойная координация по ролям плюс blameless-разбор превращают плохой день в более крепкую систему — и сигнализируют инженерам, что двигаться быстро безопасно, потому что сбой обрабатывается как процесс, а не как охота на ведьм.