Suporte em Modo Degradado: Contingência e Disaster Recovery

09:00: Seu servidor cai.

Agente abre laptop: “Sistema não carrega.”

Cliente liga: “Não consigo abrir ticket.”

Você: “Nosso sistema está down, espera 2h.”

Cliente: “Meu negócio está parado. Ajuda!”

Você: Sem sistema, sem como ajudar. Desastre.

Solução: Modo degradado. Quando sistema cai, suporte ainda funciona.

Ticket via email → Agente responde via celular → Cliente sabe status.

Downtime não vira perda de cliente.

Cenários de Contingência

Cenário 1: Sistema de Tickets Cai (Mais Comum)

IMPACTO:
├─ Agentes não conseguem responder
├─ Tickets não chegam
├─ Cliente não vê status
└─ SLA não é rastreado

CAUSA COMUM:
├─ Database down (query lenta, fora de memória)
├─ Servidor web travou
├─ Deployment errado
└─ Alguém deletou tabela (ops!)

Cenário 2: Seu Próprio Datacenter Cai

IMPACTO:
├─ Tudo offline (não é só suporte, é tudo)
├─ Múltiplas features afetadas
├─ Clientes não conseguem usar seu produto
└─ Prioridade: restaurar produto, depois suporte

CAUSA:
├─ Data center inteiro offline
├─ Poder off (até 4h)
├─ Rede down
└─ Disaster natural (raro, mas acontece)

Cenário 3: Integração Crítica Cai

IMPACTO:
├─ Email não funciona (suporte não consegue responder)
├─ Slack não funciona (agente não é notificado)
├─ API para clientes cria ticket
└─ Sistema cria fila de tickets não respondidos

CAUSA:
├─ Gmail/Office 365 down (Microsoft)
├─ Slack server down
├─ Integração custom com bug
└─ Rate limit atingido (muitos emails de uma vez)

Plano de Contingência: 5 Camadas

Camada 1: Monitoramento (Detectar)

ALERTA PARA:
├─ Servidor de tickets não responde (< 5 min)
├─ Email não funciona (testa mandando email interno)
├─ Database replication lag > 1 min
├─ Error rate > 10% por 2 min consecutivos
└─ CPU ou memória > 95% por 5 min

ESCALAÇÃO:
├─ Min 1: Slack de infra (silent)
├─ Min 5: Page do on-call dev (barulhento)
├─ Min 10: Notifica PM (pode virar modo degradado)
└─ Min 15: Se não resolvido, ativa modo degradado

Camada 2: Comunicação (Avisar)

Primeira coisa: Avisar. Antes de resolver.

QUANDO DETECTA PROBLEMA (Min 0):
├─ Atualizar status page (✗ Indisponível, ETA 30 min)
├─ Email para clientes ([email protected])
├─ Slack público (pausa todas as respostas)
└─ Twitter (mais clientes veem)

CONTEÚDO:
"Estamos vivenciando uma interrupção no suporte.
- Sistema: Indisponível desde 09:05
- Impacto: Novos tickets não estão sendo criados
- Tempo estimado: Restaurado até 09:35
- Enquanto isso: Envie email direto para [email protected]
- Updates a cada 5 min em status page"

BENEFÍCIO:
├─ Cliente não liga ("vi que tá down")
├─ Cliente não fica à toa (sabe ETA)
└─ Confiança aumenta (vocês comunicam)

Camada 3: Rota Alternativa (Funcionar)

Quando sistema cai, tickets chegam via email.

SETUP:
├─ Email de suporte backup: [email protected]
├─ Gmail ou Office 365 (não seu servidor)
├─ Agentes acessam email pelo celular/web
├─ Não é tão bonito, mas funciona

WORKFLOW:
├─ Cliente envia email (sistema está down, mas email funciona)
├─ Email chega em [email protected]
├─ Agente lê no celular (Gmail web)
├─ Agente responde via email (cliente recebe)
├─ Histórico: Google Drive compartilhado (não ideal, mas emergency)

RESULTADO:
├─ Ticket não criado, mas respondido
├─ Cliente não perdeu (recebeu resposta)
├─ Negócio não parou

Camada 4: Backup de Dados (Recuperar)

Se database morrer, quanto você perde?

ESTRATÉGIA:
├─ Replicação contínua (database secundário em tempo real)
├─ Backup diário (S3, incrementais)
├─ Backup semanal (armazenamento frio, restauração 4h)
├─ RTO (Recovery Time Objective): 15 min (máximo)
└─ RPO (Recovery Point Objective): 1 min (máximo de dados perdidos)

TESTE:
├─ Simular perda de database (1x/trimestre)
├─ Praticar restauração (quanto tempo leva?)
├─ Documentar passo-a-passo
└─ Se tomar > 15 min, otimizar

Camada 5: Restore & Resumo

Quando sistema volta, catching up e notificação.

QUANDO RESOLVIDO (Ex: Min 25):
├─ Status page: ✓ Operacional
├─ Todos os tickets que chegaram por email: importados
├─ Agentes veem fila normal (nada foi perdido)
├─ Cliente recebeu resposta (durante problema)
├─ Email para clientes: "Resolvido, desculpa incomodo"

ANÁLISE PÓS-MORTEM:
├─ O que causou?
├─ Por que levou 25 min?
├─ Como prevenir?
├─ O que funcionou bem no modo degradado?
└─ O que precisa melhorar?

Exemplo: Modo Degradado em Ação

Dia do Incidente

09:05 - DATABASE CAI
├─ Alerta: "Database replica lag > 5 min"
├─ Dev notificado (page barulhento)
└─ PM notificado (pode virar degradado)

09:07 - DIAGNOSTICADO
├─ Dev descobre: memória full, query lenta travando tudo
├─ Pode restaurar em 10 min (reiniciar process)
├─ Ou 20 min (migrate para servidor maior)
└─ Decidem: Modo degradado +20 min, vs restauração rápida +10 min

09:08 - COMUNICAÇÃO
├─ Status page atualiza: "✗ Suporte indisponível, ETA 09:28"
├─ Email enviado para clientes
├─ Slack: #suporte-emergency (modo degradado ativado)
└─ Twitter: "Investigando"

09:09 - MODO DEGRADADO ATIVADO
├─ [email protected] pronto para receber
├─ Agentes avisados: "Checkem email a cada 2 min"
├─ SLA: Responder em 1h (não 4h, é emergency)
└─ Cliente já pode enviar email

09:15 - TICKETS CHEGANDO
├─ Cliente 1: Email "Servidor login não funciona"
├─ Agente Maria (lê Gmail): Responde em 8 min
├─ Cliente 1: Satisfeito (responderam em mode degradado)

09:28 - SISTEMA RESTAURADO
├─ Database online novamente
├─ Tickets criados durante outage: importados
├─ Agentes voltam a ver fila normal
├─ Status page: "✓ Resolvido"
├─ Email: "Desculpa pelos incomodos. Estava down 23 min."

09:30 - POST-MORTEM
├─ Dev: Query lenta com índice faltante
├─ Ação: Criar índice, monitorar memória
├─ Teste: Simular problema novamente (terça)
└─ Prevenção: Auto-scale quando memória > 80%

Checklist de Contingência

Setup (Fazer Uma Vez)

COMUNICAÇÃO:
├─ [ ] Status page criada (StatusPage.io, Atlassian)
├─ [ ] Email de backup configurado (não seu servidor)
├─ [ ] Distribuição de emails (status@, suporte@, emergência@)
└─ [ ] Template de comunicação de outage

TÉCNICA:
├─ [ ] Database replicado (secundário ao vivo)
├─ [ ] Backup diário automatizado (S3)
├─ [ ] RTO de 15 min documentado (teste 1x trimestre)
├─ [ ] Email backup testado (envia/recebe)
└─ [ ] Agentes sabem acessar email backup

PESSOAL:
├─ [ ] On-call schedule (quem responde quando?)
├─ [ ] Escalação definida (1º dev, 2º PM, 3º CEO)
├─ [ ] Contato de emergência para cada time
└─ [ ] Treinamento: o que fazer se sistema cai

Teste (Fazer Trimestral)

SIMULAÇÃO:
├─ [ ] Desligar database (simulation)
├─ [ ] Medir tempo para detectar (< 5 min?)
├─ [ ] Medir tempo para comunicar (< 10 min?)
├─ [ ] Testar modo degradado (email funciona?)
├─ [ ] Medir tempo para restaurar (< 15 min?)
└─ [ ] Post-mortem: o que melhorar?

SLA em Modo Degradado

Quando sistema está down, SLA muda.

NORMAL (Sistema OK):
├─ Crítico: Responder em 1h
├─ Alto: Responder em 4h
├─ Médio: Responder em 8h

DEGRADADO (Sistema Down):
├─ Crítico: Responder em 15 min (via email, rápido)
├─ Alto: Responder em 1h
├─ Médio: Responder em 4h

RAZÃO:
├─ Agente está em celular/web (mais lento)
├─ Email é caótico (sem busca de contexto)
├─ Time reduzido (alguns talvez não consiga responder)
└─ Urgência: resolver sistema ASAP

Erros Comuns

❌ “Não preciso de plano de contingência”
→ Quando cai, desastre. Perde cliente.

❌ “Vou manter tudo em um servidor”
→ Cai tudo junto. Sem backup.

❌ “Email backup, mas nunca testei”
→ Quando precisa, não funciona.

❌ “Vou comunicar depois de resolver”
→ Cliente liga 50x. CSAT cai.

✅ “Monitoramento, comunicação, rota alternativa, backup, teste”
→ Contingência real.

✅ “Comunicar nos primeiros 5 min”
→ Cliente não fica no escuro.

Exemplo de Comunicação Real

Email Padrão de Outage

---
Assunto: ⚠️ Lucy Service Desk - Suporte Indisponível (Update)

Olá Cliente,

Estamos vivenciando uma interrupção no sistema de suporte.

SITUAÇÃO:
- Sistema: Indisponível desde 09:05 (22 min)
- Impacto: Novos tickets não estão sendo criados
- Causa: Database otimização em progresso
- Tempo estimado: Restaurado até 09:35

ENQUANTO ISSO:
- Envie email direto para: [email protected]
- Agentes estão respondendo por email (tempo: ~10-15 min)
- Seu problema será criado como ticket quando sistema voltar

ATUALIZAÇÕES:
- Site de status: status.lucy.com.br
- Atualizamos a cada 5 min

Desculpa pelos incomodos. Continuamos trabalhando.

Lucy Team
---

CTA

Seu plano de contingência está pronto?

O Lucy oferece modo degradado automático (email backup), status page integrada, e teste de recovery.

Contingência com Lucy →

Ou consultoria de disaster recovery:

Agende DR planning →