На крупной распределенной инфраструктуре дежурный инженер нередко получает несколько сотен алертов в день, и до трети из них — дубликаты одного и того же события, зафиксированного разными системами мониторинга. Это не сбой процесса, а закономерный результат того, как устроен мониторинг на пороговых правилах: каждый компонент сигналит о своей части проблемы отдельно, и инженер получает не диагноз, а поток разрозненных фактов, из которых диагноз нужно собрать самому. Час простоя при этом обходится российским IT- и телеком-компаниям в среднем в 21,7 млн рублей, а восстановление после серьезного инцидента может растянуться на две недели.
Обнаружение аномалий на основе искусственного интеллекта решает именно эту проблему — не нехватку данных, а их интерпретацию. Вместо десятков алертов о симптомах модель машинного обучения анализирует логи, метрики и трейсы одновременно, связывает их в единый инцидент и указывает вероятную причину. На практике это дает соотношение событий к инцидентам порядка 100:1 — из ста разрозненных сигналов система формирует один инцидент с указанием затронутых компонентов и предполагаемого источника проблемы. Дальше в статье разбираем, как это работает технически: какие алгоритмы стоят за обнаружением аномалий, как строится анализ коренных причин и что показывает практика компаний, уже прошедших этот переход.
Читайте нашу статью «Кабинет инцидента: рабочее место SRE-инженера».
От мониторинга до AIOps: краткая история
Первые системы мониторинга ИТ-инфраструктуры появились в начале 2000-х как ответ на простую задачу: узнать, что сервер упал, раньше, чем об этом сообщит пользователь. Zabbix, выпущенный в 2004 году, и его предшественники строились на модели опроса устройств по SNMP и агентам с фиксированными триггерами — метрика превысила порог, система отправила уведомление. Для инфраструктуры из десятков физических серверов этого было достаточно: количество компонентов и связей между ними человек мог держать в голове.
Ситуация изменилась с переходом на микросервисы и облачные платформы. Один пользовательский запрос стал проходить через десятки сервисов, и локальная метрика одного компонента перестала объяснять поведение системы в целом. Ответом на это стала концепция Observability — наблюдаемости, которая ввела три обязательных источника данных: метрики, логи и трейсы, дающие возможность не просто зафиксировать сбой, а восстановить путь запроса и понять, где именно он пошел не так.
Наблюдаемость решила проблему видимости, но не проблему объема. К середине 2010-х крупные инфраструктуры генерировали терабайты телеметрии в день, и разбор такого объема вручную стал физически невозможен даже для observability-инструментов с хорошей визуализацией. В 2016 году аналитическая компания Gartner ввела термин AIOps — Artificial Intelligence for IT Operations — как обозначение нового класса платформ, которые применяют машинное обучение не для сбора данных, а для их интерпретации: корреляции событий, снижения шума и автоматического поиска первопричины.
Индустрия описывает этот путь как модель зрелости из нескольких уровней: от консолидации разрозненной телеметрии в единую шину, через интеллектуальный мониторинг с обнаружением аномалий и дедупликацией алертов, к автоматизированному анализу первопричин и, на верхнем уровне, к частичной автономии системы — самостоятельному исполнению сценариев реагирования для проверенных классов инцидентов. Большинство компаний сегодня находятся между вторым и третьим уровнем: аномалии обнаруживаются автоматически, но окончательное решение о действии остается за инженером.
Отдельная веха этой эволюции — российский рынок. До 2014 года около 90% коммерческих проектов ИТ-мониторинга строились на зарубежном программном обеспечении, и лишь около 10% — на бесплатных решениях. После 2022 года эта пропорция изменилась кардинально: западные вендоры ушли, и отечественные AIOps-платформы прошли путь от функциональных аналогов до самостоятельных продуктов с собственной архитектурой корреляции и RCA. Таким образом путь от Zabbix-триггера до модели, которая сама находит причину сбоя, занял чуть больше двадцати лет — и на российском рынке этот путь пройден в сжатые сроки, параллельно с общим переходом индустрии от мониторинга к ИИ.
Три источника телеметрии, на которых строится ИИ в мониторинге
AIOps-платформа в ИТ-инфраструктуре.
AIOps — тот самый уровень зрелости мониторинга, о котором шла речь выше, — на практике означает конкретный набор технологий: модели машинного обучения и глубокого обучения, которые обучаются на телеметрии инфраструктуры и находят в ней закономерности без заранее прописанных правил. Такая модель никогда не работает с одним типом данных изолированно — она сопоставляет несколько потоков одновременно, и именно это отличает ее от классического дашборда с отдельными графиками для CPU, логов и задержки.
Три потока, которые модель анализирует совместно:
- Метрики — числовые ряды CPU, памяти, задержки, дисковых операций.
- Логи — текстовые записи событий, ошибок, предупреждений сервисов.
- Трейсы — путь запроса через цепочку микросервисов.
Совместный анализ этих потоков в отрасли называют Observability. Это не синоним мониторинга, а следующий уровень: мониторинг ИТ инфраструктуры отвечает на вопрос «что случилось», наблюдаемость — на вопрос «почему это случилось и где искать причину». AIOps добавляет к observability слой автоматической интерпретации: вместо того чтобы инженер сопоставлял три графика вручную, модель делает это сама и выдает готовую гипотезу о причине инцидента.
Под каждый тип телеметрии в AIOps-платформах применяется отдельный класс алгоритмов. Для числовых метрик — методы обучения без учителя, которые не требуют размеченных примеров аварий: штатных периодов работы системы всегда в разы больше, чем инцидентов, и модель должна распознавать норму без готовых образцов сбоя. Три рабочих подхода на практике:
- Isolation Forest — строит случайные деревья решений и оценивает, насколько быстро точка данных отделяется от основной массы значений.
- Автоэнкодер — обучается воссоздавать нормальное поведение системы; резкий рост ошибки реконструкции сигнализирует об отклонении.
- DBSCAN — группирует поведение по плотности и выделяет точки, не попавшие ни в один кластер.
Вариационные автоэнкодеры особенно полезны там, где нормальное поведение системы само меняется — например, у ритейлера с сезонными пиками нагрузки. Такая модель не путает плановый скачок трафика с реальной проблемой, в отличие от фиксированного порога. Для логов и трейсов применяются другие семейства моделей — трансформерные архитектуры и графовые нейросети, — о них подробнее в следующих разделах.
Анализ коренных причин: как граф зависимостей заменяет перебор гипотез
RCA (Root Cause Analysis) — самая затратная по времени часть реагирования на инцидент в мониторинге, потому что сбой одного компонента проявляется симптомами в совершенно другой части системы. Инженер, ищущий причину вручную, идет по цепочке гипотез — проверяет базу данных, потом кэш, потом сетевой сегмент — и часто теряет часы на компонентах, которые ни при чем, просто потому что симптом (рост задержки на фронтенде) находится дальше всего от источника (утечка соединений во внутреннем сервисе).
Граф зависимостей — это модель инфраструктуры, где каждый сервис, база данных или очередь сообщений представлены узлом, а связь между ними (вызов API, обращение к хранилищу, передача события) — ребром. В отличие от статичной диаграммы архитектуры, которую инженеры рисуют вручную и обновляют раз в квартал, граф в AIOps-платформе строится автоматически из реальной телеметрии и меняется в реальном времени: если сервис перестал вызывать соседа или появился новый маршрут запроса, граф отражает это без участия человека. Именно эта динамичность делает граф пригодным для микросервисной архитектуры, где состав и связи компонентов меняются с каждым релизом.
Сам поиск первопричины на графе строится на двух дополняющих принципах — топологии и времени. Топология показывает, какие узлы физически связаны и могут влиять друг на друга; время показывает, в какой последовательности на этих узлах появились отклонения. Модель сопоставляет оба измерения: если аномалия в сервисе А зафиксирована на две минуты раньше, чем скачок задержки в сервисе Б, и между ними есть ребро в графе, — это сильный кандидат на причинно-следственную связь, а не просто совпадение по времени.
Графовые нейросети с механизмом внимания работают на этой структуре иначе, чем инженер, перебирающий гипотезы по одной. Модель не проверяет компоненты по порядку, а распространяет сигнал аномалии по всему графу одновременно, оценивая, через какие узлы и ребра он проходит сильнее всего. Механизм внимания присваивает каждому узлу вес — степень его вклада в наблюдаемую проблему, — и в результате модель указывает не список подозреваемых, а конкретный узел с максимальным весом как наиболее вероятную первопричину.
Отдельный класс моделей — байесовские сети — решает ту же задачу через вероятностный подход: вместо жесткого вывода «виноват узел X» система рассчитывает вероятность для каждого узла графа быть источником проблемы, опираясь на исторические данные о том, как часто сбой в одном компоненте действительно приводил к наблюдаемому набору симптомов в других. Это особенно полезно, когда несколько компонентов демонстрируют аномальное поведение одновременно и нужно ранжировать их по степени вероятной ответственности, а не выбирать единственный вариант. На практике именно сочетание топологического графа, каузального анализа время+топология и вероятностного ранжирования сокращает время диагностики с часов до минут: инженер получает не гипотезу для проверки, а готовый ранжированный список кандидатов с указанием, почему модель считает именно этот узел первопричиной.
Обнаружение угроз безопасности через поведенческие аномалии
Не любая аномалия в облачной среде — это техническая неполадка. Часть отклонений, которые находит модель, — это ранние признаки атаки, и отличить одно от другого по единственному сигналу почти невозможно. Резкий скачок задержки может означать перегрузку сервиса, а может — сканирование инфраструктуры перед эксплуатацией уязвимости; разница видна только при сопоставлении нескольких потоков данных одновременно.
Подходы UBA (User Behavior Analytics) и UEBA (User and Entity Behavior Analytics) решают эту задачу через построение базовой линии — профиля типичного поведения для каждого пользователя, сервисной учетной записи или виртуальной машины: в какое время она обычно активна, к каким ресурсам обращается, какой объем данных передает. Кластерный анализ затем ищет объекты, которые выпадают из этого профиля, — не по одному параметру, а по совокупности признаков.
Показательный сценарий: виртуальная машина в два часа ночи начинает скачивать объем данных, в разы превышающий обычный дневной трафик, и в тот же промежуток система фиксирует всплеск нетипичных DNS-запросов с этого же хоста. По отдельности ни первое, ни второе не вызвало бы алерт — ночная выгрузка может быть плановым бэкапом, а нестандартный DNS-запрос — следствием обновления конфигурации. Совпадение двух отклонений в одном временном окне и на одном узле — это уже конкретный, проверяемый сигнал возможной утечки данных, который модель UEBA выявляет автоматически, а не постфактум, когда инцидент уже случился.
Экономика внедрения: во что обходится переход на ИИ-мониторинг
Внедрение ИИ-мониторинга — это инвестиция с измеримой отдачей, и расчет этой отдачи строится на понятной формуле: экономия равна разнице MTTR до и после внедрения, умноженной на количество инцидентов в год и на стоимость часа простоя. Из этого следует, что чем выше стоимость простоя для конкретного бизнеса, а для IT и телекома она измеряется десятками миллионов рублей в час, тем быстрее окупается платформа даже при умеренном сокращении времени восстановления.
Полная стоимость владения складывается не только из лицензии. В нее входят интеграция с существующими системами мониторинга, время команды на настройку и адаптацию ML-моделей под конкретную инфраструктуру, обучение инженеров — обычно одна-две недели — и последующее сопровождение. Оценивать эту стоимость стоит на горизонте трех лет: только на таком сроке видна честная картина окупаемости, потому что моделям требуется от трех до шести месяцев на обучение на данных конкретной инфраструктуры, прежде чем точность детекции выходит на плановый уровень.
Практика внедрений показывает три этапа, которые редко пропускают без потерь в качестве результата. Пилот на ограниченной части инфраструктуры длится один-два месяца и дает первую оценку эффекта на реальных данных. Полное внедрение с интеграцией в ITSM-процессы и настройкой автоматических реакций занимает три-шесть месяцев. Оптимизация — дообучение моделей и расширение сценариев автоматизации — растягивается на срок до года, и именно на этом этапе прогнозный ROI превращается в измеримый. Попытка сократить эти сроки обычно приводит не к ускорению эффекта, а к завышенным ожиданиям на первых неделях, когда модель еще не набрала достаточно данных о нормальном поведении конкретной системы.
ИИ в ИТ-мониторинге: российский опыт
После 2022 года российский рынок ИТ мониторинга прошел волну замены западных решений на отечественные аналоги, а к 2025–2026 году начался переход от «просто рабочего» инструмента к зрелым платформам с поддержкой и SLA. Ключевой запрос со стороны бизнеса — не просто скорость обнаружения аномалии, а объяснимость: почему модель приняла именно это решение, особенно если речь идет о критической инфраструктуре, подпадающей под требования ФСТЭК.
Аналитический рейтинг TAdviser за 2026 год охватил 15 крупнейших поставщиков систем мониторинга и управления ИТ-инфраструктурой с суммарной выручкой рынка свыше 6,1 млрд рублей — это подтверждает, что технология вышла из стадии пилотов в стадию промышленной эксплуатации. Параллельно усиливается тренд на сближение AIOps и информационной безопасности: события мониторинга и защиты данных все чаще обрабатываются в едином контуре, а не в двух изолированных системах.
На этом рынке уже работают отечественные AIOps-платформы, реализующие описанные выше принципы в производственном виде. Например, российская платформа Artimate решает задачу зонтичного мониторинга: подключается к уже установленным у клиента системам — Zabbix, wiSLA, «Пульт», UDV ITM — без замены существующего стека, нормализует данные из них и строит единую ресурсно-сервисную модель инфраструктуры, которая обновляется автоматически при каждом изменении топологии. Поверх этой модели работает ML-аналитика: детекторы аномалий временных рядов, последовательности и плотности событий, а также RCA-движок на основе байесовских вероятностных моделей и графа зависимостей, который отличает прямые причины инцидента от косвенных корреляций.
Снижение информационного шума достигает 95% — тысячи разрозненных событий превращаются в единицы инцидентов, а сокращение MTTR за счет автоматического RCA составляет 50–70%. Показательна и экономика: снижение операционных затрат на эксплуатацию инфраструктуры оценивается в 30–40%, а повторяющиеся инциденты — те, что раньше устранялись симптоматически, без устранения причины, — сокращаются до 67% благодаря точному определению первопричины, а не временной заплатке на симптом.
Обнаружение аномалий и анализ первопричин на основе ИИ перестали быть конкурентным отличием отдельных технологических гигантов — это рабочий стандарт для любой компании, где простой инфраструктуры измеряется не минутами, а прямыми потерями выручки. По прогнозу Gartner, к 2029 году 85% крупных предприятий будут использовать AI SRE-инструменты — против менее 5% в 2025 году, и разница между командами теперь не в наличии модели, а в том, насколько быстро она проходит путь от пилота до измеримого влияния на MTTR.
