Visão geral
Esta série fornece um exemplo ilustrativo de como uma organização pode criar uma estratégia de DR (recuperação de desastre) para uma plataforma de dados corporativos do Azure.
- Esta série de artigos complementa as diretrizes 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 prêmio de custo. A compensação 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 ocorram na plataforma do Azure, os datacenters do Azure da Microsoft e os serviços do Azure têm várias camadas de redundância internas. Qualquer falha normalmente é limitada em escopo e normalmente é corrigida em questão de horas. Historicamente, é muito mais provável que um serviço importante, como o gerenciamento de identidades, tenha um problema de serviço em vez de uma região inteira do Azure ficar offline.
Também deve ser reconhecido que os ataques cibernéticos, particularmente o ransomware, agora representam uma ameaça tangível para qualquer ecossistema de dados moderno e podem resultar em uma 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
Escopo
O escopo 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 e grande porte com uma função de suporte operacional definida, seguindo uma metodologia de gerenciamento de serviços baseada em Information Technology Infrastructure Library (ITIL).
- 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 da nuvem para o Azure, habilitada pela automação.
- A plataforma de dados do Azure implementou os seguintes designs na locação do Azure do cliente:
- Zona de destino corporativa – Fornecer a base da plataforma, incluindo rede, monitoramento, segurança e assim por diante.
- Plataforma de análise do Azure – fornecendo os componentes de dados que dão suporte às 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 em SME (especialista no assunto) do Azure. Como tal, os recursos devem ter o seguinte nível de conhecimentos/habilidades:
- Conceitos básicos do Azure – conhecimento prático do Azure, seus principais serviços e componentes de dados.
- Conhecimento prático de Azure DevOps. Capaz de navegar no 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 para a secundária.
Fora do escopo
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 aplicativos, componentes ou sistemas que não sejam do Azure – isso inclui, entre outros, locais, 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, aplicativos de modelagem de dados ou 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
- Estabelecer a causa raiz de um evento de 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 suposições
As principais suposições para este exemplo trabalhado de DR 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 IaC (infraestrutura como código) 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 (objetivo de ponto de recuperação), RTO (objetivo de tempo de recuperação) e MTTR (tempo médio de recuperação).
Próximas etapas
Agora que você aprendeu sobre o cenário em um alto nível, você pode seguir em frente para aprender sobre a arquitetura projetada para o caso de uso.