Матрица эскалаций

1) Назначение матрицы

• уровни SEV и их критерии;
• тайминги (обнаружение → ack → эскалации → апдейты);
• ролей/каналы для каждого шага;
• исключения (без «тихих часов» для security и комплаенса);
• связку с плейбуками и статус-страницей.

2) Классификация по тяжести (SEV)

Уточняйте целевые числа под ваш домен и SLO.

3) Базовая матрица «кто/когда/куда»

4) Решающее дерево эскалаций (суть)

1. Есть подтвержденный импакт на SLO?

→ Да: назначить IC, объявить SEV, открыть war-room.
→ Нет: ticket/наблюдение, без пейджа.

2. Есть ACK в срок?

→ Да: продолжаем по плейбуку.
→ Нет: П2 → IC → DM (лесенка по времени).

3. Security/утечка/PII?

→ Всегда Security IR + Legal, публичные сообщения согласовываются.

4. Внешний провайдер?

→ Эскалация Vendor Owner, переключение маршрутов, фикс в статусе.

5) Роли и обязанности в эскалации (коротко)

P1 (Primary): триаж, старт плейбука, связь с IC.
P2 (Secondary): бэкап, сложные действия, удержание контекста.
IC (Incident Commander): объявляет SEV, решает freeze/rollback, держит темп.
Duty Manager: снимает блокировки, перераспределяет ресурсы, принимает орг-решения.
Comms: статус-страница, апдейты по SLA.
Security IR: изоляция, форензика, юридические уведомления.
Vendor Owner: внешние провайдеры, switchover/fallback.

6) Временные гайды (ориентиры)

SEV-1/0: ACK ≤ 5 м, Declare ≤ 10 м, First Comms ≤ 15 м, Updates q=15–30 м.
Эскалационная лесенка: П1→П2 (5 м) → IC (10 м) → Duty Manager (15 м) → Exec on-call (30 м).
Security: без задержек и «тихих часов», апдейты q=15 м.

7) Маршрутизация и сегментация

По сервису/региону/тенанту: ключ маршрутизации = `service+region+tenant`.
Кворум зондов: эскалировать только при подтверждении ≥2 независимых источников (synthetic из 2 регионов + RUM/бизнес-SLI).
Дедуп: один мастер-алерт вместо десятков симптомов (БД «красная» глушит 5xx-шум).

8) Исключения и особые режимы

Security/Legal: эскалация Security IR и Legal вне очереди; публичные тексты только через согласование.
Провайдеры: отдельная матрица OLA/SLA (контакты, часовые пояса, приоритет).
Change Freeze: при SEV-1/0 — автоматический freeze релизов и конфигов.

9) Метрики зрелости матрицы

Ack p95 (SEV-1/0) ≤ 5 мин.
Time to Declare (медиана) ≤ 10 мин.
Comms SLA Adherence ≥ 95%.
Escalation Success (решено на уровне П1/П2) ≥ 70%.
No-ACK escalations ↓ QoQ.
Vendor Response Time по критичным провайдерам в пределах договора.

10) Чек-листы

Оперативный (для on-call)

• Определен импакт на SLO и потенциальный SEV.
• Сделан ACK и назначен IC (для SEV-1/0).
• Открыт war-room, плейбук прикреплен.
• Статус-апдейт опубликован/запланирован по SLA.
• Включен freeze (если нужно), эскалирован провайдер/безопасность.

Процессный (еженедельный review)

• Лестница эскалаций сработала по SLA?
• Не было ли лишних эскалаций до IC?
• Уведомления клиентов своевременны и точны?
• Были ли блокеры (доступы, контакты провайдеров, «немой» канал)?
• CAPA для сбоев процесса заведены и в работе.

11) Шаблоны

11.1 Политика эскалаций (YAML-идея)

yaml policy:
sev_levels:
- id: SEV-0 declare_tgt_min: 5 first_comms_min: 10 update_cadence_min: 15
- id: SEV-1 declare_tgt_min: 10 first_comms_min: 15 update_cadence_min: 30 ack_sla_min:
default: 5 ladder:
- after_min: 5 escalate_to: "P2:oncall-<service>"
- after_min: 10 escalate_to: "IC:ic-of-the-day"
- after_min: 15 escalate_to: "DutyManager:duty"
- after_min: 30 escalate_to: "Exec:oncall-exec"
channels:
war_room: "#war-room-<service>"
alerts: "#alerts-<service>"
security: "#sec-war-room"
providers: "vendors@list"
quorum:
required_sources: 2 sources: ["synthetic:eu,us", "rum:<service>", "biz_sli:<kpi>"]
exceptions:
security: { quiet_hours: false, legal_approval_required: true }
providers: { auto_switch: true, notify_vendor_owner: true }

11.2 Карточка «эскалация по времени» (для бота)

T + 05m: no ACK → escalated to P2
T + 10m: no ACK/Declare → escalated to IC, war-room open
T + 15m: no Comms → reminder Comms, escalation Duty Manager
T + 30m: no Updates → IC reminder, Exec on-call CC

11.3 Шаблон первого публичного апдейта

Impact: [services/regions] affected, [symptoms e.g. delays/errors].
Reason: Investigating; confirmed by monitoring quorum.
Actions: bypass routes/restrictions are enabled, provider switching is in progress.
Next update: [time, time zone].

12) Интеграции

Alert-as-Code: каждое Page-правило ссылается на ровно один плейбук и знает свою матрицу эскалаций.
ChatOps: команды `/declare sev1`, `/page p2`, `/status update`, авто-таймеры апдейтов.
CMDB/Каталог: у сервиса — владельцы, on-call, матрица, провайдеры, каналы.
Status page: шаблоны для SEV-1/0, история апдейтов, ссылки на RCA.

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

«Эскалируем всех сразу» → шум и размытая ответственность.
Нет IC/war-room — решения расползаются по чатам.
Задержка первого апдейта — рост жалоб и PR-рисков.
Отсутствие исключений для security — юридические риски.
Внешние провайдеры без владельца и контактов.
Лестница не автоматизирована — все «на ручнике».

14) Дорожная карта внедрения (3–5 недель)

1. Нед. 1: зафиксировать SEV-критерии и тайминги; собрать контакты ролей/провайдеров; выбрать каналы.
2. Нед. 2: описать политику (YAML), привязать к Alert-as-Code, включить лесенку в пейджере/боте.
3. Нед. 3: пилот на 2–3 критичных сервисах; отладить Comms SLA и шаблоны.
4. Нед. 4–5: расширить покрытие, ввести еженедельный Escalation Review и метрики зрелости.

15) Итог

Матрица эскалаций — это операционная Конституция инцидентов: кто, когда и как подключается. С четкими SEV, таймингами, каналами, исключениями для security и интеграцией с плейбуками и статус-страницей команда реагирует быстро, слаженно и прозрачно, а пользователи видят предсказуемые апдейты и уверенное восстановление сервиса.