Ciclo de Vida do Incidente

​

Visao Geral

​

Estados do Incidente

​

Fluxo da Máquina de Estados

Detected → Analyzing → Remediating → Resolved
                ↓              ↓
           Escalated      Failed/RolledBack
           (apos max          ↓
            tentativas)  Re-analise (ate 5x)
                              ↓
                         Escalated
                              ↓
                    Auto-resolve se o recurso
                    recuperar (configuravel)

​

Fase de Deteccao (Detected)

1. Pontuacao de sinal — cada tipo de sinal tem um peso (OOMKill=40, ErrorRate=30, PodRestart=25, etc.)
2. Calculo do risk score — agregado de todas as anomalias correlacionadas
3. Determinacao da severidade — Critical (risk > 80), High (> 60), Medium (> 40), Low (demais)
4. Geracao do ID do incidente — formato: INC-AAAAMMDD-NNN
5. Maximo de tentativas de remediação configurado para 5 (padrão, configuravel via Instance aiops.maxRemediationAttempts)

​

Fase de Análise (Analyzing)

1. Descoberta de runbooks candidatos (em camadas):
   • Camada 1: Todos os runbooks com SignalType + Severity + ResourceKind
   • Camada 2: Fallback por Severity + ResourceKind
   • Multiplos runbooks podem existir por trigger (causas raiz diferentes geram runbooks diferentes)
2. IA válida candidatos: O LLM recebe todos os runbooks candidatos e avalia cada um contra a análise de causa raiz atual:
   • RUNBOOK_APPROVED: <nome> → usa aquele runbook específico (caminho rapido)
   • RUNBOOK_REJECTED → ignora todos os candidatos, usa sugestoes da IA ou modo agentico
   • Nenhum dos dois → usa primeiro candidato como default (compatibilidade)
3. Se não ha candidatos e a IA tem ações sugeridas → gera um novo runbook
4. Se não ha candidatos e nem ações da IA → entra no Modo Agentico (IA passo-a-passo)
5. Transiciona para Remediating

​

Fase de Remediação (Remediating)

1. Snapshot pre-voo capturado para capacidade de rollback
2. Para cada acao no plano:
   • OBSERVE — verifica se o recurso já está saudavel (apos a ação anterior). Se sim, para imediatamente sem executar as ações restantes (early exit)
   • ACT — executa a ação com checkpoint
   • Se a ação falha → rollback automático ao estado pre-voo
3. Verificacao final de saude (polling por até 90 segundos)
4. Em caso de sucesso → Resolved + PostMortem gerado
5. Em caso de falha → rollback automático tentado → re-analise com contexto da falha

Exemplo: plano com 3 ações (AdjustResources + DeletePod + RollbackDeployment)

  Ação 1: AdjustResources → SUCCESS (memory 1Mi → 64Mi)
  Ação 2: OBSERVE → recurso healthy (ReadyReplicas == Desired)
          → EARLY EXIT! Pula DeletePod e RollbackDeployment
          → Evidence: "Resource healthy after 1/3 actions — skipped remaining 2"

​

Mecanismo de Retry

• Tentativa < MaxAttempts (5): O sistema re-analisa com o contexto da falha injetado, potencialmente selecionando um runbook ou estratégia diferente
• Todas as tentativas esgotadas: Transiciona para Escalated

​

Estado Escalated — O Que os Operadores Devem Fazer

1. Dispara a EscalationPolicy correspondente a severidade do incidente
2. Envia notificações para L1 on-call (Slack, PagerDuty, etc.)
3. Se não houver reconhecimento dentro do timeout configurado, escala para L2, depois L3
4. Gera eventos de auditoria para compliance

1. Reconhecer o incidente (para a progressao da escalacao):
   curl -X POST https://operator:8090/api/v1/incidents/INC-20260319-001/acknowledge \
     -H "X-API-Key: $API_KEY" \
     -d '{"acknowledgedBy": "seu-email@empresa.com"}'
   
2. Investigar e corrigir o problema manualmente
3. Resolver o incidente via um dos tres metodos: Metodo 1: REST API (recomendado para automacao/scripts)
   curl -X POST https://operator:8090/api/v1/incidents/INC-20260319-001/resolve \
     -H "X-API-Key: $API_KEY" \
     -d '{"resolution": "Corrigido memory leak no payment-service v2.4.1, hotfix implantado manualmente"}'
   
   Metodo 2: Web Dashboard Navegue até a pagina de detalhes do incidente e clique no botao “Resolve”. Insira a descrição da resolucao no dialogo. Metodo 3: Kubernetes Direto (avancado)
   kubectl patch issue INC-20260319-001 -n production --type=merge \
     -p '{"status":{"state":"Resolved","resolution":"Correcao manual aplicada"}}'
   

​

Auto-Resolve para Issues Escalados

“Auto-resolved: resource recovered while awaiting human intervention”

• Um operador corrige o problema manualmente (kubectl rollout undo, etc.) sem usar a API
• O recurso se auto-corrige (ex: problema de rede transitorio se resolve)
• Um pipeline de CI/CD implanta uma correcao enquanto o incidente ainda está aberto

​

Parâmetros AIOps Configuraveis

apiVersion: platform.chatcli.io/v1alpha1
kind: Instance
metadata:
  name: chatcli-prod
spec:
  provider: OPENAI
  model: gpt-5.4
  aiops:
    maxRemediationAttempts: 5    # padrão: 5, range: 1-10
    resolutionCooldownMinutes: 10 # padrão: 10, range: 0-120
    dedupTTLMinutes: 60           # padrão: 60, range: 5-1440
    enableAutoResolve: true       # padrão: true

​

Estados do Plano de Remediação

​

Modo de Remediação Agentico

1. IA propoe uma acao via AgenticStep RPC
2. Acao e executada e o resultado e observado
3. IA analisa a observacao e propoe a proxima acao
4. Loop continua até resolver ou detectar convergencia

• Max steps: 10 (configuravel via AgenticMaxSteps)
• Max tempo: 10 minutos por plano agentico
• Deteccao de convergencia:
  • Ultimas 3 observações identicas → parada forcada
  • Padrão alternante A→B→A→B → parada forcada
  • 5 ações consecutivas falharam → parada forcada

​

Limiares de Confianca do Decision Engine

​

Rollback Engine

1. Snapshot pre-voo — capturado antes de QUALQUER acao. Restaura o estado completo do recurso.
2. Checkpoints por acao — capturados antes de CADA acao. Permite rollback parcial.

• Execução da ação falha
• Verificacao de saude expira (90 segundos)

• Deployment: replicas, imagens de container, limites de recursos
• StatefulSet: replicas, imagens, recursos, partition
• DaemonSet: imagens, recursos, max unavailable
• Job/CronJob: suspend, deadline, backoff limit, parallelism
• Node: uncordon (restaurar schedulable)

​

Tipos de Ação de Remediação

​

Deployment (18 ações)

​

StatefulSet (9 ações)

​

DaemonSet (7 ações)

​

Job (9 ações)

​

CronJob (10 ações)

​

Sistema de Aprendizado de Runbooks

​

Node Failure — Fluxo de Remediação

Node MemoryPressure detectado
  → Anomaly CR criado (signal: memory_high, severity: critical)
    → Issue correlacionada com pods afetados
      → IA analisa: "Node worker-2 com MemoryPressure, pods do echo-app impactados"
        → Remediação: CordonNode (impede novos pods) + DrainNode (evacua pods existentes)
          → Kubernetes re-schedula pods em nodes saudáveis
            → Verificação: pods healthy em novos nodes → Resolved

​

Como os Runbooks São Nomeados

auto-{sinal}-{severidade}-{tipo}-{hash}

Exemplos:
  auto-oom-kill-critical-deployment-a3f2b1  (causa: tail /dev/zero)
  auto-oom-kill-critical-deployment-c7d4e9  (causa: memory limit muito baixo)
  auto-pod-not-ready-low-deployment-e8b3d2  (causa: imagem invalida)

​

Selecao Multi-Runbook

Novo incidente OOMKill em Deployment
       ↓
3 runbooks candidatos encontrados (causas raiz diferentes)
       ↓
Todos os 3 injetados no contexto da IA com seus steps e descricoes
       ↓
IA analisa a causa raiz atual e responde:
  "RUNBOOK_APPROVED: auto-oom-kill-critical-deployment-c7d4e9"
  (porque este incidente e causado por memory limits baixos, correspondendo ao runbook)
       ↓
Runbook selecionado executado → resolucao rapida sem loop agentico

​

Ciclo de Vida do Runbook

​

Geracao de PostMortem

• Timeline — eventos cronologicos da deteccao a resolucao
• Analise de causa raiz — gerada por IA com score de confianca
• Ações executadas — histórico completo de remediação
• Avaliacao de impacto — pods, servicos e SLOs afetados
• Licoes aprendidas — recomendações da IA para prevencao
• Correlacao com Git — deploys recentes que podem ter causado o problema
• Analise de cascata — incidentes relacionados entre servicos

​

Integração com SLA

• Tempo de resposta — tempo máximo da deteccao até a primeira analise
• Tempo de resolucao — tempo máximo da deteccao até a resolucao
• Horario comercial — opcionalmente pausar o relogio do SLA fora do horario comercial
• Politica de escalacao — disparada automaticamente na violacao do SLA