Descrição geral
Esta série fornece um exemplo ilustrativo de como uma organização pode projetar uma estratégia de recuperação de desastres (DR) para uma plataforma de dados corporativos do Azure.
- Esta série de artigos complementa as orientações fornecidas pelo Cloud Adoption Framework da Microsoft, o Azure Well-Architected Framework e o Business Continuity Management
O Azure fornece uma ampla gama de opções de resiliência que podem fornecer continuidade de serviço em caso de desastre. Mas níveis de serviço mais altos podem introduzir complexidade e um custo premium. O trade-off de custo versus resiliência versus complexidade é o principal fator de tomada de decisão para a maioria dos clientes em relação à DR.
Embora falhas pontuais ocasionais aconteçam no serviço do Azure, deve-se observar que os Microsoft Datacenters e os Serviços do Azure têm várias camadas de redundância internas. Qualquer falha é normalmente limitada em escopo e normalmente é recuperada em questão de horas. Historicamente, é muito mais provável que um serviço chave, como o gerenciamento de identidades, tenha um problema de serviço do que uma região inteira do Azure ficar offline.
Deve também reconhecer-se que os ciberataques, em especial os ransomware, representam agora uma ameaça tangível para qualquer ecossistema de dados moderno e podem resultar numa interrupção da plataforma de dados. Embora isso esteja fora do escopo desta série, os clientes são aconselhados a implementar controles contra esses ataques como parte do design de segurança e resiliência de qualquer plataforma de dados.
- As orientações da Microsoft sobre proteção contra ransomware estão disponíveis nos Fundamentos da Nuvem do Azure
Âmbito
O âmbito desta série de artigos inclui:
- A recuperação de serviço de uma plataforma de dados do Azure de um desastre físico para uma persona ilustrativa do cliente. Este cliente ilustrativo é:
- uma organização de médio porte com uma função de suporte operacional definida, seguindo uma metodologia de gerenciamento de serviços baseada em ITIL (Information Technology Infrastructure Library)
- Não nativo da nuvem, com sua empresa principal, os serviços compartilhados, como gerenciamento de acesso e autenticação e gerenciamento de incidentes, permanecem no local
- na jornada de migração da nuvem para o Azure, habilitada pela automação
- A plataforma de dados do Azure implementou os seguintes designs dentro da locação do Azure do cliente
- Enterprise Landing Zone – Fornecendo a base da plataforma, incluindo rede, monitoramento, segurança e assim por diante.
- Azure Analytics Platform - Fornecendo os componentes de dados que suportam as várias soluções e produtos de dados fornecidos pelo serviço
- Esse processo será executado por um recurso técnico do Azure em vez de um especialista no assunto do Azure (SME). Como tal, os recursos devem ter o seguinte nível de conhecimentos/competências
- Fundamentos do Azure – conhecimento prático do Azure, seus serviços principais e componentes de dados
- Conhecimento prático do Azure DevOps. Capaz de navegar pelo controle do código-fonte e executar implantações de pipeline
- Este processo descreve o processo de Failover, da região primária para a secundária
Fora de âmbito
Os seguintes itens são considerados fora do escopo desta série de artigos:
- O processo de fallback, da região secundária de volta para a região primária
- Quaisquer aplicações, componentes ou sistemas que não sejam do Azure – isto inclui, entre outros, no local, outros fornecedores de nuvem, serviços Web de terceiros e assim por diante.
- Recuperação de quaisquer serviços upstream, como redes locais, gateways, serviços compartilhados corporativos e assim por diante. que são pré-requisitos para este processo
- Recuperação de quaisquer serviços downstream, como sistemas operacionais locais, sistemas de relatórios de terceiros, modelagem de dados ou aplicativos de ciência de dados, e assim por diante. que dependem deste processo para recuperar os seus próprios serviços
- Cenários de perda de dados, incluindo recuperação de ransomware ou incidentes de segurança de dados semelhantes
- Estratégias de backup de dados e planos de restauração de dados
- Estabelecendo a causa raiz de um evento DR
- Para incidentes de serviço/componente do Azure, a Microsoft publica uma "Análise de Causa Raiz" na página da Web Status – Histórico
Principais pressupostos
Os principais pressupostos para este exemplo de DR trabalhado são:
- A Organização segue uma metodologia de gerenciamento de serviços baseada em ITIL para suporte operacional da plataforma de dados do Azure
- A Organização tem um processo de recuperação de desastres existente como parte de sua estrutura de restauração de serviços para ativos de TI
- A infraestrutura como código (IaC) foi usada para implantar a plataforma de dados do Azure habilitada por um serviço de automação, como o Azure DevOps ou similar
- Cada solução hospedada pela plataforma de dados do Azure concluiu uma Avaliação de Impacto nos Negócios ou similar, fornecendo requisitos de serviço claros para RPO (Recovery Point Objetive, objetivo de ponto de recuperação), RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e MTO
Próximos passos
Agora que você aprendeu sobre o cenário em um alto nível, você pode passar a aprender sobre a arquitetura projetada para o caso de uso.