Atlassian перестроила платформу обнаружения инцидентов, питающую её автоматизированную систему создания инцидентов, используя Apache Kafka, Apache Flink на Kubernetes и OpenTelemetry. Согласно опубликованным измерениям, проведённым после 18 месяцев работы, время доставки события до метрики сократилось с более чем 40 секунд до менее чем 10 секунд, тогда как устойчивая производительность выросла примерно с 500 миллионов событий в день до более чем миллиарда событий в день при использовании 50%-ной выборки.
Проект не преподносится как полностью завершённая история успеха. Доля обнаружения инцидентов, попадающих в охватываемую мониторингом область, выросла примерно с 60% до пиковых 86% в июне 2026 года, а затем снизилась до 64% в августе. Точность также осталась ниже целевого уровня, что побудило команду разделить качество самого детектора и охват продуктов и экспериментов, оснащённых измерениями.
Платформа, построенная вокруг потока событий
Atlassian управляет более чем десятью облачными продуктами для миллионов арендаторов, и эти продукты ежедневно генерируют миллиарды событий в результате взаимодействия пользователей. События включают начало и результат выполнения задачи, а также данные об арендаторе, пользователе, эксперименте и коде HTTP. Платформа использует эти данные, чтобы быстро ответить на три вопроса: существует ли проблема? Каков масштаб её воздействия? И какую команду следует уведомить и с какой степенью серьёзности?
В новой архитектуре события фильтруются на шине Apache Kafka вместо полного потребления потока внутри приложения. Фильтр подписки, насчитывающий около 770 строк YAML, хранится как часть программной конфигурации. Затем одно приложение Apache Flink 1.20 обрабатывает события на Kubernetes, обогащает их данными об арендаторе, отправляет метрики через OpenTelemetry и агрегирует воздействие инцидентов в 60-секундных окнах.
Команда использовала Apache Parquet для хранения агрегированных объёмов и многорегиональное хранилище ключевых значений, тогда как Impact API предоставляет ответы о количестве затронутых пользователей и арендаторов. Движок AutoHOT преобразует оповещения в инциденты, применяет матрицу серьёзности, подавляет кратковременные оповещения, а затем каждую минуту повторно оценивает воздействие.
Преимущества по производительности и стоимости
- Количество виртуальных машин сократилось примерно с 90, помимо уровней очередей и кэширования, до четырёх контейнеров Kubernetes.
- Ежемесячные эксплуатационные расходы снизились примерно с 20 000 долларов до около 650 долларов, то есть почти на 97%.
- Восстановление после остановки обработки стало возможным благодаря повторному воспроизведению событий Kafka примерно за 20 минут без потери данных.
- Время выполнения запроса к панели воздействия сократилось примерно с 10 секунд до около одной секунды.
- Совпадение со старым конвейером достигло 99,9% за две недели параллельной работы.
В архитектуре использовался HyperLogLog для подсчёта уникальных затронутых пользователей вместо хранения идентификаторов пользователей, с погрешностью около 1,5%. Также применялись idempotent-ключи хранения, чтобы повторное воспроизведение Kafka можно было выполнять с восстановлением без дублирования строк. Команда сохранила старые названия метрик через путь StatsD, что позволило существующим панелям SLO и детекторам продолжить работу без изменений при переходе.
Почему одних показателей производительности недостаточно?
Результаты по инцидентам показывают, что ускорение конвейера данных не обязательно означает лучшее покрытие. За девять месяцев произошло 263 крупных инцидента, но только 117 инцидентов, то есть 44,5%, затронули эксперименты, оснащённые мониторингом. Из этих инцидентов было обнаружено 80, а это означает, что за тот период система выявила лишь 30,4% от общего числа крупных инцидентов.
Точность также различалась в зависимости от типа оповещения. Точность инцидентов Sev2, созданных системой автоматически, в течение финансового года составила около 85%, тогда как точность менее серьёзных ранних предупреждений находилась в диапазоне от 70% до 79%. Подавление флуктуаций помогло сократить количество отклонённых тикетов по кратковременным оповещениям примерно на 80%. С другой стороны, задержка в системе метрик приводила к тому, что снижение объёма данных считалось нулём, что вызывало волну ложных оповещений; проблему решили, добавив к детекторам снижения объёма минимальную задержку в 120 секунд.
Оставшиеся нерешёнными ограничения
Самая крупная логическая проблема заключается в том, что молчание может выглядеть как исправность. Полная остановка базы данных может препятствовать загрузке страницы и, следовательно, вообще не порождать событий об ошибках. Точно так же остановка самого конвейера событий может сделать детектор слепым. Поэтому команда добавила детекторы снижения объёма данных и проверки актуальности метрик, а также планирует подключить независимые сигналы, такие как пограничные ошибки 5xx и синтетические зонды.
Команда также обнаружила, что обнаружение инцидента и измерение его воздействия — это две отдельные задачи. В одном из инцидентов тикет был создан рано, но система оценила воздействие примерно в две тысячи пользователей, тогда как фактическое число превысило 80 тысяч. Кроме того, интерфейс Impact API обрушился под нагрузкой примерно 100 одновременных пользователей, поскольку объединял структуры HyperLogLog во время чтения без предварительной агрегации или кэширования.
Наиболее существенной слабостью остаётся то, что шлюз событий, подписка Kafka и функция Flink работают в одном регионе, хотя механизм принятия решений работает в активном режиме в двух регионах. Это означает, что региональный сбой может оставить вычисления работоспособными, но вывести из строя сам источник обнаружения.
Редакционный разбор certi.news
Основная ценность опыта Atlassian заключается не в отдельном выборе Flink или Kafka, а в увязке архитектурных решений с проверяемыми эксплуатационными показателями: фильтрация на шине, idempotent-ключи, мониторинг платформы с помощью тех же инструментов OpenTelemetry и различение recall и coverage. Результаты показывают, что повышение эффективности может явно сократить расходы и время, но автоматически не устраняет пробелы в измерениях или инциденты, которые не порождают клиентских сигналов.
Atlassian планирует перенести детекторы в хранилище временных рядов, питаемое через OpenTelemetry, расширить конвейер Flink до активного режима между регионами и добавить ежедневную агрегацию и кэширование перед Impact API. Кроме того, компания ставит целью достичь recall и точности свыше 90% каждого в пределах области, оснащённой мониторингом, а также времени P90 для обнаружения инцидентов Sev3 менее 90 минут. Согласно опубликованному материалу, это будущие цели, а не достигнутые результаты.