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 na plataforma Azure, os datacenters do Azure e os serviços do Azure da Microsoft têm várias camadas de redundância internas. Qualquer falha é normalmente limitada em escopo e normalmente é remediada 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 ficando 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, serviços compartilhados, como gerenciamento de acesso e autenticação e gerenciamento de incidentes, permanecendo no local.
- Na jornada de migração para a 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:
- Zona de aterrissagem corporativa – Fornecendo a base da plataforma, incluindo rede, monitoramento, segurança e assim por diante.
- Plataforma de análise do Azure - Fornece os componentes de dados que suportam as várias soluções e produtos de dados fornecidos pelo serviço.
- Os processos descritos neste artigo serão executados por um recurso técnico do Azure em vez de um especialista 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.
- Esses processos descritos neste artigo abrangem operações de failover de serviço, da região primária à 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 outros, independentemente de quaisquer dependências desses serviços.
- 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 outros, independentemente de quaisquer dependências desses 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 métricas de RPO (Recovery Point Objetive, objetivo de ponto de recuperação), RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e MTTR.
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.