Event Management: от мониторинга к автоматическим инцидентам

Событие, алерт, инцидент — это не одно и то же

В ITIL 4 событие (event) — любое изменение состояния, значимое для управления услугой. Не каждое событие — проблема. Классическая классификация по типам:

• Информационные — «бэкап выполнен», «деплой прошёл». Логируем, не реагируем.
• Предупреждения (warning) — «диск заполнен на 80%», «латентность растёт». Порог приближается — стоит вмешаться до сбоя.
• Исключения (exception) — «сервис не отвечает», «диск 100%». Это уже сбой → кандидат на инцидент.

Ошибка большинства внедрений — гнать ВСЕ события как алерты и все алерты как инциденты. Получается шум, в котором тонет реальный exception. Event Management начинается с классификации: какие события вообще достойны реакции, а какие — просто запись в лог.

Фильтрация шума и корреляция

Главная ценность Event Management — не «создать тикет на каждый чих», а наоборот: превратить 500 алертов в 3 инцидента. Инструменты:

• Дедупликация — 200 одинаковых алертов «сервер X недоступен» за 10 минут = один инцидент, а не 200.
• Подавление в окно обслуживания — во время планового релиза алерты по затронутым сервисам глушатся (иначе ночной деплой = шквал ложных инцидентов).
• Корреляция — «упал балансировщик» + «5 бэкендов недоступны» = один корневой инцидент по балансировщику, а не шесть.
• Пороги и гистерезис — алерт только если метрика держится выше порога N минут, не на мгновенном спайке.

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

Автоматическое создание инцидента

Когда событие классифицировано как exception и прошло фильтры — оно становится инцидентом автоматически, без участия человека. Типовой путь интеграции в helpdesk:

Мониторинг (Zabbix/Prometheus Alertmanager)
   │  webhook при срабатывании правила
   ▼
ServiceDesk: POST /api/... (или входящий webhook)
   │  маппинг: severity → приоритет, host → услуга/CI
   ▼
Авто-инцидент: назначен на дежурную команду, SLA пошёл

Ключевое — маппинг полей: severity алерта → приоритет инцидента, имя хоста/сервиса → услуга и затронутый CI из CMDB. Тогда инцидент сразу маршрутизируется на нужную команду с правильным SLA. В TIQQET это делается через входящие webhooks/API — Alertmanager шлёт JSON, система создаёт заявку.

Авто-закрытие и обратная связь

Зрелый Event Management работает в обе стороны. Если мониторинг прислал «recovery» (сервис снова доступен) — инцидент, созданный автоматически и ещё никем не взятый, можно автоматически закрыть (флапнул на секунду — не дёргаем людей). Но осторожно:

• Авто-закрывать стоит только инциденты, которые никто не взял в работу и которые были созданы тем же правилом. Взятый оператором инцидент закрывает человек.
• Серия «упал → поднялся → упал» (flapping) — это не «всё ок», а сигнал нестабильности. Такой паттерн лучше эскалировать в проблему, а не молча авто-закрывать каждый раз.

Метрика здоровья процесса — доля авто-созданных инцидентов, подтверждённых как реальные (signal-to-noise). Если 90% авто-инцидентов закрываются как ложные — пороги и корреляция настроены плохо.

С чего начать

Внедрять Event Management имеет смысл поэтапно, не «подключить всё и сразу»:

1. Только критичные сервисы. 5–10 ключевых услуг, по которым простой реально больно. Не весь парк серверов.
2. Сначала уведомление, потом авто-создание. На первом этапе алерт → уведомление дежурному (он сам решает, заводить ли инцидент). Когда правила отлажены — включаем авто-создание.
3. Маппинг host → услуга. Без связи алерта с услугой/CI авто-инцидент бесполезен (некуда маршрутизировать). Это требует актуальной карты услуг.
4. Ревизия раз в месяц. Смотрите топ шумных правил и глушите/правьте их.

Event Management — это мост между «железной» observability и «процессным» ServiceDesk. Сделанный аккуратно, он сокращает время обнаружения сбоя с «когда позвонит пользователь» до «через минуту после события».