Матриця ескалацій

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 м.
Ескалаційна драбинка: P1→P2 (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 і інтеграцією з плейбуками і статус-сторінкою команда реагує швидко, злагоджено і прозоро, а користувачі бачать передбачувані апдейти і впевнене відновлення сервісу.