Modelos de Runbooks de Incidentes

Modelos prontos para produção para runbooks de resposta a incidentes cobrindo detecção, triagem, mitigação, resolução e comunicação.

Quando Usar Esta Habilidade

• Criando procedimentos de resposta a incidentes
• Construindo runbooks específicos de serviço
• Estabelecendo caminhos de escalonamento
• Documentando procedimentos de recuperação
• Respondendo a incidentes ativos
• Integrando engenheiros de plantão

Conceitos Principais

1. Níveis de Severidade de Incidentes

2. Estrutura do Runbook

1. Overview & Impact
2. Detection & Alerts
3. Initial Triage
4. Mitigation Steps
5. Root Cause Investigation
6. Resolution Procedures
7. Verification & Rollback
8. Communication Templates
9. Escalation Matrix

Padrões Detalhados e Exemplos Trabalhados

A documentação detalhada de padrões está em references/details.md. Leia esse arquivo quando o nível de navegação acima for insuficiente.

Melhores Práticas

Fazer

• Mantenha os runbooks atualizados - Revise após cada incidente
• Teste os runbooks regularmente - Game days, engenharia do caos
• Inclua passos de rollback - Sempre tenha uma saída de emergência
• Documente suposições - O que deve ser verdade para os passos funcionarem
• Link para dashboards - Acesso rápido sob estresse

Não Fazer

• Não assuma conhecimento - Escreva para o cérebro das 3 da manhã
• Não pule a verificação - Confirme se cada passo funcionou
• Não se esqueça da comunicação - Mantenha as partes interessadas informadas
• Não trabalhe sozinho - Escalone cedo
• Não pule os postmortems - Aprenda com cada incidente

Solução de Problemas

Passos do runbook funcionam em staging, mas falham durante um incidente real

Os passos frequentemente assumem pré-condições que são verdadeiras em um ambiente saudável, mas não durante uma interrupção. Para cada comando em seu runbook, adicione uma verificação de pré-requisito e uma nota de "o que fazer se este comando falhar":

# Step: Check pod status
kubectl get pods -n payments

# Prerequisites: kubectl configured, kubeconfig points to correct cluster
# If this fails: run `aws eks update-kubeconfig --name prod-cluster --region us-east-1`
# Expected output: pods in Running state

Engenheiro de plantão entra em pânico e pula passos fora de ordem

Adicione uma lista numerada no topo do runbook que espelhe os números das seções, para que os respondedores possam acompanhar o progresso sob estresse sem ler o documento completo:

## Quick Checklist
- [ ] 1. Declare incident severity and open war room
- [ ] 2. Check service health (Section 4.1)
- [ ] 3. Check recent deployments (Section 4.1)
- [ ] 4. Roll back if deploy is suspect (Section 4.1)
- [ ] 5. Post initial notification to #payments-incidents
- [ ] 6. Escalate if > 15 min unresolved

Runbook está desatualizado — comandos referenciam nomes de cluster ou endpoints antigos

Runbooks se deterioram porque são atualizados manualmente. Inclua uma data de "Última Verificação" e um proprietário no topo, e adicione uma verificação de CI que valide se todos os endpoints curl e nomes de contexto kubectl ainda são válidos:

## Runbook Metadata
| Field | Value |
|---|---|
| Last verified | 2024-11-15 |
| Owner | @platform-team |
| Review cadence | After every SEV1/SEV2 |

Comunicação com partes interessadas é atrasada enquanto engenheiros estão focados

Atribua uma função dedicada de comunicador de incidentes (separada do comandante do incidente) cujo único trabalho é postar atualizações de status. Adicione uma agenda permanente no modelo de comunicação:

Update every 15 minutes (even if no new information):
- Current status (Investigating / Mitigating / Monitoring)
- Impact (what is broken, who is affected, % of traffic)
- What we are doing right now
- Next update in: 15 minutes

Comandos do runbook de banco de dados causam tempo de inatividade adicional quando executados incorretamente

Adicione avisos explícitos antes de comandos SQL destrutivos e exija uma verificação de saída de "dry-run" antes de executar:

-- AVISO: Isso encerra conexões ativas. Verifique a contagem primeiro.
-- DRY RUN (verifique a contagem antes de encerrar):
SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND query_start < now() - interval '10 minutes';


…