Инциденты и SRE-плейбуки

1) Что такое инцидент и как он соотносится со SLO

Инцидент — событие, нарушающее SLO/служебную функцию или создающее риск нарушения (ошибочный бюджет прожигается неприемлемо быстро).
Классические метрики: MTTD, MTTA, MTTR, MTBF.
Ошибка бюджета и burn-rate определяют приоритет и окна эскалаций.

2) Уровни серьезности (SEV) и критерии

Триггеры SEV: превышение 5xx%, p95>порога, платежные decline spike, Kafka-lag>порог, NodeNotReady>Х мин, 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/ошибочный бюджет и постоянно улучшайте детекторы и плейбуки — это напрямую снижает риски и стоимость простоев.