Como depuramos milhares de bancos de dados com AI na Databricks

Na Databricks, substituímos as operações manuais de banco de dados por AI, reduzindo o tempo gasto com depuração em até 90%.

Nosso agente de AI interpreta, executa e depura recuperando as métricas key e logs e correlacionando os sinais automaticamente. Opera em diversos bancos de dados implantados em todas as principais cloud e em quase todas as regiões de cloud.

Essa nova capacidade de agente permitiu que os engenheiros respondessem rotineiramente a perguntas em linguagem natural sobre a integridade e o desempenho de seus serviços, sem precisar entrar em contato com os engenheiros de plantão nas equipes de armazenamento.

O que começou como um pequeno projeto de hackathon para simplificar o fluxo de trabalho de investigação evoluiu para uma plataforma inteligente com adoção em toda a empresa. Esta é a nossa jornada.

Pré AI: tudo funcionava, mas nada funcionava junto

Durante a investigação de um incidente típico do MySQL, um engenheiro costumava

• Verificar métricas no Grafana
• Mude para um dashboard do Databricks para entender a carga de trabalho do cliente
• Execução de comandos da CLI para inspecionar o status do InnoDB, um Snapshot do estado interno do MySQL que contém informações como história de transações, operações de E/S e detalhes de deadlock
• log in em um cloud console para baixar logs de query lentas

Cada ferramenta funcionava bem por si só, mas juntas não conseguiam formar um fluxo de trabalho coeso ou fornecer percepções de ponta a ponta. Um engenheiro experiente do MySQL poderia montar uma hipótese saltando entre tabs e comandos na sequência certa; no entanto, isso queima o precioso orçamento e o tempo do SLO no processo. Um engenheiro mais novo geralmente não saberia por onde começar.

Ironicamente, essa fragmentação em nosso ferramental interno refletia o mesmo desafio que a Databricks ajuda nossos clientes a superar.

A Databricks Data Intelligence Platform unifica dados, governança de dados e AI, permitindo que usuários autorizados entendam seus dados e ajam com base neles. Internamente, nossos engenheiros precisam do mesmo: uma plataforma unificada que consolide os dados e os fluxos de trabalho que sustentam nossa infraestrutura. Com essa base, podemos aplicar inteligência usando AI para interpretar os dados e fornecer um guia para os engenheiros sobre o próximo o passo correto.

Nossa jornada: de hackathon a agentes inteligentes

Não começamos com uma iniciativa grande e de vários trimestres. Em vez disso, testamos a ideia durante um hackathon de toda a empresa. Em dois dias, construímos um protótipo simples que unificava algumas métricas e dashboards de banco de dados principais em uma única view. Não estava refinado, mas melhorou imediatamente os fluxos de trabalho de investigação básicos. Isso definiu nosso princípio norteador: agir rápido e manter o foco total no cliente.

Construindo plataformas com obsessão pelo cliente

Antes de escrever mais código, entrevistamos as equipes de serviço para entender seus pontos problemáticos na depuração. Os temas eram consistentes: engenheiros júnior não sabiam por onde começar, e engenheiros sênior achavam o ferramental fragmentado e complicado.

Para ver o problema em primeira mão, acompanhamos as sessões de plantão e observamos os engenheiros depurando os problemas em tempo real. Três padrões se destacaram:

• Ferramentas fragmentadas
  Os engenheiros alternavam entre dashboards, CLIs e os passos manuais para investigação e operações como reinicializações ou restaurações. Cada ferramenta funcionava de forma isolada, mas a falta de integração tornava o fluxo de trabalho lento e propenso a erros.
• Tempo perdido coletando contexto
  A maior parte do trabalho era descobrir o que mudou, como era o "normal" e quem tinha o contexto certo para ajudar, mas não em mitigar o incidente de fato.
• Orientações pouco claras sobre mitigação segura
  Durante incidentes, os engenheiros geralmente não tinham certeza de quais ações eram seguras ou eficazes. Sem runbooks claros ou automação, eles defaultaram para longas investigações ou esperavam por especialistas.

Analisando em retrospecto, as análises post-mortem raramente expunham essa lacuna: às equipes não faltavam dados ou ferramentas; faltava a elas uma depuração inteligente para interpretar a enxurrada de sinais e guiá-las em direção a ações seguras e eficazes.

Iterando rumo à inteligência

Começamos com pouco, com a investigação do banco de dados como o primeiro caso de uso. Nossa versão 1 era um fluxo de trabalho agêntico estático que seguia um SOP de depuração, mas não era eficaz – os engenheiros queriam um relatório de diagnóstico com percepções imediatas, não uma lista de verificação manual.

Mudamos nosso foco para a obtenção dos dados corretos e a aplicação de inteligência sobre eles. Essa estratégia levou à detecção de anomalia, que revelou as anomalias corretas, mas ainda não forneceu os passos claros.

O verdadeiro avanço veio com um assistente de bate-papo que codifica o conhecimento de depuração, responde a acompanhamentos e transforma as investigações em um processo interativo. Isso transformou a forma como os engenheiros depuram incidentes de ponta a ponta.

Uma base: abstração e centralização

Dando um passo para trás, percebemos que, embora nosso framework existente pudesse unificar fluxos de trabalho e dados em uma única interface, nosso ecossistema não foi construído para que a AI raciocinasse sobre nosso cenário operacional. Qualquer agente precisaria lidar com a lógica específica da região e da cloud. E sem controles de acesso centralizados, ele se tornaria restritivo demais para ser útil ou permissivo demais para ser seguro.

Esses problemas são especialmente difíceis de resolver no Databricks, pois operamos milhares de instâncias de banco de dados em centenas de regiões, oito domínios regulatórios e três clouds. Sem uma base sólida que abstraia as diferenças de cloud e regulatórias, a integração de AI rapidamente encontraria uma série de obstáculos inevitáveis:

• Fragmentação de contexto: os dados de depuração ficavam em lugares diferentes, o que dificultava para um agente construir uma imagem consistente.
• Limites de governança pouco claros: Sem autorização centralizada e aplicação de políticas, fica difícil garantir que o agente (e os engenheiros) permaneçam com as permissões corretas.
• Ciclos de iteração lentos: abstrações inconsistentes dificultam o teste e a evolução do comportamento da AI, desacelerando gravemente a iteração ao longo do tempo.

Para tornar o desenvolvimento de AI seguro e escalável, focamos em fortalecer a base da plataforma em torno de três princípios:

• Arquitetura de sharding com prioridade central, em que uma instância global do Storex coordena shards regionais, fornecendo uma interface única e mantendo os dados confidenciais locais e em conformidade.
• Controle de acesso refinado, aplicado nos níveis de equipe, recurso e RPC, garantindo que engenheiros e agentes operem com segurança dentro das permissões corretas.
• Orquestração unificada, em que nossa plataforma integra os serviços de infraestrutura existentes, permitindo abstrações consistentes entre clouds e regiões.

Com os dados e o contexto centralizados, o próximo passo ficou claro: como poderíamos tornar a plataforma não apenas unificada, mas também inteligente?

Da visibilidade à inteligência

Com uma base unificada estabelecida, foi simples implementar e expor recursos como a recuperação de esquemas de banco de dados, métricas ou logs de query lentas para o agente de AI. Em algumas semanas, criamos um agente que podia agregar informações básicas do banco de dados, raciocinar sobre elas e apresentá-las de volta ao usuário.

Agora, a parte difícil era tornar o agente confiável: dado que os LLMs são não determinísticos, não sabíamos como ele responderia às ferramentas, aos dados e aos prompts aos quais tinha acesso. Acertar isso exigiu muita experimentação para entender quais ferramentas eram eficazes e qual contexto incluir (ou omitir) nos prompts.

Para possibilitar essa iteração rápida, criamos uma estrutura leve inspirada nas tecnologias de otimização de prompt do MLflow que aproveita o DsPy, que desacopla o prompt da implementação da ferramenta. Os engenheiros podem definir as ferramentas como classes Scala normais e assinaturas de funções, bastando adicionar uma breve docstring que descreva a ferramenta. A partir daí, o LLM pode inferir o formato de entrada da ferramenta, a estrutura de saída e como interpretar os resultados. Esse desacoplamento nos permite agir rapidamente: podemos iterar os prompts ou trocar ferramentas dentro e fora do agente sem alterar constantemente a infraestrutura subjacente que lida com análise, conexões LLM ou estado da conversa.

À medida que iteramos, como podemos provar que o agente está melhorando sem introduzir regressões? Para resolver isso, criamos uma estrutura de validação que captura Snapshots do estado de produção e os repete por meio do agente, usando um LLM "juiz" separado para classificar as respostas quanto à precisão e à utilidade à medida que modificamos os prompts e as ferramentas.

Como essa estrutura nos permite iterar rapidamente, podemos facilmente criar agentes especializados para diferentes domínios: um focado em problemas de sistema e banco de dados, outro em padrões de tráfego do lado do cliente e assim por diante. Essa decomposição permite que cada agente desenvolva um profundo conhecimento em sua área e, ao mesmo tempo, colabore com outros para fornecer uma análise de causa raiz mais completa. Ele também abre caminho para a integração de agentes de AI em outras partes de nossa infraestrutura, indo além dos bancos de dados.

Com o conhecimento especializado e o contexto operacional codificados em seu raciocínio, nosso agente pode extrair percepções significativas e atuar como guia para os engenheiros durante as investigações. Em minutos, ele apresenta logs e métricas relevantes que os engenheiros talvez não tivessem considerado examinar. Ele conecta sintomas entre camadas, como identificar o workspace que está gerando carga inesperada e correlacionar picos de IOPS com migrações de esquema recentes. Ele até explica a causa e o efeito subjacentes e recomenda os próximos passos para mitigação.

Em conjunto, estes elementos marcam nossa transição de visibilidade para inteligência. Fomos além da visibilidade de ferramentas e métricas para uma camada de raciocínio que entende nossos sistemas, aplica conhecimento especializado e guia os engenheiros para mitigações seguras e eficazes. É uma base sobre a qual podemos continuar construindo, não apenas para bancos de dados, mas também para a forma como operamos a infraestrutura como um todo.

O impacto: Redefinindo a forma como construímos e operamos em escala

A plataforma mudou a forma como os engenheiros da Databricks interagem com sua infraestrutura. Os passos individuais que antes exigiam alternar entre dashboards, CLIs e SOPs agora podem ser facilmente resolvidos pelo nosso assistente de chat, reduzindo o tempo gasto em até 90%.

A curva de aprendizado para a nossa infraestrutura entre os novos engenheiros também caiu drasticamente. Novos contratados sem nenhum contexto agora conseguem começar rapidamente uma investigação de banco de dados em menos de 5 minutos, algo que teria sido quase impossível antes. E recebemos um ótimo feedback desde o lançamento desta plataforma:

O Database Assistant realmente me poupa muito tempo, pois não preciso lembrar onde estão todos os meus painéis de query. Posso simplesmente perguntar a ele qual workspace está gerando a carga. A melhor ferramenta que você já viu!- Yuchen Huo, engenheiro da equipe

Sou um grande usuário e não consigo acreditar que vivíamos na sua ausência. O nível de polimento e utilidade é impressionante. Obrigado, equipe, é um grande passo na experiência do desenvolvedor.- Dmitriy Kunitskiy, engenheiro da equipe

Adoro especialmente como estamos trazendo percepções geradas por AI para a depuração de problemas de infraestrutura. Aprecio o quão visionária a equipe tem sido ao projetar este console do zero com isso em mente.— Ankit Mathur, Engenheiro Especialista Sênior

Em termos de arquitetura, a plataforma estabelece a base para a próxima evolução: operações de produção assistidas por AI. Com dados, contexto e mecanismos de proteção unificados, agora podemos explorar como o agente pode ajudar com restaurações, querys de produção e atualizações de configuração: o próximo passo em direção a um fluxo de trabalho operacional assistido por AI.

Mas o impacto mais significativo não foi apenas a redução do trabalho repetitivo ou um onboarding mais rápido: foi uma mudança de mentalidade. Nosso foco mudou da arquitetura técnica para as jornadas críticas do usuário (CUJs) que definem como os engenheiros vivenciam nossos sistemas. Essa abordagem que prioriza o usuário é o que permite que nossas equipes de infraestrutura criem plataformas sobre as quais nossos engenheiros possam construir produtos vencedores em suas categorias.

Principais conclusões

No final, nossa jornada se resumiu a três principais conclusões:

• A iteração rápida é essencial para o desenvolvimento de agentes: os agentes melhoram por meio de experimentação, validação e refinamento rápidos. Nosso framework inspirado no DsPy permitiu isso ao nos permitir evoluir rapidamente os prompts e as ferramentas.
• A velocidade da iteração é limitada pela base subjacente: dados unificados, abstrações consistentes e controle de acesso granular removeram nossos maiores gargalos, tornando a plataforma confiável, escalável e pronta para AI.
• A velocidade só é importante quando você tem uma direção correta: Não nos propusemos a criar uma plataforma de agentes. Cada iteração simplesmente seguia o feedback do usuário e nos aproximava da solução que os engenheiros precisavam.

Construir plataformas internas é enganosamente difícil. Mesmo na mesma empresa, as equipes de produto e plataforma operam sob restrições muito diferentes. Na Databricks, estamos diminuindo essa lacuna ao construir com obsessão pelo cliente, simplificar por meio de abstrações e aprimorar com inteligência, tratando nossos clientes internos com o mesmo cuidado e rigor que dedicamos aos nossos externos.

Faça parte da nossa equipe

Olhando para o futuro, estamos entusiasmados para continuar expandindo os limites de como a AI pode moldar os sistemas de produção e fazer com que a infraestrutura complexa pareça simples. Se você é apaixonado por construir a próxima geração de plataformas internas baseadas em AI, join nós!

(This blog post has been translated using AI-powered tools) Original Post