Практика «Мониторинг и управление событиями» часто воспринимается прежде всего как поставщик данных: она обнаруживает события в ИТ-инфраструктуре и передает информацию другим практикам таким как управлению инцидентами, проблемами, доступностью, мощностями и другим. Эта информация служит, в том числе, и для расчета метрик этих практик. Но возникает закономерный вопрос: а как понять, насколько хорошо работает сам мониторинг?
Количество собранных метрик и число конфигурационных единиц, охваченных мониторингом, сами по себе мало говорят о качестве практики. Гораздо важнее оценивать, помогает ли мониторинг своевременно обнаруживать значимые события, правильно их интерпретировать и запускать необходимые действия, то есть насколько практика выполняет свое назначение.
Для того, чтобы понять, насколько практика выполняет своё назначение, необходимо оценить достижение факторов успеха практики. Для практики мониторинг и управление событиями их три:
1. Модели событий и возможности мониторинга
Первый фактор — наличие и актуальность подходов и моделей, описывающих, что именно необходимо отслеживать и как это обнаруживать.
Здесь можно измерять долю критичных объектов и типов событий, для которых определены правила мониторинга. Например, для 95% критичных сервисов должны существовать модели, описывающие контролируемые показатели, пороговые значения и возможные реакции.
Еще одна полезная метрика — актуальность моделей мониторинга: доля правил, пересмотренных после изменений в инфраструктуре или сервисах.
Измерять такие показатели можно автоматически, сопоставляя CMDB, каталоги сервисов и системы мониторинга. При обнаружении нового критичного компонента без соответствующего мониторинга система может автоматически формировать задачу ответственному специалисту.
Например, после внедрения нового сервера он должен автоматически попасть в систему мониторинга и получить необходимый набор метрик для контроля.
2. Своевременные, релевантные и достаточные данные
Второй фактор показывает, получают ли заинтересованные стороны именно те данные, которые им нужны для управления.
Здесь важны метрики полноты и качества мониторинга. Например:
- доля критичных сервисов, покрытых мониторингом;
- доля показателей, по которым данные поступают без пропусков;
- процент «шумных» событий, не требующих действий;
- доля событий, для которых определен получатель или ответственная практика;
- задержка между возникновением события и поступлением информации о нем в систему мониторинга.
Особенно полезна метрика доля ложных или нерелевантных событий. Если система генерирует тысячи предупреждений, но большинство из них не приводит ни к каким действиям, мониторинг создает нагрузку вместо ценности.
Не следует забывать и про удовлетворенность заинтересованных сторон качеством информации мониторинга и её представлением.
Для измерения можно использовать платформы мониторинга и наблюдения, AIOps и системы управления ИТ-услугами. Они позволяют автоматически собирать события, коррелировать их, рассчитывать показатели и строить дашборды.
Например, снижение количества событий на 30% не обязательно означает улучшение. Если одновременно выросла доля пропущенных критичных событий, результат отрицательный. Поэтому метрики нужно рассматривать в комплексе.
3. Быстрое обнаружение, интерпретация и реакция
Третий фактор показывает, насколько быстро мониторинг превращает технический сигнал в управляемое событие и необходимое действие.
Здесь особенно полезны временные показатели:
- время от возникновения события до его обнаружения;
- время от обнаружения до классификации;
- время от классификации до начала необходимых действий;
- доля событий, обработанных автоматически;
- доля критичных событий, на которые отреагировали в установленный срок.
Например, отказ диска может быть обнаружен системой мониторинга за несколько секунд, автоматически классифицирован как критическое событие и будет запущена процедура замены диска. В этом случае мониторинг действительно выполняет свое назначение: он позволяет предотвратить или минимизировать последствия инцидента.
Для автоматизации применяются корреляция событий, автоматическая классификация, сценарий автоматизации и интеграция с ITSM-системой.
Ниже таблица, которую можно использовать как практический инструмент при оценке зрелости практики «Мониторинг и управление событиями».
| Фактор успеха | Метрика | Формула расчета | Источник данных | Пример целевого значения |
| 1. Создание и поддержание подходов/моделей событий и возможностей мониторинга | Покрытие критичных объектов мониторингом | Кол-во критичных объектов, для которых настроен мониторинг / общее кол-во критичных объектов × 100% | CMDB, система мониторинга, каталог услуг | ≥ 95% |
| Покрытие критичных типов событий правилами обнаружения | Кол-во типов событий с определенными правилами / общее кол-во выявленных критичных типов событий × 100% | Система мониторинга, журнал событий | ≥ 90% | |
| Актуальность моделей мониторинга | Кол-во моделей, пересмотренных в установленный срок / общее кол-во моделей × 100% | Система управления конфигурациями, реестр моделей | ≥ 95% | |
| Доля изменений с актуализацией мониторинга | Кол-во изменений, после которых необходимые правила мониторинга были актуализированы / общее кол-во изменений, требующих актуализации × 100% | ITSM-система, CMDB, система мониторинга | ≥ 95% | |
| 2. Обеспечение своевременного, релевантного и достаточного объема данных мониторинга для соответствующих заинтересованных сторон | Доля критичных сервисов, покрытых мониторингом | Кол-во критичных сервисов с необходимым набором метрик / общее кол-во критичных сервисов × 100% | Каталог услуг, система мониторинга | ≥ 95% |
| Доступность данных мониторинга | Время, когда данные доступны / общее время, когда данные должны быть доступны × 100% | Система мониторинга | ≥ 99% | |
| Доля нерелевантных событий | Кол-во событий, не потребовавших действий / общее кол-во событий × 100% | Система мониторинга, ITSM | ≤ 20% | |
| Доля событий без назначенного получателя | Кол-во событий, для которых не определен ответственный / общее кол-во событий × 100% | Система мониторинга, ITSM | ≤ 2% | |
| Задержка поступления данных мониторинга | Среднее время от возникновения события до его регистрации системой мониторинга | Система мониторинга, логи источников | ≤ 1 мин. для критичных событий | |
| Уровень удовлетворенности заинтересованных сторон данными мониторинга | Средняя оценка удовлетворенности по результатам опроса заинтересованных сторон по шкале от 1 до 5. | Опросы владельцев услуг, команд эксплуатации, Service Desk и других заинтересованных сторон | ≥ 4 (из 5) | |
| 3. Обнаружение, интерпретация и принятие мер как можно быстрее | Среднее время обнаружения события (MTTD) | Суммарное время от возникновения события до обнаружения / количество событий | Система мониторинга, логи | ≤ 5 мин. для критичных событий |
| Среднее время интерпретации/классификации события | Суммарное время от обнаружения до классификации / количество событий | Система мониторинга, ITSM | ≤ 2 мин. | |
| Среднее время начала реакции | Суммарное время от обнаружения до начала действия / количество событий | ITSM, система мониторинга | ≤ 5 мин. для критичных событий | |
| Доля событий, обработанных автоматически | Кол-во событий, для которых действие выполнено автоматически / общее кол-во событий, требующих действия × 100% | AIOps, ITSM, системы автоматизации | ≥ 50% | |
| Доля критичных событий с реакцией в установленный срок | Кол-во критичных событий, обработанных в пределах SLA общее кол-во критичных событий × 100% | ITSM, система мониторинга | ≥ 95% | |
| Доля инцидентов, которые не удалось предотвратить из-за неэффективного управления событиями | Кол-во событий, по которым не были предприняты действия, что привело к возникновению инцидентов/ общее кол-во инцидентов × 100% | ITSM, мониторинг, база инцидентов | ≥ 30% |
Несколько важных оговорок для использования таблицы
1. Приведенные в таблице целевые значения — это только примеры, а не универсальные нормативы.
Например, значение MTTD 5 минут может быть нормальным для одного сервиса и совершенно неприемлемым для другого. Целевые значения следует определять с учетом критичности услуги, требований SLA и стоимости последствий отказа.
2. Не стоит оценивать практику по одной метрике.
Например, снижение MTTD может выглядеть как улучшение, но одновременно может резко вырасти количество ложных событий. Поэтому показатели скорости нужно рассматривать вместе с показателями релевантности и качества мониторинга.
3. Для оценки особенно полезны тренды.
Например, не столько важно, составляет ли доля нерелевантных событий 15% сегодня, сколько то, снижается ли она с 30% до 15% в результате совершенствования правил корреляции.
4. Для оценки зрелости можно добавить показатель автоматизации измерений.
Если данные собираются автоматически из мониторинга, CMDB и ITSM, то такие показатели значительно надежнее, чем если его рассчитывают вручную по выборке.
Метрики должны показывать ценность, а не активность
Хорошая система измерений мониторинга не ограничивается количеством КЕ, событий или созданных правил. Эти показатели характеризуют скорее активность практики.
Гораздо важнее связать метрики с ее назначением: помогает ли мониторинг своевременно получать качественную информацию и предотвращать негативное влияние событий на услуги.
Поэтому зрелая практика измеряет не только то, сколько событий она обнаружила, но и то, какие из них были действительно значимыми, насколько быстро на них отреагировали и какой результат это дало для ИТ-услуг и бизнеса.
