Эскалация инцидентов

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

Эскалация инцидентов — это управляемый процесс быстрого привлечения правильных ролей и ресурсов для минимизации воздействия на пользователей и бизнес-метрики.

• Скорость важнее идеальности. Лучше задекларировать инцидент раньше и деэскалировать, чем опоздать.
• Единое командование. Один ответственный за решение — Incident Commander (IC).
• Прозрачность. Четкие статусы и каналы коммуникации для внутренних и внешних стейкхолдеров.
• Документируемость. Все шаги, решения и таймлайны фиксируются для аудита и улучшений.

2) Градация серьезности (SEV/P-уровни)

• SEV-0 / P0 (критический) — полная недоступность ключевой функции (логин/платеж), утечка данных, юридический риск. Немедленный пейдж всего ядра on-call, freeze релизов.
• SEV-1 / P1 (высокий) — деградация p95/p99, повышенная доля ошибок/отказов в ключевом процессе, недоступность региона/провайдера.
• SEV-2 / P2 (средний) — частичная деградация для ограниченной когорты (регион, провайдер), есть обходной путь.
• SEV-3 / P3 (низкий) — не критично для пользователя, но требует внимания (фоновая задержка ETL, просроченный отчет).

• Радиус поражения (сколько пользователей/оборот) × длительность × чувствительность (регуляторика/PR) → уровень SEV.

3) KPI процесса

MTTD (время обнаружения) — от начала инцидента до первого сигнала.
MTTA (время принятия) — от сигнала до подтверждения IC.
MTTR (время восстановления) — до восстановления SLO/функции.
Escalation Latency — от подтверждения до подключения нужной роли/команды.
Reopen Rate — доля инцидентов, повторно открытых после “решено”.
Comm SLA — соблюдение интервалов внешних/внутренних апдейтов.

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

Incident Commander (IC): владелец решения, устанавливает уровень, план, freeze, эскалации, деэскалацию. Не пишет фиксы.
Tech Lead (TL): техническая диагностика, гипотезы, координация инженеров.
Comms Lead (CL): статус-страницы, клиентская и внутренняя коммуникация, согласование с Legal/PR.
Scribe: точная фиксация фактов, таймлайна, принятых решений.
Liaisons (связные): представители внешних провайдеров/команд (платежи, KYC, хостинг).
On-call инженеры: исполнение плана, запуск плейбуков/откатов.

Назначьте дежурные графики и бэкапы по каждой роли.

5) Каналы и артефакты

War-room канал (ChatOps): единая точка координации (Slack/Teams) с шаблоном авто-аннотаций (версии, флаги, канарейки).
Видеомост для SEV-1+.
Тикет инцидента (one-pager): ID, SEV, IC, участники, гипотеза/диагноз, шаги, ETA, статус, импакт, ссылки на графики.
Статус-страница: публичная/внутренняя; расписание регулярных апдейтов (например, каждые 15–30 минут для SEV-1+).

6) Тайм-боксы и стандартные интервалы

T0 (мин. 0–5): IC назначен, SEV присвоен, freeze релизов (если нужно), war-room открыт.
T+15 мин: первое публичное/внутреннее сообщение (что затронуто, workaround, следующее окно апдейта).
T+30/60 мин: эскалация следующего уровня (платформа/БД/безопасность/провайдеры), если нет устойчивой динамики.
Регулярные апдейты: SEV-0: каждые 15 мин; SEV-1: каждые 30 мин; SEV-2+: каждый час.

7) Правила авто-эскалации (политики срабатывания)

• Burn-rate бюджета ошибок выше порога в коротком и длинном окнах.
• Кворум внешних проб: ≥2 регионов фиксируют деградацию HTTP/TLS/DNS.
• Бизнес-SLI (успех платежей/регистраций) падает ниже SLO.
• Security-сигнатуры: подозрение на утечку/компрометацию.
• Провайдерский сигнал: вебхук статуса “major outage”.

8) Процесс от обнаружения до решения

1. Декларация инцидента (IC): SEV, охват, freeze, запуск плейбуков.
2. Диагностика (TL): гипотезы, изоляция радиуса (регион, провайдер, фича), проверки (DNS/TLS/CDN/БД/кэши/шина).
3. Митигирующие действия (быстрые победы): откат/канарейка ↓, фича-флаг деградации, failover провайдера, rate-limit, кеш-оверлей.
4. Коммуникация (CL): статус-страница, клиенты/партнеры, Legal/PR, обновления по графику.
5. Подтверждение восстановления: внешняя синтетика + реальные метрики (SLI), снятие freeze.
6. Деэскалация: снижение SEV, переход в наблюдение N минут/часов.
7. Закрытие и RCA: подготовка пост-мортема, action items, владельцы и сроки.

9) Работа с внешними провайдерами

Собственные пробы к провайдерам из нескольких регионов + зеркальные лог-примеры запросов/ошибок.
Соглашения об эскалации (контакты, SLA ответа, приоритет, вебхуки статуса).
Автоматический failover/перераздача трафика по SLO провайдера.
Доказательная база: таймлайн, sample запросы/ответы, графики латентности/ошибок, ID тикета провайдера.

10) Регуляторика, безопасность и PR

Security/P0: изоляция, сбор артефактов, минимизация разглашения, обязательные уведомления (внутренние/внешние/регулятор).
Legal: согласование формулировок внешних апдейтов, учет договорных SLA/штрафов.
PR/Клиентский сервис: готовые шаблоны ответов, Q&A, компенсации/кредиты (если применимо).

11) Шаблоны сообщений

• «Мы расследуем инцидент SEV-1, затрагивающий [функцию/регион]. Симптомы: [кратко]. Мы активировали обходной путь [описание]. Следующее обновление — в [время].»

• «Диагностика: [гипотеза/подтверждение]. Действия: [переключили провайдера/откатили релиз/включили деградацию]. Импакт снижен до [процентов/когорты]. Следующий апдейт — [время].»

• «Инцидент SEV-1 решен. Причина: [корневая]. Время восстановления: [MTTR]. Следующие шаги: [фикс/проверки/наблюдение N часов]. Пост-мортем — [когда/где].»

12) Плейбуки (примерные)

Падение успеха платежей: снизить долю на провайдера A, перевести X% на B; включить “degrade-payments-UX”; включить ретраи в лимитах; оповестить фин-команду.
Рост p99 API: уменьшить канарейку новой версии; выключить тяжелые фичи; увеличить кеш-TTL; проверить БД-индексы/коннекты.
Проблема DNS/TLS/CDN: проверить сертификаты/цепочку; обновить запись; переключить на резервный CDN; пересобрать кеш.
Security-подозрение: изоляция узлов, ключевая ротация, включение mTLS-ручек, сбор артефактов, уведомление Legal.

13) Деэскалация и критерии “решено”

• SLI/SLO стабильно в зеленой зоне ≥ N интервалов;
• выполнены митигирующие действия и наблюдение — без регресса;
• для security-класса — подтверждена закрытость векторов, ключи/секреты ротированы.

Закрытие — только после фиксации таймлайна, владельцев action items и сроков.

14) Post-mortem (некарательный)

1. Факты (таймлайн, что видели пользователи/метрики).

2. Корневая причина (техническая/процессная).

3. Что сработало/не сработало в эскалации.

4. Превентивные меры (тесты, алерты, лимиты, архитектура).

5. План действий с дедлайнами и владельцами.

6. Связь с error budget и пересмотр SLO/процессов.

15) Метрики зрелости процесса

Доля инцидентов, задекларированных до жалоб пользователей.
MTTA по уровням SEV; время на подключение нужной роли.
Соблюдение интервалов апдейтов (Comm SLA).
Процент инцидентов, решенных плейбуками без ручного “творчества”.
Выполнение action items из пост-мортемов в срок.

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

“Кто-нибудь сделайте что-нибудь” — нет IC/ролей.
Многоголосие в war-room — спор о версиях вместо действий.
Поздняя декларация → потеря времени на сбор людей.
Нет freeze и аннотаций релизов — параллельные изменения маскируют причину.
Отсутствие внешней коммуникации — эскалация жалоб/PR-риск.
Закрытие без пост-мортема и действий — повторяем те же ошибки.

17) Чек-лист IC (карманная карточка)

• Присвоить SEV и открыть war-room.
• Назначить TL, CL, Scribe, проверить on-call присутствуют.
• Включить релиз-freeze (при SEV-1+).
• Подтвердить источники истины: дашборды SLI, синтетика, логи, трейсинг.
• Принять быстрые митигирующие действия (откат/флаги/failover).
• Обеспечить регулярные апдейты по расписанию.
• Зафиксировать Criteria for Resolve и наблюдение после восстановления.
• Инициировать пост-мортем и назначить владельцев action items.

18) Встраивание в ежедневные операции

Тренировки (game-days): симуляции по ключевым сценариям.
Каталог плейбуков: версионированные, протестированные, с параметрами.
Инструменты: ChatOps-команды “/declare”, “/page”, “/status”, “/rollback”.
Интеграции: тикетинг, статус-страница, пост-мортемы, CMDB/сервис-каталог.
Согласование с SLO/Error Budget: триггеры авто-эскалации и правила freeze.

19) Итог

Эскалация — это операционная дисциплина, а не просто звонок дежурному. Четкие уровни SEV, назначенный IC, готовые плейбуки, тайм-боксы обновлений и интеграция с метриками SLO и budget-политиками превращают хаотичный пожар в управляемый процесс с предсказуемым исходом — быстрым восстановлением сервиса, минимальным PR/регуляторным риском и системными улучшениями после каждого инцидента.