Skip to main content
O Motor de Decisão é o componente central que determina quando e como a plataforma AIOps deve agir autonomamente. Ele combina confiança calculada, histórico de padrões, enriquecimento de causa raiz e detecção de convergência para tomar decisões seguras em produção.
O Motor de Decisão nunca age às cegas. Cada decisão passa por um pipeline de ajustes de confiança, verificações de circuit breaker e validação de padrões antes de qualquer ação ser executada.

Visão Geral da Arquitetura

Confiança Base (AIInsight)

Todo o processo começa com o campo confidence do AIInsight CR, que é gerado pelo provedor LLM durante a análise de causa raiz. Esse valor representa a certeza da IA sobre o diagnóstico e as ações sugeridas.

Confiança Alta

0.90 - 1.00 — A IA identificou o problema com alta precisão. Cenários bem conhecidos como OOMKilled, CrashLoopBackOff com imagem inválida.

Confiança Média

0.70 - 0.89 — Diagnóstico provável mas com incerteza. Problemas de performance, resource pressure, dependências intermitentes.

Confiança Baixa

0.50 - 0.69 — A IA não tem certeza suficiente. Problemas complexos com múltiplas causas possíveis.

Confiança Muito Baixa

< 0.50 — Cenário desconhecido ou dados insuficientes. Sempre requer intervenção humana.

Fatores de Ajuste de Confiança

A confiança base nunca é usada diretamente. Ela passa por 5 fatores de ajuste que a refinam com base no contexto operacional atual.

1. Taxa de Sucesso Histórica

1

Consulta o Pattern Store

O engine calcula a taxa de sucesso de remediações anteriores para o mesmo tipo de sinal (signalType).
2

Aplica o ajuste

  • Taxa de sucesso alta (>80%): ajuste de +0.10
  • Taxa de sucesso baixa (<40%): ajuste de -0.10
  • Sem histórico: nenhum ajuste (0.00)

2. Pattern Match (Correspondência de Padrão)

Quando o Pattern Store encontra um padrão previamente resolvido que corresponde ao incidente atual, a confiança recebe um boost significativo.
O Pattern Match é o fator mais poderoso. Um incidente idêntico resolvido anteriormente pode elevar a confiança o suficiente para permitir auto-remediação mesmo em cenários que normalmente exigiriam aprovação.

3. Horário do Dia (Time of Day)

Ações automáticas fora do horário comercial carregam risco adicional porque há menos engenheiros disponíveis para intervir caso algo dê errado.

4. Issues Ativas Simultâneas

Quando o cluster está sob pressão com múltiplos incidentes ativos, o motor se torna mais conservador para evitar ações em cadeia que possam agravar a situação.
Com 10 ou mais issues ativas simultâneas, o ajuste cumulativo (-0.14 ou mais) torna praticamente impossível atingir o threshold de auto-remediação, forçando revisão humana — exatamente o comportamento desejado durante um incidente em cascata.

5. Severidade do Incidente

A severidade do Issue CR aplica um modificador fixo que reflete o risco operacional inerente.

Exemplo Prático de Cálculo

Dados do incidente:
  • Confiança base do AIInsight: 0.88
  • Severidade: high
  • Horário: 14:30 (horário comercial)
  • Issues ativas: 2
  • Pattern Store: padrão encontrado (rollback bem-sucedido há 5 dias)
  • Taxa de sucesso histórica: 90%
Cálculo:
Decisão: Confiança 1.00 + severidade high = Requer aprovação (threshold ≥0.80 + high).Mesmo com confiança máxima, incidentes high sempre exigem aprovação humana.
Dados do incidente:
  • Confiança base do AIInsight: 0.92
  • Severidade: low
  • Horário: 02:15 (fora do horário comercial)
  • Issues ativas: 1
  • Pattern Store: padrão encontrado (ajuste de memória bem-sucedido)
  • Taxa de sucesso histórica: 95%
Cálculo:
Decisão: Confiança 1.00 + severidade low = Auto-remediação (threshold ≥0.95 + low).
Dados do incidente:
  • Confiança base do AIInsight: 0.65
  • Severidade: critical
  • Horário: 10:00 (horário comercial)
  • Issues ativas: 8
  • Pattern Store: nenhum padrão correspondente
  • Taxa de sucesso histórica: 30%
Cálculo:
Decisão: Confiança 0.35 + severidade critical = Apenas manual (<0.70 ou critical).

Thresholds de Decisão

A combinação de confiança final e severidade determina o nível de autonomia permitido.
Requisitos: Confiança ≥ 0.95 e severidade lowA plataforma executa a remediação automaticamente sem qualquer intervenção humana. O RemediationPlan é criado e executado imediatamente.

Circuit Breaker

O circuit breaker é um mecanismo de segurança que bloqueia todas as auto-remediações quando detecta falhas consecutivas, prevenindo que a plataforma cause danos em cascata.
1

Monitoramento de Falhas

Cada falha de remediação é registrada com timestamp. O circuit breaker mantém uma janela deslizante de 1 hora.
2

Disparo do Circuit Breaker

Quando 3 ou mais falhas ocorrem dentro da janela de 1 hora, o circuit breaker abre e bloqueia toda auto-remediação no namespace.
3

Estado Aberto

Enquanto aberto, todos os RemediationPlan CRs são criados com requiresApproval: true, independente da confiança calculada.
4

Reset

O circuit breaker fecha automaticamente após o período de cooldown ou quando um operador faz reset manual via annotation.
Quando o circuit breaker está aberto, a annotation platform.chatcli.io/circuit-breaker: open é adicionada ao namespace. Isso é visível via kubectl get ns &lt;namespace&gt; -o yaml para diagnóstico rápido.

Pattern Store

O Pattern Store é o sistema de aprendizado de padrões da plataforma. Ele permite que a AIOps “lembre” de incidentes passados e use essa memória para tomar decisões mais informadas.

Fingerprinting SHA256

Cada padrão é identificado por uma fingerprint única calculada como:
Exemplos de fingerprints:

Armazenamento em ConfigMap

Os padrões são persistidos em um ConfigMap dedicado no namespace do operator:

RecordResolution e RecordFailure

Cálculo do Confidence Boost

O boost de confiança derivado do Pattern Store é calculado diretamente a partir da taxa de sucesso:

Cenário: Incidente Similar Recente

Quando o Pattern Store encontra uma correspondência, o motor adiciona contexto ao AIInsight e ao RemediationPlan:
Essa informação é exibida no Issue CR para que operadores possam ver rapidamente que o problema já foi resolvido antes e como.

Enriquecimento de Causa Raiz (RCA)

Antes de tomar qualquer decisão, o motor enriquece o contexto do incidente com dados adicionais do cluster. Esse enriquecimento alimenta tanto o LLM (para melhor diagnóstico) quanto o motor de decisão (para ajustes mais precisos).

DeploymentChange Detection

O motor verifica se houve uma mudança de deploy recente comparando revisões de ReplicaSets:
Resultado do enriquecimento:

ConfigChange Detection

O motor busca eventos do Kubernetes relacionados a atualizações de ConfigMaps e Secrets:
Lista issues ativas no mesmo namespace que podem estar correlacionadas:

Dependency Status

Verifica a saúde dos Services e Endpoints dos quais o recurso afetado depende:

Time Correlation

O motor calcula a correlação temporal entre mudanças detectadas e o início do incidente:
Correlação temporal forte (< 5 min) eleva automaticamente a causa para o topo da lista de PossibleCauses, pois a probabilidade de relação causal é alta.

PossibleCauses Ranking

Todas as causas possíveis são ranqueadas por probabilidade com base nos dados de enriquecimento:

Detector de Convergência

O Detector de Convergência é projetado para o loop agêntico de remediação. Ele monitora as observações do agente para determinar se a situação está melhorando, estagnada ou piorando.

IsConverged

Verifica se as últimas 3 observações são idênticas, indicando que o sistema atingiu um estado estável (para melhor ou pior).

IsOscillating

Detecta padrões de oscilação A-B-A-B onde o sistema alterna entre dois estados sem progresso real.
Oscilação é um sinal forte de que a ação de remediação está criando o problema que tenta resolver. Quando detectada, o loop agêntico é interrompido imediatamente e o incidente é escalado para intervenção humana.

ShouldStop

Função principal que combina todos os critérios de parada do loop agêntico:

EstimateProgress

Estima o progresso do loop agêntico de 0.0 a 1.0, usado para feedback visual e logging:

Fluxo Completo de Decisão

Métricas do Motor de Decisão

O motor expõe métricas Prometheus para observabilidade:

Próximos Passos

Federação Multi-Cluster

Veja como o motor de decisão opera em ambientes multi-cluster com políticas por tier.

Chaos Engineering

Valide as decisões do motor com experimentos de chaos controlados.

Auditoria e Compliance

Cada decisão gera um AuditEvent imutável para rastreabilidade.

AIOps Platform

Retorne à visão geral completa da plataforma AIOps.