event

Событие в ITSM — это фиксируемое изменение состояния в услуге или конфигурационной единице, которое важно для управления и принятия решений. Источником события обычно выступает мониторинг: инфраструктурные компоненты, приложения, средства информационной безопасности, облачные сервисы, а также средства наблюдаемости. События используются, чтобы обнаруживать отклонения от нормального функционирования, подтверждать работоспособность, измерять доступность и производительность, инициировать реакцию команды поддержки или автоматизацию. В практике управления мониторингом и событиями события фильтруют, коррелируют и обогащают контекстом (например, связью с услугой и зависимостями), после чего на их основе создают обращение в сервис-деск, инцидент или выполняют сервисную операцию автоматически. Важная область применения — проактивное управление: по сериям предупреждающих событий можно предотвратить сбой и избежать инцидента. При этом событие не описывает ценность или результат для заказчика само по себе и не является изменением как таковым: оно лишь сигнализирует о смене состояния. Вне рамок термина находятся согласование и реализация изменения, анализ коренной причины проблемы, а также выполнение запроса на обслуживание, если нет значимого изменения состояния услуги или конфигурационной единицы.

Событие часто ошибочно приравнивают к инциденту. Инцидент — это незапланированное прерывание услуги или снижение качества услуги, тогда как событие может быть как нормальным (информационным), так и предупреждающим, и лишь иногда указывает на инцидент. Типичная ошибка — автоматически создавать инцидент по любому событию, что приводит к «шуму» и перегрузке сервис-деска; корректнее настроить пороги, дедупликацию и корреляцию, а также правила эскалации только для действительно значимых событий. Другая путаница — смешение события и изменения: изменение — это контролируемое внесение модификации в услугу или конфигурацию, а событие может быть просто фактом, что состояние уже изменилось (в том числе из‑за сбоя). Также важно помнить, что не каждое событие должно иметь долгоживущую запись: некоторые события обрабатываются автоматически и нужны лишь для краткосрочной диагностики, тогда как ключевые события для управления доступностью, производительностью и риском должны сохраняться для измерения и отчётности. Наконец, событие не равно «сообщение мониторинга»: один и тот же факт может порождать множество низкоуровневых сигналов, которые следует агрегировать в одно значимое событие на уровне услуги.