Playbook de resposta a incidentes para equipas pequenas e médias

Em resumo: Quando à sexta-feira às 23:30 cai o servidor de produção, não é momento de inventar o procedimento do zero. Um playbook de resposta a incidentes é um documento que define papéis, comunicação e procedimentos antes de precisar deles. Aqui está um playbook mínimo adequado para equipa de 5-20 pessoas.

Papéis durante um incidente

Papéis claros eliminam o caos. Mesmo uma equipa pequena precisa de pelo menos:

• Incident Commander (IC) - gere o incidente, toma decisões, escala. Não escreve código.
• Technical lead - a pessoa que conhece a área problemática. Escreve o fix.
• Communications lead - atualiza status page, clientes, management. Para equipa pequena pode ser o mesmo que IC.
• Scribe - escreve timeline, quem faz o quê, quando. Crucial para o post-mortem.

Em equipa até 5 pessoas tipicamente IC + Technical lead = 2 papéis divididos, outros toma IC.

Níveis de severity

Define 3-4 níveis de gravidade com antecedência:

• SEV1 (Critical) - serviço principal completamente indisponível. Reage-se imediatamente, paging mesmo à noite.
• SEV2 (Major) - degradação significativa (parte das features, alguns utilizadores). Reação em 30 min durante horas de trabalho, em 1 h fora.
• SEV3 (Minor) - pequeno impacto, workaround existe. Reação até ao próximo dia útil.
• SEV4 (Cosmetic) - sem impacto user-facing, vai para fila normal.

Procedimento SEV1: os primeiros 15 minutos

1. 00:00 - Deteção. O alerta vem da monitorização ou do cliente. Alguém na rotação on-call confirma que o problema é real.
2. 00:02 - Ativação IC. Abre-se canal de comunicação dedicado (Slack #incident-N ou Discord). Chama-se o Technical lead.
3. 00:05 - Primeiro status update. Na status page pública: "Investigating reports of [problema]." Email às pessoas internas que deveriam saber.
4. 00:10 - Initial diagnostics. Verifica deploys recentes, gráficos de monitorização, error logs. O que mudou nos últimos 30-60 min?
5. 00:15 - Decisão: rollback, hotfix ou workaround? Se não for imediatamente claro, IC escala ou chama mais engenheiros.

Comunicação: a regra "5 + 30"

Atualização da status page pelo menos a cada 30 minutos durante SEV1, mesmo se não tiveres novas info. "Ainda a investigar, ETA ainda desconhecido" é update melhor que silêncio - os clientes pelo menos sabem que alguém está a trabalhar no problema.

O primeiro update tem de ser dentro de 5 minutos da deteção. Independentemente de saberes a causa.

Rollback como default

Para SEV1 que começou pouco após um deploy, o rollback é a primeira escolha, não hotfix. Hotfix sob pressão à noite é fonte de mais bugs. O rollback restaura um estado conhecido bom e dá tempo para diagnóstico calmo de manhã.

Para rollback é necessário ter:

• Versionamento de implantação (tags Docker, tags Git, artefacto de deployment)
• Database migrations backwards compatible (se nova versão dropar uma coluna, a antiga não recupera)
• Procedimento de rollback documentado (comandos, quanto demora, quem pode executá-lo)

Post-mortem em 48 horas

Após cada incidente SEV1/SEV2 escreve documento com estrutura:

1. Summary - 2-3 frases o que aconteceu, quanto durou, quem afetou
2. Timeline - tempos exatos de deteção, ações chave, resolução
3. Root cause - porque aconteceu (razão técnica + razão processual)
4. Impact - número de clientes afetados, impacto business
5. What went well - o que fizemos bem (apreciar a equipa)
6. What went wrong - onde perdemos tempo
7. Action items - tarefas concretas com owner e deadline (não "testar melhor" - melhor "adicionar teste de integração para payment flow em 14 dias, owner: X")

Regra blameless post-mortem: Não procuras culpado, procuras fraqueza sistémica. "O John implantou versão má" é conclusão incorreta - a certa é "o processo de deploy não continha fase canary que apanharia o bug antes do rollout completo".

Rotação on-call

Para equipa com produto 24/7:

• Rotações semanais - mais curto queima, mais longo significa continuidade do contexto
• Sempre primário + secundário on-call. Secundário toma quando primário não reage em 5 min.
• Compensação (pagamento extra, time-off) para paging noturno e de fim de semana
• "On-call review" mensal - quem foi acordado frequentemente, o que pode ser automatizado

Ferramentas

• Monitoring (ePulz.io, Datadog, New Relic) - deteção + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - escalation, rotação, SMS/voz
• Status page (própria, ePulz.io, StatusPage.io) - comunicação externa
• Hosting de runbook (Notion, GitHub Wiki, internal docs) - playbooks e runbooks
• Template postmortem (Confluence, Notion template) - padronização

Conclusão

A resposta a incidentes não pode ser improvisada sob pressão. 30 minutos investidos em escrever um playbook retornam na primeira maior queda - menos caos, MTTR mais curto, melhor comunicação com clientes e equipa que sabe o que fazer.

Começa com deteção automática

O ePulz.io resolve os primeiros minutos da resposta a incidente: deteção + alerting por e-mail, Telegram e webhook para Slack / Discord / PagerDuty.

Iniciar monitorização →