A computação em nuvem está facilitando muito alguns aspectos da recuperação de desastres, especialmente com o crescimento dos serviços de backup online. Mas a nuvem pode adicionar complexidade às operações de TI, especialmente em ambientes híbridos.
Além disso, existe a capacidade das linhas de negócios de aumentar seus próprios recursos na nuvem ou de comprar aplicativos de software como serviço (SaaS), o que significa que a TI pode não ter mais uma imagem completa da infraestrutura de TI da organização. E o plano inclui o que fazer se um serviço em nuvem cair?
A recuperação de desastres (DR) é a capacidade de retornar às operações “normais” após uma falha de TI, desastre natural ou outro evento inesperado e é uma função fundamental da TI.
Afinal, o departamento de TI é responsável pela manutenção dos principais sistemas de negócios e pela proteção de seus dados, por fornecer desktops ou outros computadores pessoais, acesso a nuvem, redes e, na maioria das vezes, comunicações de voz.
Mas o planejamento de recuperação de desastres em uma ambiente de nuvem híbrida é um desafio e uma responsabilidade de toda a empresa. As organizações dependem cada vez mais de seus dados, e a TI está se tornando cada vez mais hábil em fornecer acesso a esses dados em qualquer lugar do mundo.
Mas dada a crescente complexidade das operações de negócios e dos sistemas de TI. existem muitas armadilhas para as empresas que não estão preparadas.
Armadilha de DR 1: Falha no planejamento
A maior falha é deixar de planejar a recuperação de desastres.
Um plano de DR não precisa ser complexo. No caso de uma pequena empresa ou filial, pode incluir pouco mais do que backups regulares em discos armazenados externamente ou, cada vez mais, na nuvem, e um plano de como acessar os dados e restaurar aplicativos se o pior acontecer.
Para organizações maiores, um plano entrará em muito mais detalhes sobre quais aplicativos são protegidos, como eles serão recuperados e arranjos para espaços de trabalho alternativos para a equipe.
Um plano deve indicar em que ordem as várias plataformas devem ser recuperadas. Às vezes, isso fica óbvio pelos requisitos do aplicativo ou serviço, mas quando uma grande recuperação do site é necessária, a política interna também pode entrar em jogo.
Outros problemas ocorrem quando as organizações têm um plano de DR, mas é muito limitado em escopo. Aqui, a TI e o conselho podem ser enganados por uma falsa sensação de segurança. Nesses casos, existe um plano de DR, mas ele falha em cobrir todos os aplicativos e, principalmente, suas interdependências.
O plano também deve definir o objetivo do ponto de recuperação (RPO) e o objetivo do tempo de recuperação (RTO) quanto tempo a organização precisa voltar para obter um conjunto limpo e estável de aplicativos e dados e com que rapidez isso deve acontecer.
Armadilha 2 de DR: falha no teste
A próxima armadilha, e talvez a maior, é não conseguir testar. Uma estatística frequentemente citada é que 23% das organizações nunca testam seus planos de DR, com outros 29% testando apenas uma vez por ano.
A adequação de um teste anual dependerá muito do tamanho e da natureza do negócio. Mas um plano que nunca é testado está realmente a um passo de não ter nenhum plano.
O outro grande problema diz respeito aos testes de processos de recuperação de desastres. Isso é essencial porque até que você teste o DR, você realmente não pode ter certeza de que funcionará, ou se todos os sistemas que deveriam ser protegidos o foram.
Garantir um regime de teste robusto requer forte liderança do CIO. O teste de DR eficaz pode ser disruptivo e caro. Mas deixar de se recuperar de um desastre será ainda mais caro.
Se a organização testar o plano, os CIOs precisam garantir que todas as lições aprendidas – e haverá lições aprendidas – sejam usadas para atualizar o plano. O plano atualizado precisa ser testado e o ciclo repetido.
Armadilha 3 de DR: falha em proteger backups
Malware, e especialmente ransomware , é um dos motivos pelos quais o DR voltou à pauta nos últimos anos.
Proteger sistemas contra ransomware em particular significa criar uma lacuna entre os sistemas de produção e as cópias de backup ou usar tecnologias de armazenamento imutáveis, até porque os invasores aprenderam a direcionar os backups de dados primeiro. Algumas organizações voltaram à fita como uma forma de custo relativamente baixo de mover dados para um local externo.
Infelizmente para as equipes de DR, isso nem sempre é fácil. Os planos de continuidade dos negócios e os objetivos de menor tempo de recuperação contam com a proteção contínua de dados.
Armadilha 4 de DR: negligenciando fatores humanos
Os departamentos de TI, naturalmente, concentram seu planejamento de DR em sistemas e dados. Mas os planos eficazes também precisam cobrir onde e como as pessoas trabalharão se o local principal da empresa for comprometido.
Pode ser que os funcionários possam trabalhar em casa inicialmente, mas por quanto tempo eles podem sustentar isso?
Alguns funcionários precisam de computadores desktop ou mais largura de banda do que as conexões domésticas ou móveis podem fornecer? E quanto aos espaços de encontro e ao bem-estar físico e mental da equipe? Manter o moral no caso de um desastre costuma ser tão importante quanto os aspectos técnicos do plano de recuperação.
Armadilha 5 de DR: problemas de comando, controle e comunicação
Em uma situação de recuperação de desastre, linhas de comunicação claras e uma ideia clara de quem está no controle são vitais.
As organizações também precisam decidir quem pode invocar o plano de DR e garantir que toda a equipe principal possa continuar a se comunicar durante uma interrupção. Um teste de DR robusto geralmente expõe quaisquer falhas no comando e controle, e as comunicações de crise devem fazer parte do plano para empresas maiores.
Mas também há uma necessidade de comunicação contínua em torno de DR e continuidade de negócios. Comunicações claras ajudarão a gerenciar as expectativas sobre quais dados e sistemas podem ser recuperados, em que ordem e com que rapidez.
A pior coisa que uma empresa pode fazer é investir em um plano de DR e, em seguida, deixá-lo na prateleira
A recuperação de desastres ou exercícios de continuidade de negócios podem ser perturbadores, mas planos eficazes de DR precisam ser testados, revisados e atualizados. Quase a pior coisa que uma empresa pode fazer é investir em um plano de DR e, em seguida, deixá-lo na prateleira.
É apenas testando que a empresa saberá se o plano funciona e se é suficientemente resiliente para funcionar sob pressão. Simular e testar os sistemas de comunicação é a melhor maneira de expor qualquer fraqueza.
As equipes podem, então, alimentar os insights obtidos na fase de teste de volta à avaliação de risco e à análise de impacto nos negócios, ajustando o plano à medida que avançam.
Para saber mais sobre como a nuvem híbrida pode contribuir para o sucesso do seu negócio, entre em contato com os especialistas da OST.
Sobre a OST
Desde 1995 no mercado, a OST atende com excelência fornecendo soluções de infraestrutura, auxiliando organizações públicas e privadas a garantirem a continuidade de seus negócios.
Somos especializados em otimizar e atender a necessidade do seu negócio. A OST garante a continuidade de suas operações, fornecendo soluções avançadas de infraestrutura para ambientes de missão crítica com inovação, excelência e qualidade no serviço.
