Descrição Geral
Esta série fornece um exemplo ilustrativo de como uma organização pode conceber uma estratégia de recuperação após desastre (DR) para uma plataforma de Dados empresariais do Azure.
- Esta série de artigos complementa as orientações fornecidas pelo Cloud Adoption Framework da Microsoft, o Well-Architected Framework e a Business Continuity Management do Azure
O Azure fornece uma ampla gama de opções de resiliência que podem proporcionar continuidade de serviço em caso de desastre. No entanto, níveis de serviço mais elevados podem introduzir complexidade e um custo premium. A compensação do custo versus resiliência versus complexidade é o principal fator de tomada de decisão para a maioria dos clientes em relação à DR.
Embora ocorram falhas de pontos ocasionais em todo o serviço do Azure, deve observar-se que os Data Centers da Microsoft e os Serviços do Azure têm várias camadas de redundância incorporadas. Normalmente, qualquer falha é limitada no âmbito e é normalmente recuperada numa questão de horas. Historicamente, é muito mais provável que um serviço chave, como a gestão de identidades, tenha um problema de serviço em vez de toda uma região do Azure ficar offline.
Também deve ser reconhecido que os ciberataques, particularmente o ransomware, representam agora uma ameaça tangível para qualquer ecossistema de dados moderno e podem resultar numa falha na plataforma de dados. Embora isto esteja fora do âmbito desta série, os clientes são aconselhados a implementar controlos contra ataques como parte da estrutura de segurança e resiliência de qualquer plataforma de dados.
- A documentação de orientação da Microsoft sobre proteção contra ransomware está disponível no Cloud Fundamentals do Azure
Âmbito
O âmbito desta série de artigos inclui:
- A recuperação do 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 média-grande com uma função de suporte operacional definida, seguindo uma metodologia de gestão de serviços baseada em ITIL
- não nativo da cloud, com a sua empresa principal, os serviços partilhados como a gestão de acesso e autenticação e a gestão de incidentes permanecem no local
- no percurso da migração da cloud para o Azure, ativado pela automatização
- A plataforma de dados do Azure implementou os seguintes designs no inquilino do Azure do cliente
- Zona de Destino Empresarial – fornecer a base da plataforma, incluindo redes, monitorização, segurança, etc.
- Plataforma do Azure Analytics – Fornecer os componentes de dados que suportam as várias soluções e produtos de dados fornecidos pelo serviço
- Este processo será executado por um recurso técnico do Azure em vez de um SME do Azure especializado. Como tal, os recursos devem ter o seguinte nível de conhecimento/competências
- Noções Básicas do Azure – conhecimentos de trabalho do Azure, dos seus principais serviços e componentes de dados
- Conhecimentos de trabalho do Azure DevOps. Capaz de navegar no controlo de origem e executar implementações de pipelines
- Este processo descreve o processo de Ativação Pós-falha, da região primária para a região secundária
Fora do âmbito
Os seguintes itens são considerados fora do âmbito desta série de artigos:
- O processo de Contingência, desde a região secundária até à região primária
- Quaisquer aplicações, componentes ou sistemas não Azure– isto inclui, mas não se limita ao local, a outros fornecedores da cloud, serviços Web de terceiros, etc.
- Recuperação de quaisquer serviços a montante, tais como redes no local, gateways, serviços partilhados empresariais, etc., que são pré-requisitos para este processo
- Recuperação de quaisquer serviços a jusante, tais como sistemas operacionais no local, sistemas de relatórios de terceiros, modelação de dados ou aplicações de ciência de dados, etc., 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 Cópia de Segurança de Dados e planos de restauro 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 da Causa Raiz" na página Web Estado – Histórico
Pressupostos-chave
As principais suposições para este exemplo de dr.dr. são
- A Organização segue uma metodologia de gestão de serviços baseada em ITIL para suporte operacional da plataforma de dados do Azure
- A Organização tem um processo de recuperação após desastre existente como parte do respetivo framework de restauro de serviços para recursos de TI
- A "Infraestrutura como Código" (IaC) foi utilizada para implementar a plataforma de dados do Azure ativada por um serviço de automatização, como o Azure DevOps ou semelhante
- Cada solução alojada pela plataforma de dados do Azure concluiu uma Avaliação de Impacto empresarial ou semelhante, fornecendo requisitos de serviço claros para RPO, RTO e MTO
Passos seguintes
Agora que aprendeu sobre o cenário a um nível elevado, pode avançar para saber mais sobre a arquitetura concebida para o caso de utilização.