Incident playbook for multi-tenant Rails SaaS

Incident playbook for multi-tenant Rails SaaS

Em apps multi-tenant, um incidente pode afetar todos ou apenas um cliente. Ter um playbook claro evita decisões improvisadas e redução de escopo fica mais segura.

Objetivos

• Reduzir tempo para isolar um tenant afetado.
• Manter comunicação clara com clientes impactados.
• Restaurar serviço com rollback seguro e dados íntegros.

Preparação (antes do incidente)

• Rastreabilidade de tenant: inclua tenant_id em logs, traces e métricas.
• Feature flags por tenant: permita desativar features para um cliente sem parar o resto.
• Migrações controladas: use migrações idempotentes e reversíveis; teste com dados de exemplo por tenant.
• Backups testados: restaurações frequentes em ambiente de ensaio com múltiplos tenants.

Durante o incidente

1) Identificar escopo
Filtre logs/metrics por tenant_id. Se for um único cliente, aplique mitigação só nele.

2) Aplicar contenção

• Desligue a feature problemática via flag.
• Se precisar, coloque o tenant em modo read-only temporário.

3) Escolher caminho de restauração

• Rollback de código: se o erro começou após deploy.
• Rollback de dados por tenant: se a tabela é isolada por tenant_id e há backup recente.
• Hotfix: apenas se o risco de regressão for baixo e o teste for reproduzível.

4) Comunicar
Informe tenants impactados com: descrição curta, escopo, ETA, próximo update.

Depois do incidente

• Postmortem leve: causa raiz, detecção, tempo para mitigar, decisões de rollback/hotfix.
• Ações preventivas: alertas por tenant_id, testes de regressão por feature flag, checagem de migração reversível.
• Higiene de dados: se houve rollback parcial, reconcilie contagens e índices.

Checklist rápido

• tenant_id logado em requests, jobs e eventos.
• Flags por tenant funcionando.
• Procedimento de rollback de migração documentado.
• Backup/restore testado para um único tenant.
• Modelo de comunicação pronto (template de status).