Управление инцидентами

(Раздел: Технологии и Инфраструктура)

Краткое резюме

Управление инцидентами — это повторяемый процесс быстрого восстановления пользовательской ценности и минимизации ущерба бизнесу. Опора — четкие роли (Incident Manager, Tech Lead, Comms), SLO-гейты, эскалации, ChatOps-процессы, подготовленные рунабуки и «безобвинные» пост-инцидентные разборы с измеримыми action items.

1) Цели и принципы

Скорость и безопасность: быстрый диагноз → безопасная стабилизация → устойчивое восстановление.
Единственный владелец: назначенный Incident Manager (IM) принимает процессные решения.
Коммуникации как продукт: предсказуемые апдейты для стейкхолдеров и пользователей.
Данные > мнения: SLO/метрики/трейсы/логи — источник правды.
Blameless: разбор причин без персональных обвинений; фокус на системных улучшениях.

2) Классификация инцидентов (Severity / Impact / Urgency)

• SEV1 (критический): серьезный ущерб выручке/TTW/платежам, >20% пользователей или целые регионы; SLA нарушен/угроза PII.
• SEV2 (высокий): частичная деградация ключевых потоков (депозит/ставка/запуск игр), влияние 5–20%.
• SEV3 (средний): заметная деградация вторичных сервисов, обход есть.
• SEV4 (низкий): минор, ограниченный эффект, без влияния на SLO/SLA.

Impact: кто затронут (все/регион/тенант/канал). Urgency: скорость деградации (fast-burn/slow-burn по бюджету ошибок).

3) Жизненный цикл инцидента

1. Detect — сигнал из алертов/SLO/синтетики/репортов.
2. Acknowledge — on-call подтверждает прием, назначает IM.
3. Triage — оценка SEV/Impact, сбор гипотез, открытие War-Room.
4. Mitigate — стабилизация (откат/переключение маршрута/фичефлаги/масштабирование).
5. Communicate — регулярные статус-апдейты (внутри/наружу).
6. Recover — полное восстановление SLO/бизнес-метрик.
7. Close — фиксация хронологии, сбор артефактов, PIR (RCA + action items).

4) Роли и ответственность (RACI-схема)

Incident Manager (IM) — владелец процесса, назначает роли, следит за временем, принимает процессные решения (R).
Technical Lead (TL) — ведет диагностику/гипотезы/фиксы, координирует инженеров (A/R).
Communications (Comms) — статус-апдейты, связь с поддержкой/бизнесом/PR, статус-страница (R).
Scribe — протокол (таймлайн, принятые решения, ссылки, артефакты) (R).
Stakeholders — продукт/платежи/игровые провайдеры/безопасность (C/I).

Минимум на SEV1: IM + TL + Comms + Scribe. На SEV2 допускается совмещение ролей.

5) War-Room и ChatOps

Отдельные каналы: `#incident-warroom-<id>` (рабочий), `#incident-status` (только апдейты).
Шаблонные команды: `/incident start`, `/status update`, `/call <owner>`, `/rollback`, `/freeze`, `/scale +N`.
Бот подтягивает контекст: последние релизы, дашборды, связанные алерты, trace exemplars, схемы зависимостей.
Правила общения: кратко, по фактам, один спикер (TL), IM модерирует.

6) Триггеры и гейты

SLO-гейты: fast/slow burn, падение конверсии платежей, TTW p95 > порога, p99 API ↑, очереди выплат «горят».
Автодействия: stop canary, rollback, включение degrade-режима (ограничение функций), включение синтетики высокой частоты.
Freeze: все релизы/миграции стоп до стабилизации и PIR.

7) Типовые сценарии (рунабук-паттерны)

A) Платежи: рост таймаутов/отказов у PSP

1. Stop promote и заморозка релизов платежного контура.
2. Переключить маршрут PSP на резервный, поднять таймаут/ретраи по политике.
3. Сверка незавершенных транзакций, повтор с идемпотентными ключами.
4. Коммуникация Comms → саппорт: работаешь ли резерв? ETA.

B) API p99↑ и 5xx после релиза

1. Откат (blue-green/canary → stable).
2. Проверить кэш-хит, глубину очередей, горячие точки БД/провайдеров игр.
3. Временное масштабирование, ограничение тяжелых фич через feature flags.

C) Провайдер игр недоступен

1. Переключить трафик на доступные студии/игры, показать баннер статуса.
2. Включить синтетические проверки каждые 30–60с.
3. Согласовать компенсации/бонусы (по политике) — внести в PIR.

D) Утечка/подозрение на PII

1. Изоляция компонент, ревокация ключей/токенов, сбор логов (WORM).
2. Согласование правовой коммуникации/регуляторики.
3. Пост-инцидентные действия: секрет-ротация, маскирование, доступы.

8) Коммуникации (внутренние/внешние)

Частота апдейтов: SEV1 — каждые 15–30 мин, SEV2 — 30–60 мин.

• Что сломано: «Депозиты через PSP-X: рост таймаутов.»
• Кого затронуло: «TR/BR, ~18% пользователей потока.»
• Когда началось: «12:07 EET, SEV1.»
• Что делаем: «Переключаем маршрут на PSP-Y, включены ретраи/ограничение ставки.»
• Следующий апдейт: «через 20 минут.»
• Контакт: «IM @duty-im, TL @oncall-pay.»

Публичный статус (страница/соцсети) — сокращенный, без PII и лишних деталей, с ETA и ссылкой на дальнейшие обновления.

9) Сбор артефактов и аудит

Таймлайн событий (минутная точность), версии сервисов, фича-флаги, изменения конфигов.
Снимки дашбордов, примерные трассы (trace_id), логи «до/во время/после».
Ссылки на тикеты, PR, релизы, рунабуки.
Отчет по коммуникациям (когда/кому/что).
Все складывается в карточку инцидента.

10) Закрытие и PIR (Post-Incident Review)

• Резюме: что произошло, масштаб, длительность, SEV.
• Влияние: пользователи/регионы, SLO/SLA, фин. эффект.
• Таймлайн: детально, по минутам.
• Root Cause: техническая + организационная (почему недетектировали раньше).
• Detections & Defenses: что помогло/подвело (алерты, синтетика, фичефлаги).
• Action Items: конкретные задачи, владельцы, сроки (и как проверим эффект).
• Lessons Learned: что меняем в процессе/архитектуре/наблюдаемости.

Правила: без обвинений, максимум фактов, обязательный follow-up через 2–4 недели проверки выполненных пунктов.

11) Метрики надежности процесса

MTTD (Mean Time To Detect) — среднее время обнаружения.
MTTA (… Acknowledge) — до подтверждения on-call.
MTTR (… Restore) — до восстановления SLO.
Change Failure Rate — % релизов, приведших к инцидентам.
Incident Rate по SEV, распределение по доменам (Payments/Games/Infra).
Alert Quality: доля шумных/ложных, время до действия после алерта.
Комм-SLA: соблюдение периодичности статус-апдейтов.

12) Интеграции с SLO и релизами

Гейты в CD: промоушен канарейки только при зеленых SLO-прокси (availability, p95, conv, TTW).
Freeze-процедуры: при fast-burn/SEV1 — стоп релизов до PIR.
Авто-аннотации в графах: релизы/флаги/миграции видны на дашбордах.

13) Регуляторика и комплаенс

PII: маскирование/псевдонимизация в логах/трейсах, WORM-хранилища аудита, контроль доступа.
Региональность: не выносить пользовательские данные за пределы разрешенных юрисдикций.
Отчетность: формализованные письма/уведомления регуляторам — шаблоны и процесс эскалации.

14) Обучение и готовность (Game-Day)

Ежеквартальные учения: «падение PSP», «провайдер игр недоступен», «p99 всплеск», «утечка ключа».
Таймеры на MTTA/MTTR, ретро по упражнениям.
Обновление рунабуков и контактов, проверка ChatOps-команд.

15) Чек-лист готовности (до инцидента)

1. Согласованы SEV-правила и матрица эскалаций.
2. Назначены on-call ротации, IM/TL/Comms/Scribe.
3. Рунабуки по ключевым сценариям (платежи, игры, БД, кэши, очереди).
4. SLO-карта и burn-rate алерты, статус-страница.
5. ChatOps-бот: команды, автоконтекст, шаблоны статусов.
6. Шаблоны PIR и карточки инцидента.
7. Регулярные game-day и ревизии контактов/прав.
8. Политика freeze и «красная кнопка» (rollback/kill-switch).

16) Антипаттерны

Нет единого IM, «толпа лидирует» → хаос и задержки.
Отсутствие SLO-гейтов → поздняя детекция, шумные алерты.
Релиз во время инцидента без freeze → каскадные сбои.
Логов и трейсов недостаточно, нет артефактов → слабый PIR.
Обвинительная культура → скрытые ошибки, страх эскалации.
Коммуникации «по вдохновению» → потеря доверия бизнеса/пользователей.

17) Шаблоны (копируйте в вашу wiki)

A) Карточка инцидента (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Статус-апдейт (внутренний)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (шапка)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Итоги

Сильное управление инцидентами — это структура + дисциплина: заранее оговоренные роли, SLO-гейты, отработанные рунабуки, прозрачные коммуникации и «безобвинный» PIR. Такой контур сокращает MTTA/MTTR, снижает стоимость простоев, укрепляет доверие пользователей и позволяет релизить смелее — но безопасно.