Gerenciamento de continuidade de negócios no Azure
O Azure mantém um dos programas de gerenciamento de continuidade de negócios mais maduros e respeitados no setor. A meta da continuidade dos negócios no Azure é criar e aprimorar a capacidade de recuperação e resiliência para todos os serviços independentemente recuperáveis, seja um serviço voltado para o cliente (parte de uma oferta do Azure) ou um serviço de plataforma de suporte interno.
Ao compreender a continuidade dos negócios, é importante observar que muitas ofertas são compostas de vários serviços. No Azure, cada serviço é identificado estaticamente por meio de ferramentas e é a unidade de medida usada para privacidade, segurança, inventário, risco de gerenciamento de continuidade de negócios e outras funções. Para medir adequadamente os recursos de um serviço, os três elementos de pessoas, processos e tecnologias são incluídos para cada serviço, seja qual for o tipo de serviço.
Por exemplo:
- Se houver um processo comercial com base em pessoas, como um suporte técnico ou equipe, a prestação do serviço será o que elas fazem. As pessoas usam processos e tecnologia para executar o serviço.
- Se houver tecnologia como um serviço, como máquinas virtuais do Azure, a entrega de serviço será a tecnologia junto com as pessoas e os processos que dão suporte à sua operação.
Modelo de responsabilidade compartilhada
Muitas das ofertas que o Azure fornece exigem que você configure a recuperação de desastre em várias regiões e não são de responsabilidade da Microsoft. Nem todos os serviços do Azure replicam dados automaticamente ou retornam automaticamente de uma região com falha para replicação cruzada para outra região habilitada. Nesses casos, você é responsável por configurar a recuperação e a replicação.
A Microsoft garante que a infraestrutura e os serviços de plataforma de linha de base estejam disponíveis. Mas, em alguns cenários, o uso exige que você duplique suas implantações e armazenamento em uma capacidade de várias regiões, se preferir. Esses exemplos ilustram o modelo de responsabilidade compartilhada. É um pilar fundamental em sua estratégia de continuidade dos negócios e recuperação de desastres.
Divisão de responsabilidade
Em qualquer datacenter local, você detém a pilha inteira. À medida que você move ativos para a nuvem, algumas responsabilidades são transferidas para a Microsoft. O diagrama a seguir ilustra as áreas e a divisão de responsabilidade entre você e a Microsoft de acordo com o tipo de implantação.
Um bom exemplo do modelo de responsabilidade compartilhada é a implantação de máquinas virtuais. Se você quiser configurar a replicação entre regiões para resiliência se houver falha na região, deverá implantar um conjunto duplicado de máquinas virtuais em uma região habilitada alternativa. O Azure não replicará esses serviços automaticamente se houver uma falha. É sua responsabilidade implantar os ativos necessários. Você deve ter um processo para alterar manualmente as regiões primárias ou usar um gerenciador de tráfego para detectar e fazer failover automaticamente.
Os serviços de recuperação de desastre habilitados para o cliente têm documentação voltada para o público para orientá-lo. Para obter um exemplo de documentação voltada para o público para recuperação de desastre habilitada para o cliente, confira o Azure Data Lake Analytics.
Para obter mais informações, consulte Responsabilidade compartilhada pela resiliência.
Conformidade de continuidade de negócios: responsabilidade no nível de serviço
Cada serviço deve concluir os registros de recuperação de desastre de continuidade de negócios na ferramenta do Gerenciador de Continuidade de Negócios do Azure. Os proprietários de serviço podem usar a ferramenta para trabalhar em um modelo federado para concluir e incorporar requisitos que incluem:
Propriedades do serviço: define o serviço e como a recuperação de desastres e a resiliência são obtidas e identifica a parte responsável pela recuperação de desastres (para tecnologia). Para obter detalhes sobre a propriedade de recuperação, confira a discussão sobre o modelo de responsabilidade compartilhada na seção e no diagrama anteriores.
Análise de impacto nos negócios: essa análise ajuda o proprietário do serviço a definir o RTO (objetivo de tempo de recuperação) e o RPO (objetivo de ponto de recuperação) com base na importância do serviço em uma tabela de impactos. Os impactos operacionais, legais, regulatórios, de imagem da marca e financeiros são usados como metas de destino para a recuperação.
Observação
A Microsoft não publica RTOs ou RPOs para serviços porque esses dados são apenas para medidas internas. Todas as promessas e medidas do cliente são baseadas em SLA, pois abrangem uma faixa maior versus RTO ou RPO, que é aplicável somente em perdas catastróficas.
Dependências: cada serviço mapeia as dependências (outros serviços) de que ele precisa para operar, independentemente de quão críticas, e é mapeado para runtime, necessário apenas para recuperação ou ambos. Se houver dependências de armazenamento, outros dados serão mapeados, o que definirá o que é armazenado e se precisa de instantâneos de ponto no tempo, por exemplo.
Trabalhadores: conforme observado na definição de um serviço, é importante saber o local e a quantidade de trabalhadores para dar suporte ao serviço, garantindo que não haja pontos únicos de falha e, se funcionários críticos estiverem dispersos, evitar falhas por coabitação em um só lugar.
Fornecedores externos: a Microsoft mantém uma lista abrangente de fornecedores externos, e os fornecedores considerados críticos são medidos para as funcionalidades. Se identificados por um serviço como uma dependência, os recursos do fornecedor serão comparados às necessidades do serviço para garantir que uma interrupção de terceiros não interrompa os serviços do Azure.
Classificação de recuperação: essa classificação é exclusiva do programa de gerenciamento de continuidade de negócios do Azure. Essa classificação mede vários elementos principais para criar uma pontuação de resiliência:
- Disposição para fazer failover: embora possa haver um processo, talvez não seja a primeira opção para interrupções de curto prazo.
- Automação do failover.
- Automação da decisão de failover.
O tempo mais curto e mais confiável para failover é um serviço automatizado que não requer nenhuma decisão humana. Um serviço automatizado usa o monitoramento de pulsação ou transações sintéticas para determinar se um serviço está inoperante e iniciar a correção imediata.
Plano e teste de recuperação: o Azure exige que cada serviço tenha um plano de recuperação detalhado e teste esse plano como se o serviço falhasse devido a uma interrupção catastrófica. Os planos de recuperação devem ser escritos para que alguém com habilidades e acesso semelhantes possa concluir as tarefas. Um plano escrito evita depender de especialistas no assunto estarem disponíveis.
O teste é feito de várias maneiras, incluindo autoteste em um ambiente de produção ou quase produção e como parte do detalhamento da região completa do Azure em conjuntos de região de canário. Essas regiões habilitadas são idênticas às regiões de produção, mas podem ser desabilitadas sem afetar seus serviços. O teste é considerado integrado porque todos os serviços são afetados simultaneamente.
Habilitação do cliente: quando você é responsável por configurar a recuperação de desastre, o Azure é obrigado a ter diretrizes de documentação voltadas para o público. Para todos esses serviços, são fornecidos links para a documentação e detalhes sobre o processo.
Verifique a conformidade da continuidade de negócios
Quando um serviço tiver concluído seu registro de gerenciamento de continuidade de negócios, você deverá enviá-lo para aprovação. Ele é atribuído a um profissional experiente de gerenciamento de continuidade de negócios que revisa todo o registro para fins de integridade e qualidade. Se o registro atender a todos os requisitos, ele será aprovado. Caso contrário, será rejeitado com uma solicitação de retrabalho. Esse processo garante que ambas as partes concordem que a conformidade da continuidade dos negócios foi atendida e que o trabalho é atestado apenas pelo proprietário do serviço. As equipes de conformidade e auditoria interna do Azure também fazem amostragem aleatória periódica para garantir o envio dos melhores dados.
Teste de serviços
A Microsoft e o Azure realizam amplos testes para a recuperação de desastres e para a prontidão da zona de disponibilidade. Os serviços são testados automaticamente em um ambiente de produção ou de pré-produção para demonstrar a capacidade de recuperação independente para serviços que não dependem de failovers de plataforma principais.
Para garantir que os serviços possam ser recuperados de maneira semelhante em um cenário de região inválida, o teste do tipo “pull-the-plug” é feito em ambientes canário que são regiões totalmente implantadas que correspondem à produção. Por exemplo, os clusters, os racks e as unidades de energia são literalmente desligados para simular uma falha total da região.
Durante esses testes, o Azure usa o mesmo processo de produção para detecção, notificação, resposta e recuperação. Nenhum indivíduo está esperando uma análise, e os engenheiros necessários para a recuperação são os recursos normais de escala em sobreaviso. Essa organização de tempo evita depender de especialistas no assunto, que podem não estar disponíveis durante um evento real.
Incluídos nesses testes estão os serviços em que você é responsável por configurar a recuperação de desastres seguindo a documentação voltada para o público da Microsoft. As equipes de serviço criam instâncias do tipo cliente para mostrar que a recuperação de desastre habilitada para o cliente funciona conforme o esperado e que as instruções fornecidas são precisas.
Para obter mais informações sobre certificações, confira a Central de Confiabilidade da Microsoft e a seção sobre conformidade.