Что такое мониторинг и управление событиями и как не утонуть в оповещениях

Зачем мониторинг и управление событиями

У практикиПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 две связанные задачи: знать, в каком состоянии услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation и их части прямо сейчас, и вовремя замечать те изменения этого состояния, которые важны. Первое — наблюдение, второе — работа с событиями.

ITIL формулирует цель так 1. Систематически наблюдать за услугами и их частями. Записывать отобранные изменения состояния — те, что признаны событиями, — и сообщать о них. И назначать нужный отклик, в том числе на условия, которые ещё не стали сбоем, но могут им стать.

MOF добавляет ту же мысль в лоб: услуга, которую нельзя наблюдать, не поддаётся ни измерению, ни управлению 2.

Соединять эти две работы в одну практику разумно, и вот почему. Наблюдение без правил даёт поток цифр, который никто не читает. Правила без наблюдения нечего применять. Между ними стоит порог — значение показателя, при котором срабатывает заранее назначенный отклик 1.

Наблюдение нужно для управления событиями, но не всякое наблюдение даёт событие: что считать событиемСобытиеИзменение состояния, замеченное мониторингом.ITIL 4, решают заданные пороги и правила отбора 1.

Отсюда главная развилка практики. Современные средства позволяют мерить почти всё, и трудность текущего наблюдения — не нехватка данных, а их объём 1. Практика тем зрелее, чем меньше данных доходит до человека и чем важнее то, что доходит.

Когда практика работает

Практику видно по трём признакам, и ни один из них не покажет закупленная система наблюдения.

Про сбой узнают от системы, а не от пользователя. Как проверить: доля инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, заведённых по событию, известна и растёт. Пока эта доля не считается, о состоянии услуг знают ровно то, что рассказали люди.

Оповещение означает работу. Как проверить: по каждому типу оповещения известно, кто и что делает при его получении. Оповещение без назначенного отклика — сообщение в пустоту.

Дежурный не глушит оповещения. Как проверить: число оповещений за смену такое, что их успевают разобрать. Опасность названа прямо: избыточные оповещения топят важное в шуме 1.

Что входит и что рядом

Кто назначает пороги

Ловушка, в которую попадают почти все: пороги задаёт тот, кто настраивает систему наблюдения. Через полгода выясняется, что загрузка диска в 80% считается аварией, а недоступность заказа на сайте не считается ничем.

Разводится это аккуратно: наблюдение отвечает за обнаружение, а целевые значения и пороги по качеству услуги приходят из соседних практик — уровня услуг, доступности, мощности, безопасности, непрерывности; пороги по частям инфраструктуры — из практик инфраструктуры и разработки 1.

Русскоязычный первоисточник формулирует то же через роли: менеджер по мониторингу — эксперт в проведении наблюдения, но не в выборе того, за чем наблюдать 2. Выбор объектов остаётся за теми, кто отвечает за услугу.

Что на входе и что на выходе

Направление здесь важнее перечня. Практика почти ничего не потребляет от соседей, кроме правил и порогов, зато отдаёт данные едва ли не всем: разбору инцидентов, поиску причин, расчёту доступности, планированию мощности, безопасности, отчётности 1.

Отсюда следствие для внедрения: наблюдение, поставленное раньше, чем появились соседи, которым нужны его данные, превращается в дорогую панель, на которую никто не смотрит.

Активное и пассивное наблюдение

Два способа узнавать состояние, и разница между ними практическая 1.

Активное — система наблюдения сама опрашивает элементы по расписанию 5. Раньше замечает тенденции, потому что спрашивает регулярно, а не ждёт сообщения.

Пассивное — элементы сами сообщают о себе, когда с ними что-то происходит 5. Раньше замечает событие: сообщение уходит сразу, а не в следующий опрос.

К этому есть оговорка, которую стоит держать в голове при настройке: чем реже опрос, тем больше задержка между событием и его регистрацией 1. Организация, которая опрашивает раз в пять минут и обещает реакцию за минуту, обещает невозможное.

Три вида событий

События раскладываются по значимости, и от вида зависит отклик 1.

Смысл разделения в фокусе: категории существуют, чтобы внимание доставалось тому, что действительно важно для работы услуг 1. Организация, где все события считаются одинаково срочными, тратит внимание на вход пользователя в систему.

Как это работает

Процессов три: планирование наблюдения, обработка события и разбор 1.

Планирование наблюдения отвечает на вопросы «за чем наблюдаем», «по каким показателям», «какие пороги» и «что делаем при срабатывании» — до того, как первое оповещение придёт человеку 1.

Цвет шага: приём, учёт, работа с обращением техническая работа

Три места стоит объяснить отдельно.

Не всё стоит обнаруживать. Ограничение прямое: обнаруживать нужно критичное и то, на что можно ответить, — в пределах имеющихся сил и пропускной способности систем наблюдения 1.

Фильтрация и связывание идут до классификации. Объединение позволяет считать несколько похожих событий одним, связывание — сгруппировать события по общим последствиям 2. Без этих двух правил один упавший коммутатор даёт сотню оповещений от всего, что за ним стоит.

Разбор крупных событий — отдельная работа. Рассуждение идёт от обратного: крупный инцидент означает, что отклонение либо не заметили, либо не отреагировали, — и значит, есть повод искать показатель, который позволил бы заметить раньше 1.

Модель здоровья услуги

Понятие из «Свободного ITIL», которое стоит вытащить отдельно: модель здоровья — описание состояния элемента с четырёх сторон: доступность, конфигурация, производительность и безопасность 2.

ЦенностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation модели в том, что она переводит разговор с языка систем на язык услуги. Вместо «загрузка процессора 92%» появляется «услуга оформления заказа в жёлтой зоне по производительности». Дальше становится возможно то, ради чего практика и заводится: понятные оповещения и честная панель состояния для тех, кто услугами пользуется.

Собирается модель сверху вниз: какие возможности бизнеса поддерживают продукты и услуги, какие услуги на какую инфраструктуру опираются 1. Без карты зависимостей из CFGУправление конфигурациями эта работа делается по памяти и устаревает вместе с ней.

Что с чем путают

Событие и инцидент. Событие — изменение состояния, значимое для управления 1. Инцидент — незапланированное прерывание или снижение качества услуги. Из события инцидент получается только тогда, когда отклик по правилам говорит «заводи инцидент».

Наблюдение и измерение. Наблюдение отвечает на вопрос «что сейчас», измерение и отчётность — на вопрос «как было за период» и живут в REPИзмерение и отчётность. Стандарт разводит эти слова терминами: мониторинг — определение статуса, измерение — определение величины 3.

Оповещение и событие. Оповещение — сообщение о том, что порог достигнут 1. Событий всегда больше, чем оповещений, и это нормально: часть событий отсеивается, часть уходит в журнал.

Наблюдение и панель. Панель показывает то, что уже собрано. Практика начинается раньше — с решения о том, за чем наблюдать и что считать отклонением.

Кто участвует

Разделение первых двух ролей — то, что чаще всего пропускают. Эксперт по наблюдению отвечает за то, как наблюдать; за то, что важно наблюдать, отвечает владелец услуги 2.

Что должно быть в записи события

• источник — какой элемент или система сообщила;
• время — когда произошло, а не когда заметили;
• вид — информационное, предупреждение, исключение 1;
• тип — от него зависит отклик;
• связь — с какими событиями объединено или связано 2;
• отклик — что было сделано и кем;
• итог — заведён ли инцидент, устранено ли отклонение.

Чем автоматизируется

Практика без автоматизации не существует: наблюдение по расписанию силами человека — это обход серверной с блокнотом.

Отдельная оговорка про обученные модели: их называют средством против избыточных оповещений 1, но и они работают на данных, которые собраны и размечены. Практика, где события не записываются, машинному обучению ничего не даёт.

Как измерять

Два показателя стоит держать рядом: доля инцидентов от наблюдения и число оповещений на дежурного. Первый толкает расширять охват, второй удерживает от того, чтобы утопить людей в шуме.

Шум назван в руководстве своим словом. ITIL 4 ставит среди показателей «число и последствия шума в оповещениях о событиях» 1 — не «избыточные оповещения», а именно шум. Формулировка признаёт то, что дежурные знают и так: оповещение, на которое никто не реагирует, хуже отсутствующего, потому что приучает не реагировать и на остальные.

Отдельный показатель меряет сам подход, а не работу по нему. Первому фактору успеха — есть и поддерживается описание видов событий и способов их обнаружения — служит доля рекомендаций и требований подхода, которые не выполняются или признаны нереалистичными 1. Это редкий случай, когда свод предлагает мерить качество собственного регламента: правило, которое все обходят, сообщает о правиле, а не о нарушителях.

Третий фактор упирается в упущенное. «Последствия инцидентов и проблемПроблемаПричина одного или нескольких инцидентов.ITIL, которые не удалось предотвратить или решить из-за плохого управления событиями» 1 — показатель, ради которого практика и существует. Считается он задним числом и субъективно, зато отвечает на единственный вопрос, который задают при сокращении бюджета: что случится, если наблюдение убрать.

Зрелость мониторинга и управления событиями

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Наблюдают за железом, а не за услугой. Все датчики на серверах, а работает ли оформление заказа — неизвестно. Первый признак: о недоступности услуги узнают от пользователей при зелёной панели.

Оповещений больше, чем можно разобрать. ITIL называет это прямо: важное теряется в шуме 1. Дальше дежурный заводит правило в почте, и практика умирает тихо.

У оповещения нет отклика. Приходит сообщение, а что делать — знает Дима. План действий положено назначать на этапе планирования наблюдения, а не в момент срабатывания 1.

Пороги никто не пересматривал. Значения выставлены при внедрении и живут годами, хотя нагрузка выросла втрое.

Связывание не настроено. Один сбой рождает лавину оповещений от зависимых систем. Лечится объединением и связыванием 2, но это работа, которую надо сделать.

Крупные сбои не разбирают со стороны наблюдения. Инцидент разобрали, причину нашли, а вопрос «какой показатель позволил бы заметить раньше» не задали 1.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит наблюдение и события одной практикой, определяет виды событий и требует назначать отклик заранее 1.

MOF даёт понятие модели здоровья и разводит роли: кто умеет наблюдать и кто решает, за чем наблюдать 2.

ГОСТ Р ИСО/МЭК 20000-1 отдельного процесса управления событиями не содержит: мониторинг определён термином, а требования к нему рассыпаны по разделам про уровень услуг, доступность, мощность, поставщиков и затраты 3.

FitSM поступает так же: наблюдение входит в требования к доступности и мощности, самостоятельным процессом не становится 4.

COBIT относит наблюдение за инфраструктурой к управлению эксплуатацией, а измерение и отчётность выносит в отдельный домен 6.

Вывод для практики: требовать от организации «процесс управления событиями» стандартом не получится — его там нет. Требовать доказательства того, что состояние услуг известно и отклонения замечают, получится по любому из сводов.

Где описано

Что почитать дальше

Три соседние практики, с которыми эта работает в связке: INCУправление инцидентами — куда уходит исключение, CFGУправление конфигурациями — откуда берётся карта зависимостей, AVLУправление доступностью — кто задаёт пороги по доступности.