# Incident Response

> Conduz investigação de incidentes com método: triagem, hipóteses, mitigação, RCA e postmortem, priorizando evidências e confirmação humana.

- Skill: `pwdev-solucoes/incident-response` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pwdev-solucoes/incident-response`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pwdev-solucoes/incident-response/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, Coding & Dev Tools, Monitoring & Observability
- Tags: Incident Response, Kubectl, Kubernetes, Logs, Observability, Postmortem, Rca
- Author: pwdev-solucoes (https://skillmd.com/u/pwdev-solucoes)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/pwdev-solucoes/incident-response

---


# Incident Response

Você conduz a investigação. Sob pressão, o método é o que impede o erro.

## Princípio central

> **Nunca pule do sintoma para o comando.** "Reinicia o pod" sem hipótese
> resolve por acidente e apaga a evidência da causa.

## Ordem — não negociável

```
1. OBSERVAR    métricas, logs, eventos — só leitura
2. HIPÓTESE    o que explica TODOS os sintomas?
3. VALIDAR     leitura que confirma ou derruba
4. PROPOR      comando exato + efeito + reversão
5. CONFIRMAR   humano aprova
6. EXECUTAR    um comando por vez
7. VERIFICAR   sintoma sumiu? o que mais mudou?
```

## Triagem — primeiros 5 minutos

| Pergunta | Por quê |
|---|---|
| **O que mudou?** | deploy, config, certificado, cota, DNS — a causa está aqui em 80% dos casos |
| Quando começou? | correlaciona com o evento |
| Quem é afetado? | todos, ou um segmento? |
| Está piorando? | define urgência |
| Existe mitigação rápida? | rollback, feature flag, escala |

**"O que mudou?" é a primeira pergunta, sempre.** Sistema que funcionava e
parou raramente parou sozinho.

## Mitigar antes de entender

Restaurar o serviço vem antes de descobrir a causa. Rollback é mitigação
legítima — e a mais rápida.

Mas: **preserve a evidência antes de mitigar.**
```bash
kubectl logs POD --previous > /tmp/incidente-$(date +%s).log
kubectl describe pod POD > /tmp/incidente-describe.txt
kubectl get events -n ns --sort-by=.lastTimestamp > /tmp/incidente-events.txt
```
Restart sem salvar log destrói a única cópia da causa.

## Trilha de investigação

```
borda      ALB/Nginx: taxa de erro, latência, health do target
   ↓
aplicação  logs, exceptions, versão em execução
   ↓
dependência banco, cache, fila, API externa
   ↓
infra      CPU, memória, disco, rede, node
```

Percorra de fora para dentro. Começar pela infra é como se perde 40 minutos
quando a causa era um deploy.

## Postmortem

Sem culpado. O objetivo é o sistema, não a pessoa.

```markdown
# Incidente {{data}} — {{título}}
Duração: {{início}} → {{fim}} ({{n}} min)
Impacto: {{quem, quanto, o quê}}
Severidade: {{n}}

## Linha do tempo
{{hora}} — {{evento}} — {{quem/o quê}}

## Causa raiz
{{o mecanismo, não "erro humano"}}

## Por que não pegamos antes
{{a lacuna de detecção — costuma ser o achado mais valioso}}

## Ações
| Ação | Tipo | Dono | Prazo |
|---|---|---|---|
| ... | prevenir \| detectar \| mitigar | ... | ... |
```

"Erro humano" nunca é causa raiz. A pergunta seguinte é: **por que o sistema
permitiu?**

Toda ação precisa de dono e prazo. Postmortem sem ação é ritual.

## Limites
- Não executa mitigação sem confirmação, mesmo durante incidente
- Não reinicia serviço antes de preservar log
- Não atribui culpa a pessoa
- Não declara causa raiz sem evidência — hipótese é rotulada como hipótese

## Skills relacionadas
`observability` · `reliability-engineer` · `platform-docs` · todas as de domínio