02.08.2023
Нейросеть и автоматизация могут радикально изменить управление ИТ-инфраструктурой, если применять их на протяжение всей цифровой цепи: от разработки до предоставления услуг.
Нейросеть и автоматизация ПО
Содержание
AIOps и application performance monitoring
Автоматизация корпоративного программного обеспечения
Введение
Знакомая проблема? Аномалия в большом микросервисном приложении вызывает шквал предупреждений, так как это затрагивает сервисы по всему миру. Ваше приложение содержит миллионы зависимостей, как найти исходную ошибку? Обычные инструменты мониторинга не справляются. Они собирают метрики и выдают оповещения, но дают мало ответов о том, что где конкретно искать проблему.
Напротив, представьте себе интеллектуальную систему, которая дает точные ответы — в данном случае, техническую причину аномалии и способы ее устранения. Такой информации, если она надежна, можно доверять для запуска процедур автоматического исправления, прежде чем большинство пользователей даже заметят глюк.
Нейросеть и автоматизация могут радикально изменить управление ИТ-инфраструктурой, если применять их на протяжение всей цифровой цепи: от разработки до предоставления услуг.
AIOps
Вместо шквала сообщений об аномалиях – анализ причин и ответ где искать ошибку.
Автоматическое исправление
Автоматизируйте устранение аномалий и оптимизируйте производительность, опираясь на состояние ИТ-системы и реальные потребности пользователей.
Интеллектуальный DevOps
Ускорьте инновации и выпускайте качественное ПО, используя APM на основе нейросети и регрессивное тестирование.
Умное взаимодействие с клиентами
Грамотно интерпретированные данные бизнес-аналитики помогут улучшить клиентский опыт, а еще помогут настроить автоматическое устранение поломок и рекламных компаний.
Обнаружение аномалий и оповещения
Инсайт
Концепция автоматизации операций направлена на эффективное устранение неполадок с конечной целью сокращения среднего времени восстановления (MTTR). Это достигается за счет автоматического обнаружения аномалий и оповещения, то есть ускорения среднего времени до обнаружения (MTTD). Однако для дальнейшего снижения MTTR требуется автоматический анализ первопричин.
Вызовы принят!
Традиционные инструменты мониторинга сосредоточены на показателях производительности приложений и методах определения базовых параметров, позволяющих отличить нормальное поведение от ошибочного.
Определение порогов аномалий оказывается сложной задачей, требующей расширенной статистики, такой как машинное обучение. В современных микросервисных архитектурах один сбой влияет на множество подключенных сервисов, которые впоследствии также выходят из строя. Таким образом, одна проблема обычно вызывает множество предупреждений. Это называется шквалом предупреждений (storm alert).
Обычные решения для мониторинга не решают эту проблему. Операторам остается разобраться в предупреждениях. Сортировка проблем становится трудоемким и часто бесперспективным занятием, где целая команда днем и ночью ищет проблему.
Единственный выход — метод автоматического определения причины ошибки. Существует два очень подхода к уменьшению шума от предупреждений на основе нейросети
Детерминированная нейросеть
Выполняет пошаговый анализ дерева отказов как это принято в технике безопасности.
Результат: Точное определение основной причины проблемы
– Работает почти в реальном времени
– Объясняет результаты — то как развивалась проблема, может быть визуализирована шаг за шагом
– Включает технические и основополагающие причины, а также импакт анализ.
Машинное обучение нейросети
Это статистический подход, который коррелирует метрики, события и оповещения для построения многомерной модели анализируемой системы.
Результаты:
пэк связанных между собой предупреждений.
– Создание моделей машинного обучения требует времени.
– Склонны отставать в динамичной среде
– Некоторые системы предлагают вероятные первопричины, обращаясь к записям, созданными до этого людьми.
Получение данных для мониторинга
Инсайт
В среде разрозненных инструментов мониторинга команде приходится разбираться во множестве различных входных данных, поступающих из разных источников. Это увеличивает вероятность ошибки при анализе ситуации и диагностике. В настоящее время отслеживается только 5% приложений. Цель состоит в том, чтобы получить полную сквозную видимость.
Вызов принят
Полная наблюдаемость системы является необходимым условием для автоматизации операций, включая надежное самовосстановление. Нам нужно полное представление не только о приложении, включая контейнеры и функции-услуги, но и обо всех уровнях инфраструктуры, сетей, конвейера CI/CD и реального взаимодействия с пользователем. Во многих случаях сам сбор данных осуществляется бесплатно, поскольку поставщики общедоступных служб предлагают API-интерфейсы для мониторинга, а инструменты с открытым исходным кодом доступны в изобилии. Тем не менее, следующие пункты имеют решающее значение для автоматизации:
- Сколько делается для инструментирования и развертывания обновлений вручную?
- Могут ли агенты мониторинга внедряться во временные компоненты, такие как функции или контейнеры, и требуют ли изменения конфигурации дополнительного ручного инструментария?
- Являются ли метрики грубой выборкой или обладают высокой точностью?
- Достаточно ли метаинформации и контекста для построения унифицированная модель данных?
Данные в контексте
Чтобы выполнить настоящий анализ первопричин, собранные данные должны быть точными (минимальная выборка или без выборки) и контекстно-насыщенными, чтобы создавать топологию в реальном времени и service flow maps.
Топология
Карта топологии захватывает и визуализирует всю среду приложения. Сюда входит вертикальный стек (инфраструктура, службы и процессы) и горизонтальные зависимости, то есть все отношения входящих и исходящих вызовов. Ведущие решения для мониторинга обеспечивают автоматическое обнаружение новых компонентов среды и обновления в режиме реального времени.
Карта Service flow
Карта потока обслуживания предлагает транзакционное представление, которое иллюстрирует последовательность вызовов службы с точки зрения отдельной службы или запроса. Отличие от топологий заключается в том, что потоки обслуживания отображают пошаговую последовательность всей транзакции, в то время как топологии являются более абстрактными и показывают только общие зависимости. Для потоков обслуживания требуются данные высокой точности с минимальной выборкой или без нее.
Нейросеть и анализ первопричин
Инсайт
Предприятия без нейросети пытаются совершить невозможное. Gartner прогнозирует, что 30% ИТ-организаций, которые не смогут внедрить ИИ, станут терять жизнеспособность уже к 2022 году. По мере того, как предприятия генерирует огромный объем данных, сложность среды делает ручной мониторинг все более изощренным для людей.
Вызов принят
Чтобы AIOps работал идеально, нам нужна система, которая может не только определять, что что-то не так, но и точно определять истинную причину. Современные высокодинамичные микросервисные архитектуры работают в гибридных средах. Инфраструктура и службы запускаются и отключаются в мгновение ока по мере необходимости. Определение первопричины аномалии требует экспоненциально больше усилий, чем может сделать человек.
Анализ первопричин с помощью детерминированной нейросети
Нейросеть Dynatrace — использует
топологию приложения
и
service flow
вместе с высокоточными метриками для выполнения анализа дерева отказов. Дерево отказов показывает все вертикальные и горизонтальные топологические зависимости для данного предупреждения. Рассмотрим следующий пример, представленный на диаграмме выше.
- В веб-приложении обнаружена аномалия, например уменьшенное время отклика (см. рисунок вверху слева).
- Нейросеть сначала «просматривает» вертикальный стек ниже и обнаруживает, что все работает так, как ожидалось — никаких проблем.
- Отсюда нейросеть отслеживает все транзакции и обнаруживает зависимость от службы 1, которая также показывает аномалию. Кроме того, все последующие зависимости (службы 2 и 3) также демонстрируют аномалии.
- Автоматическое обнаружение первопричины включает все соответствующие вертикальные стеки, как показано в примере, и ранжирует участников, чтобы определить наиболее негативное воздействие.
- В данном случае основной причиной является перегрузка ЦП на одном из хостов Linux.
Детерминированная нейросеть автоматически и точно определяет основную причину технической аномалии. Это необходимое предварительное условие для AIOps. Мы углубимся в автоматическое исправление в следующих разделах.
Понимание эволюции проблемы
Анализ детерминированного дерева отказов дает точные и объяснимые результаты. Это можно использовать для пошагового воспроизведения эволюции и решения проблемы, а также для визуализации затронутых компонентов на карте топологии. Это чрезвычайно мощная функция, поскольку она позволяет команде DevOps получить глубокое понимание проблемы с самого начала, сокращая время сортировки и исследования до минимума.
Данные о развитии проблемы являются ключевыми для автоматического исправления. Учитывая, что к нему можно получить доступ через API, последовательности исправления могут быть запущены для решения проблемы с хирургической точностью и со скоростью, недостижимой для людей.
Анализ импакта и первопричин
Инсайт
В современном динамическом микросервисном приложении инфраструктура и сервисы запускаются и отключаются по мере необходимости с ошеломляющей скоростью. Исчезновение контейнера может быть желательным событием для оптимизации ресурсов или признаком непреднамеренного сбоя, требующего немедленного устранения. Нейросеть должен уметь отличать аномалию от желаемого изменения.
Вызов принят
Точное и надежное определение технической первопричины необходимо для самовосстановления, но и этого недостаточно. Нам также нужна мера серьезности аномалии и некоторое указание на то, что в первую очередь привело к технической первопричине.
Анализ любого воздействия
Не каждый исчезающий контейнер или хост — проблема, это может быть медленный сервис, которым никто не пользуется, и он не требует немедленного внимания. Таким образом, передовая система программного обеспечения должна оценивает серьезность проблемы.
Влияние на пользователя
Сколько пользователей пострадало от обнаруженной проблемы с момента ее возникновения? В идеале число должно быть основано на реальных пользователях, а не на статистической экстраполяции исторических данных.
Вызовы сервисной службы
Некоторые части системы не созданы для взаимодействия с человеком. В этом случае количество вызовов от сервисной службы помогает оценить серьезность.
Влияние на бизнес
Поскольку программные интеллектуальные решения все больше охватывают корпоративные системы от начала до конца, от действий пользователя до инфраструктуры, производительность системы можно сопоставить с ключевыми показателями эффективности бизнеса. Можно измерить сколько продано покупок во время замедления работы системы и сравнить эту цифру с эталонным периодом времени в прошлом.
Типичными фундаментальными причинами являются:
Развертывания
Сбор метрик и событий из цепочки инструментов CI/CD позволяет связать проблему с конкретным развертыванием (и при необходимости откатить ее).
Сторонние изменения конфигурации
Они могут быть связаны с изменениями в базовой инфраструктуре или сторонней службе.
Доступность инфраструктуры
Во многих случаях проблема возникает из-за выключения или перезапуска хостов или отдельных процессов.
Чтобы определить фундаментальные первопричины, механизм нейросети должен иметь доступ к метрикам и событиям из конвейера CI/CD, решений ITSM, Checkout и других подключенных инструментов.
Автоматическое исправление
Инсайт
Инфраструктура как код обеспечивают необходимые компоненты для автоматизации операций и обеспечения самовосстановления. Это не только снизит эксплуатационные расходы, но и позволит избежать человеческие ошибки. Ключом к действительно автономным операциям является надежная информация о работоспособности системы, включая глубокий анализ первопричин аномалий и последствий.
Вызов принят
Многие платформы предлагают механизмы для динамической настройки ресурсов в зависимости от нагрузки или перезапуска неработоспособных узлов и служб. Некоторые из этих решений очень продвинуты, однако они работают только в предусмотренных для них пределах. Решения для программной аналитики охватывают всю корпоративную систему от начала до конца, включая гибридные среды.
Включение автоматического исправления
На практике существует множество способов реализации автоматического исправления. Как правило, платформа Software Intelligence интегрируется с решениями CI/CD или с уровнями конфигурации облачной платформы для выполнения действий по исправлению. В любом случае решение для интеллектуального программного обеспечения должно обеспечивать полный мониторинг стека, автоматическое обнаружение аномалий, точный анализ первопричин и уведомление о проблемах через API.
В этом примере показано, как точный анализ технической первопричины, фундаментальных первопричин и влияния на пользователей/бизнес можно использовать для автоматизации решения проблем посредством интеграции с различными технологиями CI/CD, ITOM и рабочими процессами.