Quando pensamos em Disaster Recovery (DR) sempre fica uma dúvida sobre a melhor forma possível de implementar, além lógico, dos custos. Na maioria das vezes é difícil pensar em todas variáveis envolvidas, porém antes de tudo, é importante não focar apenas em fatores técnicos, mas principalmente naqueles alinhados ao negócio da sua empresa.
É importante pensarmos em Disaster Recovery como um conceito e não uma ferramenta ou um conjunto de práticas delimitadas. Pense nele como um plano global, que envolve processos e uma ou mais soluções, ou seja, não existe uma única forma de fazer e o conceito de “one size fits all” simplesmente não existe.
Se o negócio da sua empresa é crítico e não aceita indisponibilidades, certamente sua política de Disaster Recovery deverá ser mais complexa e refinada, mas ao mesmo tempo, a solução envolverá custos mais elevados. Do contrário, se a empresa aceita níveis mais flexíveis de disponibilidade, a política de DR pode ser menos complexa, com menor custo.
Mas como definir a melhor estratégia para minha empresa? Quais são as perguntas certas a fazer?
O primeiro passo é que sua empresa faça o preenchimento de um modelo de questionário BIA (Business Plan Analysis), pois ele detectará aspectos relevantes para o desenho da melhor solução de DR. Aqui você pode encontrar um bom exemplo, desenvolvido pela ISACA (Information Audit and Control Association).
Nele destacam-se questões como RTO (Recovery Time Objective), RPO (Recovery Point Objective), processos/departamentos relacionados frente a criticidade da TI para seu negócio e os impactos que uma indisponibilidade pode causar – principalmente prejuízos financeiros e de imagem.
Mas como esses termos (RTO e RPO) irão me ajudar? O que eles tem a ver com a minha empresa?
RTO (Recovery Time Objective) é o tempo que, após um desastre, sua empresa leva para restaurar plenamente seus sistemas. A pergunta certa aqui é: Quanto tempo sua empresa pode ficar indisponível? Quase sempre a resposta é NUNCA, porém, é importante alinhar os fatores expectativa e custo.
RPO (Recovery Point Objective) representa a periodicidade em que os dados de sua empresa precisam ser replicados para uma outra estrutura ou localidade. Por exemplo, se os dados da sua empresa mudam com uma frequência muito grande (banco de dados transacional, por exemplo), o RPO deve ser bastante curto. É ele quem define a periodicidade da replicação, por exemplo, se será a cada 15 minutos ou a cada 24 horas.
Quais são os sabores de DR que a minha empresa pode ter?
Existem diversos tipos e soluções de Disaster Recovery e dependendo do resultado da análise de impactos no negócio, sua empresa poderá se beneficiar de diferentes formas.
Existe também a possibilidade de começar por um modelo mais simples de DR e ir escalando conforme o tempo, mitigando riscos e gerenciando custos, porém, é importante sempre alinhar expectativas com os decisores da corporação, já que DR é um conceito amplo que permeia todo o negócio e não apenas o departamento de TI.
- ColdSiteDR: Modelo de DR onde seus dados são copiados de um local (site local) para outro (site remoto). Preferencialmente envolve uma solução (ferramenta) automatizada para replicação de dados, porém, demanda mais tempo (RTO) para recuperação de desastres uma vez necessitar passos adicionais (manuais) e também, possivelmente, aquisição de infraestrutura. Os custos dessa solução normalmente são menores.
- WarmSite DR: Modelo de DR que se posiciona como meio termo entre Cold Site e Hot Site. Nele, as soluções envolvidas já possuem algum nível de automação e complexidade para recuperação de desastres, porém, seus índices de RTO e RPO são piores do que em uma solução de HotSite DR. Pode envolver também a prévia contratação de infraestrutura de contingência/recuperação, onde os servidores serão inicializados após incidentes, com seus SLA (Service Level Agreement) definidos. Os custos dessa solução são um pouco mais elevados, principalmente por necessitar algum tipo de licenciamento e expertise de implantação.
- Hot Site DR:Modelo de DR que é o sonho de qualquer empresa e departamento de TI, nele os dados são replicados com o menor RPO (Recovery Point Objective) possível. Por possuir uma estrutura totalmente duplicada no site de contingência (remoto), o RTO (Recovery Time Objective) é mais baixo do que nas soluções anteriores, entretanto, os custos de infraestrutura, licenciamento e expertise (implantação) são elevados. Normalmente este tipo de solução é alinhado a empresas com fortes requisitos de compliance e operação de missão-crítica.
Independente do sabor de DR, sua empresa precisa ter alguma forma de continuidade.
Independente do tamanho, provavelmente a informação é o bem mais valioso que sua empresa possui. Recuperar dados em casos de incidentes pode ser a diferença entre a continuidade ou não de seu negócio, portanto, ter uma política de Disaster Recovery certamente lhe fará respirar aliviado.
Talvez, por uma série de motivos, não seja possível implementar desde já o modelo ideal para sua empresa, mas ter algum nível de replicação de dados fora de seu escritório ou datacenter principal já fará grande diferença.
Se você for do departamento de TI, exponha a importância disso aos decisores de sua empresa e construa uma agenda comum de continuidade de negócio. Se você for o decisor estratégico da corporação, levante essa discussão com os outros departamentos.
Afinal, uma cultura de continuidade de negócios e Disaster Recovery dependerá do engajamento de todos, e caso não haja, certamente também impactará à todos.
[Crédito da Imagem: Disaster Recovery – ShutterStock]
Me desculpe, mas existe uma grnade confusão entre conceitos de DR e BCP. DR é direcionado para ativos (de TI, de infra ou outro qualquer, necessário para execução dos processos corporativos). Um BIA para “ativos” é impraticável. Necessário realizar BIA para os processos e sobre o resultado, inferir os ativos críticos. Olhe no meu perfil de LinkedIN, postei vários artigos expicando cada um deles…
Fernando,
Obrigado pela sua contribuição, a idéia mesmo é trocarmos experiências por aqui.
Concordo contigo que há grande confusão sobre esses aspectos mas não penso que eles sejam conflitantes, muito pelo contrário, no post a idéia que quis passar aos leitores é que o desejável é que toda empresa tenha um BCP e não apenas um DR. Ou seja, existem aspectos muito maiores do que apenas ativos de TI, principalmente aqueles que envovem processos, processos de negócio e pessoas.
A maioria das empresas pensa apenas em ativos de TI, constroem um DR plan e pensam que está tudo bem. Quando um evento furtuito acontece, os ativos de TI estão perfeitos mas os processos, negócio e pessoa estão desorganizados, e o resultado disso, é não ter continuidade de negócio. Essas empresas não pensaram em BCP.
Quando citei o BIA, era justamente para incluir aspectos de estratégia (não apenas de ativos de TI) mas de processos de negócio. Não concordo que seja impraticável fazê-lo, pois eu mesmo já fiz em alguns projetos com empresas dos mais variados portes e deu resultado. A diferença, ao meu ver, é o nível de comprometimento e engajamento das pessoas neste sentido.
Novamente obrigado pela sua contribuição e fomento da discussão!
Um abraço!
Marcio Fernandes