A Atlassian considera que a análise de causa raiz de incidentes em ambientes de microsserviços já não pode depender apenas da revisão manual. Quando centenas de serviços interconectados operam em várias regiões, uma única falha produz um grande volume de métricas, logs e rastreamentos, enquanto o engenheiro de plantão normalmente precisa alternar entre painéis separados e construir uma hipótese mental sobre a origem do problema e seu caminho de propagação.
Em uma publicação no blog da CNCF, Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee e Lavender Neesham, da Atlassian, explicam um sistema automatizado de análise de causa raiz que busca automatizar a geração de hipóteses, para que a equipe de resposta passe mais rapidamente à etapa de validação e correção, em vez de recompilar evidências manualmente.
Transformando a análise de causa raiz em um problema de correlação multissinal
O projeto baseia-se na correlação de três camadas de evidências: tipo de sinal, tempo e topologia dos serviços. Os sinais incluem métricas, logs e rastreamentos, enquanto a simultaneidade temporal identifica eventos que podem estar relacionados, e o grafo de dependências dos serviços ajuda a distinguir o serviço que iniciou a falha daquele que foi afetado posteriormente.
O processo começa estreitando o escopo da pesquisa por meio de um mapa de serviços derivado do OpenTelemetry. Em vez de analisar todos os serviços da plataforma, o sistema identifica os serviços presentes no caminho da experiência degradada do usuário, formando um escopo que normalmente inclui dezenas de serviços, em vez de centenas. O mapa reflete as comunicações reais extraídas das relações pai-filho entre os spans no tráfego de produção, e não a estrutura presumida na documentação.
Dos dados de monitoramento a hipóteses priorizadas
Depois de definir o escopo, módulos independentes detectam anomalias em cada tipo de sinal. Nas métricas, a Atlassian monitora indicadores RED — taxa de solicitações, taxa de erros e duração da resposta — usando métodos estatísticos como o desvio absoluto mediano e intervalos de percentis. Cada anomalia gera um valor de intensidade, o valor observado e a linha de base da qual se desviou.
Já os rastreamentos distribuídos são examinados em busca de exceções inesperadas, novos padrões de propagação de erros e aumentos no tempo de resposta em spans específicos. Os logs usam técnicas de agrupamento baseadas em embeddings para reunir entradas semanticamente semelhantes e, em seguida, destacar grupos de erros novos ou raros em comparação com a distribuição habitual do serviço.
Todos os detectores transformam seus resultados em eventos com um esquema unificado que inclui o carimbo de data e hora, o nome do serviço, o tipo de sinal, o grau de intensidade e os detalhes. Essa camada permite que o mecanismo de correlação analise os eventos sem depender da forma como cada detector identificou a condição, além de permitir a adição de novos detectores ou a substituição de um modelo estatístico por outro baseado em aprendizado de máquina sem reconstruir todo o sistema.
Tempo e grafo de dependências para determinar a direção da falha
O mecanismo agrupa eventos próximos dentro de uma janela temporal configurável, normalmente de mais ou menos cinco minutos. Cada grupo recebe uma pontuação de coesão temporal; quanto mais próximos os eventos, maior a probabilidade de estarem relacionados. Para evitar repetir a mesma hipótese dezenas de vezes, o sistema usa assinaturas de sequências de serviços e combina sequências de falha repetidas em um único grupo, contabilizando o número de reinicializações. Assim, um padrão de falha que se repetiu 47 vezes em cinco minutos pode ser descrito em vez de criar 47 hipóteses idênticas.
Em seguida, o sistema identifica o nó mais afetado, ou o que chama de nó downstream, e então percorre o grafo de dependências no sentido inverso, em busca de serviços anômalos que tenham sido afetados anteriormente. Se o serviço A chama o serviço B, e um problema em B apareceu antes de um problema em A, B se torna um candidato mais forte à origem da falha, enquanto o problema em A é tratado como um efeito posterior. A avaliação final combina a coesão temporal e a pontuação do caminho de propagação para priorizar as hipóteses.
O resultado não se limita a uma lista de serviços e pontuações de confiança. Cada hipótese inclui o serviço suspeito, o caminho de propagação e as evidências em cada nó, como as métricas que ultrapassaram seus limites ou os identificadores de rastreamentos associados à falha, além de uma narrativa em linguagem humana que explica a sequência dos eventos e o motivo pelo qual determinada origem foi priorizada.
Por que essa metodologia é importante para as equipes de operações?
O valor prático não está em substituir o engenheiro de resposta, mas em reduzir o tempo necessário para chegar a uma hipótese verificável. A Atlassian conecta o mecanismo de análise de causa raiz a uma plataforma mais ampla de resposta a incidentes, que inclui a detecção do impacto da falha sobre o usuário, a identificação da equipe responsável e um assistente de incidentes capaz de sugerir ações como reverter uma versão ou desativar uma feature flag com base nas evidências disponíveis. A plataforma também registra se os engenheiros aceitaram, rejeitaram ou modificaram a hipótese, para aprimorar os pesos ao longo do tempo.
A experiência mostra que começar com métodos simples e interpretáveis pode ser mais adequado do que criar modelos complexos de aprendizado de máquina para cada sinal. Métodos como o desvio absoluto mediano e os intervalos de percentis foram suficientes para detectar muitas anomalias de métricas, enquanto técnicas de aprendizado de máquina foram usadas no agrupamento de logs e na análise da estrutura dos rastreamentos, onde os métodos estatísticos são menos adequados.
Mas a metodologia não elimina as limitações. A qualidade das hipóteses depende da consistência dos dados de monitoramento, da precisão do grafo de dependências dos serviços e da capacidade dos detectores de distinguir entre uma falha real e ruído. Além disso, a pontuação de confiança não é uma prova definitiva de causalidade; por isso, a Atlassian enfatiza a importância de mostrar a origem de cada evidência e a narrativa que a relaciona ao resultado. A empresa também explora futuramente o uso de um formato baseado em modelos de linguagem capaz de solicitar dados adicionais e ajustar hipóteses, com a exigência de limites de taxa, execução isolada e um registro claro da origem das evidências.
Leitura editorial da certi.news: a mudança efetiva nessa abordagem é transferir a análise de incidentes da comparação manual entre ferramentas separadas para um processo unificado que integra sinal, tempo e topologia. Seu sucesso operacional dependerá da interpretabilidade, da qualidade dos dados e dos ciclos de feedback, e não apenas do algoritmo de priorização. Por isso, a modularidade, a eliminação de duplicidades e a documentação das evidências parecem princípios mais aplicáveis imediatamente do que a promessa de automação completa da análise de causa raiz.