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 під час SEV1 щонайменше кожні 30 хвилин, навіть якщо немає нової інформації. «Все ще розслідуємо, 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.

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