Como a Databricks usa IA para acelerar a investigação de incidentes

Em nosso post anterior do blog, compartilhamos como a Databricks usa AI para depurar milhares de bancos de dados. Aqui, continuamos essa história explorando como nossos engenheiros usam AI para operar centenas de microsserviços em mais de 1500 clusters Kubernetes, abrangendo mais de 70 regiões e três nuvens.

Quando algo falha às 2h da manhã, o engenheiro de plantão precisa responder a uma pergunta rapidamente: O que mudou?

O AI SRE é um agente de depuração baseado em AI que começa a investigar assim que um incidente ocorre. Ele correlaciona sinais de toda a nossa stack e orienta os engenheiros na análise de causa raiz.

Neste post, descrevemos a jornada de depuração que moldou o AI SRE, a arquitetura por trás dele e os princípios de engenharia que seguimos para tornar um sistema baseado em LLM confiável durante incidentes.

Antes do AI SRE: A experiência das 2h da manhã

Imagine um alerta de plantão típico. Um pico de latência atinge uma API voltada para o cliente. O engenheiro acorda e começa a rotina familiar:

• Inspecionar métricas de serviço em painéis e regiões.
• Buscar erros nos logs que sejam relevantes e incomuns ao mesmo tempo.
• Revisar implantações, alterações de dependência e atualizações de feature flags.
• Verificar a integridade da nuvem, da rede e da plataforma compartilhada.
• Encontrar e executar o runbook apropriado.

Cada um desses fluxos de trabalho funciona bem isoladamente, mas o fluxo de depuração — ou seja, o ato de conectar os sinais entre eles — ocorre inteiramente na mente do engenheiro. Engenheiros experientes conseguiam fazer isso em poucos minutos porque já tinham visto o padrão antes. Engenheiros mais novos podiam passar horas ou escalar o problema para outra pessoa.

As ferramentas não eram o principal problema. O fardo de conectar esses sinais recaía sobre o engenheiro de plantão, que trabalhava sob a pressão de um SLA.

Começando pelo cliente, não pela tecnologia

Não começamos construindo um agente. Começamos observando as pessoas depurarem.

Ao longo de várias semanas, entrevistamos engenheiros de plantão em dezenas de equipes para mapear suas jornadas de depuração de ponta a ponta. Lemos postmortems e documentos de investigação. Fizemos uma pergunta simples: onde você gasta seu tempo e onde você costuma travar?

Três padrões surgiram de forma consistente:

• A montagem do contexto consumia a maior parte do tempo. O momento da descoberta real — ou seja, identificar a causa raiz — costumava ser rápido assim que o engenheiro tinha os sinais certos à sua frente. Mas reunir esses sinais (a métrica certa, a janela de tempo correta, a implantação relevante, a dependência upstream que mudou) consumia de 60% a 80% do tempo de investigação.
• O conhecimento era distribuído de forma desigual. Cada equipe tinha alguns especialistas que "simplesmente sabiam" como o sistema falhava. Quando esses especialistas não estavam disponíveis, as investigações ficavam drasticamente mais lentas. Os runbooks existiam, mas geralmente estavam desatualizados ou incompletos, e não conseguiam responder a novos modos de falha.
• A integridade da plataforma era invisível até que deixava de ser. Muitos incidentes tinham origem em problemas de infraestrutura em grande escala, como uma interrupção no provedor de nuvem ou na rede, ou uma falha crítica de sistema como Auth. Mas os engenheiros que depuravam na camada de aplicação não tinham uma maneira fácil de verificar esses sinais, então passavam o tempo investigando hipóteses no nível da aplicação antes de descobrir que o problema estava em camadas inferiores de infraestrutura.

Assim que reconhecemos a depuração como uma sequência de etapas investigativas repetíveis seguidas pelo julgamento de especialistas, ficou claro que os agentes de AI poderiam acelerar o trabalho. Mas nenhuma equipe sozinha conseguiria construir um agente que entendesse cada serviço, sinal e modo de falha. Precisávamos de uma plataforma compartilhada que lidasse com os blocos de construção comuns, como reunir contexto, executar ferramentas e runbooks e correlacionar evidências, permitindo que as equipes a estendessem com seu próprio conhecimento operacional. A pergunta mudou de Podemos automatizar a depuração? para Como oferecemos a cada equipe uma plataforma baseada em AI para um diagnóstico e resolução mais rápidos e informados?

Apresentando o AI SRE

O AI SRE oferece suporte a duas experiências complementares: triagem automática, que começa assim que um incidente ocorre, e investigação interativa, que permite aos engenheiros de plantão explorar hipóteses e solicitar evidências adicionais.

Triagem automática quando um incidente ocorre

Quando um incidente ocorre, o AI SRE entra em ação imediatamente, antes mesmo de o engenheiro abrir o notebook. Ele inicia três frentes de investigação em paralelo, reunindo evidências complementares para produzir uma avaliação inicial:

As verificações de integridade da plataforma avaliam o ambiente no qual o serviço está sendo executado.

• A infraestrutura de nuvem subjacente está íntegra?
• Há problemas de rede em andamento na região relevante?
• As dependências upstream (bancos de dados, filas de mensagens, serviços compartilhados) estão sofrendo degradação?

Isso por si só elimina uma grande categoria de pistas falsas, de modo que o engenheiro não precisa mais passar 30 minutos depurando o código da aplicação apenas para descobrir que a causa raiz era um problema de infraestrutura em grande escala.

A análise em nível de serviço extrai os logs, métricas e traces relevantes para o serviço afetado e suas dependências diretas. Ela examina implantações recentes e alterações de configuração. Identifica anomalias em relação ao comportamento de referência do serviço, não apenas "o uso de CPU está alto", mas "a CPU teve um pico de 3x às 2h47 da manhã, coincidindo com uma implantação que alterou o tamanho do lote no pipeline de processamento".

A execução de runbooks é onde o AI SRE assume uma persona específica da equipe. As equipes codificam seus procedimentos de depuração, como as verificações que um especialista no domínio executaria, os limites que procurariam e as etapas de mitigação que tomariam. As equipes podem converter seus runbooks existentes em runbooks agênticos usando habilidades. Essas habilidades utilizam a base de código, dados de observabilidade e o histórico de incidentes anteriores para tornar os runbooks mais precisos e conscientes do contexto. Ele então executa essas etapas em nome do engenheiro de plantão, realizando a mesma investigação que um especialista faria, mas em segundos em vez de minutos.

No momento em que o engenheiro lê os detalhes do incidente pela primeira vez, o AI SRE já montou um resumo de diagnóstico detalhado: aqui está o que falhou, aqui está o que mudou e aqui está o que o runbook da sua equipe diz para verificar — todos os sinais, correlações e próximas etapas em uma única visualização.

Depuração interativa para investigação mais profunda

Nem toda investigação termina com a triagem automática. Às vezes, a causa raiz é sutil ou o engenheiro deseja explorar uma hipótese. A UI do AI SRE fornece um ambiente de depuração interativo onde os engenheiros podem fazer perguntas de acompanhamento em linguagem natural, solicitar sinais adicionais e detalhar janelas de tempo ou componentes específicos.

É aqui que a combinação de verificações de integridade estruturadas e AI conversacional se torna poderosa. Um engenheiro pode perguntar: "Houve algo incomum no consumer lag do Kafka nos 10 minutos anteriores a este alerta?" O AI SRE busca as métricas relevantes, sobrepõe-nas à linha do tempo do incidente e explica o que encontrou.

Uma arquitetura em camadas para depuração

As Primitivas formam a base: os dados operacionais brutos dos quais toda investigação depende em última análise. Já existem primitivas para métricas, alertas, logs, informações de lançamento e código, mas acessá-las durante um incidente significava alternar entre cinco ferramentas diferentes com cinco linguagens de consulta distintas. A camada de primitivas não substitui esses sistemas; ela os reconhece como a fonte da verdade.

A Camada de API utiliza primitivas e fornece acesso controlado e uniforme aos dados subjacentes. Em vez de fazer com que cada ferramenta de depuração consulte diretamente as fontes de dados, como o repositório de logs ou métricas, criamos APIs para fins específicos: uma API de Observabilidade, uma API de Implantação e uma API de Alertas que lidam com autenticação, limitação de taxa e normalização de dados. Esta é a camada que transforma a "infraestrutura bruta" em "infraestrutura depurável". Isso também significa que, quando substituímos um sistema subjacente, as ferramentas de depuração acima não param de funcionar.

O Mecanismo Principal é onde a inteligência reside. Um framework de bot fornece a camada de orquestração para criar fluxos de trabalho de depuração, e o mecanismo lida com a mecânica de execução paralela, correlação de resultados e síntese baseada em LLM. Esta é a plataforma na qual nossos bots proprietários são executados, mas, fundamentalmente, é também a mesma plataforma disponível para todas as equipes que desejam criar os seus próprios.

A Camada de Aplicação é onde a depuração realmente acontece. É aqui que o nosso bot de triagem de incidentes em nível de plataforma é executado. Também é onde ferramentas de IA de terceiros podem se conectar, fornecendo recursos complementares sem que precisemos reconstruir tudo do zero.

Essa separação nos permite melhorar o acesso a dados e a orquestração de forma independente, ao mesmo tempo em que oferece suporte a fluxos de trabalho mantidos centralmente e runbooks de propriedade das equipes

Desenvolvendo para Confiabilidade em um Mundo Não Determinístico

Tornar um agente baseado em LLM confiável o suficiente para resposta a incidentes, onde a confiança é tudo, exigiu uma engenharia deliberada. Alguns princípios nos guiaram:

Verificações estruturadas antes do raciocínio aberto. O AI SRE executa primeiro verificações determinísticas de integridade da plataforma e etapas de runbook. A camada de LLM sintetiza e explica os resultados, mas a coleta de dados não fica a critério do modelo.

Transparência em vez de respostas de caixa preta. Cada conclusão apresentada pelo AI SRE aponta de volta para a evidência subjacente: a métrica específica, a linha de log, o diff de deploy. Os engenheiros podem verificar o raciocínio, não apenas confiar nele. Isso era inegociável, pois os engenheiros de plantão não agiriam com base em uma recomendação que não pudessem auditar.

Degradação suave. Se o AI SRE não conseguir determinar uma causa raiz com confiança, ele dirá isso explicitamente e apresentará as evidências que coletou, organizadas por relevância. Uma investigação parcial que seja honesta sobre seus limites é muito mais útil do que um diagnóstico com alucinações.

Impacto

O AI SRE agora apoia mais de 150 equipes na Databricks, com mais de 250 usuários ativos semanais executando mais de 2.000 investigações todos os dias e economizando várias horas de tempo de depuração. Recebemos feedbacks positivos desde o lançamento:

“A equipe da plataforma de armazenamento depende muito do AI SRE para a triagem. Ele se antecipa às minhas investigações: antes mesmo de eu abrir um alerta, o agente já correlacionou os sinais e gerou uma análise inicial da causa raiz. Parabéns à equipe por criar uma plataforma de depuração verdadeiramente genérica que permite a várias equipes integrar fluxos de trabalho baseados em agentes no seu dia a dia.”—Gaurav Garg, Engenheiro Staff Sênior

“Antes do AI SRE, a primeira etapa de um incidente era a reunião de contexto: dashboards, janelas de tempo, filtros em toda a frota. Agora, o contexto relevante chega em um só lugar, já delimitado para o alerta/incidente. Não preciso apenas acreditar na palavra do agente. A evidência está incorporada na investigação, e um clique abre a ferramenta subjacente, pré-filtrada, para que eu mesmo possa verificar.”—Himanshu Mishra, Engenheiro Sênior

“O AI SRE transformou a resposta a incidentes ao unificar métricas, logs e integridade de dependências, acelerando a triagem de incidentes, identificando as causas raiz mais cedo e, consequentemente, reduzindo o MTTR em toda a empresa.”—Adama Kone, Gerente - Equipe NOC

O resultado mais importante não foi substituir o julgamento dos engenheiros. Foi dar a eles um ponto de partida mais rápido e baseado em evidências para a investigação.

O que Aprendemos

Três lições aprendidas ao criar o AI SRE:

Deixe que as equipes sejam donas de suas especialidades. Um agente centralizado que tenta codificar o conhecimento de domínio de cada equipe sempre será desatualizado e frágil. Ao transformar os runbooks baseados em agentes em uma primitiva combinável que as equipes possuem e mantêm, transformamos o AI SRE em uma plataforma que fica mais inteligente à medida que cresce, sem que a plataforma se torne o gargalo.

Crie a camada de contexto antes de otimizar o modelo. Passamos mais tempo mapeando como os engenheiros realmente investigam incidentes do que com engenharia de prompt. Esse investimento inicial na compreensão do problema significou que construímos a coisa certa, ou seja, um agente que reúne o contexto e executa verificações conhecidas, em vez do óbvio, que teria sido um chatbot acoplado ao nosso sistema de observabilidade.

Conquiste a confiança por meio de evidências rastreáveis. Toda recomendação feita pelo AI SRE é apoiada por evidências rastreáveis. Essa transparência foi o que transformou os primeiros usuários céticos em usuários diários.

Os guardrails importam mais para agentes do que para pessoas. Dar aos agentes acesso aos dados de observabilidade significou redesenhar nossa camada de API, e não apenas abri-la. Os agentes fazem consultas de maneira diferente dos humanos. Eles acessam endpoints em rajadas, executam verificações em paralelo e não se cansam nem recuam por conta própria. Tivemos que criar guardrails para que os agentes pudessem trabalhar rapidamente sem derrubar a infraestrutura que também alimenta o monitoramento e os alertas críticos para os negócios.

O que Vem a Seguir

O AI SRE hoje se concentra na fase de investigação da resposta a incidentes: entender o que aconteceu e o porquê. O próximo passo natural é expandir para a mitigação guiada — não apenas diagnosticar o problema, mas ajudar os engenheiros a tomar a ação corretiva correta com segurança.

Também estamos investindo no aprendizado entre incidentes (cross-incident learning): usando padrões de incidentes anteriores para melhorar diagnósticos futuros, identificar problemas recorrentes antes que gerem alertas e ajudar as equipes a identificar lacunas sistêmicas de confiabilidade.

Junte-se a Nós

Olhando para o futuro, estamos entusiasmados em continuar expandindo os limites de como a IA pode moldar os sistemas de produção e fazer com que a infraestrutura complexa pareça simples. Se você tem paixão por criar a próxima geração de plataformas internas baseadas em IA, junte-se a nós!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original