A empresa Wix gerencia uma plataforma de desenvolvimento em nuvem que atende 250 milhões de usuários, processando mais de 4 bilhões de transações HTTP diárias e armazenando 7 petabytes de dados em um data lake. Para lidar com esse volume, a equipe de Engenharia de Dados da Wix mantém mais de 3.500 pipelines Apache Airflow, que lidam com processos ETL e operações de Machine Learning, mas mesmo uma taxa de confiabilidade de 99,9% resulta em falhas diárias. Anteriormente, a resolução dessas falhas dependia de fluxos manuais reativos, com engenheiros atuando como “analisadores de erros humanos”, navegando por logs de Airflow, Spark e Kubernetes, o que gerava alta carga cognitiva e aumentava o Tempo Médio para Entender (MTTU).
Escala do Ecossistema e Desafios da Monitoração Tradicional
A plataforma da Wix opera em um ambiente heterogêneo que inclui Airflow, Trino, Spark, Kubernetes e serviços internos, tornando integrações hard-coded frágeis e não escaláveis. O processo manual de investigação envolvia quatro etapas principais: alerta genérico via Opsgenie, navegação por interfaces para localizar instâncias de tarefas, análise de megabytes de logs distribuídos e mapeamento do erro para mudanças recentes no código. Essa fricção resultava em latência operacional, com o Tempo Médio para Recuperação (MTTR) gasto principalmente em localização de bugs em vez de correções, além de custo de oportunidade para engenheiros altamente qualificados e custo humano pela exaustão mental em turnos de plantão.
Além disso, os alertas tradicionais falhavam em escala devido à complexidade combinatória do stack, transformando engenheiros em “roteadores humanos” para tarefas repetitivas de investigação, em detrimento de novas funcionalidades.
A Solução: AirBot e Suas Capacidades Principais
AirBot é um agente Slack impulsionado por IA projetado para o ecossistema da Wix, utilizando Modelos de Linguagem Grandes (LLMs) para converter alertas estáticos em investigações ativas. Suas três capacidades centrais incluem classificação imediata de alertas com contexto, diagnósticos contextuais usando código e logs de ferramentas internas como GitHub, Trino, Spark e OpenMetadata, e orientação de remediação acionável com geração de pull requests (PRs). Os conceitos por trás do AirBot são universais, visando resolver a complexidade em stacks semelhantes.
Na prática, o AirBot prioriza segurança e modularidade em uma arquitetura de microsserviços, superando limitações de automações simples baseadas em APIs.
Arquitetura e Design do AirBot
Para conectar o bot hospedado em nuvem aos clusters internos de Airflow sem comprometer o perímetro de segurança, o AirBot usa o Socket Mode, iniciando conexões WebSocket outbound para evitar portas de firewall inbound, garantindo segurança zero-trust, desempenho via conexões persistentes e simplificação no desenvolvimento local. O sistema é construído com o framework Slack Bolt Python para gerenciamento de conexões e FastAPI para o backend.
A camada de inteligência emprega o Protocolo de Contexto de Modelo (MCP) para visibilidade na infraestrutura, com um MCP personalizado para logs de Airflow em vez da API padrão, usando papéis IAM para acesso granular e busca semântica para erros relevantes. Integrações via MCP incluem GitHub para análise estática e geração de PRs, Trino e Spark para consultas diagnósticas, OpenMetadata para esquemas e contexto de negócios, DDS (Data Discovery Service) para linhagem de tabelas e tags de propriedade para roteamento de alertas. O motor de raciocínio adota uma arquitetura Chain of Thought com LangChain, dividida em cadeias de classificação (identificando operadores como Spark ou Trino e categorias de erro), análise (ingestão de código e logs para causa raiz) e solução (geração de plano ou PR), com modelos de saída JSON tipados para confiabilidade.
Em seguida, a infraestrutura de implantação usa containerização com Docker, deployment serverless para escalabilidade e gerenciamento de segredos via Vault, alinhando-se a princípios DevOps modernos.
Fluxos Operacionais e Impactos Mensuráveis
Em cenários práticos, como uma falha de consulta Trino devido a uma coluna inexistente (r.opendate), o AirBot busca SQL no GitHub e esquema no OpenMetadata, identifica o mismatch e abre um PR substituindo pela coluna correta (r.startdate), apresentando um botão “Review PR” no Slack. Em outro caso, um timeout de pipeline aguardando dados de uma tabela upstream (prod.wtloggedusers.blocks), o bot consulta APIs internas, resolve a tag de propriedade da tabela não atualizada e notifica o time responsável diretamente, evitando o engenheiro downstream.
Nos últimos 30 dias, em 30 canais de equipe suportando 60 engenheiros de dados, o AirBot gerou 180 PRs candidatos, com 28 mesclados diretamente (taxa de 15% de correção totalmente automatizada), muitos servindo como “blueprint” para implementações manuais. Um ciclo de depuração manual típico leva 45 minutos, reduzido em pelo menos 15 minutos por incidente, com base em 4.200 fluxos bem-sucedidos e taxa de feedback positivo de 66%, resultando em aproximadamente 2.700 intervenções impactantes e economia de 675 horas de engenharia por mês, equivalente a quatro engenheiros em tempo integral. Cada interação custa cerca de US$ 0,30, gerando ROI imediato ao comparar com o custo salarial do tempo poupado, com uso escalando conforme volume de pipelines e alertas.
