A Atlassian reconstruiu a plataforma de detecção de incidentes que alimenta seu sistema automatizado de criação de incidentes, baseando-se em Apache Kafka, Apache Flink no Kubernetes e OpenTelemetry. Segundo as medições publicadas após 18 meses de trabalho, o tempo de chegada do evento à métrica caiu de mais de 40 segundos para menos de 10 segundos, enquanto a capacidade sustentada aumentou de cerca de 500 milhões de eventos por dia para mais de 1 bilhão de eventos por dia com o uso de amostragem de 50%.
O projeto não se apresenta como uma história de sucesso completa. A taxa de recall dos incidentes dentro do escopo monitorado aumentou de cerca de 60% para um pico de 86% em junho de 2026, antes de cair para 64% em agosto. A precisão também permaneceu abaixo do nível desejado, levando a equipe a separar a qualidade do próprio detector da extensão da cobertura dos produtos e das experiências instrumentadas com métricas.
Uma plataforma construída em torno do fluxo de eventos
A Atlassian administra mais de dez produtos em nuvem para milhões de locatários, e esses produtos geram bilhões de eventos diariamente a partir das interações dos usuários. Os eventos incluem o início e o resultado da tarefa, com dados sobre o locatário, o usuário, a experiência e o código HTTP. A plataforma usa esses dados para responder rapidamente a três perguntas: existe um problema? Qual é a dimensão de seu impacto? E qual equipe deve ser alertada e com que grau de severidade?
No novo design, os eventos são filtrados no barramento do Apache Kafka, em vez de todo o fluxo ser consumido dentro da aplicação. O filtro de assinatura, com cerca de 770 linhas de YAML, é mantido como parte da configuração do código. Em seguida, uma única aplicação do Apache Flink 1.20 processa os eventos no Kubernetes, enriquecendo-os com dados do locatário, enviando métricas por meio do OpenTelemetry e agregando o impacto dos incidentes em janelas de 60 segundos.
A equipe usou Apache Parquet para armazenar os volumes agregados e um armazenamento de chave-valor multirregional, enquanto a Impact API fornece respostas sobre o número de usuários e locatários afetados. O mecanismo AutoHOT transforma alertas em incidentes, aplica uma matriz de severidade, impede alertas transitórios e reavalia o impacto a cada minuto.
Ganhos de desempenho e custo
- O número de máquinas virtuais caiu de cerca de 90 máquinas, além das camadas de filas e cache, para quatro contêineres Kubernetes.
- O custo operacional mensal caiu de cerca de 20 mil dólares para aproximadamente 650 dólares, uma redução de quase 97%.
- A recuperação de uma interrupção do processamento tornou-se possível por meio da reprodução dos eventos do Kafka em cerca de 20 minutos, sem perda de dados.
- O tempo de consulta do painel de impacto caiu de cerca de 10 segundos para aproximadamente um segundo.
- A correspondência com o caminho antigo chegou a 99,9% durante uma execução paralela de duas semanas.
O design usou HyperLogLog para calcular os usuários únicos afetados, em vez de armazenar identificadores de usuários, com um erro de aproximadamente 1,5%. Também foram usadas chaves de armazenamento idempotent para tornar a reprodução do Kafka recuperável sem duplicar linhas. A equipe manteve os nomes antigos das métricas por meio de um caminho StatsD, permitindo que os painéis de SLO e os detectores existentes continuassem funcionando sem alterações durante a migração.
Por que os números de desempenho não são suficientes?
Os resultados dos incidentes mostram que acelerar o pipeline de dados não equivale necessariamente a obter uma cobertura melhor. Durante nove meses, ocorreram 263 incidentes de grande porte, mas apenas 117 incidentes, ou 44,5%, afetaram experiências instrumentadas com monitoramento. Oitenta desses incidentes foram detectados, o que significa que o sistema capturou apenas 30,4% do total de incidentes de grande porte naquele período.
A precisão também variou conforme o tipo de alerta. A precisão dos incidentes Sev2 criados automaticamente pelo sistema ficou em cerca de 85% durante o ano fiscal, enquanto a precisão dos alertas antecipados de menor gravidade variou entre 70% e 79%. A supressão de oscilações contribuiu para reduzir em cerca de 80% os tíquetes rejeitados de alertas transitórios. Por outro lado, o atraso do sistema de métricas fazia com que a redução dos dados fosse considerada zero, gerando uma onda de falsos positivos; isso foi tratado com a adição de um atraso mínimo de 120 segundos aos detectores de redução de volume.
Limitações que permaneceram em aberto
O maior problema lógico é que o silêncio pode parecer saúde. Uma interrupção completa do banco de dados pode impedir o carregamento da página e, portanto, não produzir eventos de falha. Da mesma forma, uma interrupção do próprio pipeline de eventos pode deixar o detector cego. Por isso, a equipe adicionou detectores de redução do volume de dados e verificações de atualidade das métricas, e planeja incluir sinais independentes, como erros 5xx na borda e sondas sintéticas.
A equipe também constatou que detectar o incidente e medir seu impacto são dois problemas separados. Em um dos incidentes, o tíquete foi criado cedo, mas o sistema estimou o impacto em cerca de 2 mil usuários, enquanto o número real ultrapassou 80 mil. A Impact API também entrou em colapso sob uma carga de aproximadamente 100 usuários simultâneos, pois agregava os esquemas HyperLogLog no momento da leitura, sem pré-agregação ou cache.
O ponto fraco mais importante continua sendo o fato de que o gateway de eventos, a assinatura do Kafka e a função do Flink operam em uma única região, embora o mecanismo de decisão opere em modo ativo-ativo em duas regiões. Isso significa que uma falha regional pode manter a computação íntegra, mas interromper a própria fonte de detecção.
A leitura editorial da certi.news
O principal valor da experiência da Atlassian não está na escolha isolada do Flink ou do Kafka, mas em conectar as decisões de arquitetura a métricas operacionais auditáveis: filtragem no barramento, chaves idempotent, monitoramento da plataforma com as mesmas ferramentas do OpenTelemetry e distinção entre recall e coverage. Os resultados mostram que melhorar a eficiência pode reduzir claramente o custo e o tempo, mas não resolve automaticamente as lacunas de medição nem os incidentes que não produzem sinais úteis.
A Atlassian planeja migrar os detectores para um armazenamento de séries temporais alimentado por meio do OpenTelemetry, expandir o pipeline do Flink para um modo ativo-ativo entre regiões e adicionar agregação diária e cache diante da Impact API. Também pretende alcançar recall e precisão superiores a 90% cada um dentro do escopo instrumentado com monitoramento, com um tempo de P90 para a detecção de incidentes Sev3 inferior a 90 minutos. Esses continuam sendo objetivos futuros, e não resultados alcançados segundo o material publicado.