Atividades do cliente necessárias
Pré-incidente
Para Serviços do Azure
- Conhecer a Integridade do Serviço do Azure no portal do Azure. Esta página funcionará como o um local centralizado durante um incidente
- Considere o uso de alertas de Integridade do Serviço, que podem ser configurados para gerar notificações automaticamente quando ocorrerem incidentes do Azure
Para o Power BI
- Conhecer a Integridade do Serviço no centro de administração do Microsoft 365. Esta página funcionará como o um local centralizado durante um incidente
- Considere o uso do aplicativo móvel Microsoft 365 Admin para obter notificações automáticas de alerta de incidentes de serviço
Durante o incidente
Para Serviços do Azure
- A Integridade do Serviço do Azure no portal de gerenciamento do Azure fornecerá as atualizações mais recentes
- Se houver problemas ao acessar a Integridade do Serviço, consulte a página Status do Azure
- Se houver problemas para acessar a página Status, acesse o @AzureSupport X (antigo Twitter)
- Se o impacto ou os problemas não corresponderem ao incidente (ou persistirem após a mitigação), entre em contato com o suporte para gerar um tíquete de suporte de serviço
Para o Power BI
- A página Integridade do Serviço no centro de administração do Microsoft 365 fornecerá as atualizações mais recentes
- Se houver problemas ao acessar a Integridade do Serviço, consulte a página Status do Microsoft 365
- Se o impacto ou os problemas não corresponderem ao incidente (ou se os problemas persistirem após a mitigação), você deverá gerar um tíquete de suporte de serviço.
Recuperação pós da Microsoft
Confira a seção abaixo para obter este detalhe.
Pós incidente
Para Serviços do Azure
- A Microsoft publicará um PIR no portal do Azure - Integridade do Serviço para revisão
Para o Power BI
- A Microsoft publicará um PIR no Administrador do Microsoft 365 - Integridade do Serviço para revisão
Aguarde o processo da Microsoft
O processo "Esperar pela Microsoft" é simplesmente esperar que a Microsoft recupere todos os componentes e serviços na região primária afetada. Uma vez recuperado, valide a vinculação da plataforma de dados à empresa compartilhada ou a outros serviços, a data do conjunto de dados e, em seguida, execute os processos de atualização do sistema até a data atual.
Uma vez que esse processo tenha sido concluído, a validação técnica e comercial dos SMEs (especialistas no assunto) pode ser concluída, permitindo a aprovação das partes interessadas para a recuperação do serviço.
Reimplantação em caso de desastre
Para uma estratégia de "Reimplantar em caso de desastre", o seguinte fluxo de processo de alto nível pode ser descrito.
Recuperar Contoso – Serviços Compartilhados Corporativos e sistemas de origem
- Esta etapa é um pré-requisito para a recuperação da plataforma de dados
- Esta etapa é concluída pelos vários grupos de suporte operacional da Contoso responsáveis pelos serviços compartilhados corporativos e sistemas de origem operacionais
Recuperar serviços do Azure Os Serviços do Azure referem-se aos aplicativos e serviços que fazem a oferta de Nuvem do Azure e estão disponíveis na região secundária para implantação.
Os Serviços do Azure referem-se aos aplicativos e serviços que fazem a oferta de Nuvem do Azure e estão disponíveis na região secundária para implantação.
- Esta etapa é um pré-requisito para a recuperação da plataforma de dados
- Essa etapa será concluída pela Microsoft e outros parceiros de PaaS (plataforma como serviço)/SaaS (software como serviço)
Recuperar a base da plataforma de dados
- Esta etapa é o ponto de entrada para as atividades de recuperação da Plataforma
- Para a estratégia de Reimplantação, cada componente/serviço necessário seria adquirido e implantado na região secundária
- Consulte a Seção de Serviços e Componentes do Azure nesta série para obter vários detalhes dos componentes e das estratégias de implantação
- Esse processo também deve incluir atividades como a vinculação aos serviços compartilhados corporativos, garantindo a conectividade com o acesso/autenticação e validando se o descarregamento de log está funcionando, ao mesmo tempo em que garante a conectividade com os processos upstream e downstream
- Os Dados/processamento devem ser confirmados. Por exemplo, validação do carimbo de data/hora da plataforma recuperada
- Se houver dúvidas sobre a integridade dos dados, a decisão pode ser tomada para reverter ainda mais no tempo antes de executar o novo processamento para atualizar a plataforma
- Ter uma ordem de prioridade para os processos (com base no impacto nos negócios) ajudará a orquestrar a recuperação
- Esta etapa deve ser encerrada mediante validação técnica, a menos que os usuários corporativos interajam diretamente com os serviços. Se houver acesso direto, será necessária uma etapa de validação de negócios
- Depois que a validação for concluída, acontece a liberação para as equipes de solução individuais para iniciarem seu próprio processo de recuperação de DR (recuperação de desastre)
- Essa transferência deve incluir a confirmação do carimbo de data/hora atual dos dados/processos
- Se os principais processos de dados corporativos forem executados, as soluções individuais devem ser informadas disso - fluxos de entrada/saída, por exemplo
Recupere as soluções individuais hospedadas pela plataforma
- Cada solução individual deve ter seu próprio runbook de DR. Os runbooks devem conter pelo menos as partes interessadas de negócios nomeadas que testarão e confirmarão que a recuperação do serviço foi concluída
- Dependendo da contenção ou prioridade de recursos, as principais soluções/cargas de trabalho podem ser priorizadas em relação a outras, como processos corporativos principais em vez de laboratórios ad hoc
- Depois que as etapas de validação forem concluídas, acontece a liberação para as soluções downstream para iniciar seu processo de recuperação de DR
Liberação para sistemas dependentes downstream
- Depois que os serviços dependentes forem recuperados, o processo de recuperação de DR do E2E estará concluído
Observação
Embora seja teoricamente possível automatizar completamente um processo de DR E2E, isso é improvável, dado o risco do evento em comparação ao custo das atividades SDLC necessárias para cobrir o processo de E2E
Fallback para a região primária Fallback é o processo de mover o serviço de plataforma de dados e seus dados de volta para a região primária, uma vez que esteja disponível para BAU.
Dependendo da natureza dos sistemas de origem e dos vários processos de dados, o fallback da plataforma de dados pode ser feito independentemente de outras partes do ecossistema de dados.
Os clientes são aconselhados a rever as dependências da sua própria plataforma de dados (upstream e downstream) para tomar a decisão apropriada. A seção a seguir pressupõe uma recuperação independente da plataforma de dados.
- Depois que todos os componentes/serviços necessários estiverem disponíveis na região principal, os clientes concluirão um teste de fumaça para validar a recuperação da Microsoft
- A configuração do Componente/Serviço é validada. Os deltas são resolvidos por meio da reimplantação do controle do código-fonte
- A data do sistema na região primária é estabelecida entre os componentes com estado. O delta entre a data estabelecida e o carimbo de data/hora na região secundária deve ser resolvido executando ou repetindo os processos de ingestão de dados a partir desse ponto
- Com a aprovação dos stakeholders técnicas e de negócios, uma janela de fallback é selecionada. Idealmente, durante uma pausa na atividade e processamento do sistema
- Durante o fallback, a região primária é sincronizada com a região secundária, antes que o sistema seja alternado
- Após um período de execução paralela, a região secundária é desativada do sistema
- Os componentes na região secundária são descartados ou removidos, dependendo da estratégia de DR selecionada
Processo de reposição a morno
Para uma estratégia de "Warm Spare", o fluxo de processo de alto nível está intimamente alinhado ao do "Reimplantar mediante Desastre", a principal diferença é que os componentes já foram adquiridos na região secundária. Essa estratégia elimina o risco de contenção de recursos de outras organizações que desejam concluir seu próprio DR nessa região.
Processo de reposição a quente
A estratégia "Reposição a Quente" significa que os serviços da Plataforma, incluindo sistemas PaaS e IaaS (infraestrutura como serviço), persistirão apesar do evento de desastre, pois os sistemas secundários são executados em conjunto com os sistemas primários. Tal como acontece com a estratégia "Reposição a Morno", esta estratégia elimina o risco de contenção de recursos de outras organizações que procuram concluir o seu próprio DR nessa região.
Os clientes de Reposição a Quente monitoram a recuperação de componentes/serviços da Microsoft na região primária. Depois de concluídos, os clientes validam os sistemas da região primária e concluem o fallback para a região primária. Esse processo seria semelhante ao processo de DR Failover, ou seja, verificar a base de código e os dados disponíveis, reimplantando conforme necessário.
Observação
Uma observação especial aqui deve ser feita para garantir que todos os metadados do sistema sejam consistentes entre as duas regiões.
- Depois que o Fallback para a região primária for concluído, os balanceadores de carga do sistema poderão ser atualizados para trazer a região primária de volta à topologia do sistema. Se disponível, uma abordagem de liberação canária pode ser usada para ativar incrementalmente a região primária do sistema.
Estrutura do plano de DR
Um plano de DR eficaz apresenta um guia passo a passo para recuperação de serviço que pode ser executado por um recurso técnico do Azure. Para isso, a seguir está listada uma estrutura MVP proposta para um Plano de DR.
- Requisitos de processos
- Qualquer detalhe específico do processo de DR do cliente, como a autorização correta necessária para iniciar a recuperação de desastres e tomar decisões importantes sobre a recuperação conforme necessário (incluindo "definição de concluído"), referência de tíquetes de DR de suporte de serviço e detalhes da sala de guerra
- Confirmação de recursos, incluindo o líder de DR e o backup do executor. Todos os recursos devem ser documentados com contatos primários e secundários, caminhos de escalonamento e calendários de saída. Em situações críticas de DR, os sistemas de lista podem precisar ser considerados
- Laptops, pacotes de energia e/ou energia de backup, conectividade de rede e detalhes do telefone celular para o executor de DR, backup de DR e quaisquer pontos de escalonamento
- O processo a ser seguido se algum dos requisitos do processo não for atendido
- Listagem de Contatos
- Liderança de DR e grupos de suporte
- PME empresariais que completarão o ciclo de teste/revisão para a recuperação técnica
- Proprietários de empresas afetados, incluindo os aprovadores de recuperação de serviço
- Proprietários técnicos afetados, incluindo os aprovadores de recuperação técnica
- Suporte às PME em todas as áreas afetadas, incluindo as principais soluções hospedadas pela plataforma
- Sistemas de impacto Downstream – suporte operacional
- Sistemas de origem upstream – suporte operacional
- Contatos de serviços compartilhados corporativos. Por exemplo, suporte a acesso/autenticação, monitoramento de segurança e suporte a gateway
- Quaisquer fornecedores externos ou de terceiros, incluindo contatos de suporte para provedores de nuvem
- Projeto de arquitetura
- Descrever os detalhes do cenário final do E2E e anexar toda a documentação de suporte associada
- Dependências
- Listar todas as relações e dependências do componente
- Pré-requisitos de DR
- Confirmação de que os sistemas de origem upstream estão disponíveis conforme necessário
- O acesso elevado em toda a pilha foi concedido aos recursos do executor de DR
- Os serviços do Azure estão disponíveis conforme necessário
- O processo a ser seguido se algum dos pré-requisitos não tiver sido atendido
- Recuperação técnica - Instruções passo a passo
- Ordem de execução
- Descrição da etapa
- Pré-requisito da etapa
- Etapas detalhadas do processo para cada ação dedicada, incluindo URLs
- Instruções de validação, incluindo as provas necessárias
- Tempo esperado para concluir cada etapa, incluindo contingência
- O processo a ser seguido se a etapa falhar
- Os pontos de escalonamento em caso de falha ou suporte a PMEs
- Recuperação Técnica - Requisitos para pós
- Confirmar o carimbo de data/hora atual do sistema nos principais componentes
- Confirmar as URLs do sistema de DR & os IPs
- Preparar-se para o processo de revisão dos Stakeholder do Negócio, incluindo a confirmação do acesso aos sistemas e as PMEs de negócios concluindo a validação e aprovação
- Revisão e Aprovação de Stakeholder de Negócios
- Detalhes de contato do recurso comercial
- As etapas de validação de negócios de acordo com a recuperação técnica acima
- A trilha de Evidência exigida do Aprovador de Negócios que assina a recuperação
- Requisitos pós recuperação
- Liberação para o suporte operacional para execução dos processos de dados e atualização do sistema
- Entregar os processos e soluções downstream – confirmando a data e os detalhes de conexão do sistema de DR
- Confirmar o processo de recuperação completo com o líder de DR – confirmando a trilha de evidência e o runbook concluído
- Notificar a administração de segurança de que privilégios de acesso elevados podem ser removidos da equipe de DR
Notificações
- Recomenda-se incluir capturas de tela do sistema de cada processo de etapa. Essas capturas de tela ajudarão a resolver a dependência das PMEs do sistema para concluir as tarefas
- Para mitigar o risco da rápida evolução dos serviços de nuvem, o plano de DR deve ser revisitado regularmente, testado e executado por recursos com conhecimento atual do Azure e de seus serviços
- As etapas de recuperação técnica devem refletir a prioridade do componente e da solução para a organização. Por exemplo, os principais fluxos de dados corporativos são recuperados antes de laboratórios de análise de dados ad hoc
- As etapas de recuperação técnica devem seguir a ordem dos fluxos de trabalho (normalmente da esquerda para a direita), uma vez que os componentes/serviços básicos, como o Key Vault, tenham sido recuperados. Essa estratégia garantirá que as dependências a montante estejam disponíveis e que os componentes possam ser testados adequadamente
- Uma vez concluído o plano passo a passo, deve-se obter um tempo total para atividades com contingência. Se esse total for superior ao RTO (objetivo de tempo de recuperação) acordado, há várias opções disponíveis:
- Automatizar os processos de recuperação selecionados (sempre que possível)
- Procurar oportunidades para executar etapas de recuperação selecionadas em paralelo (quando possível). No entanto, observando que essa estratégia pode exigir recursos adicionais do executor de DR.
- Elevar os principais componentes para níveis mais altos de níveis de serviço, como PaaS, onde a Microsoft assume maior responsabilidade pelas atividades de recuperação de serviço
- Estender o RTO com os stakeholders
Teste de DR
A natureza da oferta do Serviço de Nuvem do Azure resulta em restrições para quaisquer cenários de teste de DR. Portanto, a orientação é manter uma assinatura de DR com os componentes da plataforma de dados, pois eles estariam disponíveis na região secundária.
A partir dessa linha de base, o runbook do plano de DR pode ser executado seletivamente, prestando atenção específica aos serviços e componentes que podem ser implantados e validados. Esse processo exigirá um conjunto de dados de teste com curadoria, permitindo a confirmação das verificações de validação técnica e comercial de acordo com o plano.
Um plano de DR deve ser testado regularmente não apenas para garantir que esteja atualizado, mas também para criar "memória muscular" para as equipes que executam atividades de failover e recuperação.
- Os backups de dados e configuração também devem ser testados regularmente para garantir que estejam "adequados à finalidade" para dar suporte a quaisquer atividades de recuperação.
A principal área a ser focalizada durante um teste de DR é garantir que as etapas prescritivas ainda estejam corretas e que os tempos estimados ainda sejam relevantes.
- Se as instruções refletirem as telas do portal em vez de código, as instruções devem ser validadas pelo menos a cada 12 meses devido à cadência de mudança na nuvem.
Embora a aspiração seja ter um processo de DR totalmente automatizado, a automação total pode ser improvável devido à raridade do evento. Portanto, é recomendável estabelecer a linha de base de recuperação com a Desired State Configuration (DSC) infrastructure as code (IaC) usada para entregar a plataforma e, em seguida, aumentar à medida que novos projetos surgirem na linha de base.
- Ao longo do tempo, à medida que os componentes e serviços são estendidos, uma NFR deve ser aplicada, exigindo que o pipeline de implantação de produção seja refatorado para fornecer cobertura para DR.
Se os tempos do runbook excederem o RTO, há várias opções:
- Estender o RTO com os stakeholders
- Diminuir o tempo necessário para as atividades de recuperação, por meio de automação, execução de tarefas em paralelo ou migração para camadas mais altas de servidor em nuvem
Azure Chaos Studio
O Azure Chaos Studio é um serviço gerenciado para melhorar a resiliência injetando falhas em seus aplicativos do Azure. O Chaos Studio permite orquestrar a injeção de falhas em seus recursos do Azure de maneira segura e controlada, usando experimentos. Consulte a documentação do produto para obter uma descrição dos tipos de falhas atualmente suportados.
A iteração atual do Chaos Studio abrange apenas um subconjunto de componentes e serviços do Azure. Até que mais bibliotecas de falhas sejam adicionadas, o Chaos Studio é uma abordagem recomendada para testes de resiliência isolados em vez de testes completos de DR do sistema.
Mais informações sobre o Chaos Studio estão disponíveis aqui.
Azure Site Recovery
Para componentes IaaS, o Azure Site Recovery protegerá a maioria das cargas de trabalho em execução em uma VM ou servidor físico compatível
Há uma forte orientação para:
- Executar um simulador de recuperação de desastres de VM do Azure
- Executar um failover de DR para uma região secundária
- Executar um fallback de DR para a região primária
- Habilitar a automação de um plano de DR
Recursos relacionados
- Criar arquitetura para resiliência e disponibilidade
- Continuidade dos negócios e recuperação de desastres
- Backup e recuperação de desastre para aplicativos do Azure
- Resiliência no Azure
- Resumo dos SLAs (contratos de nível de serviço)
- Cinco práticas recomendadas para antecipar falhas
Próximas etapas
Agora que aprendeu a implantar o cenário, você pode ler um resumo da série de plataformas de dados DR para Azure.