Реакция на инциденты и аварии

(Раздел: Операции и Управление)

1) Определения и цели

Инцидент — событие, нарушающее SLO/безопасность/комплаенс или создающее риск для клиентов, денег, данных, репутации.
Цели реакции: быстро восстановить сервис, минимизировать ущерб, зафиксировать доказательства, прозрачно коммуницировать и не допустить повторения.

Ключевые принципы

Safety first: защита людей/данных/денег важнее функций.
One throat to choke: единый Incident Commander (IC) принимает решения.
Actionable now: каждая гипотеза сопровождается проверкой/действием.
Evidence matters: все логируется, артефакты подписываются, таймлайн — детальный.

2) Классификация (severity & приоритет)

Триггер: нарушение SLO, правило алерта, ручной репорт, юридический инцидент (DPO/CCO).

3) Роли и ответственность (RACI)

Incident Commander (A) — лидер инцидента, постановка задач, принятие решений, смены IC при длинных инцидентах.
Tech Lead (R) — техническая диагностика/фиксы, координация SRE/инжиниринга.
Comms Lead (R) — пишет статус-обновления (внутри/внешне), владелец статус-страницы.
Scribe (R) — протокол, таймлайн, сбор артефактов.
Security/Legal (C/A для секьюрити-случаев) — оценка рисков, обязательные уведомления.
Customer Support (C) — шаблоны ответов, маршрутизация тикетов.
Partner Liaison (C) — коммуникация с провайдерами/тенантами.
Management (I) — информирование, бизнес-решения (кредиты/компенсации).

4) Первые 15 минут (шаблон)

1. Назначить IC и открыть карточку инцидента (чат-канал, видеомост, Jira/Tracker).
2. Присвоить SEV и зафиксировать SLO-симптом (что именно нарушено).

• включить runbooks/руны: circuit-breakers, троттлинг, переключение маршрута, пауза промо;
• при компрометации — kill-switch чувствительных функций.
• 4. Команды: Tech Lead — диагностика; Comms — «технический холд» (через 10–15 мин — первое обновление).
• 5. Определить гипотезы (три максимум), назначить владельцев, поставить таймеры на проверку (5–10 мин).
• 6. Собирать артефакты: снапшоты метрик, конфиги, хэши релизов, логи с `trace_id`, квитанции.

5) Первый час (шаблон)

Коммуникация v1 (15–20 мин): факт, охват, симптомы, что делаем, следующее обновление. Без спекуляций.
Границы инцидента: какие регионы/тенанты/каналы/версии затронуты.
Контроль ущерба: временные капы/ограничения, отключение «шумных» интеграций, включение деградационного режима.
Форензика: заморозить ротации логов, защитить артефакты (WORM/подписи).
Дорожная карта восстановления: T+30/T+60 с чек-поинтами.

6) Коммуникации и статус-страница

Внутренние интервалы: P1 — каждые 15 мин, P2 — 30–60 мин.
Внешние: статус-страница/тенанты/партнеры по SLA.

• Что видно: «с X:YY UTC рост отказов checkout в регионе EU (p95>250 мс)»
• Кого затрагивает: «операторы A/B/C, ~40% трафика»
• Что делаем: «включили альтернативный маршрут, троттлинг промо; работаем с провайдером PSP-1»
• Данные/дедлайны: «следующее обновление через 15 мин»
• Компенсации: «применим кредит-ноты согласно SLA после закрытия инцидента»

7) Плейбуки (референсы для iGaming/финтех)

PriceMismatch (витрина ≠ checkout): форс-инвалидация кэша, сверка `fx_version/tax_rule_version`, заморозка динамических промо, компенсация расхождений по политике.
WebhookLag (партнеры/аффилиаты): масштабирование воркеров, увеличение batch, приоритет ретраев, временный кап на новые подписки.
Payments Outage/PSP-деградация: переключение на резервного PSP, снижение таймаутов клиентов, ручной клиринг очереди, «серые» транзакции в карантин.
RTP Drift: пауза бонусов, проверка таблиц выплат/версий, расширение окна наблюдения, откат профиля RTP.
Fraud Spike: ужесточить velocity/лимиты, включить дополнительную KYC-проверку, изоляция подозрительных когорт, ручной ревью высоких выигрышей.
Data/PII Exposure: изоляция систем, уведомление DPO/Legal, инвентаризация затронутых записей, регуляторные уведомления по срокам.

8) Инструменты и руны (auto-actions)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Гвард-рейлы: защита от «седлания» — откаты ограничены, журналы подписаны, каждое действие ↔ IC/Scribe.
Доказуемость: DSSE-подписи, хэши снапшотов, Merkle-срезы логов.

9) Завершение инцидента

Критерии: SLO восстановлены, очередь погашена, данные/деньги сверены, риски закрыты, коммуникации отправлены.
Ритуал закрытия: финальное обновление статуса, зафиксированный таймлайн, список влияний, предварительные гипотезы причин, назначена дата пост-мортема.

10) Пост-мортем (без обвинений)

Срок: P1 — в течение 3 рабочих дней; P2 — 5 рабочих дней.
Содержание: факты/таймлайн, первопричины (5 Whys/FRAM), влияние (SLO, финансы, клиенты), что сработало/нет, action items (owner, срок, измеримый эффект).
Проверка эффективности: через 30–60 дней — ревью выполнения и метрик (повторяемость, MTTR, шум алертов).

11) Метрики и SLO инцидент-менеджмента

MTTD/MTTA/MTTR, Change Failure Rate, Time to Comms v1, % авто-разрешенных (рунами).
Alert Noise: доля неактуальных сигналов, pages per on-call shift.
Repeat Incidents: доля повторов за 90 дней.
Post-mortem SLA: доля проведенных/закрытых в срок.
SLO реакции: P1 — первая коммуникация ≤ 15 мин; MTTR ≤ 60 мин; полнота артефактов = 100%.

12) Право/комплаенс/приватность

Юридические уведомления: сроки локальных регуляторов по утечкам/инцидентам.
PII-минимизация: доступ к первичке только через утвержденные джобы; токенизация/маскирование.
Хранение артефактов: WORM-журналы, период хранения по юрисдикциям; контроль доступа (RBAC/ABAC, JIT).
Контрагенты: договорные SLA, процесс эскалации, квитанции разбирательств.

13) Организация дежурств и эскалаций

24×7 on-call: ротации по ролям (SRE, App, Data, Security, Payments).
Матрица эскалаций: кто за регионы/продукты/провайдеров; дублирование контактов (чат/голос/SMS).
Учения (GameDays): симуляции — падение PSP, лавина ретраев, рассинхрон цен, компрометация ключа, отказ региона.

14) Дашборды инцидентов

Жара (сейчас): статус SLO, p95/p99, карта регионов/тенантов, очередь задач, артефакты собраны/нет.
История: тренды по типам инцидентов, эффективность рун, повторяемость причин.
Контроль качества: полнота таймлайна, «coverage» пост-мортемов, SLA коммуникаций.

15) Чек-лист внедрения

• Утвердить шкалу SEV и триггеры SLO.
• Назначить роли (IC/Tech/Comms/Scribe/Sec/Legal) и ротации 24×7.
• Запустить единый шаблон карточки инцидента и статус-страницу.
• Описать плейбуки (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Реализовать руны с аудитом и «красной кнопкой».
• Включить форензик-политику: WORM/подписи/сбор артефактов.
• Регламент коммуникаций (внутр./внешн.), SLA обновлений.
• Пост-мортем процесс и шаблоны; KPI выполнения action items.
• GameDays ежемесячно; квартальный обзор трендов инцидентов.
• Метрики IR на дашборде (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

Почему «IC один»?
Единая точка принятия решений убирает хаос и ускоряет реакцию.

Когда объявлять публично?
Как только есть подтвержденный факт и план стабилизации. Оцените регуляторные сроки.

Что важнее — фикс или отчет?
Сначала — восстановление и безопасность. Параллельно — сбор артефактов. Отчет — после стабилизации.

Можно ли автоматизировать все?
Нет, но руны закрывают «частые и простые» шаги. Остальное — через четкие плейбуки и тренировки.

Резюме: Сильный Incident Response — это не только PagerDuty и чат-канал. Это дисциплина ролей, быстрые первые 15 минут, управляемые руны, прозрачные коммуникации, форензика с доказуемостью и обязательный пост-мортем. С таким контуром вы снижаете MTTR, защищаете деньги и данные, и повышаете доверие клиентов и регуляторов.