Atlassian считает, что анализ первопричин инцидентов в средах микросервисов больше нельзя надёжно выполнять только вручную. Когда сотни взаимосвязанных сервисов работают в нескольких регионах, один сбой порождает большие объёмы метрик, журналов и трассировок, а дежурному инженеру обычно приходится переключаться между отдельными панелями и мысленно выстраивать гипотезу об источнике проблемы и пути её распространения.
В публикации в блоге CNCF Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee и Lavender Neesham из Atlassian описывают автоматизированную систему анализа первопричин, предназначенную для автоматизации генерации гипотез, чтобы команда реагирования быстрее переходила к проверке и устранению проблемы, а не собирала доказательства вручную заново.
Превращение анализа первопричин в задачу связывания нескольких сигналов
В основе дизайна лежит связывание трёх уровней доказательств: типа сигнала, времени и топологии сервисов. К сигналам относятся метрики, журналы и трассировки, временная синхронность определяет события, которые могут быть связаны, а граф зависимостей сервисов помогает отличить сервис, в котором начался сбой, от сервиса, пострадавшего от него позднее.
Процесс начинается с сужения области поиска с помощью карты сервисов, полученной из OpenTelemetry. Вместо анализа всех сервисов платформы система определяет сервисы, находящиеся на пути ухудшившегося пользовательского сценария, формируя область, которая обычно включает десятки сервисов, а не сотни. Карта отражает фактические взаимодействия, извлечённые из отношений родительских и дочерних спанов в производственном трафике, а не предполагаемую структуру, описанную в документации.
От данных мониторинга к упорядоченным гипотезам
После определения области независимые модули обнаруживают аномалии в каждом типе сигналов. Для метрик Atlassian отслеживает показатели RED — скорость запросов, уровень ошибок и задержку ответа — с помощью статистических методов, таких как медианное абсолютное отклонение и перцентильные диапазоны. Каждое аномальное состояние получает оценку выраженности, наблюдаемое значение и базовую линию, от которой оно отклонилось.
Распределённые трассировки проверяются на наличие неожиданных исключений, новых моделей распространения ошибок и увеличения задержки на определённых спанах. Для журналов используются методы кластеризации на основе эмбеддингов, позволяющие объединять семантически похожие записи, а затем выделять новые или редкие группы ошибок по сравнению с обычным распределением для сервиса.
Все детекторы преобразуют свои результаты в события с унифицированной схемой, включающей временную метку, имя сервиса, тип сигнала, степень выраженности и подробности. Этот слой позволяет механизму связывания анализировать события независимо от способа, которым каждый детектор обнаружил состояние, а также добавлять новые детекторы или заменять одну статистическую модель другой, основанной на машинном обучении, без перестройки всей системы.
Время и граф зависимостей для определения направления сбоя
Механизм объединяет близкие по времени события в настраиваемом временном окне, обычно плюс-минус пять минут. Каждая группа получает оценку временной согласованности: чем ближе события расположены во времени, тем выше вероятность их связи. Чтобы одна и та же гипотеза не повторялась десятки раз, система использует отпечатки последовательностей сервисов и объединяет повторяющиеся цепочки отказов в одну группу, подсчитывая количество повторов. Благодаря этому модель отказа, повторившаяся 47 раз за пять минут, описывается одной гипотезой, а не 47 идентичными гипотезами.
Затем система определяет наиболее пострадавший узел, который она называет узлом-потомком, и движется в обратном направлении по графу зависимостей в поисках аномальных сервисов, предшествовавших ему во времени. Если сервис A вызывает сервис B, а проблема в B появилась раньше проблемы в A, B становится более сильным кандидатом на источник сбоя, тогда как проблема A рассматривается как последующий эффект. Итоговая оценка объединяет временную согласованность и оценку пути распространения для упорядочивания гипотез.
Результат представляет собой не просто список сервисов и оценок уверенности. Каждая гипотеза включает подозреваемый сервис, путь распространения и доказательства на каждом узле — например, метрики, превысившие свои пороговые значения, или идентификаторы трассировок, связанные со сбоем, — а также изложение на естественном языке, объясняющее последовательность событий и причины выбора конкретного источника.
Почему эта методология важна для операционных команд?
Практическая ценность заключается не в замене инженера реагирования, а в сокращении времени, необходимого для получения проверяемой гипотезы. Atlassian связывает механизм анализа первопричин с более широкой платформой реагирования на инциденты, включающей обнаружение влияния сбоя на пользователей, определение ответственной команды и помощника по инцидентам, который может предлагать такие действия, как откат выпуска или отключение флага функции, основываясь на доступных доказательствах. Платформа также фиксирует, приняли ли инженеры гипотезу, отклонили её или изменили, чтобы со временем улучшать веса.
Опыт показывает, что начинать с простых интерпретируемых методов может быть целесообразнее, чем создавать сложные модели машинного обучения для каждого сигнала. Такие методы, как медианное абсолютное отклонение и перцентильные диапазоны, были достаточны для обнаружения многих аномалий метрик, тогда как методы машинного обучения применялись для кластеризации журналов и анализа структуры трассировок, где статистические подходы менее подходят.
Однако методология не устраняет ограничения. Качество гипотез зависит от согласованности данных мониторинга, точности графа зависимостей сервисов и способности детекторов отличать настоящий сбой от шума. Кроме того, оценка уверенности не является окончательным доказательством причинности; поэтому Atlassian подчёркивает важность отображения источника каждого доказательства и повествования, связывающего его с результатом. Позднее компания планирует изучить использование формата на основе языковых моделей, который сможет запрашивать дополнительные данные и корректировать гипотезы, при условии ограничения частоты запросов, изолированного выполнения и прозрачного журнала источников доказательств.
Редакционный комментарий certi.news: Фактическое изменение в этом подходе заключается в переносе анализа инцидентов от ручного сравнения отдельных инструментов к единому процессу, объединяющему сигнал, время и топологию. Его операционный успех будет зависеть от интерпретируемости, качества данных и циклов обратной связи, а не только от алгоритма ранжирования. Поэтому модульность, устранение дублирования и документирование доказательств выглядят более применимыми уже сейчас принципами, чем обещание полной автоматизации анализа первопричин.