Ir para o conteúdo

Health Monitor Flow
Tipo Resiliência proativa
Trigger Sinal de degradação, revisão preventiva agendada, pós-deploy de P1/P2 — /health-check <sistema>
Agentes health-monitor-agent → (condicional) bug-investigator ou critical-incident-flow
Checkpoints humanos 0, 1 ou 2 — conforme a severidade detectada

Pré-requisito: instalação concluída — ver 00 — Instalação e Setup.

1. O que é e quando usar

Workflow de detecção precoce: o humano fornece sinais de saúde (logs, métricas, alertas, outputs) e o agente classifica o sistema, roteando automaticamente conforme a severidade.

Use quando: - Há sinal de degradação a investigar. - Pós-deploy de qualquer ticket (smoke check). - Revisão preventiva agendada de um sistema.

O agente não acessa produção — ele analisa os sinais que o humano cola.

2. Visão geral do fluxo

Sinais de saúde fornecidos pelo humano (logs · métricas · alertas · outputs)
          │
          ▼
   /health-check <sistema>
          │
          ▼
  health-monitor-agent
  ├── Lê baseline (metrics-feed.jsonl — últimos 10 tickets)
  ├── Lê thresholds (risk-map.md ou padrões)
  ├── Analisa e classifica cada sinal
  ├── Cruza com known-issues
  └── Classificação final = pior nível individual
          │
          ▼
    ┌─────┬────────┬──────────┬──────────────┐
   🟢     🟡        🟠           🔴
 NORMAL  MÉDIO     ALTO        CRÍTICO
   │      │          │            │
 Registra Monitora  ⚡ CP1 →    ⚡ CP2 →
 e encerra  24h    /analyze-bug  critical-
                    como P2     incident-flow

3. Passo a passo

Passo 1 — /health-check <sistema> — health-monitor-agent

  1. Identifica o sistema-alvo via $ARGUMENTS.
  2. Calcula o baseline histórico dos últimos 10 tickets do sistema (metrics-feed.jsonl).
  3. Lê os thresholds configurados no risk-map.md (ou usa padrões).
  4. Analisa cada sinal recebido e classifica individualmente.
  5. Cruza com known-issues e risk-map.
  6. Determina a classificação final (pior nível individual). Output: .ns-flow/monitoring/health-<sistema>-<DATA>.md

Ramos por classificação

Cor Nível Ação
🟢 NORMAL Registra verificação bem-sucedida. Sem ação adicional.
🟡 MÉDIO Monitoramento continuado. Propõe ticket se o padrão persistir em 2+ verificações. Recomenda nova verificação em 24h. Não aciona bug automaticamente.
🟠 ALTO Para. Checkpoint 1 antes de escalar.
🔴 CRÍTICO Para. Checkpoint 2 antes de escalar.

Passo 2 — 🟠 ⚡ Checkpoint 1 (decisão de escalada)

O responsável técnico confirma se a degradação é real ou falso positivo e autoriza/rejeita abrir um ticket no provider. Se aprovado: abra um ticket P2 e rode /analyze-bug <ticket-id>. Se FP: registre a decisão e monitore.

Passo 3 — 🔴 ⚡ Checkpoint 2 (autoriza critical-incident-flow)

O Tech Lead confirma a classificação como incidente crítico e autoriza o critical-incident-flow. Se rejeitado: reclassifica como 🟠 ALTO. Ao acionar o critical-incident-flow, fornece o Health Report como contexto inicial (sistema, sinais, KI correspondente, baseline) — o bug-investigator usa isso como hipótese inicial (H1), acelerando a contenção.

4. Checkpoints humanos

# Quando Quem decide Verifica
— 🟢/🟡 (automático) Registra; sem parada
1 🟠 ALTO Responsável técnico Degradação real ou FP? Autoriza abrir bug P2?
2 🔴 CRÍTICO Tech Lead Confirma incidente crítico? Autoriza critical-incident-flow?

5. Pastas e arquivos

Etapa Arquivo
Entrada sinais colados pelo humano + .speckit/incidents/metrics-feed.jsonl + risk-map.md
Health Report .ns-flow/monitoring/health-<sistema>-<DATA>.md
Escalada 🟠 aciona Bug Flow (P2)
Escalada 🔴 aciona critical-incident-flow

6. Cadência recomendada

Contexto Frequência
Pós-deploy de qualquer ticket Imediatamente (smoke check)
Sistemas com P1 históricos Semanal
Sistemas com risk-map ALTO Quinzenal
Outros sistemas estáveis Mensal ou sob demanda

Thresholds customizados por sistema

Adicione ao .speckit/architecture/risk-map.md: 

## Thresholds de Saúde
### {SISTEMA}
- taxa_erro_critico: 3%      # padrão: 5%
- taxa_erro_alto: 1%         # padrão: 2%
- latencia_p95_fator: 2.5    # padrão: 3×
- restart_processo: CRÍTICO  # padrão: CRÍTICO

7. Aplicação pelo time (papéis)

Papel Responsabilidade
On-call / Dev Roda /health-check no pós-deploy e ao notar sinais; cola logs/métricas
Responsável técnico Decide escalada em 🟠 ALTO (CP1)
Tech Lead Autoriza critical-incident-flow em 🔴 CRÍTICO (CP2)

É o workflow de entrada da resiliência: roda barato e frequente, e só escala (com aprovação humana) quando os sinais justificam.

Referências

Voltar ao topo