🟢 Статус: Conceptually stable · v0.1

Концепция устойчива, проверена опытом, литературой и практикой.

02. Severity = действие

Главный тезис

Если на алерт никто не реагирует — это не алерт. Это метрика.

Понизьте severity, переведите в дашборд, удалите. Что угодно — кроме оставить как есть и продолжать делать вид, что у вас Disaster-алерт.

Большинство Zabbix-инсталляций приходят к одной из двух патологий:

1. Disaster Inflation. 200+ триггеров с severity Disaster, на которые никто не реагирует. Когда падает что-то реально критичное — оно тонет в потоке.
2. Silent Mode. Все алерты выключены или подавлены в каналах, потому что «бесило». Дежурный узнаёт про инциденты от пользователей.

Обе патологии — симптом одной болезни: severity никак не связан с реальным действием.

Правильная модель

Severity описывает что должен сделать человек, получив этот алерт.

Severity	Что значит	Куда летит	Реакция
Disaster	Бизнес-сервис лежит	звонок дежурному + SMS + ITSM P1	< 15 мин
High	Сервис деградирует, скоро ляжет	Telegram/email дежурному	< 1 час
Average	Узел требует внимания, не критично	email команде	в рабочее время
Warning	Тренд, превентив	дашборд, без email	плановая работа
Information	События для аудита	лог-поток, отдельно от алертов	—
Not classified	Временный placeholder или legacy-импорт	не используется в production	—

Not classified — штатная severity Zabbix. В production-триггерах не должна использоваться: её наличие сигнализирует о необработанном импорте или незавершённой настройке.

Заметьте: severity описан через канал и время реакции, не через «насколько страшно». Это потому что «насколько страшно» — субъективно, а «звонок vs email vs ничего» — измеримо.

Что куда

Disaster — бизнес-сервис или критическая инфраструктурная зависимость

Disaster — это «бизнес-сервис лежит». Или критический инфраструктурный сервис, от которого прямо зависит несколько бизнес-сервисов (DC, DNS, core network). Не «хосту плохо». Не «диск 95%». Не «один из десяти процессов упал».

Примеры правильного Disaster:

• 1C-ERP недоступен (синтетика логина падает)
• Exchange не отправляет почту (синтетика mon-out → mon-in)
• Все RPHost'ы упали, кластер 1С неработоспособен
• DC недоступен с трёх разных площадок одновременно
• HASP-лицензии 1С исчерпаны (нельзя логиниться)

Примеры неправильного Disaster:

• Один из десяти RPHost упал (это деградация, High)
• Диск 95% (как правило, High — но если немедленно доказан business impact, например запись встала и сервис упал, то Disaster оправдан)
• CPU 100% на одном из членов кластера (High, не Disaster)
• Свободного RAM нет на одной из VM (High)

High — деградация или скоро упадёт

High — это «через час будет Disaster, если не починить». Или «уже деградация, пользователь чувствует, но сервис работает».

• Очередь почты Exchange растёт быстрее, чем разгребается
• Backup last success > 24 часов при RPO 24 — RPO уже нарушен, это не «риск», а факт нарушения обязательств; сервис работает, но recovery-риск подтверждён
• Один из членов DAG отстаёт на 50+ логов
• Деградация SLA по синтетике (но не полное падение)

Average — техническое внимание

Алерт «утром разберись». Не будит, не звонит.

• Свободное место на диске < 20% (но > 10%)
• Один из не-критичных сервисов упал
• Запоздавшая антивирусная база на нескольких хостах
• Конфиг изменился — нужно ревью

Warning — тренд

Алерт в дашборд, не в email. Никого не будит.

• Рост утилизации CPU за неделю на 20%
• Прогноз заполнения диска через 30 дней
• Аномалия в трафике (не критичная)

Information — аудит

Логирование событий, которые нужно знать, но реагировать не нужно.

• Изменения в группах безопасности AD
• Логин в Zabbix под учётной записью администратора
• Изменение шаблона в Zabbix

Важно: в Zabbix Information — это всё равно trigger severity, которая создаёт Problem/Event. Для аудитных целей иногда правильнее использовать audit log Zabbix, event stream или report, а не Problem-события: они захламляют ленту Problems и могут мешать дежурному видеть реальные инциденты.

Правило runbook'а

Каждый Disaster обязан иметь ссылку на runbook прямо в описании триггера. Для High — обязательно для новых триггеров, целевой стандарт для существующих.

В Zabbix ссылка хранится в поле Menu entry URL триггера, а в уведомления попадает через макрос {TRIGGER.URL}.

Description: 1С-ERP сервис недоступен. Runbook: {TRIGGER.URL}
Menu entry URL: https://wiki.example.com/runbooks/1c-erp-down

Дежурный получает алерт → видит ссылку → за 30 секунд открывает runbook → читает первые 3 строки → действует.

Для Disaster это жёсткое правило: нет runbook'а — нет алерта. Для High — целевой стандарт: новые триггеры без runbook'а не принимаются, старые мигрируются партиями.

Подробно о runbook'ах — глава 9.

Как проверить, что severity у вас осмыслен

Один простой эксперимент, занимает полдня:

1. Выгрузите все события за последние 90 дней по severity и тегам триггеров
2. Для каждого Disaster/High посчитайте: сколько раз сработал, сколько раз была реальная цепочка — Problem event → acknowledge/update → тикет/изменение/worklog → recovery
3. Любой Disaster с 0 действий за 90 дней — это не Disaster

Учтите: реальные действия могут жить в ITSM, а не в Zabbix. Если у вас есть интеграция с ServiceDesk, метрику "действие" считайте по цепочке в обоих системах.

Для этого есть готовый скрипт zbx_audit_now.py в репозитории книги — он выгружает в CSV все активные проблемы со severity и тегами, дальше можно крутить в Excel или pandas.

Как чистить severity inflation

Если вы заходите в проект и видите 200+ Disaster-триггеров, не чистите их в первый месяц. Это типовая ошибка.

Правильный порядок:

1. Месяц 1 (Discovery): read-only, инвентаризация, выгрузка статистики срабатываний (см. глава 7)
2. Месяц 2 (Стандартизация): сначала делаете tag schema, шаблоны, severity model на бумаге. Потом переключаете старые триггеры
3. Месяц 3 (Покрытие): новые триггеры уже в правильной модели; старые — мигрируются партиями

Иначе будет вечная переделка: почистили → перенастроили шаблоны → опять чистить.

Резюме

• Severity описывает действие, не субъективную оценку серьёзности
• Disaster — только когда бизнес-сервис лежит или отказала критическая инфраструктурная зависимость, не «компонента грустно»
• Disaster обязан иметь runbook; для High — обязателен для новых триггеров, целевой стандарт для существующих
• Любой алерт без действий за 90 дней — не алерт
• Severity inflation чистится после стандартизации шаблонов, не до

См. также: глава 9 — Runbooks, глава 12 — Эксплуатационная модель мониторинга.