Incident Response e Postmortem: do pager ao aprendizado
- ⬜🎯 SLOs e Error Budgets: a contabilidade da confiabilidade(Observabilidade & SRE)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
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ÇÃO RESPOSTA RESOLUÇÃO APRENDIZADO
─────────────────────────────────────────────────────────────────────
Alerta dispara → Triage: P1/P2/P3? → Mitigação → Postmortem
Usuário reporta → Declarar incidente → Root cause → Action items
Monitoramento → Mobilizar equipe → Fix ou rollback → Review 30d
│ │ │ │
▼ ▼ ▼ ▼
[00:00] [00:05-00:15] [00:30-2:00+] [24-48h depois]
Severidades:
─────────────────────────────────────────────────────────────────────
P1 │ Produção down ou dados corrompidos │ Resposta: 5min │ PD
P2 │ Funcionalidade crítica degradada │ Resposta: 15min │ Slack
P3 │ Funcionalidade não-crítica afetada │ Resposta: 2h │ Ticket
P4 │ Issue sem impacto a usuário │ Resposta: 1 dia │ Backlog
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 |
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
Canal Slack do Incidente — fluxo ideal
─────────────────────────────────────────────────────────
[14:05] @ic: 🚨 Incidente declarado. Checkout com 40% erro rate.
IC: @joao. Tech Lead: @maria. Comms: @ana.
Hipótese inicial: deploy de 13:50 pode ser causa.
[14:07] @maria: Confirmado: payment-service com 429 do Stripe.
Checando se é rate limit ou falha da nossa parte.
[14:09] @pedro: Stripe status page: verde. É nosso rate limiting.
Vendo configuração de retry.
[14:11] @ic: UPDATE: causa provável = config de retry agressiva
no deploy 13:50. Avaliando rollback vs hotfix.
[14:12] @maria: Rollback é mais seguro. Preparo PR agora.
[14:13] @ic: Aprovado. @maria executa rollback. @ana: atualiza
status page para "mitigação em andamento".
[14:18] @maria: Rollback concluído. Error rate: 2%. Observando.
[14:22] @ic: Error rate estável < 1%. Incidente RESOLVIDO.
Impacto total: ~17min de degradação no checkout.
Postmortem em 24h. /incident close
─────────────────────────────────────────────────────────
O que funciona:
✅ IC comanda sem resolver tecnicamente
✅ Updates frequentes e factuais
✅ Decisão explícita (rollback vs fix) com dono claro
✅ Timeline clara para postmortem
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.
❌ Análise ruim (para no erro humano) ✅ Análise correta (vai ao sistema)
───────────────────────────────────────── ──────────────────────────────────
Por quê o sistema falhou? Por quê o sistema falhou?
→ Engenheiro configurou retry errado → Retry sem backoff causou storm
Por quê o engenheiro errou? Por quê o retry não tinha backoff?
→ "Falta de atenção" → Padrão de retry da lib não tem
backoff por default
FIM DA ANÁLISE — CONCLUSÃO ERRADA: Por quê a lib não tem backoff por default?
"Treinar engenheiro para ser mais → Escolhemos a lib sem avaliar esse critério
cuidadoso"
Por quê não avaliamos esse critério?
Resultado: nada muda. Próximo → Não há checklist de avaliação de libs
engenheiro comete o mesmo erro. para integrações externas
Por quê não há checklist?
→ Processo de adoção de libs não tem
guia de rate limiting externo
CONCLUSÃO CORRETA:
"Criar guia + checklist de rate limits
no processo de adoção de libs"
Resultado: sistema é melhorado,
próximo engenheiro é protegido.
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
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: Priorizar no backlog normal — Anti-pattern — features sempre ganham, postmortem AIs acumulam
Alt: Sprint dedicado de confiabilidade (trimestral) — Funciona em times maiores com backlog de confiabilidade acumulado
Alt: Delegar para time de SRE dedicado — Se existe time de SRE separado do time de produto — mas mesmo assim, AIs de código são do time de produto
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 |
# 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/support
Learning 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
P: Como você lidaria com um incidente onde a causa raiz é um bug introduzido por outro time?
R: Durante o incidente: foco em mitigar o impacto (rollback, feature flag, roteamento alternativo) — não em culpa. Após resolver: postmortem blameless conjunto com os dois times. A pergunta é "quais sistemas ou processos falharam em detectar esse bug antes de produção" — não "quem introduziu o bug". Action items podem incluir melhores testes de integração entre times, review cruzado de deploys de serviços com dependências críticas, ou canary automático para serviços com histórico de interdependências.
P: Qual a diferença entre MTTR, MTTD e MTTF?
R: MTTD (Mean Time To Detect): tempo médio entre a falha acontecer e ser detectada — mede qualidade dos alertas. MTTR (Mean Time To Recover): tempo médio entre detecção e resolução — mede eficiência da resposta. MTTF (Mean Time To Failure): tempo médio entre o fim de um incidente e o próximo — mede frequência. Times maduros otimizam MTTD (alertas mais rápidos e precisos) e MTTR (runbooks, automação de rollback) antes de atacar MTTF.
P: Como convencer liderança a investir em confiabilidade vs features quando não há incidente visível?
R: Use dados de error budget: "Nos últimos 3 meses consumimos 78% do error budget de 90 dias. Se o padrão continuar, violaremos o SLA em X semanas — com custo de $Y em créditos de cliente." Error budget transforma "queremos fazer a coisa certa" em "temos dados mostrando risco financeiro concreto". Se não há incidente visível mas o budget está alto, é hora de investir — não esperar o incidente.
- Incidente Commander não resolve — coordena. Separar os papéis é o que transforma caos em resposta estruturada.
- Declare cedo: o custo de declarar um incidente que não era é mínimo. O custo de não declarar um que era é alto.
- Blameless postmortem não é cortesia — é estratégia: blame cria incentivo para esconder erros e garantir reincidência.
- 5 Whys deve terminar no sistema, nunca no "erro humano". Qual proteção sistêmica estava ausente?
- Action items sem owner + prazo + ticket são promessas vazias. 80% dos postmortems falham na execução, não na análise.
- On-call saudável: cada alerta é actionable, tem runbook, e é revisado após cada rotação. Alert fatigue mata a eficácia.
- Observabilidade completa = logs estruturados + métricas RED/USE + traces distribuídos + SLOs com burn rate alerts + incidente response — tudo integrado.
Quiz rápido
4 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito