Просмотр кода страницы Концепция анализа первопричин

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

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

Анализ первопричин призван восполнить этот пробел, используя всю доступную контекстную информацию для оценки инцидента и определения его точной первопричины. Не менее важно оценить влияние инцидента, что позволит оперативной группе быстро оценить этот инцидента и сократить среднее время его устранения (MTTR).

== Инциденты и проблемы ==
Инцидент — это аномалия в вашей среде — в приложении, инфраструктуре и т. д. Проблема — это объект , который представляет инцидент в среде Ключ-АСТРОМ. Проблема является результатом автоматического анализа первопричин и последствий инцидента с помощью искусственного интеллекта. Проблемы (как и основные инциденты) могут охватывать множество зависимых компонентов, имеющих одинаковое воздействие и основную причину.

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

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

== События ==
События представляют собой различные типы единичных аномалий, таких как нарушение порогового значения показателя, ухудшение базового уровня или события в определенный момент времени, такие как сбои процесса. Среда Ключ-АСТРОМ также обнаруживает и обрабатывает информационные события, такие как развертывание нового программного обеспечения, изменения конфигурации и другие типы событий.

Среда Ключ-АСТРОМ принимает и сохраняет события из нескольких источников. Эти события могут запускать анализ первопричин, автоматизацию или служить необработанными данными для информационных панелей и отчетов. Вместе с журналами, метриками и трассировками события предоставляют входные данные для анализа первопричин и последствий.

Большинство событий не указывают на аномальные или неработоспособные состояния, поэтому лишь небольшая часть событий рассматривается как проблема.

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

Чтобы определить основную причину проблем, одной временной корреляции недостаточно. Среда Ключ-АСТРОМ использует контекстно-зависимый подход, обнаруживая взаимозависимые события во времени, процессах, хостах, службах, приложениях, а также с точки зрения вертикального и горизонтального топологического мониторинга. Этот подход объединяет несколько отдельных аномалий в одну последовательную проблему, что значительно снижает нагрузку на оповещения.

На изображении ниже показано, как ИИ анализирует все горизонтальные и вертикальные зависимости проблемы. В этом примере приложение демонстрирует ненормальное поведение, в то время как базовый вертикальный стек работает нормально. Анализ отслеживает транзакции приложения, выявляя зависимость от службы (<code>Service 1</code>), которая также демонстрирует ненормальное поведение. В свою очередь, все зависимости службы также ведут себя ненормально и являются частью одной и той же проблемы.

[[Файл:Анализ проблемы ИИ.png|граница]]

ИИ включает все соответствующие отклонения и ранжирует все основные причины, определяя, какое из них является основным негативным воздействием. Вы можете перейти к уровню компонента и проанализировать основную причину вплоть до уровня исходного кода. Например, среда Ключ-АСТРОМ может показывать ошибочные методы в коде вашего сервиса или высокую активность GC в базовых процессах Java.

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

Однако одной временной корреляции недостаточно для выявления основной причины многих проблем приложений и служб. Рассмотрим, например, простую временную корреляцию, при которой служба <code>Booking</code>вызывает <code>Verification</code>службу, а <code>Verification</code> служба замедляется. Первым событием в развитии проблемы является замедление работы службы <code>Verification</code>. Впоследствии <code>Booking</code>служба также испытывает замедление, вызванное зависимостью от <code>Verification</code>службы. В этом случае временная корреляция хорошо помогает обнаружить основную причину проблемы: замедление работы службы <code>Verification</code>. Однако это слишком упрощенное описание того, что происходит в реальных приложениях.

Что, если события в последовательности развития проблемы будут более тонкими и открытыми для интерпретации? Что, если, например, у службы <code>Booking</code> уже давно есть проблемы с производительностью? Без полного контекста становится невозможным сделать окончательный вывод о том, что замедление работы <code>Booking</code> службы вызвано замедлением работы службой <code>Verfication</code>. Существует вероятность того, что у службы <code>Booking</code> возникла другая проблема с производительностью, не связанная с <code>Verfication</code>.

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

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

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

Анализ последствий определяет, какие службы точки входа приложений затронуты инцидентом, а также размер общего «радиуса взрыва» с точки зрения общего количества затронутых объектов. Анализ последствия также позволяет определить количество затронутых SLO, а также количество потенциально затронутых реальных пользователей.

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

== Жизненный цикл проблемы ==
Среда Ключ-АСТРОМ обнаруживает проблему при получении первого индикатора инцидента, который обычно представляет собой одно событие, отражающее аномальное поведение, такое как замедление работы службы, перегрузка узла или сбой и перезапуск рабочей нагрузки.

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

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

[[Файл:Проблема новая.png|граница]]

# Система Ключ-АСТРМО обнаруживает инцидент с производительностью на уровне инфраструктуры и создает новую проблему для целей отслеживания. Уведомление также отправляется.
# Через несколько минут проблема инфраструктуры приводит к появлению проблемы снижения производительности в одной из служб приложения.
# Начинают появляться дополнительные проблемы снижения производительности на уровне служб. То, что началось как изолированная проблема, касающаяся только инфраструктуры, переросло в серию проблем на уровне служб, каждая из которых имеет первопричину в исходном инциденте на уровне инфраструктуры.
# В конце концов, проблемы уровня служб начинают влиять на пользовательский опыт клиентов, которые взаимодействуют с приложением через настольные или мобильные браузеры. На этом этапе жизненного цикла проблемы у вас есть проблема приложения с одной основной причиной на уровне инфраструктуры и дополнительными основными причинами на уровне обслуживания.
# Поскольку система Ключ-АСТРОМ понимает все зависимости в вашей среде, она сопоставляет проблему снижения производительности, с которой сталкиваются ваши клиенты, с исходной проблемой производительности на уровне инфраструктуры, способствуя быстрому решению проблемы.

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

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

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

[[Файл:Imageавав.png|граница]]

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

* '''Начало анализа триггерного события''' — это самый ранний момент времени, когда было обнаружено состояние нарушения.
* '''Конец анализа триггерного события''' — это момент времени, когда собраны все необходимые образцы нарушений и обнаружена проблема.
* Поскольку каждое событие, связанное с проблемой, использует скользящее окно, каждая проблема имеет завершающий период, в течение которого закрытая проблема может быть открыта повторно. Это называется '''периодом повторного открытия''', и его максимальная продолжительность составляет 30 минут.
* Если проблема остается открытой более 90 минут, после 90-минутной точки в нее не добавляются новые события. Это не позволяет ИИ собирать несвязанную информацию о длительных инцидентах (например, синтетический тест постоянно терпит неудачу и проблемы остаются открытыми в течение нескольких недель).

==== Краткое описание временного цикла проблемы: ====

* В отдельных событиях используются скользящие окна анализа переменных.
* Проблема возникает в метке времени анализа завершения события.
* Продолжительность жизни проблемы определяется продолжительностью жизни отдельных событий в задаче.
* Задача считается закрытой, когда закрыты все события в задаче.
* Закрытую проблему можно открыть повторно в течение 30 минут.
* Если проблема длится более 90 минут, новые события не будут объединяться после 90 минут — вместо этого будет создана новая проблема.

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

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

* На момент обнаружения в анализе первопричин может отсутствовать необходимая информация для объединения обеих проблем в один инцидент.
* После того как запоздалая информация будет рассмотрена и выявлена одна основная проблема, остальные идентичные проблемы помечаются как дубликаты ( <code>dt.davis.is_duplicate=true</code>).

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

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