Quase nenhuma PME cai por causa de um ciberataque de cinema. Cai por causa do aborrecido: um servidor que se desliga e não volta, um ransomware que cifra a pasta partilhada numa sexta-feira à tarde, uma canalização que rebenta por cima do rack, um fornecedor de nuvem com uma paragem de seis horas. A pergunta que realmente importa não é se vai acontecer, mas quantas horas a sua empresa pode ficar sem faturar, sem produzir ou sem atender clientes antes de o dano ser irreversível. Um plano de continuidade de negócio para PME é exatamente a resposta a essa pergunta, posta por escrito e testada.
E não, não é preciso um manual de 200 páginas nem o orçamento de uma multinacional. É preciso saber que processos não podem parar, quanto aguenta realmente e que três coisas faz na primeira hora. O resto é enfeite. Vamos ao concreto.
Continuidade vs. recuperação: o que é um BCP e o que é um DRP
Confundem-se constantemente, e essa confusão é cara. O BCP (Business Continuity Plan) responde a “como continua o meu negócio a funcionar enquanto algo está avariado”. O DRP (Disaster Recovery Plan) responde a “como recupero a tecnologia que caiu”. Um olha para o negócio; o outro, para os sistemas.
Um exemplo: cai-lhe o ERP. O DRP diz como restaura a base de dados a partir da cópia e em que servidor a coloca de pé. O BCP diz como a equipa de faturação continua a emitir guias de remessa num modelo provisório entretanto, para que o armazém não pare. O DRP repara a máquina; o BCP mantém o dinheiro a entrar pela porta. Precisa dos dois, e precisa que falem entre si.
Recuperar o sistema em dois dias não serve de nada se o seu negócio morre em quatro horas sem ele.
O erro clássico da PME é ter (com sorte) um bocado de DRP —as cópias de segurança— e nem rasto de BCP. Tem backups, sim, mas ninguém sabe quem decide ativar a recuperação, a quem se avisa, como se atendem os clientes entretanto nem quanto tempo é “demasiado”. Isso não é um plano: é uma pasta de ficheiros e os dedos cruzados.
Que processos não podem parar e quanto aguenta: RTO e RPO em português claro
Todo o plano sério arranca do mesmo ponto: nem tudo importa por igual. Se tentar proteger cada sistema com a mesma urgência, nem termina nem o consegue pagar. Faça uma lista honesta dos seus processos —faturar, produzir, tratar encomendas, pagar salários, dar suporte— e classifique-os pelo que acontece se pararem uma hora, um dia, uma semana. Os que doem em horas são os seus processos críticos. Esses é que mandam.
Sobre essa lista surgem duas siglas que soam técnicas mas são puro senso comum:
- RTO (objetivo de tempo de recuperação): quanto tempo um processo pode estar em baixo antes de o dano ser grave. É o seu “relógio”. Se a sua loja online não pode estar mais de 2 horas sem vender, o seu RTO é 2 horas.
- RPO (objetivo de ponto de recuperação): quantos dados se pode permitir perder, medidos em tempo. Se faz cópia a cada 24 horas, o seu RPO é de um dia: perante um desastre, perde até um dia de trabalho. Para um ERP de faturação isso costuma ser inaceitável.
A magia está em cruzar ambos com a realidade. Se o seu processo crítico exige um RTO de 2 horas mas a sua única cópia está num disco USB que alguém leva para casa às sextas, a sua capacidade real de recuperação é de dias, não de horas. Aí tem o buraco, medido e com números. E com esses números já pode decidir onde investir: replicação na nuvem, cópias mais frequentes, um servidor secundário. Não por medo, mas por critério.
Um conselho que poupa dinheiro: ajuste o RTO e o RPO ao valor do processo, não à sua ansiedade. O servidor de ficheiros do marketing pode tolerar um RPO de 24 horas sem drama. A base de dados de encomendas, não. Proteger tudo como se fosse crítico é a forma mais rápida de rebentar o orçamento e nunca terminar o plano.
Um plano simples que vai mesmo usar
O melhor plano de continuidade não é o mais completo: é o que a sua equipa consegue executar às 3 da madrugada, com adrenalina, sem o informático de serviço contactável. Isso significa curto, claro e acionável. Um documento de duas ou três páginas bem feitas vale mais do que um calhamaço que ninguém abriu.
O mínimo que deve conter:
- Processos críticos e os seus RTO/RPO: a lista do ponto anterior, priorizada. O que se recupera primeiro e o que pode esperar.
- Quem decide e quem executa: nomes e suplentes. Quem declara o incidente, quem autoriza a recuperação, quem fala com os clientes. Sem papéis definidos, há paralisia.
- Contactos-chave fora do sistema: telefones da equipa, do fornecedor de IT, do banco, do seguro. Impressos ou no telemóvel, porque se a rede cair não terá acesso ao Drive.
- Onde estão as cópias e como se restauram: localização, credenciais de acesso controladas e o procedimento passo a passo. Uma cópia que ninguém sabe restaurar não é uma cópia.
- O plano B manual: como cada processo crítico continua a operar sem o seu sistema. Faturar num modelo, tirar encomendas por telefone, o que quer que mantenha o negócio vivo nessas horas.
Repare no que não está: jargão, diagramas de arquitetura lindíssimos, cenários improváveis. O plano descreve o que fazer na primeira hora das três ou quatro quedas que realmente lhe podem acontecer. Todo o resto sobra até este núcleo funcionar. Comece pequeno, ponha-o por escrito hoje e melhore-o depois.
Como testá-lo para que funcione a sério
Um plano por testar é uma hipótese. E na continuidade, as hipóteses caem precisamente quando mais precisa delas. A cópia que “se fazia sozinha” falhava em silêncio há três meses; o procedimento de restauro demorava oito horas em vez de duas porque ninguém o tinha cronometrado. Estas coisas não se descobrem a ler o plano: descobrem-se a executá-lo.
Não é preciso simular um incêndio. Teste por camadas:
- Restauro real das cópias: pegue num backup e recupere-o num ambiente à parte. Cronometre. Cumpre o seu RTO? Estão lá todos os dados? Isto faz-se todos os trimestres, não uma vez na vida.
- Simulacro de mesa: junte a equipa uma hora, lance “são 9:00 e o ERP não arranca” e que cada um diga o que faz. As lacunas aparecem sem tocar num único sistema.
- Teste do plano B manual: passe meio dia a faturar ou a tirar encomendas como se o sistema não existisse. Vai descobrir o que falta antes de precisar dele a sério.
Cada teste deixa tarefas: atualizar um contacto, corrigir um backup, esclarecer um passo confuso. Esse ciclo —testar, encontrar a falha, corrigi-la— é o que transforma um documento numa capacidade real. E aqui a monitorização desempenha um papel silencioso mas decisivo: se vigiar os sistemas e as cópias em tempo real, muitos incidentes são detetados e contidos antes de se transformarem num desastre que ative todo o plano. Prevenir sai muito mais barato do que recuperar.
Como a MagicBoxDesk o prepara
Tudo isto —classificar processos, fixar RTO e RPO realistas, montar cópias que de facto se restauram, escrever o plano e testá-lo todos os trimestres— é trabalho especializado e contínuo. É exatamente o que fazemos quando externalizamos o departamento de TI de uma empresa: não vendemos um PDF e desaparecemos, deixamos montada a capacidade real de encaixar um golpe e continuar a faturar. Desenhamos o BCP e o DRP à medida da sua operação, com monitorização 24/7 que deteta os problemas antes de o deitarem abaixo e com cópias verificadas de forma automática, não “na teoria”.
Damos suporte remoto e presencial em toda a Espanha, com a experiência de quem levantou sistemas caídos a um domingo à noite mais vezes do que gostaria. Se não sabe quantas horas o seu negócio aguenta sem os seus sistemas, esse é precisamente o ponto de partida. Peça um orçamento sem compromisso e dizemos-lhe, com números, onde está o seu risco real e o que precisa mesmo para dormir descansado.
