Antes de publicar
Prevencao: Checklist de mudanca, dono definido e criterio claro para seguir ou voltar.
Continuidade operacional
O site nao precisa cair para a empresa descobrir que dependia de memoria.
Use este guia para planejar o minimo necessario caso servidor, dominio, e-mail, banco, fornecedor, acesso, campanha ou conteudo critico falhe em uma pequena empresa.
Como pensar
Continuidade nao e prever tudo. E saber o que fazer primeiro quando algo importante falha.
Pequenas empresas nao precisam de um manual enorme. Precisam de clareza sobre impacto, responsavel, acesso, evidencia, rollback, comunicacao e validacao. O resto pode evoluir em ciclos curtos.
Durante a falha
Resposta: Servico estabilizado, impacto delimitado e evidencias preservadas.
Depois de normalizar
Aprendizado: Rotina melhorada para que a mesma falha nao dependa de memoria individual.
Cenarios criticos
O que precisa continuar funcionando.
Cada bloco abaixo mostra o que pode falhar, sinais iniciais, primeiras acoes, plano minimo e evidencias para a empresa nao depender apenas de tentativa e erro.
VPS, containers ou backend fora do ar
Servidor inacessivel, container parado, porta errada, proxy sem rota, variavel ausente, backend em loop ou deploy publicado sem validar rotas reais.
Sinais iniciais
- Site abre, mas rotas internas retornam erro
- API responde 502, 503 ou 500
- Container reinicia repetidamente
- Log mostra variavel ausente ou falha de conexao
Primeiras acoes
- Confirmar se o problema e geral ou limitado a uma rota
- Verificar container, logs e resposta HTTP da aplicacao
- Comparar versao publicada, variaveis e proxy
- Decidir entre rollback, ajuste de configuracao ou hotfix pequeno
Plano minimo
Manter checklist pos-deploy, comando de rollback conhecido, mapa de portas e variaveis, alem de uma rota simples para validar saude do backend.
Evidencias
Status HTTP, logs do container, versao publicada, variaveis revisadas, rota validada.
Dominio, DNS, Cloudflare ou SSL com problema
Registro A ou CNAME aponta para lugar errado, proxy muda comportamento, SSL falha, MX e SPF sao alterados sem criterio ou uma entrada antiga fica concorrendo com a nova.
Sinais iniciais
- Domino abre de uma rede e falha em outra
- HTTPS mostra alerta de certificado
- E-mail do dominio para de autenticar
- Formulario salva contato, mas notificacao nao chega
Primeiras acoes
- Registrar o estado atual de DNS, proxy e SSL antes de mexer
- Validar IP, CNAME, MX, SPF, DKIM e status de proxy
- Testar site, e-mail e formulario depois da alteracao
- Guardar print ou exportacao dos registros revisados
Plano minimo
Ter um mapa de DNS com finalidade de cada registro, dono da conta, regra para mudanca e teste obrigatorio de site e e-mail apos qualquer ajuste.
Evidencias
Registros DNS, status Cloudflare, certificado SSL, MX/SPF/DKIM, teste de e-mail.
E-mail, SMTP ou formulario falhando
Formulario grava no banco, mas nao envia e-mail; SMTP recusa remetente; senha expira; SPF/DKIM muda; ou UTM chega vazia por mudanca de URL.
Sinais iniciais
- Contato aparece no sistema, mas nao chega na caixa
- Log mostra sender invalido ou conexao recusada
- Teste manual funciona sem UTM e falha com campanha
- Google Ads registra clique, mas a equipe nao recebe lead
Primeiras acoes
- Confirmar se o contato foi salvo antes de investigar SMTP
- Ler log do backend e mensagem real do provedor de e-mail
- Testar remetente, senha, porta, SSL e autenticacao
- Enviar novo teste com UTM e conferir e-mail recebido
Plano minimo
Separar persistencia do contato, envio de notificacao, alerta de falha e teste periodico com origem de campanha.
Evidencias
Contato salvo, log SMTP, mensagem recebida, UTM source, UTM campaign.
Banco, backup ou restauracao necessaria
Migration altera schema sem plano de retorno, backup existe mas nunca foi restaurado, dado e removido por engano ou consulta critica fica lenta apos mudanca.
Sinais iniciais
- Erro aparece somente em fluxo com dado real
- Backup mais recente nao tem data ou tamanho claro
- Restauracao nunca foi testada
- Consulta fica lenta depois de uma migration
Primeiras acoes
- Identificar quais dados e tabelas foram afetados
- Localizar backup mais recente e confirmar integridade
- Evitar nova escrita destrutiva enquanto o impacto nao estiver claro
- Testar restauracao em ambiente controlado quando possivel
Plano minimo
Documentar rotina de backup, responsavel, frequencia, local, tempo estimado de retorno e ultimo teste de restauracao.
Evidencias
Data do backup, tamanho, local, teste de restauracao, migration revisada.
Acesso, segredo ou conta comprometida
Senha real vaza, token fica em repositorio, conta antiga continua ativa, fornecedor sai sem transferencia ou automacao usa permissao maior que o necessario.
Sinais iniciais
- Variavel sensivel aparece em arquivo ou log
- Conta compartilhada nao tem dono claro
- Pessoa que saiu ainda tem acesso
- Troca de senha quebra deploy, SMTP ou integracao
Primeiras acoes
- Identificar escopo do segredo e sistemas dependentes
- Rotacionar credencial e remover exposicao antiga
- Testar aplicacao depois da troca
- Registrar quem revisou acessos e quais contas ficaram ativas
Plano minimo
Manter inventario simples de contas, variaveis sensiveis, donos, nivel de permissao e data da ultima revisao.
Evidencias
Segredo rotacionado, acesso removido, teste pos-rotacao, responsavel, data.
Fornecedor, freelancer ou pessoa-chave indisponivel
Deploy, dominio, banco, campanhas ou documentacao dependem de uma pessoa. Quando ela fica indisponivel, a empresa nao sabe onde estao acessos, comandos e decisoes.
Sinais iniciais
- Somente uma pessoa sabe publicar
- A conta principal nao pertence a empresa
- Documentacao esta em conversa privada
- Nao existe substituto para validar uma mudanca
Primeiras acoes
- Confirmar quais acessos pertencem a empresa
- Registrar comandos, provedores e dependencias criticas
- Definir substituto minimo por area
- Criar modelo de entrega tecnica para novos fornecedores
Plano minimo
Separar propriedade da execucao: fornecedor pode operar, mas dominio, dados, repositorio, contas e historico precisam ficar sob controle da empresa.
Evidencias
Lista de acessos, repositorio, provedores, comandos de deploy, substituto definido.
Campanha, tag ou monetizacao sem rastreamento
Tag do Google Ads nao dispara, conversao nao registra, UTM some, AdSense nao enxerga valor editorial ou uma mudanca de pagina quebra destino de campanha.
Sinais iniciais
- Tag Assistant encontra a tag, mas nao o evento esperado
- Google Ads mostra clique sem conversao
- Contato chega sem origem de campanha
- Pagina nova nao aparece na busca interna ou sitemap
Primeiras acoes
- Validar carregamento da tag e evento no fluxo real
- Testar formulario com UTM e conferir e-mail recebido
- Confirmar canonical, sitemap, robots e links internos
- Evitar trocar lances antes de corrigir medicao
Plano minimo
Toda campanha deve ter URL final, UTM, pagina de destino validada, evento testado e evidencias antes de avaliar resultado.
Evidencias
Tag Assistant, evento, UTM, lead recebido, URL final, sitemap.
Conteudo, indexacao ou AdSense com risco
Pagina fica rasa, duplicada, sem link interno, sem autoria clara, com erro visual, sem sitemap ou com CTA comercial antes de responder uma pergunta real.
Sinais iniciais
- Busca interna nao encontra a pagina publicada
- Pagina tem pouco contexto antes de monetizar
- Schema nao corresponde ao conteudo visivel
- Links internos nao ajudam o leitor a continuar
Primeiras acoes
- Conferir se a pagina responde uma duvida especifica
- Adicionar links para guias, modelos, indicadores e fontes
- Validar title, description, canonical e JSON-LD
- Abrir em mobile e desktop procurando sobreposicao ou bloco quebrado
Plano minimo
Tratar cada pagina como parte do portal: descoberta, profundidade, autoria, experiencia, navegacao e atualizacao precisam caminhar juntos.
Evidencias
URL, canonical, schema, links internos, sitemap, print mobile.
IA, documentos ou fontes internas desatualizadas
IA responde com fonte antiga, documento sem permissao, regra fora de contexto ou codigo gerado sem revisao humana. O risco parece produtividade, mas vira decisao errada.
Sinais iniciais
- Resposta nao cita fonte ou data
- Documento duplicado entra na base
- Prompts usam dado sensivel sem criterio
- Codigo gerado por IA vai para producao sem teste
Primeiras acoes
- Identificar fonte, dono, data e permissao
- Separar uso interno, publico e sensivel
- Criar perguntas de teste com resposta esperada
- Exigir revisao humana antes de publicar ou automatizar
Plano minimo
Manter mapa de fontes para IA/RAG com dono, validade, permissao, escopo de uso e criterio de revisao.
Evidencias
Fonte, dono, data, permissao, teste, revisao humana.
Rotina minima
Tres momentos mantem a continuidade viva.
O plano so ajuda se for revisado em momentos reais: antes de mudancas, durante falhas e depois da normalizacao.
Antes de publicar
- Confirmar responsavel por deploy, DNS, banco, formulario e conteudo
- Separar o que precisa de rollback do que pode ser corrigido com ajuste simples
- Preparar evidencia do estado anterior e plano de validacao
Checklist de mudanca, dono definido e criterio claro para seguir ou voltar.
Durante a falha
- Reduzir impacto antes de investigar todos os detalhes
- Guardar horario, sintoma, rota, log e decisao tomada
- Comunicar apenas o que ja foi confirmado
Servico estabilizado, impacto delimitado e evidencias preservadas.
Depois de normalizar
- Fechar causa confirmada e nao somente sintoma
- Atualizar playbook, checklist, responsavel ou indicador
- Registrar acao preventiva com prazo realista
Rotina melhorada para que a mesma falha nao dependa de memoria individual.
Perguntas comuns
Continuidade boa cabe na rotina.
O objetivo e reduzir dependencia de memoria, aumentar qualidade da resposta e transformar falhas em melhoria operacional.
Plano de continuidade precisa ser grande para pequena empresa?
Nao. Para uma empresa pequena, o melhor plano costuma ser curto: cenarios criticos, primeiro responsavel, acessos, evidencias, rollback e como validar que voltou ao normal.
Qual a diferenca entre playbook e continuidade operacional?
Playbook orienta a resposta em um problema especifico. Continuidade operacional conecta varios playbooks, responsaveis, acessos, comunicacao, backup e aprendizado para manter a empresa funcionando.
Quando revisar o plano de continuidade?
Revise depois de incidente, antes de mudanca relevante, quando trocar fornecedor, ao mudar DNS/e-mail/servidor e sempre que uma rotina critica depender de uma pessoa so.