Pular para conteúdo

RFC-011: Incident Response Process e SLAs

Campo Valor
Status Draft
Author Time de Tecnologia
Created 2026-02-05
Updated 2026-02-05
Reunião A ser agendada
Deciders Todo o time técnico

Status

🟡 Draft - RFC em elaboração, aguardando apresentação

Contexto e Problema

Processo de incident response documentado em docs/security/incident-response.md, mas falta:

  • SLAs de resposta por severidade
  • On-call rotation formal e handoff process
  • Postmortem template e cadence obrigatória
  • Escalation matrix clara
  • War room procedures para P0

Por que resolver isso agora?

  • Incidentes não têm SLA claro
  • Resposta inconsistente por severidade
  • On-call informal e ad-hoc
  • Postmortems não são sempre feitos
  • Falta clareza de quem escalar quando

Impacto de não resolver

  • SLAs não cumpridos
  • Clientes impactados por mais tempo
  • Burnout de on-call (24/7 sem rotação formal)
  • Aprendizados de incidentes perdidos
  • Repetição de mesmos incidentes

Documentação relacionada: - docs/security/incident-response.md - Processo atual - docs/observability/alerting.md - Severidade de alertas (P0-P3) - docs/runbooks/common-issues.md - Issues comuns - docs/observability/troubleshooting.md - Guias

Proposta de Solução

Incident response com SLAs formais, on-call rotation, e postmortems obrigatórios.

Níveis de Severidade e SLAs

P0 - Crítico: - Definição: Sistema completamente down, data loss, security breach - Impacto: Todos os usuários afetados, negócio parado - Response Time: < 15 minutos - Resolution Time: < 4 horas (best effort) - Comunicação: A cada 30 minutos - Notificação: PagerDuty/phone call + Slack #incidents + Email - On-call: Response imediato - Postmortem: Obrigatório (dentro de 48h)

Exemplos P0: - Site/API completamente down - Database corrompida/perdida - Security breach (dados vazados) - Payment processing down

P1 - Alto: - Definição: Feature crítica não funciona, performance muito degradada - Impacto: Maioria dos usuários afetados - Response Time: < 1 hora - Resolution Time: < 24 horas - Comunicação: A cada 2 horas - Notificação: Slack #incidents + Email - On-call: Response dentro de 1h - Postmortem: Obrigatório

Exemplos P1: - Login quebrado - Checkout não funciona - API latency > 5s - Alarmes críticos disparando

P2 - Médio: - Definição: Feature não-crítica com problema, performance degradada - Impacto: Alguns usuários afetados - Response Time: < 4 horas - Resolution Time: < 3 dias - Comunicação: Diária - Notificação: Slack #tech - Postmortem: Opcional (se aprendizados relevantes)

Exemplos P2: - Feature secundária quebrada - Emails atrasados - Dashboard com dados incorretos

P3 - Baixo: - Definição: Problema cosmético, performance sub-ótima - Impacto: Poucos usuários afetados - Response Time: Próximo dia útil - Resolution Time: < 2 semanas - Notificação: Ticket no sistema - Postmortem: Não necessário

Exemplos P3: - Typo em UI - Logs com warnings - Performance ligeiramente degradada

On-Call Rotation

Schedule: - Rotação: Semanal (Segunda 9h a Segunda 9h) - Horário: 24/7 - Backup on-call: Sempre disponível - Handoff: Segunda-feira 9h (reunião 15min)

Responsabilidades do on-call: - Responder a alertas conforme SLA - Investigar e resolver (ou escalar) - Documentar ações no incident log - Criar postmortem para P0/P1 - Manter #incidents atualizado - Handoff detalhado no fim da semana

Handoff checklist: 

## On-call Handoff - [Data]

### Incidents Esta Semana
- P0: 0
- P1: 1 (login issue, resolvido)
- P2: 2 (em andamento)

### Ongoing Issues
- [ ] P2-123: Dashboard latency - investigando
- [ ] P2-124: Email queue backup - monitorando

### Upcoming
- Deploy agendado: Quarta 14h
- Maintenance window: Quinta 22h-23h

### Notes
- RDS teve spike de CPU na Terça (resolvido, causa identificada)
- Novo alarme configurado para X

### Questions?
[Qualquer dúvida para próximo on-call]

Compensação: - 1 dia extra de folga por semana on-call - Ou compensação financeira (a definir)

War Room (P0 Incidents)

Quando ativar: - P0 incident declarado - Múltiplos P1 simultâneos - Incident prolongado (> 2h)

Processo: 1. Declare war room no Slack (#war-room-[incident-id]) 2. Roles atribuídos: - Incident Commander: Coordena resposta, toma decisões - Tech Lead: Investiga causa raiz, implementa fix - Communications: Atualiza stakeholders - Scribe: Documenta timeline, ações, decisões 3. Status updates: A cada 15-30 min (P0) 4. All hands on deck: Time principal disponível 5. Parar tudo: Outros trabalhos pausados 6. Resolve: Aplicar fix, verificar 7. Close war room: Quando resolvido e estável 8. Postmortem: Agendar para próximos 1-2 dias

Escalation Matrix

Level 1: On-call engineer - Primeiro respondente - 15 min para acknowledging (P0) - Investiga e tenta resolver

Level 2: Tech Lead / Senior Dev - Escalation se on-call não resolve em: - P0: 30 min - P1: 2 horas - Toma ownership, coordena resposta

Level 3: CTO / Engineering Manager - Escalation se Level 2 não resolve em: - P0: 1 hora - P1: 4 horas - Decisões de negócio, comunicação externa

Level 4: CEO - Apenas para crises severas - Security breach - Data loss major - Legal implications

Postmortem Process

Obrigatório para: - P0 (sempre) - P1 (sempre) - P2 se aprendizados relevantes - Qualquer incident com customer impact > 100 users

Template:

# Postmortem: [Title]

**Date**: YYYY-MM-DD
**Severity**: P0 / P1 / P2
**Duration**: Xh Ym
**Impact**: X users affected, Y requests failed

## Summary
[2-3 sentences describing the incident]

## Timeline (UTC)
- 14:00 - Alert triggered: High error rate
- 14:05 - On-call acknowledged
- 14:15 - Root cause identified: Database connection pool exhausted
- 14:30 - Mitigation applied: Increased pool size
- 14:45 - Service recovered
- 15:00 - Incident closed

## Root Cause
[Detailed explanation of what caused the incident]

## Impact
- Users affected: ~1,000
- Duration: 45 minutes
- Failed requests: ~5,000
- Revenue impact: ~$500 (estimated)

## Detection
- How was it detected? CloudWatch alarm
- Could it be detected earlier? Yes (see Action Items)

## Response
- What went well?
  - Fast response time (5 min)
  - Clear communication
- What could be improved?
  - Took 15 min to identify root cause
  - Mitigation was manual

## Resolution
[How was it fixed?]

## Action Items
- [ ] Add monitoring for connection pool exhaustion (Owner: @alice, Due: Week)
- [ ] Implement auto-scaling for connection pool (Owner: @bob, Due: 2 weeks)
- [ ] Update runbook with this scenario (Owner: @charlie, Due: 3 days)

## Lessons Learned
1. Connection pool limits were too low for peak traffic
2. Alarm threshold was set too high
3. Runbook was outdated

## Prevention
[How do we prevent this from happening again?]

Review: - Postmortem reviewed em reunião com time - Action items tracked até completion - Blameless culture (focus em sistemas, não pessoas)

Communication

Internal (Slack #incidents):

🚨 **P0 INCIDENT** - API Down
Started: 14:00 UTC
Status: Investigating
Incident Commander: @alice
War Room: #war-room-20260205-001

Update 14:15: Root cause identified, applying fix
Update 14:30: Fix deployed, monitoring
Update 14:45: Resolved ✅

Postmortem: [link]

External (Status Page):

🔴 Major Outage - API Unavailable
We are investigating an issue affecting API availability.
All services are currently unavailable.

Updated 10 minutes ago

--

🟡 Monitoring - Issue Resolved
The issue has been resolved and services are operational.
We are monitoring for stability.

Updated 5 minutes ago

--

🟢 Operational - All Systems Normal
All systems are fully operational.

Updated 1 minute ago

Alternativas Consideradas

Opção 1: PagerDuty para on-call

Prós: - Ferramenta profissional - Escalation automático - Integrado com tudo

Contras: - Custo ($25/user/mês) - Complexidade adicional

Por que não escolhemos: Slack + CloudWatch + scripts é suficiente para começar. Podemos adicionar PagerDuty depois.

Opção 2: On-call 24/7 sem rotação

Prós: - Sem overhead de handoffs - Pessoa conhece sistema bem

Contras: - Burnout garantido - Não escala - Single point of failure

Por que não escolhemos: Insustentável e arriscado.

Análise de Impacto

Impacto Técnico

  • On-call rotation formal
  • Postmortems obrigatórios
  • War room procedures
  • Escalation automática

Impacto em Negócio

  • ✅ MTTR reduzido
  • ✅ SLAs claros e cumpridos
  • ✅ Aprendizados capturados
  • ✅ Time menos sobrecarregado
  • ⚠️ Overhead de postmortems (~2h/incident)

Riscos

Risco: On-call rotation com time pequeno é difícil

Mitigação: Backup on-call, compensação adequada, tech lead como fallback.

Plano de Implementação

Fase 1: SLAs (Semana 1)

  • Formalizar SLAs por severidade
  • Documentar escalation matrix
  • Comunicar ao time

Fase 2: On-call (Semana 2)

  • Setup rotation schedule
  • Define compensation
  • Primeiro handoff

Fase 3: Postmortems (Semana 3)

  • Criar template
  • Training em como escrever
  • Fazer postmortem de incident anterior

Fase 4: War Room (Semana 4)

  • Procedures documentadas
  • Roles definidos
  • Drill/simulação

Métricas de Sucesso

Após 1 mês: - ✅ SLAs cumpridos em 90%+ dos incidents - ✅ On-call rotation funcionando - ✅ Postmortems feitos para todos P0/P1

Após 3 meses: - ✅ MTTR reduzido em 40% - ✅ Action items de postmortems 80%+ completos - ✅ Zero burnout de on-call

Referências