Severity Classification & Escalation

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

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

Главный навык на уровне L5 — довести матрицу до чисел. Формулировка «значительная часть пользователей» выглядит рамкой, а работает как приглашение поспорить в тот момент, когда спорить некогда. Числа назначаются волевым решением: сколько процентов затронутых — уже SEV1, с какой суммы потерь в минуту подключается руководство. Ошибиться в порогах не страшно, страшно их не иметь.

Знает шкалу своей команды; выставляет уровень честно, когда объявляет инцидент, а не «всё SEV1, потому что страшно».
Знает путь эскалации для своего сервиса и то, где он записан.

Реагирует по уровню: SEV0 — war room, уведомление руководства, коммуникация с клиентами; SEV1 — IC и старший инженер; SEV2 — дежурный и уведомление руководителя; SEV3 — асинхронная починка, никого не будим.
Эскалирует по правилам: по таймеру (пять минут без подтверждения — резервный дежурный, пятнадцать — IC, тридцать — руководство при SEV1 и выше) и по критериям (целостность данных или регуляторные последствия — сразу CISO и юристы).

Проектирует матрицу: что пострадало (потеря данных, деградация для клиента, только внутренние неудобства) × какой охват (один пользователь, часть системы, всё сразу). Пороги — в числах: процент затронутых пользователей, потери в деньгах за минуту.
Связывает уровень со скоростью сжигания бюджета: высокий burn rate поднимает уровень автоматически, а нарушение SLO, которое видит пользователь, — это минимум SEV1.
Калибрует шкалу по прошлым инцидентам раз в квартал: как распределились уровни, где были ложные срабатывания, что матрица не поймала вовсе.

L6+

Проектирует общие правила на уровне организации: единая шкала для всех команд, регуляторные зацепки (утечка персональных данных — сразу CISO и юристы), пороги, с которых начинается коммуникация с клиентами.
Принимает стратегические решения: как говорить наружу о крупных инцидентах, с какого уровня докладывают совету директоров, когда наступает срок раскрытия перед регулятором.

Материалы

Книги

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. Прикладные шаблоны матрицы и примеры из Google.

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

PagerDuty Incident Response Documentation — открытый playbook. Целая глава про определения уровней, политики эскалации и ритм коммуникации. По моим наблюдениям, чаще всего именно её берут как стартовый шаблон. Apache 2.0.
Atlassian Incident Management Handbook. Своя шкала уровней, политики эскалации, паттерны общения с клиентами, связка со Statuspage. Полезно как пример того, что число уровней — решение компании, а не универсальный стандарт.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), главы 17–18. Уровни для инцидентов безопасности и принятие решений под давлением.
GDPR, Article 33 — первичный текст требования об уведомлении надзорного органа. Нужен для точной границы: не каждый инцидент безопасности — это утечка персональных данных, а исключение зависит от риска для прав и свобод людей.

Инструменты

PagerDuty / incident.io / FireHydrant — оповещение, политики эскалации, учёт уровней. Opsgenie из этого ряда выбывает: Atlassian прекратила продажи в 2025 и отключает продукт в апреле 2027. Эскалация по таймауту встроена везде, шкала настраивается под команду. По моим наблюдениям, инструмент здесь редко выбирают под severity — берут тот, что уже стоит под paging, и достраивают классификацию поверх него.
Atlassian Statuspage / Better Stack — внешняя сторона: как внутренний уровень превращается в публичный статус.
Slack workflows + ChatOps боты — объявление инцидента через /incident sev1 <описание>, автоматическое создание канала под war room, автоматический вызов дежурного. Netflix Dispatch — open-source пример.

Best practices

Severity считается по impact и scope, а не по громкости крика в чате. Когда критично всё, критичного нет вовсе — это и есть severity inflation, от которой команда выгорает за квартал. Рамка держится на четырёх вопросах: что именно пострадало (потеря данных хуже деградации для пользователя, деградация хуже внутренних неудобств), какой охват в процентах пользователей и blast radius, затронута ли целостность данных, есть ли регуляторные последствия.

Реакция на уровень тоже разная, и это принципиально. Полный war room с созывом всех подряд на каждый инцидент — прямая дорога к выгоранию и потере фокуса. SEV0 поднимает war room, руководство и коммуникацию с клиентами. SEV1 — IC и старший инженер. SEV2 обходится дежурным и уведомлением руководителя, а SEV3 вообще чинится асинхронно и никого не будит.

Эскалация по таймауту настраивается один раз и дальше работает сама. Иначе получается классика: вызов ушёл, основной дежурный не ответил, и полчаса об этом никто не знает. Пять минут без подтверждения — подключается резервный, пятнадцать — IC, тридцать — руководство, если уровень не ниже SEV1. Цепочка проверяется на game day. Не на реальном инциденте.

Severity не статична — её повышают и понижают по ходу. «Один раз объявили SEV2 — значит, SEV2 до конца» держится на неловкости: повышать вроде как стыдно, признавать преувеличение тоже. А scope в реальных инцидентах меняется постоянно: думали, задет один пользователь, выяснилось — половина базы, и это уже SEV0. Процедура простая: IC объявляет смену уровня явно и уведомляет заинтересованных. Понижение так же законно, как повышение, если первичная оценка была алармистской и для понижения есть обоснование. По моим наблюдениям, именно нежелание трогать однажды выставленный уровень чаще всего разводит реакцию и реальную тяжесть инцидента.

Мост от burn rate к severity. Пока эти две вещи живут отдельно, уровень выставляется на глаз, одинаковые ситуации в разных инцидентах получают разные уровни, а матрица обесценивается целиком. Правило в алертинге закрывает разрыв: burn rate выше порога поднимает IC и ставит минимум SEV1. Пять процентов бюджета за час — уже первая тяжесть.

У регуляторных уведомлений нет одного универсального таймера. По статье 33 GDPR контролёр уведомляет надзорный орган без неоправданной задержки и, где это возможно, не позднее 72 часов после того, как ему стало известно об утечке персональных данных; исключение действует, если нарушение вряд ли создаст риск для прав и свобод людей. Это не универсальные 72 часа на любой инцидент. Задача матрицы здесь одна — быстро подключить CISO, юристов и комплаенс. Применимость и момент, с которого пошёл отсчёт, определяются уже с ними, по конкретному факту и юрисдикции, а не таблицей в вики.

Пересмотр матрицы раз в квартал. «Схему прописали год назад и больше не трогаем» — и она тихо расходится с реальностью, потому что состав инцидентов меняется. Раз в квартал стоит смотреть на распределение: если восемьдесят процентов инцидентов оказались SEV1, критерии выставлены слишком низко. Туда же — ложные срабатывания и случаи, которые матрица не поймала вовсе. Дальше правим критерии и дописываем примеры к каждому уровню. Я регулярно вижу команды с матрицей, по которой через полгода уже невозможно отличить SEV1 от SEV2, и спор об уровне съедает первые минуты инцидента.

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

Incident Response — уровень определяет интенсивность реакции: собирать ли war room, с каким ритмом писать сводки, нужен ли постмортем.
On-Call Rotation — пути эскалации переплетены со структурой ротации.
Blameless Postmortem — требования к разбору зависят от уровня: у SEV0 постмортем обязателен, с публичной хронологией и ревью на уровне руководства, у SEV3 он необязателен или облегчённый.
Customer Communications — уровень определяет и аудиторию, и ритм внешних сообщений.
Runbooks — матрица уровней входит в структуру runbook; пути эскалации записаны там же.
SLO Engineering — скорость сжигания бюджета питает решение об уровне.
Service Ownership — эскалация идёт по цепочке владения сервисом.
War Room Patterns — SEV0 и выше требуют структурированного war room.
Action Items Tracking — уровень определяет, нужен ли формальный разбор задач по итогам: для SEV0 и SEV1 обязателен, для SEV3 нет.
ChatOps — объявление инцидента слэш-командой (/incident sev1 <описание>) — каноническая команда ChatOps; по уровню сообщение уходит в разные каналы и разным группам дежурных.
Status Page Management — соответствие между внутренним уровнем и публичным статусом компонента (operational / degraded / partial outage / major outage) задаётся формально, а не «по ощущениям».

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

Customer Communications, War Room Patterns и Status Page Management разъехались отсюда в отдельные листья и слинкованы выше.

Severity vs Priority в трекерах (TBD) — как соотносятся тяжесть в момент инцидента и приоритет задачи в бэклоге, куда уезжает follow-up.

Чего у меня нет — критерия, сколько уровней держать в шкале. Число уровней остаётся решением компании, а не универсальным стандартом, и формулировка честная, но выбирать-то всё равно приходится наугад. Здесь же и граница листа: описанная рамка рассчитана на команду с собственным дежурством, а в организации, где инциденты разбирает выделенный отдел, она не работает — там решение об уровне принимает не тот, кто тушит.