ИИ в мониторинге инфраструктуры: как предсказать сбои до их появления

Чем раньше обнаружить вероятность возникновения сбоя в ИТ-инфраструктуре, тем больше шансов его не допустить. Решить эту задачу наиболее эффективно позволяют инструменты предиктивной аналитики в системе зонтичного мониторинга Naumen Business Service Monitoring (BSM). Специальные ML-модели позволяют определить вероятность возникновения сбоев на ранних стадиях. Рассказываем, как это работает.

Прогнозирование метрик: как ML рассчитывает будущее

Один из аналитических инструментов на базе ИИ, который используется в системе Naumen BSM, — это модель прогнозирования. Она анализирует значения метрик оборудования и определяет, как они будут меняться. Если сценарий неблагоприятный, то заранее предупреждает о возможной аварии. Рассмотрим, как обучить ИИ на данных конкретной метрики и учитывать прогнозы на уровне оборудования и сервисов.

Здоровье конфигурационной единицы (КЕ) зависит от одной или нескольких ключевых метрик. Разные показатели постоянно поступают в систему зонтичного мониторинга. Однако, чтобы заметить критичное изменение, нужно неотрывно следить за графиком либо настроить триггер, указав пороговое значение. Тогда важное изменение метрики получится заметить по возникшему событию (алерту).

Чтобы заранее узнавать о вероятных сбоях, нужно подключить ML-модель прогнозирования сбоев в ИТ.

Как подключить к метрике модель прогнозирования:

1. Добавить модель к выбранной метрике.
2. Задать горизонт прогнозирования.
3. Обучить модель на исторических данных.

Горизонт прогнозирования — это период, например, ближайшие несколько часов или дней, на который рассчитывается прогноз. Желаемый горизонт определяет пользователь.

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

Качество прогноза зависит от горизонта прогнозирования и объема исторических данных. Если в системе хранятся данные о поведении метрики лишь за сутки, то модель рассчитает прогноз на неделю с невысокой точностью. А когда данных уже накопилось за неделю или месяц, то прогноз за несколько часов вперед скорее окажется точнее.

Рассмотрим на примере. На здоровье сервера влияет метрика «Память на диске». ИТ-службе необходимо понимать, как будут меняться значения этой характеристики в течение ближайших 4 часов. Такой период выбран потому, что при риске возникновения сбоя специалисты успеют принять предупреждающие меры. Отсюда задается нужный горизонт прогнозирования, модель обучается и выдает график, на котором будет отображаться четырехчасовой прогноз по метрике «Память на диске». График будет перестраиваться в соответствии с частотой расчета, при этом более ранние прогнозы здесь не отображаются, но сохраняются в истории.

Модель прогнозирования дает возможность предотвращать инциденты. В результате сокращается время простоев сервисов и снижаются издержки на восстановление систем.

Детектирование аномалий в ИТ-инфраструктуре

Детектирование аномалий — это инструмент интеллектуальной аналитики в Naumen BSM для обнаружения отклонений в значениях метрик. Он используется для выявления возможных аварий на ранних стадиях, особенно если для данной метрики не настроен триггер с пороговым значением.

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

ML-модель обнаружения аномалий не требует устанавливать границы типичных значений. Она обучается на исторических данных и затем автоматически определяет, какие значения считать аномальными для метрики, учитывая заданный период обучения. Качество анализа зависит от свойств метрики и доступных данных.

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

Как подключить модель детектирования аномалий к метрике:

1. Добавить одну из моделей к нужной метрике.
2. Задать частоту расчета.
3. Обучить модель на исторических данных.
4. Повторить процедуру с одной и несколькими другими моделями.
5. Сравнить результаты разных моделей и выбрать оптимальный вариант.

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

Итог обучения — график с историческими данными, на котором красным выделены точки с нетипичными значениями. Пунктирная линия показывает момент обучения модели.

Например, ИТ-службе необходимо определить границы типичных значений для метрики «Загрузка ЦПУ» сервера. Инженер обучил две ML-модели, получил и сравнил графики. Модель Isolation Forest на одном из участков выделила больше аномальных точек, чем другая, основанная на алгоритме Moving Z-Score. Значит, Isolation Forest лучше подходит для выявления отклонений по этой конкретной метрике.

В дальнейшем алгоритм будет анализировать значения метрики с периодичностью, заданной пользователем. Можно настроить, чтобы система автоматически отслеживала частоту отклонений, тогда при ее повышении (если за короткое время возникает много аномалий) ИТ-служба получит предупреждение о риске сбоя.

ИИ помогает организовать контроль за частотой возникновения аномалий в метриках. Это позволяет заблаговременно узнавать о риске возникновения сбоя и вовремя реагировать на подобные ситуации. Также ML-модели на уровне зонтичного мониторинга могут заменить настройку порогов для метрик или повысить точность определения порогов для тех показателей, пороги которых меняются со временем и требуют периодического пересмотра.

Как результаты ML-моделей превращаются в статусы, события и инциденты

Результаты работы ML-моделей сами по себе — это аналитические выводы. Чтобы они стали действием, система мониторинга должна интерпретировать эти результаты и встроить в привычные для ИТ-специалистов процессы: управление событиями, оценку здоровья оборудования, регистрацию инцидентов.

Разберем, как ML-модели проходят путь от технического сигнала до бизнес-контекста и интеграции с Service Desk.

1. От ML-анализа к событию

На первом этапе результат работы ML-модели — прогноз выхода метрики за допустимые границы или выявленная аномалия — регистрируется в системе как событие. Система фиксирует факт, но не предписывает обязательных действий.

Пример. ML-модель в ЦОД анализирует температуру и нагрузку на серверы. При обнаружении аномального нагрева в серверной стойке и прогнозе превышения температурного порога через 30 минут ИИ регистрирует событие.

2. От события к статусу здоровья оборудования

Оценка здоровья конфигурационной единицы (КЕ) — сервера, коммутатора, базы данных — формируется на основе совокупности событий, связанных с данной КЕ. В расчет принимаются как уже произошедшие сбои или отклонения, так и прогнозы ML-моделей.

Правила влияния прогнозов на статус здоровья настраиваемы. Например, может быть задано правило: при получении от ML-модели неблагоприятного прогноза по критической метрике статус КЕ автоматически переводится в состояние «Предупреждение», даже при отсутствии реальных сбоев.

Пример. ML-модель прогнозирует перегрев серверной стойки через 30 минут, хотя текущая температура в норме. Система регистрирует событие, и статус здоровья серверов автоматически меняется на «Предупреждение» до реального сбоя.

3. От критичности к событию или инциденту

Не каждый предиктивный сигнал требует оперативного вмешательства. Для предотвращения нецелевого использования ресурсов ИТ-служб необходима фильтрация и приоритизация сигналов на основе настроенных правил.

Разберем, как эта логика реализуется Naumen BSM.

Настройка условий срабатывания триггера. В отличие от обычных пороговых значений, в Naumen BSM можно задать сложное условие реакции на событие, объединяющее несколько метрик. Например, создавать инцидент только в том случае, если для этого сработали 2 фактора. Это позволяет отсеивать ложные срабатывания, вызванные единичными отклонениями.

Приоритизация по критичности инцидента. Результаты анализа ML-моделей поступают в систему как события. На этапе обработки им присваивается уровень критичности. Например, «Потенциально недоступно» для прогноза отказа критического сервиса. В Naumen BSM настраивается правило: только события с определенным уровнем критичности инициируют создание инцидента в Service Desk. Остальные регистрируются только для статистики.

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

Но если модель наблюдает устойчивый тренд роста температуры, а прогноз показывает превышение критического порога через 30 минут, это уже квалифицируется как инцидент с приоритетом «Высокий». Система уведомляет дежурного инженера для принятия мер.

4. Бизнес-контекст инцидента: от оборудования к сервису через РСМ

Ключевой принцип целостного подхода — переход от технического восприятия («отказал сервер») к бизнес-ориентированному («пострадал сервис, влияющий на выручку»).

Инструментом для этого служит ресурсно-сервисная модель (РСМ) — схема связей между ИТ-компонентами и бизнес-сервисами, откуда ИИ может брать данные.

Благодаря РСМ система мониторинга на основе прогноза сбоя конкретной КЕ автоматически определяет, какие бизнес-сервисы (платежный шлюз, интернет-банк, CRM-система) зависят от этого компонента.

Пример. РСМ показывает, что в стойке, где произойдет перегрев, находятся серверы платежного шлюза. Система добавляет в инцидент необходимый контекст: «Под угрозой платежный шлюз».

Интеграция с Naumen Service Desk

Финальный этап работы ML-модели — автоматическая передача событий и инцидентов в систему управления ИТ-процессами, например, Naumen Service Desk. В рамках интеграции настраиваются сценарии обработки в зависимости от типа и критичности предиктивного сигнала:

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

В результате ИТ-службы получают возможность оценивать критичность сервисов, находящихся под угрозой из-за прогнозируемого сбоя КЕ, и принимать упреждающие меры до того, как инцидент повлияет на пользователей.

Живой пример: как ML-модели работают на реальных данных

ИТ-служба компании регулярно сталкивалась с внезапным выходом из строя жестких дисков на файловых серверах и серверах баз данных. Простои сервисов вели к прямым финансовым потерям и снижению производительности сотрудников.

Чтобы исправить ситуацию, в Naumen BSM организовали сбор метрик состояния дисков: количество переназначенных секторов, частоту ошибок, температуру. К этим показателям подключили ML-модель прогнозирования и обучили на двухмесячной истории. Горизонт прогноза установили на 24 часа. Также настроили триггер: если модель предсказывает превышение критического порога в ближайшие сутки, создается инцидент высокого приоритета.

В результате внедрения ИИ за следующий месяц получили измеримый результат.

Бизнес перешел к предиктивному управлению одного сегмента ИТ-инфраструктуры и теперь может масштабировать это решение на другие сервисы.

К выводам

ML-модели в Naumen BSM осуществляют прогнозирование сбоев и детектирование аномалий в ИТ-инфраструктуре. На основе данных предиктивной аналитики создаются события, которые обрабатываются в соответствии с правилами, заложенными в системе.

Прогнозы могут влиять на статус здоровья конфигурационной единицы (компонента инфраструктуры) и связанных сервисов, а также на создание запросов и инцидентов в системе класса Service Desk. Таким образом, благодаря предиктивной аналитике ИТ-служба будет заранее получать предупреждения о вероятных сбоях.