Avito conectou um LLM a testes de caos e ampliou a cobertura de incidentes de 22% para 41%

O incidente terminou, a equipe escreveu a analise e abriu as tarefas necessarias; um trimestre depois, enfrentou uma falha quase identica. E uma historia conhecida: funcionalidades de produto passam constantemente a frente da divida tecnica, enquanto as conclusoes dos post-mortems acabam, aos poucos, virando arquivo.

A Avito tentou fechar essa lacuna. Falhas anteriores se tornaram uma fonte de cenarios para testes de caos, e o LLM virou um filtro para ajudar a processar centenas de relatorios. O modelo estudou 977 LSRs, avaliou quais falhas poderiam ser reproduzidas e sugeriu anomalias adequadas. Em seguida, um engenheiro verifica se o teste realmente reproduz a causa raiz, em vez de apenas criar um quadro semelhante nos graficos.

Do relatorio de incidente a validacao em producao

O pipeline enriquecia o texto do LSR com mensagens do chat associado e depois fazia seis perguntas separadas ao modelo. Ele descrevia brevemente a causa e o sintoma, avaliava a viabilidade de um teste de caos, verificava o destino dos Action Items, atribuía ao cenario uma nota de 0 a 10 e selecionava anomalias de uma biblioteca interna. Os resultados eram armazenados no MongoDB, enquanto o Elasticsearch era usado para criar um indice vetorial destinado a busca de incidentes semelhantes.

Com isso, a Avito obteve 432 conclusoes atualizadas automaticamente para 408 servicos. Segundo a estimativa do modelo, 41% das falhas analisadas poderiam ser reproduzidas com ferramentas existentes ou planejadas. Apenas com o LitmusChaos, que atua principalmente no nivel dos pods, o indicador ficava em torno de 22%. O orquestrador de dominio Kratos quase dobrou a cobertura potencial ao adicionar cenarios para bancos de dados e rede.

Um exemplo simples e o failover do master do Redis. Um teste convencional pode encerrar um processo ou excluir um pod, mas isso nao equivale a uma reeleicao real do primary dentro de um replica set. Por isso, a equipe adicionou o cenario trigger-primary-re-election para MongoDB e Redis. Ele e usado em 95,6% das execucoes automaticas: os servicos sao testados com um failover real do master, e nao com uma simulacao aproximada.

Onde o LLM erra

Uma nota alta do modelo ainda nao significa que o teste seja util. Em um dos casos, a falha foi causada por uma configuracao incorreta do Nginx depois da correcao de uma vulnerabilidade. O LLM deu ao cenario uma nota de 10 em 10 e sugeriu adicionar latencia de rede. Os sintomas eram realmente semelhantes: erros HTTP, timeouts e documentos indisponiveis. No entanto, o teste de caos nao podia alterar a configuracao de um sistema de terceiros e, portanto, jamais reproduziria a causa raiz.

Essa e uma limitacao importante. O modelo consegue classificar bem um grande conjunto de relatorios e indicar ao engenheiro onde procurar, mas pode confundir causa e efeito. A Avito nao lhe entrega a decisao final: uma pessoa verifica a hipotese, o raio de impacto e a seguranca da execucao. O proprio pipeline de analise esta suspenso no momento, apos o encerramento do servico interno que hospedava o modelo anterior, embora o dataset acumulado e a metodologia tenham sido preservados.

O que pode ser aplicado na sua organizacao

O ponto de partida nao deve ser a compra de uma plataforma de caos, mas o mapeamento de falhas reais. Divida-as entre recursos, rede, processos, camada de aplicacao, infraestrutura externa e logica de negocio. Depois, associe cada classe a uma causa raiz verificavel, a uma janela segura e a um criterio mensuravel de recuperacao.

Nesse caso, o LLM e util como uma camada de busca sobre os post-mortems: encontra causas recorrentes, agrupa incidentes e sugere candidatos a automacao. Mas um teste so deve ser adicionado quando reproduzir o mecanismo da falha. Caso contrario, a equipe tera um relatorio verde, um cronograma de execucoes e uma perigosa falsa sensacao de seguranca.