Severity Classification & Escalation

«Всё SEV1, потому что страшно» — антипаттерн, который я регулярно вижу в команде без чёткой severity matrix. Severity inflation: всё «критично» → ничего реально не критично, команда выгорает, клиенты получают неуместные паникёрские сообщения, executive escalation тратится впустую. Severity Classification — это рамка по критериям: impact × scope даёт уровень (SEV0..SEV3), уровень определяет — кого пейджит, кого вовлекать, с какой каденцией общаться с клиентами, какой постмортем требуется. Третий лист под L1 Incident Management (рядом с Incident Response и On-Call Rotation).

Что должен уметь

Главный навык на уровне L5 — связывать SLO burn rate с severity через автоматическое правило. Severity отдельно от alerting — это субъективная оценка IC «по ощущениям». High burn rate (5% бюджета за час) — это уже сигнал severity 1: customer impact в данный момент. Auto-escalation rule в alerting: burn rate > threshold → page IC + auto-classify SEV1 минимум. Без этого моста severity становится subjective, и в разных инцидентах одинаковая ситуация получает разный severity.

Знает severity scheme своей команды; применяет корректную severity при declare, не «всё SEV1 потому что страшно».
Знает escalation path для своего сервиса; где это документировано.

Использует severity-based response: SEV0 — war room + leadership notify + customer comms, SEV1 — IC + senior eng, SEV2 — on-call + уведомление руководителя, SEV3 — async fix без paging других.
Делает escalation по правилам: time-based (5 мин без ack → secondary, 15 мин → IC, 30 мин → leadership при SEV1+), criteria-based (data integrity / regulatory triggers → CISO / Legal).

Проектирует severity matrix: impact (data loss / customer-facing degradation / internal-only) × scope (один пользователь / blast radius / global) → severity. Численные пороги (% затронутых пользователей, $/min revenue impact).
Связывает severity с SLO burn rate: high burn rate автоматически elevates severity; SLO breach с пользовательским impact = минимум SEV1.
Калибрует scheme на основе lookback (квартальный ревью): distribution по severity, false-positives, missed cases.

L6+

Проектирует org-level severity governance: единая scheme через все команды, regulatory hooks (GDPR breach → CISO/Legal), customer comms gates.
Принимает strategic severity decisions: external comm strategy для major incidents, board-level reporting threshold, regulatory disclosure timing.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 14. Каноническая структура ролей, severity, command-and-control модель.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 9. Прикладные шаблоны severity matrix, examples из Google.

Статьи и доклады

PagerDuty Incident Response Documentation — open-source playbook. Полная глава по severity definitions, escalation policies, communication cadence. По моим наблюдениям, чаще всего именно её берут как стартовый шаблон. Apache 2.0.
Atlassian Incident Management Handbook. Severity definitions (SEV1..SEV5), escalation policies, customer communication patterns, integrated со Statuspage.
Google Cloud — Building Secure and Reliable Systems — главы 17–18. Severity для security-incidents, decision-making под давлением.

Инструменты

PagerDuty / Opsgenie / incident.io / FireHydrant — paging + escalation policies + severity tracking. Auto-escalation по timeout встроена; severity classification конфигурируема per-team.
Atlassian Statuspage / Better Stack — customer-facing severity communication. Mapping internal severity → public status.
Slack workflows + ChatOps боты — declare incident через /incident sev1 <description>, auto-create war room channel, auto-page on-call. Netflix Dispatch — open-source пример.

Best practices

Короткие правила:

Severity = impact + scope, не «громкость крика». Severity-inflation: всё «критично» → ничего реально не критично. Severity — рамка по критериям: customer impact (data loss > user-facing degradation > internal-only), scope (% пользователей / blast radius), data integrity, regulatory implications.
Severity-based response — не уравниловка. Для каждого incident — full war room и all-hands → burnout, потеря фокуса. SEV0 = war room + leadership + customer comms; SEV1 = IC + senior eng; SEV2 = on-call + уведомление руководителя; SEV3 = on-call async fix.
Auto-escalation по timeout, не «жду ответа». Pager сработал, primary не ответил за 30 минут — никто не знает. Auto-escalation в paging tool: 5 мин без ack → secondary; 15 мин → IC; 30 мин → leadership (при SEV1+). Настроить однажды, тестировать на game day.

Подробнее:

Severity не статична — upgrade/downgrade в ходе incident. «Один раз declared SEV2 — навсегда SEV2» (стыдно повышать) — реальные incidents меняют scope в ходе investigation. Думали один пользователь → оказалось 50% базы → SEV0. Process: IC явно declare severity change с уведомлением stakeholders; downgrade тоже валиден (initial assessment был алармистский — формальный downgrade с явным обоснованием). По моим наблюдениям, нежелание менять severity в ходе инцидента — частая причина mismatched response.

SLO burn rate → severity bridge. «Severity отдельно, alerting отдельно» — high burn rate (5% бюджета за час) — это уже сигнал severity 1. Auto-escalation rules в alerting: burn rate > threshold → page IC + auto-classify SEV1 минимум. Без этого моста severity становится subjective.

Регуляторные escalations — first 24h critical. GDPR 72-hour breach notification — стартовый таймер с момента discovery, не с момента подтверждения. Severity matrix должна включать regulatory triggers (data breach / financial data exposure / health data / payment card data) с auto-page CISO / Legal / Compliance — не «оповестим в рабочее время».

Calibration lookback каждый квартал. «Severity scheme прописали год назад и не трогаем» — reality drift: распределение incidents меняется. Quarterly review: distribution по severity (если 80% SEV1 — критерии слишком низкие), false-positives, missed cases. Adjust criteria, document examples per level. Я регулярно вижу команды с устаревшей severity matrix, по которой через полгода стало невозможно отличить SEV1 от SEV2.

Связанные листья

Incident Response — severity определяет response intensity (war room, comm cadence, postmortem requirements).
On-Call Rotation — escalation paths переплетены с rotation structure.
Blameless Postmortem — severity-based postmortem requirements: SEV0 — обязательный PM с external timeline и executive review; SEV3 — optional / lightweight.
Customer Communications — severity определяет audience matrix и cadence customer comms.
Runbooks — severity matrix часть runbook structure; escalation paths документированы в runbook.
SLO Engineering — burn rate как input для severity.
Service Ownership — escalation идёт по service ownership chain.
War Room Patterns — SEV0+ требует структурированного war room.
Action Items Tracking — severity определяет, требуется ли formal action items review (SEV0/1 — обязательно, SEV3 — optional).
ChatOps — declare-incident через slash-command (/incident sev1 <description>) — каноническая ChatOps команда; SEV-routing к разным каналам и pager-группам.
Status Page Management — internal severity → public component status mapping (operational / degraded / partial outage / major outage) должен быть формальным, не «по ощущениям».

Открытые вопросы

Customer Communications уже выделена в отдельный лист.
War Room Patterns уже выделен в отдельный лист.
Status Page Management — выделен в отдельный лист (см. Связанные листья).
Severity vs Priority в trackers — соотношение incident severity (момент инцидента) и priority в backlog для follow-up.