Як перетворити інцидент на короткий runbook

Нічний дзвінок і вісім хвилин, які не можна втратити

У 02:13 на чат заходить черговий після короткого дзвінка від on-call менеджера: API видає 500, користувачі скаржаться на затримки, а у логах вже видно багато POST /orders помилок. Замість довгого RCA, перш ніж щось ламати назад, черговий має зафіксувати мінімум контексту. Саме тут і народжується runbook після інциденту — короткий, точний, без «суперкомандирських» висновків.

Інцидент уже дав стрес, але runbook не про героїзм. Він про те, щоб через 2 години інженер, який не був на чергуванні, зрозумів: що сталося, як ми це побачили, що перевіряли, чому зупинилися на певних діях, і що далі робити без додаткових припущень.

Починай з готового каркасу: Symptom Snapshot

Ніяких відступів. Перші 90 секунд — один блок:

• Заголовок інциденту: інцидент-платіжний-API-2026-...
• Час виявлення, перший симптом, рівень впливу.
• Які сервіси у фокусі: API, БД, черга, кеш.
• Хто постраждав: внутрішні користувачі, публічний API, CI.
• Що вже зроблено: рестарт, ручне масштабування, mute алертів (якщо було).

У прикладі вище: головний симптом — збільшення 500 і час відповіді, другий — накопичення повідомлень у черзі, третій — збій webhook retry. Уже цього достатньо, щоб людина з іншої зміни продовжила роботу.

Verification: рівно три перевірки, які треба мати в кожному runbook

Перевірка має бути конкретною і відтворюваною.

1. Перевірка здоров’я основного шляху

• Команда: kubectl get pods -n prod -l app=api-gateway або systemctl status ....
• Очікувано: не більше 1 нездорового події, або список відомих restart-ів з часу інциденту.
• Факт у runbook: кількість restart-ів, перший падіння подібних метрик.

2. Перевірка залежностей і черги

• Команда: curl -sf https://.../healthz або перевірка статусу БД/кешу.
• Очікувано: downstream не повертає 5xx, черга не росте без обмеження.
• Факт: точні значення latency, depth queue, відсоток помилок.

3. Перевірка користувацького впливу

• Команда: пошук останніх звернень у support channel або моніторингові алерти.
• Очікувано: підтвердження кількості уражених flows.
• Факт: які частини сервісу реально «червоні», а що було шумом від моніторингу.

Тимчасова стабілізація перед відновленням

Власник інциденту призначає дію, яка зменшує шкоду до очищення причини:

• Перевести трафік на стабільний шлях (або вимкнути шумний фіч-флаг).
• Припинити агресивні автоматичні ретраї, якщо вони розганяють деградацію.
• Заблокувати шумні перезапуски, які не дають системі стабілізуватися.

Не плутайте тимчасову стабілізацію з остаточним рішенням. Тут мета — зменшити шкоду і зберегти стан для відновлення.

Recovery: відновлення без повторного запуску хаосу

Коли контроль стабілізовано, плануйте відновлення в двох рівнях:

• Невеликий rollback до останнього стабільного стану, якщо зміни явно свіжі й сумнівні.
• Або точкова міграція назад без зворотного запуску всього стека, якщо проблема у новому конфігураційному значенні.

Важливо: у кожному кроці прописати, хто перевіряє успіх і через який інструмент. Без цього отримаємо «відкотили — щось стало краще, але чому невідомо».

Communication та owners: як вивести шум у структуру

Найчастіша помилка — спочатку гасити, потім пояснювати. Додавайте в runbook чітко:

• Власник інциденту.
• Хто підтверджує перевірки.
• Кому надсилаються оновлення (канал, чат, менеджер, клієнтський канал).
• Який статус на момент звіту: “ще триває”, “стабілізовано”, “відновлено”.

Що часто забувають

• Тимчасові симптоми замінюють на гіпотези.
• Не пишуть, хто саме запускав rollback.
• Змішують факт із припущенням: “ймовірно” не дорівнює доказ.
• Не фіксують таймлайн, а потім годинами сперечаються за порядок подій.
• Немає блоку про те, що не перевірялося.

Коли короткий runbook не потрібен

Не треба застосовувати цю схему до:

• Локальних проблем у дев-середовищі без впливу на користувачів.
• Малих випадкових збою, де причина очевидна за 1–2 команди та вже виправлена.
• Довготривалих інженерних RCA, що потребують глибокої дискусії — там потрібен окремий повний аналіз, а цей каркас можна згенерувати як стартову нотатку.

Перші 3 дії завтра

• Додайте шаблон runbook у каналі чергування з обов’язковими 3 перевірками.
• Після будь-якого rollback додайте обов’язкову секцію “що не перевірено”.
• Передавайте чергу так: “симптоми -> перевірки -> стабілізація -> відновлення -> власник”.

Джерела

• https://www.atlassian.com/incident-management/incident-management
• https://sre.google/sre-book/table-of-contents/
• https://www.pagerduty.com/resources/learn/incident-response/
• https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/