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

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

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

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

В команде до 5 человек обычно выделяют IC и Technical lead, а остальные роли берёт на себя 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 как вариант по умолчанию

При 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 on-call
• Всегда primary + secondary on-call. Secondary берёт на себя, когда primary не реагирует в течение 5 мин.
• Компенсируйте ночной и выходной 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.

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