Agentes de incidentes: antes da causa raiz automática, organize as relações

Uma apresentação sobre observabilidade na Netflix descreve o uso de ontologia e grafos para relacionar serviços, responsáveis, implantações, alertas e incidentes.[20] Um exemplo de falha mobilizou nove equipes e mais de 30 engenheiros durante cerca de quatro horas, com investigações fragmentadas sobre sintomas relacionados.[20] O problema discutido não é apenas coletar mais telemetria, mas conectar evidências com significado operacional.

O que muda para quem desenvolve

A proposta utiliza RDF, OWL, SPARQL e SHACL para representar entidades, relações e restrições.[20] O coletor começa com extração determinística de identificadores, validação no catálogo de serviços e enriquecimento por APIs; depois entram classificação com LLM e correlação probabilística.[20]

Minha leitura: essa ordem é mais importante do que copiar a pilha tecnológica. Comece pelo que pode ser identificado e confirmado de maneira direta. Reserve ao modelo a proposta de relações que exigem interpretação, mantendo essa origem visível.

O grafo QuipuDB relaciona mensagens, dashboards, serviços, pessoas e ações.[20] O AutoSRE consulta telemetria, topologia, código e o grafo por ferramentas MCP e CLI para apoiar investigação e sugerir próximos passos.[20] Isso é apoio ao diagnóstico, não demonstração de que uma resposta inicial sempre determina a causa.

Recomendo distinguir observação, hipótese e decisão no próprio modelo de dados. Uma implantação anterior a um erro pode ser uma pista; não deveria ser registrada automaticamente como causa confirmada. O agente precisa conseguir mostrar de onde veio cada relação e o que ainda falta verificar.

Como aplicar

Escolha um serviço e um pequeno conjunto de incidentes já documentados. Defina identificadores estáveis para serviço, implantação, alerta e incidente. Registre também responsável e referência à evidência, com escopo mínimo de dados pessoais.

Monte primeiro uma linha do tempo por extração determinística. Depois, proponha relações candidatas usando um modelo e mantenha-as separadas dos vínculos confirmados. Exija origem, justificativa e possibilidade de rejeição para cada hipótese.

Como experimento, use um caso conhecido e uma entrada congelada. Avalie se o sistema encontra as entidades esperadas, evita criar serviços inexistentes e aponta evidências suficientes para reconstruir a sequência. Compare com o resultado conhecido sem permitir que o agente leia previamente a conclusão.

Só então teste perguntas de investigação e sugestões de próximos passos. Mantenha a execução de remediação fora do piloto: a primeira meta é recuperar contexto corretamente e expor lacunas.

Cuidados e limites

Os autores esclarecem que não colocam cada evento bruto de telemetria no grafo; capturam metadados, fingerprints e padrões com referências ao restante dos dados.[20] Essa decisão evita confundir escala de coleta com escala de entidades relacionais.

O relato inclui agentes que propõem alterações no coletor em branches ou worktrees, mas humanos examinam e autorizam os merges.[20] Causa raiz automática, remediação e infraestrutura autorrecuperável aparecem no roadmap, não como capacidades concluídas.[20]

Os autores também reconhecem que os mecanismos de qualidade ainda não foram aplicados extensivamente em todas as frentes, e não anunciam abertura imediata do código.[20] O trade-off é manter uma base estruturada, com revisão e controle de evolução. Para um piloto pequeno, prefira relações verificáveis a uma ontologia enorme que ninguém consegue conferir.

Fonte

[20] Fonte: InfoQ, apresentação de Prasanna Vijayanathan e Renzo Sanchez-Silva