Ciclo de Vida do Incidente

​

Visão Geral

​

Estados do Incidente

​

Fluxo da Máquina de Estados

Detected → Analyzing → Remediating → Resolved
                ↓              ↓        ↑
           Escalated   Contained ───────┘ (humano restaura replicas)
           (após max   (ação com
            tentativas) containment=true)
                ↓              ↓
           Re-análise      Failed/RolledBack
           (até 5x)            ↓
                Escalated
                              ↓
                    Auto-resolve se o recurso
                    recuperar (configurável)

​

Fase de Detecção (Detected)

1. Pontuação de sinal — cada tipo de sinal tem um peso (OOMKill=40, ErrorRate=30, PodRestart=25, etc.)
2. Cálculo do risk score — agregado de todas as anomalias correlacionadas
3. Determinação da severidade — Critical (risk > 80), High (> 60), Medium (> 40), Low (demais)
4. Geração do ID do incidente — formato: INC-AAAAMMDD-NNN
5. Máximo de tentativas de remediação configurado para 5 (padrão, configurável 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 rápido)
   • RUNBOOK_REJECTED → ignora todos os candidatos, usa sugestões 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á saudável (após 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. Verificação 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-análise 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 progressão da escalação):
   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: Método 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"}'
   
   Método 2: Web Dashboard Navegue até a página de detalhes do incidente e clique no botão “Resolve”. Insira a descrição da resolução no diálogo. Método 3: Kubernetes Direto (avancado)
   kubectl patch issue INC-20260319-001 -n production --type=merge \
     -p '{"status":{"state":"Resolved","resolution":"Correção 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 correção 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 (configurável via AgenticMaxSteps)
• Max tempo: 10 minutos por plano agentico
• Detecção 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 Confiança do Decision Engine

​

Rollback Engine

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

• Execução da ação falha
• Verificação 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)

​

Seleção 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 descrições
       ↓
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 → resolução rapida sem loop agentico

​

Ciclo de Vida do Runbook

​

Geração de PostMortem

• Timeline — eventos cronológicos da detecção a resolução
• Análise de causa raiz — gerada por IA com score de confiança
• Ações executadas — histórico completo de remediação
• Avaliação de impacto — pods, serviços e SLOs afetados
• Lições aprendidas — recomendações da IA para prevenção
• Correlação com Git — deploys recentes que podem ter causado o problema
• Análise de cascata — incidentes relacionados entre servicos

​

PostMortems com requiresHumanAction

# Issue
kubectl get issue <name> -o jsonpath='{.status.requiresHumanAction}'
# true
kubectl get issue <name> -o jsonpath='{.status.requiredAction}'
# restore the deployment's replicas to the desired count after fixing the root cause...

# PostMortem
kubectl get postmortem pm-<name> -o jsonpath='{.status.requiresHumanAction}'
# true
kubectl get postmortem pm-<name> -o jsonpath='{.status.requiredAction}'
# (mesmo texto, propagado do Issue)

• O PostMortemReconciler se recusa a transitar para Closed enquanto a anotação aiops.chatcli.io/human-action-acknowledged não for true (mesmo se alguém forçar kubectl patch)
• Quando o auto-resolve dispara (humano restaura replicas), o controller limpa os dois fields e adiciona condition RequiresHumanAction: False — o CR nunca mente sobre o estado atual
• A REST API expõe os fields como top-level no IncidentItem (spec.requiresHumanAction, spec.requiredAction) para dashboards renderizarem direto sem precisar fetch do PostMortem matching

# Via API REST
curl -X POST -H "Authorization: Bearer $TOKEN" \
  "$AIOPS_URL/api/v1/postmortems/<pm-name>/ack-human-action?namespace=default" \
  -d '{"acknowledgedBy":"sre-team","note":"rolled back to v1.2.3 and scaled to 3 replicas"}'

# Ou via kubectl
kubectl annotate postmortem <pm-name> -n default \
  aiops.chatcli.io/human-action-acknowledged=true \
  aiops.chatcli.io/human-action-acknowledged-by=sre-team

​

Correlação com Chaos Engineering

• platform.chatcli.io/source=chaos-experiment
• platform.chatcli.io/chaos-experiment=<nome-do-experimento>

​

Integração com SLA

• Tempo de resposta — tempo máximo da detecção até a primeira análise
• Tempo de resolução — tempo máximo da detecção até a resolução
• Horario comercial — opcionalmente pausar o relogio do SLA fora do horario comercial
• Política de escalação — disparada automaticamente na violação do SLA