Інциденти і SRE-плейбуки

1) Що таке інцидент і як він співвідноситься з SLO

Інцидент - подія, що порушує SLO/службову функцію або створює ризик порушення (помилковий бюджет пропалюється неприйнятно швидко).
Класичні метрики: MTTD, MTTA, MTTR, MTBF.
Помилка бюджету і burn-rate визначають пріоритет і вікна ескалацій.

2) Рівні серйозності (SEV) і критерії

Тригери SEV: перевищення 5xx%, р95> порогу, платіжні decline spike, Kafka-lag> поріг, NodeNotReady> X хв, TLS закінчується <7 днів, сигнали DDoS/витік.

3) Ролі та відповідальність (RACI)

Incident Commander (IC) - одноосібне прийняття рішень, менеджмент потоку завдань, зміна статусу SEV.
Ops Lead (Tech Lead) - технічна стратегія, гіпотези, координація фіксів.
Communications Lead (Comms) - статус-апдейти (внутрішні/зовнішні), StatusPage/чат/пошта.
Scribe (Хроніст) - таймлайн, рішення, артефакти, посилання на графіки/логи.
On-call Engineers/SMEs - виконання дій з плейбуків.
Security/Privacy - включаються при інцидентах безпеки або PII.
FinOps/Payments - при впливі на білінг/PSP/вартість.

4) Життєвий цикл інциденту

1. Детект (алерт/репорт/синтетика) → авто-створення картки інциденту.
2. Тріаж (IC призначений, SEV привласнений, збір мінімального контексту).
3. Стабілізація (mitigation: вимкнути фічу/роллбек/rate-limit/failover).
4. Розслідування (RCA-гіпотези, збір фактів).
5. Відновлення сервісу (validate SLO, спостереження).
6. Комунікація (всередині/зовні, підсумковий звіт).
7. Постмортем (без звинувачень, CAPA-план, власники, терміни).
8. Prevention (тести/алерти/плейбуки/прапори, довчення команди).

5) Комунікації та «war-room»

Єдиний канал інциденту ('#inc -sev1-YYYYMMDD-hhmm'), тільки факти і дії.
Команди в стилі радіо-протоколу: «IC: призначаю rollback версії 1. 24 → ETA 10 хв".
Статус-апдейти: SEV-1 кожні 15 хв, SEV-2 - кожні 30-60 хв.
Status Page/зовнішня комунікація - через Comms Lead за шаблоном.
Заборонено: паралельні «тихі» кімнати, неперевірені гіпотези в загальний канал.

6) Алертинг і SLO-burn (приклад правил)

Швидкий канал (1-5 хв) і повільний канал (1-2 год) burn-rate.
Мульти-сигнали: помилка бюджету, 5xx%, p95, Kafka-lag, платіжні decline-rate, синтетика.
Пошук першопричини - тільки після стабілізації симптомів.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Плейбуки vs ранбуки

Плейбук - сценарій дій за типом інциденту (розгалуження, умови, ризики).
Ранбук - конкретна «карта» кроків/команд (перевірки, фікси, верифікація).
Правило: плейбук посилається на кілька ранбуків (rollbacks, feature-flags, failover, масштабування, блокування трафіку і т.д.).

8) Шаблон картки інциденту

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) Шаблон SRE-плейбука (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Типові плейбуки

10. 1 API 5xx Spike

Стабілізація: відключити проблемний фічефлаг; підвищити репліки API; увімкнути кешування; відкат релізу.
Діагностика: diff релізу, помилки в логах (top-exceptions), зростання p95, pressure БД/кеша.
Ризики: каскад у платежах/бекендах.

10. 2 БД: replication lag / lock storm

Стабілізація: призупинення важких джобів/репортів; перенаправити читання на майстер; збільшити wal_buffers/реплика-слоты.
Діагностика: довгі транзакції, блокуючі запити, зміни плану.
Фіксація: індекси/хінти, перепланування джобів, розбиття запитів.

10. 3 Kafka consumer lag

Стабілізація: тимчасово масштабувати consumer'и; знизити продюсинг з не-критичних сервісів; збільшити партії/квоти.
Діагностика: rebalances, повільні десеріалізації, GC-паузи.
Верифікація: лаг → до цільового значення, немає дропів.

10. 4 K8s NodeNotReady/ресурсний шторм

Стабілізація: cordon+drain; перерозподілити навантаження; перевірити CNI/overlay; вимкнути гучні DaemonSet'и.
Діагностика: disk pressure, OOM, throttling, network drops.
Профілактика: pod disruption budgets, ресурсні ліміти/requests.

10. 5 TLS/сертифікати закінчуються

Стабілізація: примусове оновлення секрету/ingress; тимчасові override.
Діагностика: ланцюжок довіри, clock-skew.
Профілактика: альберти T-30/T-7/T-1, авто-реньюал.

10. 6 DDoS/аномальний трафік

Стабілізація: WAF/бот-правила, rate-limit/geo-фільтри, upstream shed load.
Діагностика: профілі атаки (L3/4/7), джерела, «парасольки».
Профілактика: anycast, autoscaling, кешування, play-nice з провайдерами.

10. 7 Платіжний PSP-аутейдж

Стабілізація: smart-routing на альтернативні PSP/методи; підняти retry з джиттером; «м'яка» деградація UI.
Діагностика: spike відмов за кодами, статуси API/статус-сторінки PSP.
Комунікації: прозорі апдейти для бізнесу і саппорту, коректна статистика ND/конверсії.

10. 8 Інцидент безпеки/витік PII

Стабілізація: ізоляція вузлів/секрет-ротація, блокування ексфільтрації, Legal Hold.
Діагностика: таймлайн доступу, порушені суб'єкти/поля.
Сповіщення: регулятори/партнери/користувачі за вимогами юрисдикцій.
Профілактика: посилення DLP/сегментації, «least privilege».

11) Автоматизація плейбуків

ChatOps команди: `/ic set sev 1`, `/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-боти: напів-автоматичні кроки (drain node, flip traffic, purge cache).
Self-healing хуки: детектор → стандартний mitigation (rate-limit, restart, scale).
Авто-створення карток/таймлайну з алертів і команд.

12) Якість плейбуків: чек-лист

• Ясні симптоми і детектори (метрики/логи/траси).
• Швидкі кроки стабілізації з оцінкою ризику.
• Команди/скрипти актуальні, перевірені в staging.
• Верифікація відновлення SLO.
• Комунікаційні шаблони та критерії зовнішніх апдейтів.
• Постмортем-посилання і CAPA після закриття.

13) Постмортем (blameless) і CAPA

Мета: навчитися, а не знайти винного.
Зміст: що сталося, як виявили, що було добре/погано, внесок факторів (тих + процеси), дії для запобігання.
Термін: SEV-1 - протягом 48 годин; SEV-2 - 3 робочих дні.
CAPA: конкретні власники, терміни, вимірювані ефекти (зниження MTTR/зростання MTTD).

14) Правові аспекти та доказова база

Legal Hold: заморожування логів/трас/алертів, write-once сховища.
Ланцюжок зберігання артефактів: доступи за ролями, контроль цілісності.
Регуляторні повідомлення: терміни/шаблони для юрисдикцій (особливо при порушених платежах/PII).
Приватність: мінімізація та маскування PII при розборі.

15) Метрики ефективності процесу інцидентів

MTTD/MTTA/MTTR по кварталах і доменах.
Правильність SEV (underrating/overrating).
Частка інцидентів з авто-мітігейтом.
Покриття плейбуками топ-N сценаріїв (> 90%).
Виконання CAPA вчасно.

16) Впровадження за етапами

1. Тиждень 1: SEV-матриця, ролі on-call, загальний шаблон картки, war-room регламент.
2. Тиждень 2: Плейбуки для топ-5 симптомів (5xx, БД-лаг, Kafka-lag, NodeNotReady, TLS).
3. Тиждень 3: ChatOps/боти, авто-створення карток, шаблони комунікацій/StatusPage.
4. Тиждень 4 +: Плейбуки безпеки, PSP-аутейджі, Legal Hold, регулярні дрилі/ігри хаосу.

17) Приклади «швидких» ранбуків (фрагменти)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (приклад)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Міні-FAQ

Коли піднімати SEV-1?
Коли страждає ключове SLO/бізнес-функція (платежі, логін, гра), і burn-rate «з'їдає» бюджет на годинник вперед.

Що важливіше - RCA або відновлення?
Завжди стабілізація, потім RCA. Час до стабілізації - головний показник.

Чи потрібно все автоматизувати?
Автоматизуйте часті та безпечні кроки; рідкісні/ризикові - через напів-авто і підтвердження IC.

Підсумок

Надійний процес інцидентів тримається на трьох стовпах: чіткі ролі та SEV-правила, якісні плейбуки/ранбуки з автоматизацією та культура постмортемів без звинувачень. Зафіксуйте шаблони, тренуйте on-call, вимірюйте MTTR/помилковий бюджет і постійно покращуйте детектори і плейбуки - це безпосередньо знижує ризики і вартість простоїв.