Gestão da continuidade do negócio em Azure
A Azure mantém um dos programas de gestão de continuidade de negócios mais maduros e respeitados do setor. O objetivo da continuidade do negócio em Azure é construir e promover a recuperabilidade e a resiliência para todos os serviços independentemente recuperáveis, quer um serviço seja virado para o cliente (parte de uma oferta Azure) ou um serviço de plataforma de apoio interno.
Ao compreender a continuidade do negócio, é importante notar que muitas ofertas são compostas por múltiplos serviços. Na Azure, cada serviço é identificado estáticamente através de ferramentas e é a unidade de medida utilizada para privacidade, segurança, inventário, gestão da continuidade do negócio de risco, e outras funções. Para medir adequadamente as capacidades de um serviço, os três elementos de pessoas, processo e tecnologia estão incluídos para cada serviço, qualquer que seja o tipo de serviço.
Por exemplo:
- Se houver um processo de negócio baseado em pessoas, como um balcão de ajuda ou uma equipa, a prestação de serviço é o que fazem. As pessoas usam processos e tecnologia para realizar o serviço.
- Se existe tecnologia como serviço, como o Azure Máquinas Virtuais, a prestação de serviços é a tecnologia juntamente com as pessoas e processos que suportam o seu funcionamento.
Modelo de responsabilidade partilhada
Muitas das ofertas que o Azure fornece exigem que os clientes criem recuperação de desastres em várias regiões e não são da responsabilidade da Microsoft. Nem todos os serviços Azure replicam automaticamente os dados ou recuam automaticamente de uma região falhada para se replicarem cruzadamente para outra região ativada. Nestes casos, a recuperação e a replicação devem ser configuradas pelo cliente.
A Microsoft garante que a infraestrutura de base e os serviços da plataforma estão disponíveis. Mas em alguns cenários, o uso requer que o cliente duplique as suas implementações e armazenamento numa capacidade multi-região, se optar. Estes exemplos ilustram o modelo de responsabilidade partilhada. É um pilar fundamental na sua estratégia de continuidade de negócios e recuperação de desastres.
Divisão de responsabilidade
Em qualquer datacenter no local, és dono de toda a pilha. À medida que transfere os ativos para a nuvem, algumas responsabilidades transferem-se para a Microsoft. O diagrama que se segue ilustra áreas e divisão de responsabilidade entre si e a Microsoft de acordo com o tipo de implementação.
Um bom exemplo do modelo de responsabilidade partilhada é a implantação de máquinas virtuais. Se um cliente quiser configurar uma replicação transversal para a resiliência se houver falha na região, deve implantar um conjunto duplicado de máquinas virtuais numa região alternativa habilitada. O Azure não replica automaticamente estes serviços se houver uma falha. É da responsabilidade do cliente mobilizar os bens necessários. O cliente deve ter um processo para alterar manualmente as regiões primárias, ou deve usar um gestor de tráfego para detetar e falhar automaticamente.
Os serviços de recuperação de desastres ativados pelo cliente têm documentação virada para o público para o orientar. Para um exemplo de documentação virada para o público para a recuperação de desastres ativada pelo cliente, consulte a Azure Data Lake Analytics.
Para obter mais informações sobre o modelo de responsabilidade partilhada, consulte o Microsoft Trust Center.
Conformidade de continuidade do negócio: responsabilidade ao nível do serviço
Cada serviço é necessário para completar os registos de recuperação de desastres de continuidade de negócios na Ferramenta Azure Business Continuity Manager. Os proprietários de serviços podem usar a ferramenta para trabalhar dentro de um modelo federado para completar e incorporar requisitos que incluem:
Propriedades de serviço: Define o serviço e como a recuperação e a resiliência de desastres são alcançadas e identifica o responsável pela recuperação de desastres (para a tecnologia). Para mais informações sobre a propriedade da recuperação, consulte a discussão sobre o modelo de responsabilidade partilhada na secção anterior e no diagrama.
Análise de impacto do negócio: Esta análise ajuda o proprietário do serviço a definir o objetivo de tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO) com base na criticidade do serviço através de uma tabela de impactos. Os impactos operacionais, legais, regulamentares, de marca e financeiros são utilizados como metas-alvo para a recuperação.
Nota
A Microsoft não publica RTO ou RPOs para serviços porque estes dados são apenas para medidas internas. Todas as promessas e medidas do cliente são baseadas em SLA porque abrange uma gama mais ampla versus RTO ou RPO, que só é aplicável em perdas catastróficas.
Dependências: Cada serviço mapeia as dependências (outros serviços) que requer para operar por mais crítico, e é mapeado para o tempo de execução, necessário apenas para a recuperação, ou ambos. Se houver dependências de armazenamento, outro dado é mapeado que define o que é armazenado, e se requer instantâneos pontuais, por exemplo.
Mão-de-obra: Como se nota na definição de um serviço, é importante conhecer a localização e quantidade de mão-de-obra capaz de suportar o serviço, garantindo que não há pontos únicos de falha, e se os colaboradores críticos são dispersos para evitar falhas por coabitação num único local.
Fornecedores externos: A Microsoft mantém uma lista completa de fornecedores externos, e os fornecedores considerados críticos são medidos para capacidades. Se identificado por um serviço como uma dependência, as capacidades do fornecedor são comparadas com as necessidades do serviço para garantir que uma paragem de terceiros não perturbe os serviços da Azure.
Classificação de recuperação: Esta classificação é exclusiva do programa Azure Business Continuity Management. Esta classificação mede vários elementos-chave para criar uma pontuação de resiliência:
- Vontade de falhar: Embora possa haver um processo, pode não ser a primeira escolha para interrupções a curto prazo.
- Automatização do fracasso.
- Automação da decisão de falhar.
O tempo mais fiável e curto para falhar é um serviço automatizado e que não requer decisão humana. Um serviço automatizado utiliza monitorização de batimentos cardíacos ou transações sintéticas para determinar que um serviço está em baixo e para iniciar a reparação imediata.
Plano de recuperação e teste: O Azure exige que todos os serviços tenham um plano de recuperação detalhado e que testem esse plano como se o serviço tivesse falhado devido a uma paragem catastrófica. Os planos de recuperação são necessários para que alguém com habilidades e acesso semelhantes possa completar as tarefas. Um plano escrito evita confiar na disponibilização de especialistas em assuntos.
Os testes são efetuados de várias formas, incluindo o auto-teste num ambiente de produção ou de quase produção, e como parte dos exercícios de down de Azure em conjuntos da região canária. Estas regiões ativadas são idênticas às regiões de produção, mas podem ser desativadas sem afetar os clientes. Os testes são considerados integrados porque todos os serviços são afetados simultaneamente.
Habilitação do cliente: Quando o cliente é responsável pela recuperação de desastres, a Azure é obrigada a ter orientação de documentação virada para o público. Para todos estes serviços, os links são fornecidos à documentação e detalhes sobre o processo.
Verifique a conformidade da continuidade do seu negócio
Quando um serviço tiver concluído o seu registo de gestão de continuidade de negócio, deve submetê-lo para aprovação. É atribuído a um profissional experiente em gestão de continuidade de negócios que revê todo o recorde de completude e qualidade. Se o registo cumprir todos os requisitos, é aprovado. Se não, é rejeitado com um pedido de reformulação. Este processo garante que ambas as partes concordam que o cumprimento da continuidade do negócio foi cumprido e que a obra só é atesta pelo proprietário do serviço. As equipas de auditoria interna e de conformidade do Azure também fazem amostras aleatórias periódicas para garantir que os melhores dados estão a ser apresentados.
Teste de serviços
A Microsoft e o Azure fazem testes extensivos tanto para a recuperação de desastres como para a prontidão da zona de disponibilidade. Os serviços são auto-testados num ambiente de produção ou pré-produção para demonstrar uma recuperação independente de serviços que não dependem de falhas nas grandes plataformas.
Para garantir que os serviços podem igualmente recuperar num verdadeiro cenário de down-region, os testes do tipo "pull-the-plug" são feitos em ambientes canários que são regiões totalmente implantadas que correspondem à produção. Por exemplo, os aglomerados, racks e unidades de energia são literalmente desligados para simular uma falha total da região.
Durante estes testes, a Azure utiliza o mesmo processo de produção para deteção, notificação, resposta e recuperação. Nenhum indivíduo está à espera de um exercício, e os engenheiros que dependem para a recuperação são os recursos normais de rotação de permanência. Este tempo evita depender de especialistas em assuntos que possam não estar disponíveis durante um evento real.
Incluídos nestes testes estão serviços onde o cliente é responsável pela configuração da recuperação de desastres após a documentação da Microsoft virada para o público. As equipas de serviço criam casos semelhantes ao cliente para mostrar que a recuperação de desastres ativada pelo cliente funciona como esperado e que as instruções fornecidas são precisas.
Para obter mais informações sobre certificações, consulte o Microsoft Trust Center e a secção sobre conformidade.