Сообщить об ошибкеКороткий ответ
Severity — это объективная оценка влияния инцидента на пользователей/бизнес прямо сейчас (сколько пользователей затронуто, есть ли потеря данных, критична ли функция), а шкала серьёзности нужна, чтобы заранее определить, кого эскалировать, как быстро реагировать и когда коммуницировать клиентам.
Как это работает подробнее
типичная шкала — от SEV1 (критический, массовый отказ или потеря данных, требуется немедленная реакция и эскалация руководству) до SEV4 (незначительное влияние, можно чинить в рабочее время). Шкала заранее определяет пороги: сколько пользователей затронуто, есть ли обходной путь, затронуты ли деньги/безопасность/данные.
Пример / кейс
Ожидаемое поведение: дежурный, увидев алерт "ошибки в отчёте для 2% пользователей", присваивает SEV3 согласно заранее описанным критериям и не поднимает всю команду среди ночи, в отличие от алерта о полном отказе оплаты.
Пример кода
SEV1: полный отказ оплаты для всех пользователей — эскалация немедленно, статус-страница обновляется.
SEV3: ошибки в редко используемом отчёте для 2% пользователей — фикс в рабочее время, без эскалации руководству.Что использовать на практике
- Практический подход. Шкала серьёзности убирает субъективность в момент инцидента — дежурному не нужно решать "это важно или нет", он сверяется с заранее согласованными критериями. От severity зависит, нужно ли поднимать дополнительных людей по эскалации, уведомлять ли клиентов статус-страницей, нужен ли пост-инцидентный разбор.
Подводные камни
- Частые ошибки. Присваивать высокую severity любому алерту "на всякий случай", что приводит к усталости от ложных тревог; не иметь формализованной шкалы вообще, из-за чего разные дежурные по-разному оценивают одинаковые инциденты; путать severity с приоритетом разработки фичи — это разные шкалы для разных процессов.