engenharia·trail11·beginner
Incident Response: comando, comunicação e postmortem blameless
⏱ 16 min·⭐ 80 XP
Incidentes são inevitáveis. Todo sistema suficientemente complexo vai falhar — a questão não é se, mas quando. A diferença entre times maduros e imaturos não está em ter menos incidentes: está em como respondem durante a crise e o quanto aprendem depois.
Incident response mal estruturado transforma problemas de 15 minutos em crises de 4 horas. Postmortems que buscam culpados criam cultura de medo que garante que os mesmos incidentes se repitam. Neste módulo você vai aprender o processo completo — do pager à cultura de aprendizado.
Ciclo de vida de um incidente
DetecçãoAlerta · usuário reporta · monitoramento · T+00:00
RespostaTriage P1–P4 · declarar incidente · mobilizar equipe · T+05–15min
ResoluçãoMitigação · root cause · fix ou rollback · T+30min–2h
AprendizadoPostmortem · action items · review 30d · T+24–48h
| Severidade | Impacto | Tempo de resposta | Canal |
|---|---|---|---|
| P1 | Produção down ou dados corrompidos | 5 min | PagerDuty |
| P2 | Funcionalidade crítica degradada | 15 min | Slack |
| P3 | Funcionalidade não-crítica afetada | 2 h | Ticket |
| P4 | Issue sem impacto a usuário | 1 dia | Backlog |
SeveridadeP1
ImpactoProdução down ou dados corrompidos
Tempo de resposta5 min
CanalPagerDuty
SeveridadeP2
ImpactoFuncionalidade crítica degradada
Tempo de resposta15 min
CanalSlack
SeveridadeP3
ImpactoFuncionalidade não-crítica afetada
Tempo de resposta2 h
CanalTicket
SeveridadeP4
ImpactoIssue sem impacto a usuário
Tempo de resposta1 dia
CanalBacklog
Roles em incidentes P1/P2
Em incidentes grandes, papéis claros eliminam confusão e duplicação de esforço:
| Role | Responsabilidade | Não faz |
|---|---|---|
| Incident Commander (IC) | Coordena resposta, delega, mantém timeline, toma decisões de escalonamento | Debug técnico, escrever código, rollback direto |
| Tech Lead | Diagnóstico técnico, coordena engenheiros de domínio, propõe e executa mitigação | Comunicação externa, tomar decisões de negócio |
| Communications Lead | Atualiza página de status, notifica clientes VIP, gerencia expectativa externa | Debug técnico, tomar decisões de prioridade |
| Scribe | Documenta timeline em tempo real no canal de incidente, registra decisões | Debug, comunicação externa |
| Subject Matter Experts | Diagnosticam área específica (DB, infra, serviço X) quando chamados | Ficar no canal se não forem necessários |
RoleIncident Commander (IC)
ResponsabilidadeCoordena resposta, delega, mantém timeline, toma decisões de escalonamento
Não fazDebug técnico, escrever código, rollback direto
RoleTech Lead
ResponsabilidadeDiagnóstico técnico, coordena engenheiros de domínio, propõe e executa mitigação
Não fazComunicação externa, tomar decisões de negócio
RoleCommunications Lead
ResponsabilidadeAtualiza página de status, notifica clientes VIP, gerencia expectativa externa
Não fazDebug técnico, tomar decisões de prioridade
RoleScribe
ResponsabilidadeDocumenta timeline em tempo real no canal de incidente, registra decisões
Não fazDebug, comunicação externa
RoleSubject Matter Experts
ResponsabilidadeDiagnosticam área específica (DB, infra, serviço X) quando chamados
Não fazFicar no canal se não forem necessários
⚠️
O erro mais comum: IC tenta resolver tecnicamente E coordenar ao mesmo tempo. Resultado: nem coordena bem nem resolve bem. IC que digita no terminal durante um P1 é sinal de que o time não tem IC real — tem um engenheiro sobrecarregado. Em incidentes P1, o IC nunca deve abrir um terminal.
Playbook de resposta: os primeiros 15 minutos
Os primeiros minutos determinam a qualidade da resposta. Um playbook impede que o stress degrade a tomada de decisão:
# Playbook P1 — Primeiros 15 minutos
## T+0: Alerta recebido
- [ ] Confirmar que o alerta é real (não falso positivo)
- [ ] Acessar dashboard: https://grafana.internal/d/overview
- [ ] Se impacto confirmado → DECLARE INCIDENTE
## T+1: Declarar incidente
- [ ] Criar canal Slack: #inc-YYYY-MM-DD-brief-description
- [ ] Postar template:
```
[INCIDENTE] DECLARADO: [descrição breve]
Severidade: P1/P2/P3
IC: @seu_nome
Tech Lead: @tbd
Impacto: [o que está quebrado, quem é afetado]
Início detectado: HH:MM UTC
Status page: INVESTIGANDO
```
- [ ] Atualizar https://status.empresa.com → "Investigando"
## T+2: Mobilizar
- [ ] Notificar on-call do serviço afetado via PagerDuty
- [ ] Para P1: notificar gerente de plantão
- [ ] Assignar Communications Lead
## T+5: Triage inicial
- [ ] Qual serviço/componente está afetado?
- [ ] Houve deploy recente (último 1h)? → candidato a rollback
- [ ] Qual o blast radius? (% de usuários, região, feature)
- [ ] Temos runbook para esse padrão?
## T+10: Hipótese inicial
- [ ] Tech Lead propõe hipótese mais provável
- [ ] Validar hipótese com dados (logs, traces, métricas)
- [ ] Não implementar fix sem dados — bias de confirmação mata
## T+15: Primeiro update externo
- [ ] Communications Lead posta primeiro update público:
"Estamos investigando problemas com [serviço]. Nossa equipe está
trabalhando na resolução. Próximo update em 30 minutos."
- [ ] Frequência mínima de updates: 30min (P1), 1h (P2)
## Regras gerais
- NUNCA silenciar alerta sem investigar
- NUNCA fazer múltiplas mudanças ao mesmo tempo
- Se rollback está disponível e deploy recente: rollback primeiro, investigue depois
- Se incerto entre rollback e fix: rollback é mais seguroDurante o incidente: disciplina de comunicação
14:05 — IC declara incidente
▼
14:07 — Maria confirma
▼
14:09 — Pedro analisa
▼
14:11 — IC atualiza
▼
14:13 — Decisão: rollback
▼
14:22 — Incidente RESOLVIDO
💡
Status page é obrigatório em P1/P2: Clientes que sabem que você está trabalhando no problema são mais pacientes. Status page desatualizada (ou inexistente) gera mais tickets de suporte do que o próprio incidente. Atualize a cada 30 minutos mesmo que não haja novidades: "Continuamos investigando. Próximo update em 30 minutos."
Blameless postmortem: estrutura completa
O postmortem não é punição — é o investimento mais rentável que um time de engenharia pode fazer. Cada incidente bem analisado reduz a probabilidade dos próximos.
# Postmortem — Checkout Degradado — 2024-01-15
**Data do incidente:** 2024-01-15 14:05–14:22 UTC (17 minutos)
**Severidade:** P1
**Owner do postmortem:** Maria (Tech Lead)
**Status:** FECHADO — Action items no Linear projeto SRE
---
## Resumo executivo
Às 14:05 UTC, o checkout começou a apresentar 40% de taxa de erro
devido a rate limiting excessivo na integração com Stripe. Um deploy
de 13:50 introduziu configuração de retry agressiva (5 retries sem
backoff) que multiplicou o volume de chamadas à API do Stripe em 4×,
atingindo os limites de rate da conta. Rollback às 14:13 resolveu
o problema. Impacto: ~17 minutos de degradação, estimativa de ~230
checkouts não completados.
---
## Timeline
| Hora UTC | Evento |
|----------|--------|
| 13:50 | Deploy v2.1.4 do payment-service em produção |
| 14:05 | Alerta PagerDuty: error rate > 10% no checkout |
| 14:06 | João (IC) declara incidente P1, cria canal Slack |
| 14:07 | Maria identifica 429s do Stripe nos logs |
| 14:09 | Pedro confirma Stripe status page verde — problema é nosso |
| 14:11 | Hipótese confirmada: retry agressivo no código do deploy |
| 14:13 | Aprovação de rollback. Rollback iniciado. |
| 14:18 | Error rate < 2%. Rollback confirmado |
| 14:22 | Incidente fechado. Error rate < 0.5% |
---
## Root cause analysis — 5 Whys
**Sintoma:** 40% de requisições de checkout falhando com timeout
**Por quê 1:** payment-service recebia 429 (Too Many Requests) do Stripe
**Por quê 2:** Volume de chamadas à API do Stripe era 4× o normal
**Por quê 3:** Nova configuração de retry fazia 5 tentativas imediatas
(sem backoff) em cada falha transitória de rede
**Por quê 4:** O código foi alterado sem revisão da documentação de
rate limits do Stripe (100 req/s por conta)
**Por quê 5:** Não existia teste de integração que validasse o volume
total de chamadas a APIs externas sob carga; e o processo de
revisão de PR não inclui checklist de rate limits de terceiros
**Root cause:** Ausência de testes de volume de chamadas a APIs
externas e de checklist de rate limits no processo de review.
---
## O que foi bem
- Alerta detectou o problema em < 1 minuto após o deploy
- Rollback foi executado em < 5 minutos da decisão
- Comunicação no canal do incidente foi clara e chronológica
- Status page atualizada em < 10 minutos
## O que pode melhorar
- Review de PR não tinha checklist para integrações externas
- Não havia teste de carga para validar volume de chamadas ao Stripe
- Configuração de retry não tinha documentação de intenção
- Alerta poderia ter disparado em staging (temos Stripe sandbox)
---
## Action Items
| ID | Ação | Owner | Prazo | Ticket |
|----|------|-------|-------|--------|
| AI-1 | Adicionar exponential backoff com jitter no retry do Stripe | Carlos | 2024-01-22 | SRE-234 |
| AI-2 | Implementar teste de volume de chamadas no CI (k6 + mock) | Maria | 2024-01-29 | SRE-235 |
| AI-3 | Adicionar checklist "rate limits de terceiros" no PR template | João | 2024-01-19 | SRE-236 |
| AI-4 | Configurar alerta em staging quando chamadas Stripe > 80 req/s | Pedro | 2024-01-26 | SRE-237 |
| AI-5 | Documentar configuração de retry em ADR-023 | Carlos | 2024-01-22 | SRE-238 |
---
## Lições aprendidas
Integrações com rate limits externos precisam de testes de volume
automatizados no CI e checklist explícito no processo de review.
Retry sem backoff é um padrão perigoso em qualquer integração
com sistema externo — considerar linter de código para detectar.Técnica dos 5 Whys: como aplicar sem cair na armadilha
Os 5 Whys é poderoso mas tem uma armadilha comum: parar no "erro humano" como causa raiz.
⚠️
Regra do blameless postmortem: Se a análise termina em "pessoa X deveria ter feito Y diferente", você não chegou na causa raiz. Pergunte: "Qual sistema, processo ou ferramenta teria protegido qualquer engenheiro de cometer esse erro?"
Acompanhamento de action items: onde postmortems falham
Análise impecável, zero execução — é o padrão mais comum. Action items de postmortem competem com features no backlog e frequentemente perdem.
📋 Time tem 8 postmortems dos últimos 3 meses com 40+ action items, apenas 5 foram concluídos
✓ Postmortem action items em sprints dedicados + SLO de resolução de AIs
Action items de postmortem não competem bem com features por atenção. A solução é reservar capacidade fixa (20% do sprint) para trabalho de confiabilidade + SLO interno: AIs de P1 concluídos em 30 dias, P2 em 60 dias. Itens não concluídos no prazo escalam automaticamente para o manager.
Alt: —
Alt: —
Alt: —
On-call saudável: evitar burnout e alertas de ruído
| Problema | Sintoma | Solução |
|---|---|---|
| Alert fatigue | On-call silencia alertas sem investigar | Cada alerta deve ser actionable. Revisar e fechar alertas ruidosos após cada semana de on-call |
| Pager de madrugada frequente | SRE exausta, rotatividade alta | SLO para % de alertas fora do horário comercial; auto-healing para causas conhecidas |
| Sem runbook | Cada incidente reinventa a solução | Runbook obrigatório para cada alerta. Link no próprio alerta |
| Escalação tarde demais | Incidente se prolonga por horas sem ajuda | IC deve escalar após 30min sem progresso — não é fraqueza, é protocolo |
| Rotação muito curta | Contexto insuficiente para diagnosticar | Rotações de 1 semana mínimo. Handoff estruturado (escrito) entre turnos |
ProblemaAlert fatigue
SintomaOn-call silencia alertas sem investigar
SoluçãoCada alerta deve ser actionable. Revisar e fechar alertas ruidosos após cada semana de on-call
ProblemaPager de madrugada frequente
SintomaSRE exausta, rotatividade alta
SoluçãoSLO para % de alertas fora do horário comercial; auto-healing para causas conhecidas
ProblemaSem runbook
SintomaCada incidente reinventa a solução
SoluçãoRunbook obrigatório para cada alerta. Link no próprio alerta
ProblemaEscalação tarde demais
SintomaIncidente se prolonga por horas sem ajuda
SoluçãoIC deve escalar após 30min sem progresso — não é fraqueza, é protocolo
ProblemaRotação muito curta
SintomaContexto insuficiente para diagnosticar
SoluçãoRotações de 1 semana mínimo. Handoff estruturado (escrito) entre turnos
# Template de handoff de on-call
## Handoff On-Call — 2024-01-15 → 2024-01-22
**Saindo:** @maria **Assumindo:** @pedro
### Incidentes da semana
- [RESOLVIDO] Checkout degradado 01/15 — rollback em produção, postmortem em andamento
- [EM MONITORAMENTO] Latência elevada no relatório de vendas (P3) — investigando query lenta
### Alertas ruidosos (revisar)
- "DiskUsage > 80% em worker-03": falso positivo — disco era de log rotation, já corrigido
→ Ação: atualizar threshold para 90% ou excluir o volume de log
### Runbooks atualizados esta semana
- Adicionado: payment-service-rate-limit.md
- Atualizado: database-connection-pool.md (novo threshold)
### O que ficar de olho
- Deploy planejado para quarta (16:00 BRT) — checkout v2.1.5 com o fix do retry
- Capacidade de DB: atual 73%, projeção de 85% até sexta com volume de vendas
### Contatos de plantão
- Stripe suporte enterprise: +1-xxx (incidente P1 de pagamento)
- AWS Enterprise Support: console.aws.amazon.com/supportLearning review: fechando o ciclo
Além do postmortem imediato (24-48h), times maduros fazem uma revisão de aprendizados 30 dias depois para verificar se os action items foram executados e se os padrões mudaram.
# Learning Review — Fevereiro 2024
## Action Items de Postmortems (Jan 2024)
| AI | Status | Resultado |
|----|--------|-----------|
| AI-1: Backoff no retry Stripe | ✅ Concluído | Sem novos incidents de rate limit |
| AI-2: Teste de volume no CI | ✅ Concluído | Capturou 2 bugs em PR antes do merge |
| AI-3: Checklist de rate limits | ✅ Concluído | Em uso desde 01/20 |
| AI-4: Alerta em staging | 🟡 Em progresso | ETA: 02/15 |
| AI-5: ADR de retry | ✅ Concluído | ADR-023 publicado |
## Métricas do mês
- Incidentes P1: 1 (meta: < 2) ✅
- MTTR médio: 23 min (meta: < 30 min) ✅
- Alertas fora do horário: 4 (meta: < 5) ✅
- Action items concluídos no prazo: 80% (meta: > 70%) ✅
## Tendências
- Nenhum reincidente de rate limiting (AI-1 funcionou)
- Latência de DB ainda preocupante — iniciar investigação de índices
## Próximo foco
- Automatizar runbook de connection pool (toil recorrente)
- Revisar alertas de DiskUsage (3× falso positivo no mês)Q&A — perguntas típicas de entrevista SRE
✅
Take-aways — encerrando a trilha de Observabilidade & SRE:
Discussão
Carregando…