Automated RCA in microservices — это практический способ сократить анализ инцидентов, заменив догадки проверкой гипотез. В Atlassian система превращает корреляцию телеметрии в ранжированный список гипотез о корневой причине сбоя.
В масштабе Atlassian сотни взаимосвязанных микросервисов, распределённых по нескольким регионам, по умолчанию делают реагирование на инциденты довольно сложным. Один сбой, затрагивающий пользователей, может генерировать столько телеметрии, что диагностика не ускоряется, а, наоборот, замедляется. Проблема не в отсутствии видимости. Узкое место — стоимость поиска причинно-следственного сигнала среди метрик, логов и трейсов. На практике эта работа всё ещё во многом зависит от человеческой памяти, интуиции и ручного сопоставления данных.
Ответ команды — автоматизированный RCA-пайплайн, построенный вокруг простой инженерной идеи: root cause analysis — это задача корреляции по трём измерениям. Если аномалии можно независимо обнаружить, выровнять по общей временной шкале и проследить через граф зависимостей сервисов, система сможет сформировать ранжированные гипотезы о том, где начался сбой и каким образом он распространился. Это прагматичный подход, а не попытка заменить экспертизу специалистов, реагирующих на инциденты. Он переводит их работу от генерации гипотез к их проверке — именно там во время аварии особенно важна каждая минута.
Архитектура изначально спроектирована как модульная. Каждый детектор аномалий представляет собой подключаемый компонент, а движок корреляции получает нормализованные события аномалий независимо от их источника. Это позволяет команде развивать пайплайн без необходимости перестраивать его целиком. В дальнейшем статистические детекторы можно заменить ML-моделями, а новые типы сигналов добавлять постепенно. Компромисс очевиден: модульность требует дисциплины в проектировании интерфейсов, зато позволяет избежать жёстко связанной системы, которую было бы трудно расширять в условиях давления во время инцидента.
Первый шаг после обнаружения инцидента — определить масштаб его воздействия (blast radius). Вместо сканирования всей платформы система обращается к карте сервисов, построенной на основе данных OpenTelemetry, чтобы изолировать сервисы, участвующие в затронутой цепочке вызовов. Это сокращает задачу с сотен сервисов до сфокусированного подграфа, обычно состоящего из нескольких десятков сервисов. Граф строится на основе отношений parent-child между спанами, наблюдаемыми в производственном трафике, поэтому он отражает реальные коммуникации между сервисами, а не то, как они должны взаимодействовать согласно документации.
После определения релевантных сервисов система запускает специализированные детекторы для каждого типа телеметрии. Для метрик она отслеживает сигналы RED — rate, error rate и duration — и использует статистические методы, такие как медианное абсолютное отклонение (MAD) и диапазоны на основе перцентилей. Для трейсов система ищет структурные аномалии: неожиданные исключения, новые схемы распространения ошибок и скачки задержки на уровне спанов. Для логов используется кластеризация на основе embeddings, позволяющая выявлять редкие или новые кластеры ошибок без наивного сканирования каждой строки. Ключевая техническая деталь здесь — нормализация. Каждый детектор формирует события по одной и той же схеме, поэтому движок корреляции может анализировать различные сигналы, не учитывая, какой именно детектор их создал.
Корреляция начинается со времени. Движок объединяет аномалии, возникшие близко друг к другу, используя скользящее окно — обычно ±5 минут. Это важно, поскольку сбой редко проявляется только в одном сигнале. Ошибка базы данных может вызвать тайм-ауты на вышестоящих сервисах, которые затем проявятся как ошибки 500 на фронтенде. Система присваивает каждому такому набору оценку временной связанности (temporal cohesion score), поэтому тесно сгруппированные события получают более высокий приоритет, чем распределённые во времени. Кроме того, система устраняет дубликаты повторяющихся цепочек отказов с помощью sequence fingerprinting. Без этого один и тот же причинно-следственный паттерн может воспроизводиться десятки раз и буквально утопить реальный сигнал в копиях.
После временной группировки система использует граф зависимостей для определения направления распространения сбоя. Она начинает с узла-приёмника (sink node) — сервиса с наиболее высокой тяжестью аномалии — и движется вверх по графу с помощью ограниченного BFS. Если Service A зависит от Service B, а аномалия в B появилась раньше по времени, то B с большей вероятностью является источником сбоя. Каждый кандидатный путь получает оценку на основе тяжести аномалии, силы зависимости и временного расстояния до sink node. Итоговая оценка набора объединяет temporal cohesion и оценку пути, после чего наиболее высоко оценённые наборы становятся гипотезами о корневой причине (root cause hypotheses).
Результат — это не просто список сервисов. Каждая гипотеза содержит объяснение, которое специалист может быстро прочитать и проверить по телеметрии. Это важно, поскольку доверие к инструментам реагирования на инциденты строится на доказательствах, а не только на числовой оценке. Система также является частью более крупной платформы incident response в Atlassian, где автоматическое обнаружение воздействия на пользователей, идентификация неисправного сервиса, причинно-следственная диагностика и AI-powered incident copilot работают с единым контекстом инцидента. Этот общий контекст выступает в роли управляющего слоя (control plane) всего рабочего процесса и позволяет держать сигналы, гипотезы и действия согласованными в одном месте.
Самый полезный урок здесь одновременно является и самым консервативным: начинать стоит с максимально простого детектора аномалий, который действительно работает. Статистические методы проще отлаживать, чем сложные ML-модели, особенно когда они генерируют ложные срабатывания. Модульность со временем даёт накопительный эффект. Дедупликация в больших системах обязательна. А граф зависимостей является наиболее сильным исходным ориентиром (prior), если задача заключается в том, чтобы отличить действительно сломавшийся сервис от сервиса, который лишь пострадал из-за другого сбоя.
Текущая система запускается один раз для каждого триггера инцидента. Следующий этап — более адаптивная оркестрация, вероятно с использованием LLM-based agents, которые смогут запрашивать дополнительную телеметрию и безопасно уточнять гипотезы. Команда также планирует расширить набор сигналов, добавив инфраструктурные метрики, события деплоя, изменения feature flags и результаты synthetic checks. Это приближает систему к более сложному вопросу: не только какой сервис вышел из строя, но и какое изменение стало причиной этого сбоя.