Знакомая проблема? Аномалия в большом микросервисном приложении вызывает шквал предупреждений, так как это затрагивает сервисы по всему миру. Ваше приложение содержит миллионы зависимостей, как найти исходную ошибку? Обычные инструменты мониторинга не справляются. Они собирают метрики и выдают оповещения, но дают мало ответов о том, что где конкретно искать проблему.

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

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

Вместо шквала сообщений об аномалиях – анализ причин и ответ где искать ошибку.

Автоматизируйте устранение аномалий и оптимизируйте производительность, опираясь на состояние ИТ-системы и реальные потребности пользователей.

Ускорьте инновации и выпускайте качественное ПО, используя APM на основе нейросети и регрессивное тестирование.

Грамотно интерпретированные данные бизнес-аналитики помогут улучшить клиентский опыт, а еще помогут настроить автоматическое устранение поломок и рекламных компаний.

Концепция автоматизации операций направлена ​​на эффективное устранение неполадок с конечной целью сокращения среднего времени восстановления (MTTR). Это достигается за счет автоматического обнаружения аномалий и оповещения, то есть ускорения среднего времени до обнаружения (MTTD). Однако для дальнейшего снижения MTTR требуется автоматический анализ первопричин.

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

Определение порогов аномалий оказывается сложной задачей, требующей расширенной статистики, такой как машинное обучение. В современных микросервисных архитектурах один сбой влияет на множество подключенных сервисов, которые впоследствии также выходят из строя. Таким образом, одна проблема обычно вызывает множество предупреждений. Это называется шквалом предупреждений (storm alert).

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

Единственный выход — метод автоматического определения причины ошибки. Существует два очень подхода к уменьшению шума от предупреждений на основе нейросети

Детерминированная нейросеть

Машинное обучение нейросети

В среде разрозненных инструментов мониторинга команде приходится разбираться во множестве различных входных данных, поступающих из разных источников. Это увеличивает вероятность ошибки при анализе ситуации и диагностике. В настоящее время отслеживается только 5% приложений. Цель состоит в том, чтобы получить полную сквозную видимость.

Полная наблюдаемость системы является необходимым условием для автоматизации операций, включая надежное самовосстановление. Нам нужно полное представление не только о приложении, включая контейнеры и функции-услуги, но и обо всех уровнях инфраструктуры, сетей, конвейера CI/CD и реального взаимодействия с пользователем. Во многих случаях сам сбор данных осуществляется бесплатно, поскольку поставщики общедоступных служб предлагают API-интерфейсы для мониторинга, а инструменты с открытым исходным кодом доступны в изобилии. Тем не менее, следующие пункты имеют решающее значение для автоматизации:

Чтобы выполнить настоящий анализ первопричин, собранные данные должны быть точными (минимальная выборка или без выборки) и контекстно-насыщенными, чтобы создавать топологию в реальном времени и service flow maps.

Топология

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

Карта Service flow

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

Предприятия без нейросети пытаются совершить невозможное. Gartner прогнозирует, что 30% ИТ-организаций, которые не смогут внедрить ИИ, станут терять жизнеспособность уже к 2022 году. По мере того, как предприятия генерирует огромный объем данных, сложность среды делает ручной мониторинг все более изощренным для людей.

Чтобы AIOps работал идеально, нам нужна система, которая может не только определять, что что-то не так, но и точно определять истинную причину. Современные высокодинамичные микросервисные архитектуры работают в гибридных средах. Инфраструктура и службы запускаются и отключаются в мгновение ока по мере необходимости. Определение первопричины аномалии требует экспоненциально больше усилий, чем может сделать человек.

Анализ первопричин с помощью детерминированной нейросети

Нейросеть Dynatrace — использует топологию приложения и service flow вместе с высокоточными метриками для выполнения анализа дерева отказов. Дерево отказов показывает все вертикальные и горизонтальные топологические зависимости для данного предупреждения. Рассмотрим следующий пример, представленный на диаграмме выше.

Детерминированная нейросеть автоматически и точно определяет основную причину технической аномалии. Это необходимое предварительное условие для AIOps. Мы углубимся в автоматическое исправление в следующих разделах.

Понимание эволюции проблемы

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

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

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

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

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

Сколько пользователей пострадало от обнаруженной проблемы с момента ее возникновения? В идеале число должно быть основано на реальных пользователях, а не на статистической экстраполяции исторических данных.

Некоторые части системы не созданы для взаимодействия с человеком. В этом случае количество вызовов от сервисной службы помогает оценить серьезность.

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

Типичными фундаментальными причинами являются:

Сбор метрик и событий из цепочки инструментов CI/CD позволяет связать проблему с конкретным развертыванием (и при необходимости откатить ее).

Они могут быть связаны с изменениями в базовой инфраструктуре или сторонней службе.

Во многих случаях проблема возникает из-за выключения или перезапуска хостов или отдельных процессов.

Чтобы определить фундаментальные первопричины, механизм нейросети должен иметь доступ к метрикам и событиям из конвейера CI/CD, решений ITSM, Checkout и других подключенных инструментов.

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

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

На практике существует множество способов реализации автоматического исправления. Как правило, платформа Software Intelligence интегрируется с решениями CI/CD или с уровнями конфигурации облачной платформы для выполнения действий по исправлению. В любом случае решение для интеллектуального программного обеспечения должно обеспечивать полный мониторинг стека, автоматическое обнаружение аномалий, точный анализ первопричин и уведомление о проблемах через API.

В этом примере показано, как точный анализ технической первопричины, фундаментальных первопричин и влияния на пользователей/бизнес можно использовать для автоматизации решения проблем посредством интеграции с различными технологиями CI/CD, ITOM и рабочими процессами.