Guia de planejamento de recuperação de desastres

Last reviewed 2023-11-22 UTC

Este documento é a primeira parte de uma série que discute a recuperação de desastres (DR, na sigla em inglês) no Google Cloud. Nesta parte, apresentamos uma visão geral do processo de planejamento de DR: o que é necessário saber para projetar e implantar um plano de DR. As partes subsequentes discutem os casos de uso de DR específicos com implantações de exemplo no Google Cloud.

A série consiste nas partes a seguir:

Introdução

Casos de interrupção de serviço podem acontecer a qualquer momento. Sua rede pode ter uma interrupção, o envio mais recente do aplicativo pode apresentar um bug crítico ou pode ser necessário enfrentar um desastre natural. Quando as coisas dão errado, é importante ter um plano de recuperação de desastres robusto, direcionado e bem testado.

Ao adotar um plano de DR bem-projetado e bem testado, em caso de catástrofe, é possível garantir que o impacto sobre a produção da empresa seja mínimo. Independentemente de qual seja sua necessidade de DR, o Google Cloud tem uma seleção robusta, flexível e econômica de produtos e recursos que pode ser usada para criar ou ampliar a solução certa para você.

Noções básicas de planejamento de DR

A DR é um subconjunto do planejamento de continuidade de negócios. O planejamento de DR começa verificando os negócios com uma análise de impacto, em que são definidas duas métricas principais:

  • Um objetivo do tempo de recuperação (RTO, na sigla em inglês), que é o período máximo aceitável em que o aplicativo pode ficar off-line. Este valor é normalmente definido como parte de um contrato de nível de serviço (SLA, na sigla em inglês) maior.
  • Um objetivo do ponto de recuperação (RPO, na sigla em inglês), que é o período máximo aceitável em que os dados podem ser perdidos pelo aplicativo devido a um grande incidente. Essa métrica varia com base nas maneiras como os dados são usados. Por exemplo, os dados do usuário que são frequentemente modificados podem ter um RPO de apenas alguns minutos. Por outro lado, dados menos críticos e modificados com pouca frequência podem ter um RPO de várias horas. Nessa métrica, apenas é descrito o período de tempo, não é abordada a quantidade ou a qualidade dos dados perdidos.

Normalmente, quanto menores forem os valores de RTO e RPO, ou seja, quanto mais rápido o aplicativo precisar se recuperar de uma interrupção, maior será o custo para que ele seja executado. O gráfico a seguir mostra a proporção de custo para RTO/RPO.

Gráfico mostrando que os pequenos RTO/RPO são associados a alto custo.

Como os valores de RTO e RPO menores geralmente significam maior complexidade, a sobrecarga administrativa associada segue uma curva semelhante. Um aplicativo de alta disponibilidade pode exigir que você gerencie a distribuição entre dois data centers fisicamente separados, gerencie a replicação e muito mais.

Os valores de RTO e RPO normalmente se acumulam em outra métrica: o objetivo de nível de serviço (SLO, na sigla em inglês), que é um elemento chave mensurável de um SLA. SLAs e SLOs geralmente são confundidos. Um SLA é o acordo completo, que especifica qual serviço deve ser provisionado, como ele é suportado, horários, locais, custos, desempenho, penalidades e responsabilidades das partes envolvidas. Os SLOs são características específicas e mensuráveis do SLA, como disponibilidade, taxa de transferência, frequência, tempo de resposta ou qualidade. Um SLA pode conter muitos SLOs. RTOs e RPOs são mensuráveis e devem ser considerados SLOs.

Leia mais sobre SLOs e SLAs no livro Engenharia de confiabilidade de sites do Google.

Talvez você esteja planejando uma arquitetura para alta disponibilidade (HA, na sigla em inglês). O HA não se sobrepõe totalmente ao DR, mas geralmente é necessário considerar o HA quando você está pensando nos valores de RTO e RPO. HA ajuda a garantir um nível acordado de desempenho operacional, geralmente tempo de atividade, por um período maior que o normal. Ao executar cargas de trabalho de produção no Google Cloud, é possível usar um sistema distribuído globalmente para que, caso algo dê errado em uma região, o aplicativo continue a fornecer serviços, mesmo que não esteja tão disponível. Em essência, esse aplicativo invoca seu plano de DR.

Por que usar o Google Cloud?

O Google Cloud pode reduzir significativamente os custos associados ao RTO e ao RPO em comparação com o atendimento dos requisitos de RTO e RPO no local. Por exemplo, o planejamento tradicional de DR exige que você atenda a uma série de requisitos, incluindo:

  • capacidade: aquisição de recursos suficientes para fazer o dimensionamento conforme necessário;
  • segurança: segurança física para proteger os recursos;
  • infraestrutura de rede: componentes de software, como firewalls e balanceadores de carga;
  • suporte: disponibilização de técnicos capacitados para realizar manutenções e solucionar problemas;
  • largura de banda: largura de banda adequada para carga de pico;
  • instalações: infraestrutura física, incluindo equipamentos e energia.

Ao fornecer uma solução altamente gerenciada em uma plataforma de produção de classe mundial, o Google Cloud permite que você ignore a maioria ou todos esses fatores complicadores, eliminando muitos custos comerciais no processo. Além disso, o foco do Google Cloud em simplicidade administrativa significa que os custos de gerenciamento de um aplicativo complexo também são reduzidos.

O Google Cloud oferece vários recursos relevantes para o planejamento de DR, incluindo:

  • Uma rede global. O Google tem uma das maiores e mais avançadas redes de computadores do mundo. A rede de backbone do Google utiliza uma rede avançada, definida por software, e conta com serviços de armazenamento em cache próximo dos usuários finais para oferecer desempenho rápido, consistente e escalonável.
  • Redundância. Vários pontos de presença (PoPs, na sigla em inglês) em todo o mundo significam uma redundância forte. Seus dados são espelhados automaticamente em dispositivos de armazenamento em vários locais.
  • Escalonabilidade. O Google Cloud foi projetado para escalonar como outros produtos do Google, como a pesquisa e o Gmail, mesmo diante de um grande pico de tráfego. Os serviços gerenciados, como o App Engine, os autoescaladores do Compute Engine e o Datastore, oferecem escalonamento automático que permite que seu aplicativo aumente e diminua conforme necessário.
  • Segurança. O modelo de segurança do Google se baseia em mais de 15 anos de experiência, ajudando a manter os clientes seguros em aplicativos do Google, como o Gmail e o espaço de trabalho do Google. Além disso, as equipes de engenharia de confiabilidade do Google ajudam a garantir alta disponibilidade e impedir o abuso de recursos da plataforma.
  • Conformidade. O Google passa regularmente por auditorias independentes realizadas por terceiros para verificar se o Google Cloud está alinhado às normas e práticas recomendadas de segurança, privacidade e conformidade. O Google Cloud está em conformidade com certificações como ISO 27001, SOC 2/3 e PCI DSS 3.0.

Padrões de DR

Os padrões de DR são considerados como frio, morno ou quente. Esses padrões indicam a facilidade com que o sistema pode se recuperar quando algo dá errado. Uma possível analogia poderia ser o que você faria se estivesse dirigindo e furasse um pneu de carro.

Três fotos de cenários de carros com pneus furados: sem estepe; um estepe com ferramentas; um pneu furado.

O que você faria depende da preparação para lidar com um pneu furado:

  • Frio: você não tem pneu sobressalente, então precisará chamar alguém para vir até você com um pneu novo e substituí-lo. Sua viagem é interrompida até que a ajuda chegue para fazer o reparo.
  • Morno: você tem um pneu sobressalente e um kit de substituição para poder voltar à estrada usando o que tem no carro. No entanto, você precisa interromper sua jornada para reparar o problema.
  • Quente: você tem pneus "run-flat". Talvez você precise desacelerar um pouco, mas não há impacto imediato na jornada. Você precisará resolver o problema, mas os pneus funcionam bem o suficiente para que possa continuar, embora precise acabar resolvendo o problema.

Como criar um plano detalhado de DR

Nesta seção, fornecemos recomendações sobre como criar seu plano de DR.

Projetar de acordo com as metas de recuperação

Ao projetar seu plano de DR, você precisa combinar suas técnicas de aplicativo e recuperação de dados e analisar a visão geral. A maneira típica de fazer isso é observar seus valores de RTO e RPO e qual padrão de DR é possível adotar para atender a esses valores. Por exemplo, no caso de dados orientados para conformidade histórica, você provavelmente não precisa de acesso rápido aos dados, portanto, um valor grande de RTO e um padrão de DR frio é apropriado. No entanto, se o serviço on-line sofrer uma interrupção, convém recuperar o mais rápido possível os dados e a parte do aplicativo voltada para o cliente. Nesse caso, um padrão quente seria mais apropriado. Seu sistema de notificação por e-mail, que normalmente não é essencial para os negócios, provavelmente é um candidato a um padrão morno.

Para orientações sobre como usar o Google Cloud para lidar com cenários comuns de DR, consulte os cenários de recuperação de aplicativos. Esses cenários fornecem estratégias específicas de DR para vários casos de uso e oferecem exemplos de implantações no Google Cloud para cada um.

Projetar para recuperação completa

Não basta apenas ter um plano para fazer backup ou arquivar seus dados. Verifique se em seu plano de DR foi abordado o processo de recuperação completo, desde o backup até a restauração e a limpeza. Discutimos isso nos documentos relacionados sobre dados e recuperação de DR.

Tornar as tarefas específicas

Quando é hora de executar seu plano de DR, você não quer ficar preso adivinhando o que as etapas significam. Faça com que as tarefas de seu plano de DR incluam um ou mais comandos ou ações concretas e não ambíguas. Por exemplo, "Executar o script de restauração" é muito geral. Por outro lado, "Abrir Bash e executar /home/example/restore.sh" é preciso e concreto.

Como implementar medidas de controle

Adicione controles para evitar a ocorrência de desastres e detectar problemas antes que eles ocorram. Por exemplo, você tem a opção de adicionar um monitor que envie um alerta quando um fluxo de destruição de dados, como um pipeline de exclusão, mostrar picos inesperados ou outras atividades incomuns. Esse monitor também pode eliminar os processos do canal, se um determinado limite de exclusão for atingido, evitando uma situação catastrófica.

Preparar seu software

Parte do seu planejamento de recuperação de desastres é garantir que o software em que você confia esteja pronto para um evento de recuperação.

Verificar a possibilidade de instalação do software

Certifique-se de que o software do aplicativo possa ser instalado a partir da origem ou de uma imagem pré-configurada. Verifique se você tem a licença adequada para qualquer software que será implantado no Google Cloud. Consulte o fornecedor do software para receber orientação.

Verifique se os recursos necessários do Compute Engine estão disponíveis no ambiente de recuperação. Isso pode exigir pré-alocação ou reserva de instâncias.

Projetar implantação contínua para recuperação

Seu conjunto de ferramentas de implantação contínua (CD) é um componente integral quando você está implantando seus aplicativos. Como parte do seu plano de recuperação, você precisa considerar onde, no ambiente recuperado, você implantará os artefatos. Planeje onde você quer hospedar seu ambiente de CD e artefatos. Eles precisam estar disponíveis e operacionais no caso de um desastre.

Implementar controles de segurança e conformidade

A segurança é importante quando você cria um plano de DR. Os mesmos controles que você tem em seu ambiente de produção precisam se aplicar ao ambiente recuperado. Os regulamentos de conformidade também se aplicam ao ambiente recuperado.

Configurar a segurança da mesma forma usada para os ambientes de DR e produção

Verifique se seus controles de rede fornecem a mesma separação e bloqueio, usados no ambiente de produção. Aprenda a configurar a VPC compartilhada e os firewalls para permitir o estabelecimento de uma rede centralizada e o controle de segurança da sua implantação, configurar sub-redes, controlar o tráfego de entrada e saída e assim por diante. Saiba como usar contas de serviço para implantar privilégios mínimos aos aplicativos que acessam as APIs do Google Cloud. Certifique-se de usar contas de serviço como parte das regras de firewall.

Garanta que seja concedido aos usuários o mesmo acesso ao ambiente de DR que eles têm no ambiente de produção de origem. A lista a seguir descreve maneiras de sincronizar permissões entre ambientes:

  • Caso seu ambiente de produção seja o Google Cloud, a replicação de políticas do IAM no ambiente de DR é simples. É possível usar ferramentas de infraestrutura como código (IaC, na sigla em inglês), como o Terraform, para implantar políticas do IAM à produção. Em seguida, use as mesmas ferramentas para vincular as políticas aos recursos correspondentes no ambiente de DR como parte do processo para manter esse ambiente.

  • Se o ambiente de produção estiver no local, mapeie os papéis funcionais, como o administrador da rede e os papéis de auditor, para as políticas do IAM que tenham os papéis apropriados do IAM. A documentação do IAM tem alguns exemplos de configurações de papéis funcionais. Por exemplo, consulte a documentação sobre como criar papéis funcionais de rede e de geração de registros de auditoria.

  • Você precisa configurar as políticas do IAM para conceder as permissões apropriadas aos produtos. Por exemplo, é possível restringir o acesso a buckets específicos do Cloud Storage.

  • Se o ambiente de produção for outro provedor de nuvem, mapeie as permissões nas políticas de IAM desse provedor para as políticas do Google Cloud IAM.

Verifique sua segurança de DR

Depois de configurar as permissões para o ambiente de recuperação de desastres, verifique se tudo foi testado. Crie um ambiente de teste. Use ferramentas de IaC, como o Terraform, para implantar as políticas do Google Cloud no ambiente de teste. Verifique se as permissões concedidas aos usuários correspondem às permissões concedidas aos usuários no local.

Verifique se os usuários podem acessar o ambiente de DR

Não espere que ocorra um desastre. Verifique antes se os usuários podem acessar o ambiente de recuperação de desastres. Verifique se foram concedidos direitos de acesso apropriados a usuários, desenvolvedores, operadores, cientistas de dados, administradores de segurança, administradores de rede e quaisquer outros papéis na organização. Se você estiver usando um sistema de identidade alternativo, verifique se as contas foram sincronizadas com sua conta do Cloud Identity. Como o ambiente de recuperação de desastres será seu ambiente de produção por um tempo, adote medidas para que os usuários que precisarão acessar esse ambiente façam login e resolvam qualquer problema de autenticação. Incorpore usuários que estejam fazendo login no ambiente de DR como parte dos testes regulares de DR implementados por você.

Para gerenciar de maneira centralizada quem tem acesso SSH às máquinas virtuais (VMs) iniciadas, ative o recurso Login do SO nos projetos do Google Cloud que constituem seu ambiente de DR.

Treine os usuários

Os usuários precisam entender como executar as ações no Google Cloud que estão acostumados a realizar no ambiente de produção, como fazer login, acessar VMs e assim por diante. Use o ambiente de teste para treinar seus usuários a executar essas tarefas visando proteger a segurança do seu sistema.

Certifique-se de que o ambiente de DR atende aos requisitos de conformidade

Verifique se o acesso a seu ambiente de DR está restrito somente àqueles que precisam de acesso. Verifique se os dados de PII estão editados e criptografados. Se você realizar testes de penetração regulares no ambiente de produção, deverá incluir seu ambiente de DR como parte desse escopo e realizar testes regulares com a permanência em um ambiente de DR.

Verifique se, enquanto seu ambiente de DR estiver em serviço, todos os registros coletados serão preenchidos no arquivo de registros do ambiente de produção. Da mesma forma, verifique se, como parte do ambiente de DR, é possível exportar registros de auditoria coletados por meio do Cloud Logging para o arquivo principal do coletor de registros. Use as facilidades do coletor de exportação. Para registros de aplicativos, crie um espelho do ambiente de monitoramento e geração de registros no local. Se o ambiente de produção for outro provedor de nuvem, mapeie a geração de registro e o monitoramento desse provedor para os serviços equivalentes do Google Cloud. Tenha um processo para formatar a entrada no ambiente de produção.

Use o Cloud Storage como parte das rotinas diárias de backup

Usar o Cloud Storage para armazenar backups. Verifique se os buckets em que estão seus backups têm as permissões apropriadas aplicadas a eles.

Gerencie secrets adequadamente

Gerencie chaves e secrets no nível do aplicativo usando o Google Cloud para hospedar o KMS (serviço de gerenciamento de secrets/chave). Use o Cloud KMS ou uma solução de terceiros como o HashiCorp Vault com um back-end do Google Cloud, como o Spanner ou o Cloud Storage.

Trate dados recuperados como dados de produção

Verifique se os controles de segurança aplicados aos dados de produção também se aplicam aos dados recuperados: as mesmas permissões, criptografia e requisitos de auditoria devem se aplicar.

Saiba onde seus backups estão localizados e quem está autorizado a restaurar os dados. Verifique se o processo de recuperação é auditável após uma recuperação de desastre, veja quem teve acesso aos dados de backup e quem executou a recuperação.

Verificar se o plano de DR funciona

Verifique se o plano de DR funciona conforme o esperado, caso ocorra um desastre.

Manter mais de um caminho de recuperação de dados

No caso de um desastre, seu método de conexão com o Google Cloud pode ficar indisponível. Implemente um meio alternativo de acesso ao Google Cloud para ajudar a garantir a transferência de dados para o Google Cloud. Teste regularmente se o caminho de backup está funcionando.

Teste o plano regularmente

Depois de criar um plano de DR, teste-o regularmente, observando os problemas que surgirem e ajustando seu plano adequadamente. Usando o Google Cloud, é possível testar cenários de recuperação a um custo mínimo. Recomendamos que você faça as seguintes implementações para ajudar nos testes:

  • Automatize o provisionamento da infraestrutura. É possível usar ferramentas de IaC, como o Terraform, para automatizar o provisionamento de instâncias de VM e outra infraestrutura do Google Cloud. Se você estiver executando o ambiente de produção no local, certifique-se de que há um processo de monitoramento que pode iniciar o processo de DR ao detectar uma falha e acionar as ações de recuperação adequadas.
  • Monitore e depure seus testes com o Cloud Logging e o Cloud Monitoring. O Google Cloud tem excelentes ferramentas de geração de registros e monitoramento que podem ser acessadas por chamadas de API, permitindo automatizar a implantação de cenários de recuperação reagindo às métricas. Ao elaborar testes, verifique se você tem monitoramento e alertas adequados que possam acionar ações de recuperação apropriadas.

  • Executar o teste anotado anteriormente:

    • Teste o funcionamento das permissões e do acesso do usuário no ambiente DR, como fazem no ambiente de produção.
    • Realize testes de penetração no ambiente DR.
    • Realize um teste em que o caminho de acesso habitual ao Google Cloud não funcione.

A seguir