AIOps: o que funciona hoje

“AIOps” é vendido há mais de uma década com a mesma promessa: o sistema detecta, entende e corrige sozinho. A realidade entrega bem menos que isso — e mesmo assim entrega coisas úteis. Esta página separa uma da outra, para você investir onde há retorno.

O pré-requisito vale para tudo o que vem abaixo: nada disso funciona sem observabilidade boa. Modelo aplicado a dado ruim produz ruído com aparência de sofisticação.

O que realmente funciona

Detecção de anomalia em métrica com sazonalidade. Serviços têm padrão por hora do dia e dia da semana. Limiar fixo dispara todo domingo de madrugada ou perde uma queda de 40% na segunda de manhã. Modelos simples de série temporal lidam bem com isso.

# antes de trazer modelo: compare com a semana passada. Resolve boa parte dos casos.
sum(rate(pedidos_criados_total[10m]))
  / sum(rate(pedidos_criados_total[10m] offset 1w)) < 0.6

Agrupamento e correlação de alertas. Um incidente gera dezenas de alertas relacionados. Agrupar por proximidade temporal, topologia e serviço reduz drasticamente o que chega a quem está de plantão. Alertmanager já faz muito disso com group_by e inhibit_rules — comece por eles.

Detecção de anomalia de custo. Funciona bem e vem pronta nos provedores. Retorno imediato.

Triagem e resumo. Um modelo de linguagem lendo logs, eventos e diff recente produz um resumo inicial útil: o que mudou, o que está falhando, quais hipóteses investigar. Economiza os primeiros minutos — que são os mais caros.

Classificação e roteamento. Direcionar alerta ou chamado para o time certo com base em histórico é um problema de classificação bem resolvido.

O que ainda não funciona

• Causa raiz automática. Sistemas apontam correlação; causa exige entender intenção e contexto de negócio. Trate a sugestão como hipótese, nunca como conclusão.
• Remediação autônoma ampla. Ação automática funciona em cenários estreitos e ensaiados (reiniciar réplica, limpar disco, escalar). “O sistema se conserta sozinho” é o assunto — e o risco — de agentes de operação.
• Predição de falha genérica. Predição funciona para tendência simples (disco enche em N horas). “Vai haver um incidente amanhã” não é acionável.
• Substituir alerta bem definido. Um SLO com burn rate continua sendo o melhor alerta que você pode ter. Anomalia complementa; não substitui.

Detecção de anomalia sem virar ruído

Aplique só onde limiar fixo falha de verdade — métricas de negócio com sazonalidade forte (pedidos, cadastros, pagamentos), e não em CPU de container.

Regras que evitam o efeito colateral clássico:

• Sensibilidade separada por direção. Queda de pedidos importa; alta, quase nunca.
• Janela mínima: anomalia de 30 segundos raramente merece página.
• Feriados e campanhas distorcem qualquer modelo — anote esses eventos e exclua-os do treinamento.
• Severidade menor por padrão: anomalia abre ticket, SLO abre página.
• Meça o falso positivo. Se mais da metade não gera ação, desligue e recalibre.

Resumo de incidente

O caso de uso mais defensável hoje. Um assistente que, ao abrir o incidente, monta:

Serviço: checkout   Início: 13h55   Sintoma: 5xx em 6% das requisições
Mudanças recentes: deploy pedidos 1.8.3 (13h48), flag pagamento.async ligada (11h20)
Sinais: latência do banco p95 de 40ms → 900ms; pool de conexões em 100%
Alertas relacionados: 4 (agrupados)
Hipóteses: (1) mudança de pool no PR #482  (2) consulta nova sem índice
Links: painel · logs filtrados · runbook · PR

Note que nada aí é conclusão: é coleta e organização — exatamente o trabalho manual que consome os dez primeiros minutos. E deixe explícito para quem lê que são hipóteses, ou o resumo vira âncora e o time para de investigar alternativas.

Como adotar sem se enganar

1. Arrume a base primeiro: métricas com significado, alertas por sintoma, logs estruturados, catálogo com donos.
2. Comece pelo agrupamento de alertas — pouco risco, ganho imediato.
3. Acrescente anomalia em duas ou três métricas de negócio.
4. Avalie triagem assistida em modo somente leitura.
5. Meça: acionamentos por semana, tempo até mitigação, percentual de alerta acionável.

Se as métricas não melhoram depois de um trimestre, o problema não estava na inteligência — estava nos dados ou no processo. É quase sempre o caso.

Próximo passo: veja onde LLM ajuda antes da produção em LLM no pipeline.