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.

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