20 passos para o planejamento de uma Recuperação de Desastre

Obs.: Tradução livre do texto “20 Things to Plan for an IT Disaster Recovery“

1. Novo datacenter principal: Antes de planejar um datacenter secundário (remoto), você deve certificar se todos os componentes em seu datacenter primário são altamente redundante. Seu foco deve ser em projetar um datacenter primário tão resistente quanto possível, que você consiga se recuperar rapidamente da maioria dos desastres (exceto desastres naturais) sem ter que usar sempre o datacenter secundário. Por exemplo, ter um banco de dados standby no mesmo datacenter do seu banco de dados de produção, configurar placas de rede e placas HBA dupla em todos os servidores de produção, configurar servidores de web múltiplos com balanceamento de carga, conectar o servidor em dois circuitos de energia usando fontes redundantes, etc;
2. Datacenter secundário (remoto): Se você implementar um novo datacenter primário, o objetivo de um datacenter remoto é principalmente para as catástrofes naturais como terremotos, incêndios, inundações, etc. Embora isso possa ser muito óbvio, vale dizer, já que eu já vi algumas empresas fazerem isso, que tem tanto datacenter primário quanto o secundário na mesma cidade, o que compromete o propósito da Recuperação de Desastre;
3. Replicar componentes de produção no datacenter secundário: Você não precisa replicar todo o hardware e aplicativos de datacenter primário para o secundário. Um administrador de sistemas, técnicos ou qualquer pessoa pode rapidamente identificar todo o hardware e software crítico que precisa ser replicado no site remoto, mas você pode precisar de ajuda de outros departamentos para identificar as aplicações que são críticas para o negócio. Você tem de mapear as funções críticas de negócios em função dos componentes da infraestrutura de TI, se certificando que realmente todos os componentes de infraestrutura juntamento com a aplicação e os dados foram replicados para o site remoto;
4. Plano de armazenamento – Storage: Se você tiver algum tipo de storage SAN (ou storage NAS) que suporta a aplicação crítica no datacenter primário, você precisa ter um solução similar em seu site remoto também. Por motivos de desempenho, os servidores no datacenter remoto devem ter as mesmas características dos servidores de produção do datacenter primário. No entanto, para o storage, se você tiver um storage SAN high-end de um grande fornecedor no site principal, pode-se considerar o uso de um storage SAN high-end de um fornecedor de pequeno porte, que pode custar-lhe muito menos, com configuração e desempenho semelhante;
5. Replicar dados para o site remoto da base em uso: Sincronizar os dados entre o datacenter primário e o remoto é um aspecto crítico de uma implementação bem sucedida de Recuperação de Desastre. Uma vez que você listou todas as aplicações que precisam ser replicadas para o site remoto, você agora precisa descobrir como sincronizar os dados entre estes dois locais para todas essas aplicações. Por exemplo, você pode replicar o banco de dados Oracle usando as tecnologias de replicação fornecidas pelo fabricante do storage ou você pode usar o dataguard para replicar estes dados. Ambas soluções tem suas vantagens e desvantagens e você tem que analisá-las cuidadosamente e escolher aquela que se encaixa no seu orçamento e escopo do plano de Recuperação de Desastre;
6. Replicar os dados iniciais usando um método manual: Quando você estiver configurando o site remoto pela primeia vez, você tem que decidir como será a sincronização inicial dos dados. Por exemplo, se você for replicar um banco de dados de tamanho enorme, você não pode copiar o backup do banco de dados através da rede para o site remoto, pois irá utilizar toda banda de rede. Em vez disso, você poderia realizar um backup em fita no datacenter primário e usá-lo no datacenter secundário para configurar o banco de dados. Uma vez que a configuração inicial é feito, você pode implementar alguma forma de sincronização automática entre os sites;
7. Tempo de Recuperação – Recovery Time Objective: Você deve identificar, junto com os gerentes de negócio, qual o Tempo de Recuperação aceitável. Por exemplo, sua organização pode decidir que o Tempo de Recuperação deve ser de 8 horas, ou seja, após um desastre, no prazo máximo de 8 horas todas as aplicações críticas devem estar plenamente operacionais no site remoto. O Tempo de Recuperação tem um impacto direto sobre quanto valor deve ser gasto na implementação da solução de Recuperação de Desastre. Por exemplo, um Tempo de Recuperação de uma hora pode exigir uma solução mais sofisticada que será muito mais cara do que uma solução com o Tempo de Recuperação de 24 horas;
8. Ponto de Recuperação – Recovery Point Objective: Assim como Tempo de Recuperação, você deve decidir, junto com os gerentes de negócios, um Ponto de Recuperação aceitável. Por exemplo, sua organização pode decidir que o Ponto de Recuperação aceitável é de 2 horas, ou seja, depois de um desastre, quando você recuperou o serviço no datacenter remoto, 2 horas de perda de dados é aceitável para o negócio. Por exemplo, se o desastre aconteceu às 15:00h, depois de restaurar o sistema no site remoto, este irá conter dados de produção somente a partir das 13:00h. O que significa que você perdeu os dados desde às 13:00 até às 15:00h. Em termos simples, se seu Ponto de Recuperação é de 2 horas, a sua empresa deve estar disposto a perder 2 horas de dados durante um desastre;
9. Failover – Transferência em caso de falha – automático ou manual? Você tem decidir se você quer que o failover ocorra automaticamente ou manualmente após um desastre. Na maioria dos casos, uma intervenção manual é aceitável, pois você não quer uma transferência automática para o datacenter remoto em caso de um falso-positivo. Tenha em mente que, depois de um failover, há muito trabalho para voltar para o datacenter principal;
10. Failover da rede: Tenho visto que os planos de Recuperação de Desastres dão muito foco para replicação de dados, mas menos foco para os aspectos da rede. Junto com sua equipe de rede, é preciso identificar todas as infraestruturas de rede que precisam ser replicadas. Por exemplo, se certificar de que os endereços de produção (URL) estão apontando para o site remoto após o failover. Se você tiver estabelecido conexões VPN com seus clientes, identificar como restabelecer estas conexões VPN. Quando você criar/modificar as regras de firewall (ou qualquer coisa relacionada a segurança) no datacenter principal, você precisa identificar como estas políticas de segurança podem ser replicadas para o site remoto de forma contínua;
11. Configuração no lado remoto: Você precisa ter um plano adequado para acessar o datacenter remoto para depurar todos os problemas. Você pode configurar um KVM no site remoto para acessar o console do hardware remoto do seu escritório. Ou, você precisa planejar algum tipo de manual de serviços no lado remoto, onde alguém pode ir para o datacenter de contingência e executar suas instruções;
12. Testes anuais de Recuperação de Desastre: Várias organizações gastam muito tempo e dinheiro na criação de um site de contingência apenas para descobrir que ele realmente não funciona como esperado quando se está em uma situação real de Recuperação de Desastre. Uma vez por ano, você deve validar suas configurações atuais para garantir que o site remoto funciona corretamente e cumpre o objetivo original. Se tudo estiver configurado corretamente, você deve ser capaz de transferir manualmente suas aplicações críticas do datacenter principal para o remoto, e deixá-las funcionando por alguns dias. Isso também ajuda a ver como o site remoto lida com uma situação com carga em tempo real;
13. Datacenter remoto como uma plataforma de Garantia de Qualidade – Quality Assurance: Em vez de usar o site remoto só para a situação de desastre, você pode usá-lo como uma plataforma de Garantia de Qualidade, fazendo testes de carga e desempenho de seus aplicativos. Isso pode ser útil, pois você não precisa investir em infraestrutura de testes adicional no datacenter primário. Quando você tomar essa atitude, você estará sincronizando os dados do site primário para o site remoto de forma contínua. No entanto, sempre que você fizer um teste de carga, você precisa implementar uma solução adicional, onde você precisa marcar um ponto de verificação do estado atual do site remoto, realizar seu teste de qualidade, e logo em seguida voltar a situação anterior para continuar a sincronização dos dados com o site primário;
14. Plano de resposta: Uma vez que você implementou o site remoto, você precisa ter um plano de Recuperação de Desastre sobre como você e sua equipe devem agir em uma situação real. Colaborar com vários departamentos em sua organização, identificando os recursos chaves que farão parte da equipe de resposta a incidentes e identificar o seu papel específico no plano de resposta. O plano de resposta a incidentes é um simples passo-a-passo sobre o que precisa ser feito quando há uma desastre, quem irá realizar as tarefas e em que sequência as tarefas serão executadas;
15. Não tem um site de contigência? Muitas organizações não têm um site remoto. Se você está trabalhando para um delas e você é responsável pelas aplicações críticas e infraestrutura de TI, é de sua responsabilidade elaborar um plano de Recuperação de Desastre, orientar a sua gerência sobre a importância de gastar tempo e dinheiro em Recuperação de Desastre e obter a sua aprovação. Mostre três diferentes planos, um que custa muito, outro de custo razoável e um com custo pequeno. Como explicado anteriormente, o plano de Recuperação de Desastre pode variar dependendo de vários fatores, onde o custo é um deles. Depois de ter apresentado o seu plano detalhado para a sua gerência, e se este plano não foi aprovado, pelo menos você vai se sentir bem, já que deu o seu melhor na preparação de um bom plano;
16. Quando declarar um desastre? Você precisa identificar claramente isso o quanto antes. Você precisa ter um critério muito claro, escrito, sobre quando você vai mudar para o site remoto. Quais os critérios que desencadeiam a transferência? Quando você inicia uma Recuperação de Desastre? Em que ponto você declarar um desastre e começar a trabalhar na transferência para o site remoto? A resposta para estas questões devem ser claramente definidas e revisadas por todos os departamentos em sua organização, e finalmente, esses critérios devem ser aprovados pela alta administração. Quando o ambiente de produção fica “fora do ar”, porque alguém excluiu algum arquivo por engano, este evento pode ou não desencadear um desastre. Para algumas empresas, a recuperação dos dados do backup no próprio datacenter principal provavelmente será a melhor solução. Para outras, que não podem esperar esta restauração do backup, é necessário mudar para o site remoto;
17. Backup, backup e backup: Backups são muito importantes em um plano de Recuperação de Desastre. Como mencionamos anteriormente, seu objetivo deve ser nunca usar o site remoto, a menos que um desastre natural real aconteça. Assim, uma forte estratégia de backup em seu site principal é muito crítico. Você deve fazer backup de todos os seus aplicativos críticos. Quando fizer o backup de seu banco de dados, deve armazenar este backup em quatro locais. Backups são praticamente inúteis se você não restaurá-los em um servidor de teste para confirmar que estão funcionando corretamente;
18. Aplicação de patches: Quando você aplica uma correção de sistema operacional, atualização de firmware ou realiza qualquer tipo de gerenciamento de configuração do hardware no site principal, você precisa ter uma estratégia para fazer estas mudanças no site remoto de forma contínua. Você não quer uma situação, onde a configuração do sistema operacional em seu site principal é diferente do site remoto;
19. O sucesso depende de muitos fatores: Gestão a partir do topo, alocação adequada do orçamento, envolvimento de todas as divisões de negócios, um forte plano de Recuperação de Desastre, recursos técnicos, teste total da solução de desastre, etc. Mais importante, um escopo bem definido de Recuperação de Desastre alinhado com o objetivo de negócio é o mais importante para uma solução de sucesso;
20. Documentação: Um planejamento de Recuperação de Desastre adequado requer vários processos estabelecidos. Todos estes processos devem ser documentados de forma adequada. Por exemplo, um documento que explica o processo de escalonamento quando um desastre ocorre. A documentação técnica que explica o que precisa ser feito para fazer a transferência em caso de falha para o site remoto. Um documento de comunicação que listas todos os membros da equipe envolvidos na Recuperação de Desastre, suas responsabilidades e como eles podem ser contatados durante o desastre. Um documento para a equipe de suporte ao cliente, para saber o que precisa ser comunicado ao cliente e como encontrar os clientes durante um desastre. Um documento que lista todos os testes que uma equipe de qualidade precisa realizar depois que o site remoto foi ativado, etc.

O que foi apresentado é apenas uma pequena parcela do que é Recuperação de Desastre. Há muito mais, além dos  itens acima. Se você é um administrador de sistema ou alguém que é responsável pelas aplicações de TI e infraestrutura e se não tiver um plano de desastre, considere isto como um lembrete para começar sua estratégia de Recuperação de Desastre.