Incident response playbook для малых и средних команд

Кратко: Когда в пятницу в 23:30 падает production сервер, не время выдумывать процедуру с нуля. Incident response playbook - документ, который определяет роли, коммуникацию и процедуры до того, как они вам понадобятся. Здесь минимальный playbook, подходящий для команды 5-20 человек.

Роли во время инцидента

Чёткие роли устраняют хаос. Даже маленькой команде нужен минимум:

• Incident Commander (IC) - управляет инцидентом, принимает решения, эскалирует. Не пишет код.
• Technical lead - человек, знающий проблемную область. Пишет fix.
• Communications lead - обновляет status page, клиентов, менеджмент. Для маленькой команды может быть тем же, что IC.
• Scribe - пишет timeline, кто что делает, когда. Ключевое для post-mortem.

В команде до 5 человек типично IC + Technical lead = 2 роли разделены, остальные берёт IC.

Severity уровни

Определите 3-4 уровня серьёзности заранее:

• SEV1 (Critical) - основной сервис полностью недоступен. Реагируют немедленно, paging даже ночью.
• SEV2 (Major) - значительная деградация (часть фичей, некоторые пользователи). Реакция в течение 30 мин в рабочее время, 1 ч вне.
• SEV3 (Minor) - маленькое влияние, workaround существует. Реакция к следующему рабочему дню.
• SEV4 (Cosmetic) - без user-facing влияния, идёт в обычную queue.

Процедура SEV1: первые 15 минут

1. 00:00 - Детектирование. Alert приходит от мониторинга или от клиента. Кто-то на on-call ротации подтверждает, что проблема реальна.
2. 00:02 - Активация IC. Открывается выделенный канал коммуникации (Slack #incident-N или Discord). Вызывают Technical lead.
3. 00:05 - Первый status update. На публичной status page: «Investigating reports of [проблема].» Email внутренним людям, которые должны знать.
4. 00:10 - Initial diagnostics. Проверьте недавние деплои, графики мониторинга, error логи. Что изменилось за последние 30-60 мин?
5. 00:15 - Решение: rollback, hotfix или workaround? Если не сразу ясно, IC эскалирует или зовёт других инженеров.

Коммуникация: правило «5 + 30»

Обновление status page минимум каждые 30 минут во время SEV1, даже если нет новой инфы. «Всё ещё расследуем, ETA пока неизвестен» - лучший update, чем тишина - клиенты хотя бы знают, что кто-то работает над проблемой.

Первый update должен быть в течение 5 минут от детектирования. Независимо от того, знаете ли вы причину.

Rollback как default

При SEV1, начавшемся вскоре после деплоя, rollback - первый выбор, не hotfix. Hotfix под давлением ночью - источник дальнейших багов. Rollback восстанавливает известное хорошее состояние и даёт время на спокойную диагностику утром.

Для rollback необходимо иметь:

• Версионирование развёртывания (Docker tags, Git tags, deployment артефакт)
• Database migrations backwards compatible (если новая версия дропает столбец, старая не восстановит)
• Документированную rollback процедуру (команды, сколько занимает, кто может запустить)

Post-mortem в течение 48 часов

После каждого SEV1/SEV2 инцидента напишите документ со структурой:

1. Summary - 2-3 предложения что случилось, сколько длилось, кого затронуло
2. Timeline - точные времена детектирования, ключевых действий, разрешения
3. Root cause - почему это случилось (техническая причина + процедурная причина)
4. Impact - количество затронутых клиентов, business impact
5. What went well - что мы сделали хорошо (оценить команду)
6. What went wrong - где мы потеряли время
7. Action items - конкретные задачи с owner и deadline (не «тестировать лучше» - лучше «добавить integration test для payment flow в течение 14 дней, owner: X»)

Правило blameless post-mortem: Не ищете виновника, ищете системную слабость. «John задеплоил плохую версию» - неправильный вывод - правильный «процесс деплоя не содержал canary фазу, которая поймала бы баг до полного rollout».

On-call ротация

Для команды с 24/7 продуктом:

• Недельные ротации - короче выгорает, длиннее означает непрерывность контекста
• Всегда primary + secondary on-call. Secondary перенимает, когда primary не реагирует за 5 мин.
• Компенсация (экстра оплата, time-off) за ночной и выходной paging
• Месячный «on-call review» - кого часто будили, что можно автоматизировать

Инструменты

• Monitoring (ePulz.io, Datadog, New Relic) - детектирование + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - эскалация, ротация, SMS/голос
• Status page (собственная, ePulz.io, StatusPage.io) - внешняя коммуникация
• Хостинг runbook (Notion, GitHub Wiki, internal docs) - playbooks и runbooks
• Шаблон postmortem (Confluence, Notion template) - стандартизация

Вывод

Incident response нельзя импровизировать под давлением. 30 минут, инвестированных в написание playbook, окупаются при первом более крупном сбое - меньше хаоса, короче MTTR, лучшая коммуникация с клиентами и команда, которая знает что делать.

Начните с автоматического детектирования

ePulz.io решает первые минуты incident response: детектирование + alerting через e-mail, Telegram и webhook в Slack / Discord / PagerDuty.

Запустить мониторинг →