Circle K reduz a análise de incidentes de 45–60 para menos de 15 minutos

Quando um alerta dispara, o engenheiro normalmente ainda não está consertando o sistema. Primeiro ele abre as métricas, procura as linhas certas nos logs, verifica o estado dos contêineres, lê a documentação do serviço e examina as mudanças recentes no código. Na Circle K, essa análise levava de 45 a 60 minutos. A empresa automatizou justamente essa parte do trabalho: um agente coleta contexto de várias fontes e envia ao engenheiro de plantão, no Slack, a causa provável da falha, as evidências e os próximos passos.

Segundo as métricas internas da Circle K, o tempo médio da análise inicial caiu para menos de 15 minutos, uma redução de 67–75%. Casos simples são resolvidos em 5–8 minutos. Não se trata de um experimento independente, mas de uma análise publicada pela AWS sobre a implantação de seu próprio serviço, portanto os números devem ser vistos como o resultado de uma equipe específica, não como uma promessa para qualquer infraestrutura.

Como funciona a análise

Um sinal do Grafana chega ao Lambda por meio do Amazon SNS e do SQS. Na primeira versão, dois agentes especializados trabalhavam em paralelo. Um verificava o estado das tarefas do ECS, dos balanceadores, as métricas e os logs do CloudWatch. O outro procurava erros de aplicação e traces no OpenSearch, além de buscar na base de conhecimento a ficha do serviço com suas dependências.

Em seguida, um terceiro agente consultava o GitHub: encontrava o repositório do serviço afetado e estudava o código, os arquivos de infraestrutura e os commits recentes. Uma chamada final ao modelo reunia os resultados em um relatório curto: causa provável, fatos que a sustentam, responsável pelo serviço e ações recomendadas.

Imagine um pico de respostas HTTP 5xx. A verificação da infraestrutura detecta reinícios de contêineres, os logs mostram recusa de conexão com o PostgreSQL e a análise do repositório revela que uma nova conexão é criada a cada requisição. Se uma campanha de marketing começou pouco antes da falha, o sistema relaciona o aumento da carga ao esgotamento do pool de conexões. O engenheiro de plantão recebe não um amontoado de mensagens, mas uma hipótese verificável e opções de correção: reutilizar conexões, adicionar o RDS Proxy ou ajustar o escalonamento.

O que mudou com o aumento da carga

Quando o volume de logs e de contexto cresceu, os nós individuais do Bedrock Flows passaram a ficar sem tempo. A equipe primeiro reforçou a filtragem e reduziu o contexto transmitido, e depois migrou a lógica para o Amazon Bedrock AgentCore Runtime. Os três agentes foram unificados em um único processo com estado persistente, e o acesso ao OpenSearch, à base de conhecimento e ao GitHub foi centralizado via AgentCore Gateway.

Na prática, três decisões são importantes. Primeiro, o agente pode refinar suas consultas ao longo da investigação sem perder o contexto já encontrado. Segundo, os traces do OpenTelemetry mostram a duração das etapas e os gargalos. Terceiro, as ferramentas recebem acesso limitado e gerenciado de forma centralizada aos dados.

O que pode ser replicado sem depender da AWS

A ideia principal aqui não está na escolha do modelo nem na autonomia total. Vale começar automatizando a coleta repetível de fatos, deixando a decisão e a correção com o engenheiro. Divida as fontes em infraestrutura, logs de aplicação, documentação e código; conceda a cada ferramenta as permissões mínimas; exija que o relatório final cite dados observáveis.

A Circle K destaca separadamente que é mais útil filtrar os logs com antecedência e passar ao modelo as linhas relevantes do que obrigá-lo a vasculhar sozinho enormes volumes. Mas esse filtro pode esconder um sinal importante, e o modelo pode conectar de forma convincente eventos não relacionados. Por isso, o resultado do agente deve continuar sendo uma hipótese: com carimbos de data e hora, fontes e a possibilidade de verificar rapidamente cada conclusão. A melhor primeira etapa da implantação é o modo sombra sobre o histórico de incidentes, medindo o tempo, a precisão das causas e a proporção de recomendações falsas, e só depois conectar ao canal real de plantão.