[329] AIOps na Prática: O Que a IA Já Faz em Operações Hoje

Poucas áreas da tecnologia acumulam tanto entusiasmo e tanta confusão simultâneos quanto a aplicação de inteligência artificial a operações de software. Vendors prometem sistemas que "resolvem incidentes automaticamente", "preveem falhas antes que aconteçam" e "eliminam o trabalho manual de operações". Parte disso já existe e funciona. Parte é aspiracional. Parte é marketing reembalado de funcionalidades que existem há anos sob outro nome.

Este artigo é uma avaliação honesta do estado atual: o que a IA já faz em operações com resultado comprovado, onde ainda é promessa, e como um engenheiro pode começar a aplicar essas ferramentas sem se perder em hype.

AIOps é o termo consolidado para a aplicação de machine learning e análise de dados a operações de TI. O conceito foi cunhado pelo Gartner em 2017 e desde então expandiu para cobrir desde correlação de alertas até geração automática de código de infraestrutura. Para este artigo, é útil dividir o território em quatro categorias por maturidade.

Categoria 1: Consolidado e Funcionando

Detecção de Anomalias em Métricas

A detecção de anomalias em séries temporais é o caso de uso mais maduro do AIOps. O problema é bem definido: dado o comportamento histórico de uma métrica (taxa de requisições, latência, uso de CPU), identificar quando o valor atual desvia significativamente do esperado — considerando sazonalidade, tendências e padrões de dia da semana.

O AWS CloudWatch Anomaly Detection e o Azure Monitor com Dynamic Thresholds resolvem exatamente esse problema. Em vez de configurar manualmente um alerta "dispare quando a latência ultrapassar 500ms", é possível configurar "dispare quando a latência estiver fora do intervalo esperado para este horário e dia da semana". O modelo aprende com 14 dias de histórico e ajusta os limites automaticamente.

# boto3 — configurar Anomaly Detector no CloudWatch
import boto3

cloudwatch = boto3.client('cloudwatch', region_name='sa-east-1')

# Criar um anomaly detector para a métrica de latência
cloudwatch.put_anomaly_detector(
    Namespace='MinhaApp',
    MetricName='Latencia_p99',
    Dimensions=[
        {'Name': 'Servico', 'Value': 'order-service'},
    ],
    Stat='p99',
    Configuration={
        # Janelas a excluir do treino — use para tirar do baseline o
        # período de um incidente ou de uma migração, que sujariam o modelo.
        # A sazonalidade semanal o modelo já aprende sozinho.
        'ExcludedTimeRanges': [],
        'MetricTimezone': 'America/Sao_Paulo'
    }
)

# Criar alerta baseado no anomaly detector
cloudwatch.put_metric_alarm(
    AlarmName='order-service-latencia-anomalia',
    AlarmDescription='Latência p99 fora do padrão esperado',
    # ANOMALY_DETECTION_BAND retorna o intervalo esperado pelo modelo
    Metrics=[
        {
            'Id': 'latencia',
            'MetricStat': {
                'Metric': {
                    'Namespace': 'MinhaApp',
                    'MetricName': 'Latencia_p99',
                    'Dimensions': [{'Name': 'Servico', 'Value': 'order-service'}]
                },
                'Period': 300,
                'Stat': 'p99'
            }
        },
        {
            'Id': 'banda_esperada',
            'Expression': 'ANOMALY_DETECTION_BAND(latencia, 2)',
            # 2 = desvios padrão acima/abaixo do esperado
        }
    ],
    'ComparisonOperator': 'GreaterThanUpperThreshold',
    'ThresholdMetricId': 'banda_esperada',
    'EvaluationPeriods': 3,
    'TreatMissingData': 'notBreaching',
    'AlarmActions': ['arn:aws:sns:sa-east-1:123456789012:alertas-criticos']
)

Correlação de Alertas e Redução de Ruído

Sistemas de observabilidade modernos geram centenas ou milhares de alertas durante um incidente. Um serviço cai, e imediatamente disparam alertas de latência, de taxa de erro, de health check, de filas acumulando, de dependentes que começam a falhar em cascata. Sem correlação, o engenheiro de plantão recebe 50 notificações sobre o mesmo problema raiz.

A correlação de alertas — agrupar alertas relacionados em um único incidente — é a funcionalidade central do PagerDuty, Opsgenie e ferramentas similares. O que o machine learning adiciona é a capacidade de aprender quais alertas tendem a aparecer juntos, qual deles geralmente é a causa raiz, e qual a sequência temporal típica — sem configuração manual de regras de correlação.

O Prometheus AlertManager sozinho não faz isso (tem agrupamento por labels, mas não correlação inteligente). Ferramentas como o AWS DevOps Guru e o Dynatrace Davis aplicam ML para reduzir dezenas de alertas a um único evento de "problema detectado" com causa raiz inferida.

Análise Inteligente de Logs

A busca em logs com expressões regulares e filtros manuais existe há décadas. O que o ML adiciona é a capacidade de classificar logs sem configuração prévia: identificar quais mensagens de log são "normais para este horário", quais são padrões novos que nunca apareceram antes, e quais correlacionam com degradações de performance.

O CloudWatch Log Insights com ML e o Elastic Observability com ML Jobs fazem isso nativamente. O exemplo mais útil na prática é a detecção de padrões novos: em vez de procurar por uma string específica de erro, o sistema alerta quando um tipo de mensagem de log aparece pela primeira vez ou com frequência anormalmente alta.

# Exemplo: usar o AWS DevOps Guru para análise automática de anomalias
# O DevOps Guru analisa CloudWatch métricas e logs automaticamente
# Configuração via Terraform:

resource "aws_devopsguru_resource_collection" "minha_app" {
  type = "AWS_CLOUD_FORMATION"

  cloud_formation {
    # DevOps Guru monitora todos os recursos desta stack
    stack_names = [
      "minha-app-producao",
      "minha-app-infraestrutura"
    ]
  }
}

# O DevOps Guru gera insights automaticamente quando detecta anomalias.
# Não requer configuração de alertas individuais — ele aprende o baseline
# e notifica quando algo está fora do padrão, com causa raiz inferida.

Categoria 2: Emergindo com Resultados Reais

Assistentes de Código para Infraestrutura

O GitHub Copilot, o Cursor e ferramentas similares têm impacto mensurável na escrita de Terraform, scripts Bash, manifestos Kubernetes e pipelines YAML. O benefício não é que a IA escreve código perfeito — é que ela elimina o tempo gasto consultando documentação para lembrar a sintaxe de um recurso que se usa raramente.

Um engenheiro que sabe o que quer fazer mas precisa consultar a documentação do azurerm_kubernetes_cluster para lembrar o nome exato do campo de Workload Identity economiza 5 minutos com o Copilot. Multiplicado por dezenas de interações por dia, o ganho de produtividade é real e já documentado em estudos do GitHub: desenvolvedores completam tarefas com assistência de IA entre 35% e 55% mais rápido em benchmarks controlados.

O próximo artigo (E10) cobre isso em profundidade com exemplos práticos de geração e revisão de pipelines.

Root Cause Analysis Assistida

Ferramentas como o Datadog Watchdog e o Dynatrace Davis vão além da detecção de anomalias: elas tentam identificar a causa raiz automaticamente, correlacionando eventos de infraestrutura, deploys recentes, mudanças de configuração e métricas de aplicação.

O resultado prático não é "a IA resolve o incidente sozinha" — ainda é o engenheiro que toma as decisões e executa as ações. O que a ferramenta faz é apresentar um diagnóstico estruturado: "Anomalia detectada às 14:23. Correlacionada com deploy realizado às 14:20. Serviço order-service mostrando latência 3x acima do normal. Possível causa: nova versão da query de banco de dados em /src/orders/repository.js linha 47."

Isso reduz o tempo de diagnóstico — o MTTD (Mean Time to Detect) e o MTTR (Mean Time to Recover) — que são as métricas que realmente importam em operações.

Categoria 3: Promissora mas Ainda Imatura

Remediação Automática

A ideia de um sistema que detecta um problema e automaticamente o corrige — reinicia o pod com crash, faz rollback do deploy problemático, aumenta a capacidade — existe em implementações limitadas e confiáveis. O Kubernetes já faz isso em nível básico com liveness probes e restarts automáticos. O HPA escala automaticamente baseado em métricas.

O que ainda é imaturo é a remediação autônoma de problemas mais complexos: "a query está lenta porque o índice está fragmentado — reconstruir o índice automaticamente em produção". Esse tipo de ação requer confiança muito alta na decisão da IA, porque uma ação errada pode piorar o problema. A maioria das organizações com cultura de engenharia madura ainda prefere "IA sugere, humano aprova e executa" para ações de remediação não-triviais.

Previsão de Capacidade

Machine learning aplicado a previsão de capacidade — "quantas instâncias vou precisar semana que vem para a campanha de Black Friday?" — funciona razoavelmente bem em problemas com padrões históricos claros. Mas para eventos sem precedente, crescimento acelerado de usuários ou mudanças de comportamento causadas por features novas, a previsão tem limitações inerentes: não é possível prever o que nunca aconteceu antes.

Como Começar: Um Roteiro Prático

Para times que querem começar a aplicar AIOps sem grandes investimentos em ferramentas especializadas, o roteiro mais pragmático segue três passos.

O primeiro é ativar as funcionalidades de ML que já estão nos serviços em uso. O CloudWatch Anomaly Detection, o Azure Monitor com Dynamic Thresholds, o AWS DevOps Guru e o Datadog Watchdog são ativados com poucos cliques ou linhas de Terraform. Não requerem dados de treinamento customizados nem expertise em ML.

O segundo é integrar um assistente de código ao workflow de desenvolvimento. GitHub Copilot ou Cursor para escrita de Terraform, pipelines e scripts. O ROI é imediato e mensurável em horas economizadas.

O terceiro é instrumentar as métricas de negócio que alimentarão os modelos. Detecção de anomalias em métricas técnicas (CPU, latência) é útil, mas detecção de anomalias em métricas de negócio (taxa de conversão, pedidos por minuto) é o que gera valor direto. Isso requer que as métricas de negócio estejam sendo coletadas com consistência — o que foi construído no capstone desta série.

Referências para Aprofundamento

• AWS DevOps Guru — Documentação
• CloudWatch Anomaly Detection
• Azure Monitor — Dynamic Thresholds
• Datadog Watchdog
• GitHub Copilot — Pesquisa de Produtividade

Exercícios

Exercício 1

No alarme do CloudWatch, a expressão é ANOMALY_DETECTION_BAND(latencia, 2), o operador é GreaterThanUpperThreshold e EvaluationPeriods é 3 com Period de 300. Traduza isso em uma frase: o que exatamente precisa acontecer para o alarme disparar?

Exercício 2

Você ativa o CloudWatch Anomaly Detection num serviço novo, colocado em produção há três dias. Nas primeiras semanas o alarme dispara constantemente por qualquer coisa. Por que — e o que fazer?

Exercício 3

O artigo diz que o Prometheus AlertManager "tem agrupamento por labels, mas não correlação inteligente". Qual é a diferença concreta entre as duas coisas? Descreva um incidente em que o agrupamento por labels não resolve.

Exercício 4

O artigo classifica a remediação automática como imatura, mas reconhece que o Kubernetes já reinicia pods e o HPA já escala sozinho. Não é contradição? O que separa o que o Kubernetes faz do que ainda não se confia à automação?

Exercício 5

O roteiro de três passos termina com "instrumentar as métricas de negócio", e o artigo afirma que elas geram mais valor que as técnicas. Por que detectar anomalia em "pedidos por minuto" vale mais do que em "uso de CPU"?