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

Papéis durante um incidente

Papéis claramente distribuídos eliminam o caos. Mesmo uma equipa pequena precisa de pelo menos:

• Incident Commander (IC) - gere o incidente, toma decisões e escala. Não escreve código.
• Technical lead - a pessoa que conhece a área problemática. Escreve o fix.
• Communications lead - atualiza a status page, informa clientes e management. Numa equipa pequena pode ser a mesma pessoa que o IC.
• Scribe - mantém a timeline: quem faz o quê e quando. Uma base crucial para o post-mortem.

Numa equipa até 5 pessoas separam-se normalmente o IC e o Technical lead, e o IC assume os restantes papéis.

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 delas.
• SEV3 (Minor) - pequeno impacto, existe um workaround. Reação até ao próximo dia útil.
• SEV4 (Cosmetic) - sem impacto user-facing, vai para a 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 um canal de comunicação dedicado (Slack #incident-N ou Discord) e 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 os deploys recentes, os gráficos de monitorização e os 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, o IC escala ou chama mais engenheiros.

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

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

O primeiro update tem de surgir dentro de 5 minutos da deteção, independentemente de já saberes a causa.

Rollback como opção predefinida

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

O rollback pressupõe ter:

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

Post-mortem em 48 horas

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

1. Summary - 2-3 frases sobre o que aconteceu, quanto durou e quem afetou
2. Timeline - os tempos exatos de deteção, ações chave e resolução
3. Root cause - porque aconteceu (razão técnica e processual)
4. Impact - número de clientes afetados e 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", mas antes "adicionar um teste de integração para o payment flow em 14 dias, owner: X")

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

Rotação on-call

Para uma equipa com produto 24/7:

• As rotações semanais são o ponto ideal - as mais curtas provocam esgotamento, as mais longas sobrecarregam o on-call primário
• Tem sempre um on-call primário + secundário. O secundário assume quando o primário não reage em 5 min.
• Compensa o paging noturno e de fim de semana (pagamento extra ou folga)
• Implementa um "on-call review" mensal - quem foi acordado com mais frequência e 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 queda maior - menos caos, MTTR mais curto, melhor comunicação com os clientes e uma 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 →