Versão: 1.0.0
Data de criação: 03/06/2026
Última atualização: 03/06/2026
Status: Interno — Uso operacional
Sumário
1. Objetivo
2. Escopo
3. Análise de Impacto nos Negócios (BIA)
7. Estratégias de Continuidade
8. Plano de Comunicação de Crise
11. Referências
1. Objetivo
Este Plano de Continuidade de Negócios (PCN / BCP) define as estratégias e procedimentos para garantir que o Forms2You possa continuar operando — ou retomar operações rapidamente — em caso de disrupção significativa, seja por falha técnica, incidente de segurança, desastre natural ou qualquer outro evento adverso.
2. Escopo
Este plano cobre:
A plataforma Forms2You (aplicação web)
A API e os formulários públicos
O banco de dados e infraestrutura de dados
Os e-mails transacionais
O processamento de pagamentos
O suporte ao Cliente durante crises
3. Análise de Impacto nos Negócios (BIA)
3.1 Funções críticas por prioridade
| Prioridade | Função | Impacto se indisponível |
|---|---|---|
| 1 — Crítico | Formulários públicos (/f/[slug]) | Clientes não coletam dados; perda direta de receita para eles |
| 1 — Crítico | Banco de dados (PostgreSQL) | Toda a plataforma inoperante |
| 2 — Alto | Painel do Cliente (Dashboard) | Clientes não conseguem gerenciar formulários |
| 2 — Alto | Autenticação | Clientes não conseguem acessar suas contas |
| 3 — Médio | E-mails transacionais | Notificações e alertas não chegam; impacto na experiência |
| 3 — Médio | Exportação de dados | Clientes não conseguem extrair respostas |
| 4 — Baixo | Integrações com terceiros | Webhooks e sincronizações falham |
| 4 — Baixo | Painel administrativo interno | Operação interna impactada; Clientes não afetados diretamente |
3.2 Impacto financeiro estimado por hora de indisponibilidade
[REVISAR] — Calcular com base na base de Clientes e MRR atual.
4. Objetivos de Recuperação
| Métrica | Definição | Meta Forms2You |
|---|---|---|
| RTO (Recovery Time Objective) | Tempo máximo aceitável para retomar operações | 4 horas (P1); 24 horas (P2) |
| RPO (Recovery Point Objective) | Perda máxima aceitável de dados | 24 horas (backup diário) |
| MTTR (Mean Time to Recover) | Tempo médio de recuperação histórico | Meta: < 2 horas |
[REVISAR] — Ajustar metas conforme SLA oferecido e capacidade operacional real.
5. Cenários de Disrupção
Cenário 1 — Falha do servidor principal
Probabilidade: Média | Impacto: Crítico
Causas possíveis: falha de hardware, problema no hypervisor do provedor, corrupção de sistema
Estratégia de resposta:
1. Identificar a causa com o provedor de hospedagem
2. Solicitar restauração da VM ou migração para novo servidor
3. Restaurar a partir do backup mais recente
4. Validar integridade dos dados e serviços
5. Reconfigurar DNS se necessário
Tempo esperado de recuperação: 2–8 horas
Cenário 2 — Comprometimento de segurança
Probabilidade: Baixa | Impacto: Crítico
Ver Plano de Resposta a Incidentes para o protocolo completo.
Passos específicos de continuidade:
1. Isolar sistemas comprometidos
2. Ativar modo de manutenção (página de status)
3. Restaurar a partir de backup limpo em nova infraestrutura
4. Validar e recolocar em produção após confirmação de limpeza
Cenário 3 — Falha do banco de dados
Probabilidade: Baixa | Impacto: Crítico
Causas possíveis: corrupção de dados, falha de disco, erro em migração
Estratégia de resposta:
1. Identificar a causa (corrupção, hardware, query)
2. Se recuperável sem restauração: executar recovery do PostgreSQL
3. Se necessário restaurar: usar backup mais recente
4. Verificar integridade dos dados após restauração
5. Comunicar Clientes sobre possível perda de dados (se RPO impactar)
Tempo esperado de recuperação: 1–4 horas
Cenário 4 — Indisponibilidade do provedor de hospedagem
Probabilidade: Baixa | Impacto: Alto
Causas possíveis: manutenção não planejada, falha do datacenter, problema de rede do provedor
Estratégia de resposta:
1. Confirmar que o problema é do provedor (não da nossa infraestrutura)
2. Comunicar Clientes via e-mail e redes sociais
3. Acompanhar status page do provedor
4. Se indisponibilidade prevista > 4h: avaliar migração emergencial para provedor alternativo [REVISAR]
Cenário 5 — Falha no processamento de pagamentos
Probabilidade: Média | Impacto: Médio
Causas possíveis: falha do gateway de pagamento, mudança de API
Estratégia de resposta:
1. Confirmar o problema com o provedor de pagamentos
2. Suspender temporariamente novos cadastros (se necessário)
3. Não suspender contas de Clientes ativos durante a falha
4. Comunicar Clientes com cobranças pendentes
5. Resolver após retorno do serviço do provedor
Cenário 6 — Perda ou desligamento de membro-chave da equipe
Probabilidade: Média | Impacto: Médio–Alto
Estratégia de resposta:
1. Documentação técnica deve ser suficiente para que outro membro assuma
2. Runbooks devem estar atualizados e acessíveis
3. Acesso às credenciais críticas não deve depender de uma única pessoa
4. [REVISAR] — Definir redundância de pessoas para funções críticas
6. Estrutura de Resposta
Níveis de ativação
| Nível | Critério | Quem ativa |
|---|---|---|
| Operacional | Incidente técnico com impacto limitado | Equipe técnica |
| Tático | Impacto em > 10% dos Clientes ou > 2h de indisponibilidade | Liderança técnica |
| Estratégico | Impacto generalizado; risco reputacional; violação de dados | Fundador/CEO |
Papéis durante crise
| Papel | Responsabilidade |
|---|---|
| Diretor de Crise | Coordena toda a resposta; comunicações externas |
| Líder Técnico | Dirige a recuperação técnica |
| Responsável por Comunicação | Gerencia comunicações com Clientes e stakeholders |
| Responsável Financeiro | Gerencia impacto financeiro; créditos e SLA |
7. Estratégias de Continuidade
7.1 Infraestrutura
Atual: servidor único VPS com Docker
Estratégias de mitigação:
Backups diários automáticos em local separado (ver Runbook de Backup)
Documentação de infraestrutura como código (docker-compose)
Capacidade de redeployar em novo servidor em < 2 horas a partir do zero
Monitoramento de disponibilidade com alertas
Meta futura: [REVISAR] — Avaliar multi-região ou servidor de standby para SLA mais robusto conforme crescimento.
7.2 Dados
Backup diário completo do PostgreSQL
Backup armazenado fora do servidor principal
Teste de restauração mensal
Scripts de restore documentados em Runbook de Backup
7.3 Comunicação com Clientes durante crise
Página de status: [REVISAR] — criar status.forms2you.com ou usar serviço como Instatus/Betterstack
E-mail direto para Clientes afetados
Redes sociais oficiais para atualizações públicas
8. Plano de Comunicação de Crise
8.1 Gatilhos para comunicação externa
| Situação | Comunicar Clientes? | Canais |
|---|---|---|
| Indisponibilidade < 30 min | Não (se fora do horário de pico) | — |
| Indisponibilidade 30 min – 2h | Sim | Página de status |
| Indisponibilidade > 2h | Sim | Página de status + E-mail |
| Perda ou risco de dados pessoais | Sim (obrigatório) | E-mail direto + ANPD |
| Manutenção planejada | Sim (com antecedência) | E-mail + Página de status |
8.2 Templates de comunicação
Template — Indisponibilidade em andamento:
Estamos cientes de que alguns Clientes estão com dificuldades de acesso ao Forms2You. Nossa equipe está investigando ativamente o problema. Atualizações a cada [X] minutos em [link da página de status]. Pedimos desculpas pelo transtorno.
Template — Recuperação confirmada:
O Forms2You está totalmente operacional. O problema [descrição breve] foi resolvido às [horário]. Implementamos melhorias para evitar recorrência. Clientes que precisem de crédito por tempo de inatividade devem entrar em contato em [e-mail].
Template — Incidente de dados:
[Ver templates específicos no Plano de Resposta a Incidentes]
8.3 Quem está autorizado a comunicar
Comunicações externas: apenas o Diretor de Crise ou porta-voz designado
Membros da equipe não devem postar nas redes sociais sobre o incidente sem autorização
9. Dependências Críticas
| Dependência | Provedor | Alternativa em caso de falha | SLA do provedor |
|---|---|---|---|
| Servidor / VPS | Hostinger [REVISAR] | Migração para DigitalOcean/AWS/Hetzner | [REVISAR] |
| DNS | Cloudflare | Migração para outro nameserver | 99.9%+ |
| SSL | Let's Encrypt (via Traefik) | Certificado manual temporário | N/A |
| Banco de dados | PostgreSQL (self-hosted) | Restore a partir de backup | N/A |
Postal (self-hosted) [REVISAR] | SMTP externo temporário (ex: Resend) | N/A | |
| Pagamentos | [REVISAR] | [REVISAR] | [REVISAR] |
10. Testes e Manutenção
Calendário de testes
| Teste | Frequência | Responsável |
|---|---|---|
| Teste de restauração de backup | Mensal | Responsável técnico |
| Revisão dos runbooks | Trimestral | Equipe técnica |
| Simulação de incidente (tabletop) | Semestral [REVISAR] | Toda a equipe |
| Revisão completa do PCN | Anual | Liderança |
Critérios de revisão obrigatória
Este plano deve ser revisado após:
Qualquer incidente real com impacto significativo
Mudanças relevantes na infraestrutura
Adição ou remoção de dependências críticas
Mudanças na equipe que afetam papéis definidos aqui
11. Referências
*Documento de uso interno. Manter atualizado e acessível à equipe em local seguro. Testar regularmente.*