Implantação e teste para cargas de trabalho críticas no Azure

A implantação e o teste do ambiente crítico da missão é uma parte crucial da arquitetura de referência geral. Os carimbos de aplicativo individuais são implantados usando a infraestrutura como código de um repositório de código-fonte. As atualizações na infraestrutura, e no aplicativo por cima disso, devem ser implantadas sem tempo de inatividade para o aplicativo. Um pipeline de integração contínua de DevOps é recomendado para recuperar o código-fonte do repositório e implantar os carimbos individuais no Azure.

Implantação e atualizações são o processo central na arquitetura. As atualizações relacionadas à infraestrutura e ao aplicativo devem ser implantadas em selos totalmente independentes. Somente os componentes de infraestrutura global na arquitetura são compartilhados entre os carimbos. Os carimbos existentes na infraestrutura não são tocados. As atualizações de infraestrutura são implantadas somente nesses novos carimbos. As novas versões do aplicativo são implantadas somente nesses novos carimbos.

Os novos selos são adicionados ao Azure Front Door. O tráfego é transferido gradualmente para os novos carimbos. Quando o tráfego é servido a partir dos novos carimbos sem problemas, os carimbos anteriores são excluídos.

Testes de penetração, caos e estresse são recomendados para o ambiente implantado. O teste proativo da infraestrutura descobre pontos fracos e como o aplicativo implantado se comporta se houver uma falha.

Implantação

A implantação da infraestrutura na arquitetura de referência depende dos seguintes processos e componentes:

• DevOps - O código-fonte do GitHub e pipelines para a infraestrutura.

• Atualizações sem tempo de inatividade - As atualizações e upgrades são implantados no ambiente com zero tempo de inatividade para o aplicativo implantado.

• Ambientes - Ambientes de curta duração e permanentes utilizados para a arquitetura.

• Recursos compartilhados e dedicados - Recursos do Azure que são dedicados e compartilhados aos carimbos e à infraestrutura geral.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: considerações sobre design

Implantação: DevOps

Os componentes de DevOps fornecem o repositório de código-fonte e pipelines de CI/CD para implantação da infraestrutura e atualizações. O GitHub e o Azure Pipelines foram escolhidos como componentes.

• do GitHub – Contém os repositórios de código-fonte para o aplicativo e a infraestrutura.

• Azure Pipelines - Os pipelines usados pela arquitetura para todas as tarefas de compilação, teste e versão.

Um componente extra no design usado para a implantação são os agentes de compilação. Os agentes de build hospedados pela Microsoft são usados como parte do Azure Pipelines para implantar a infraestrutura e as atualizações. O uso de agentes de build hospedados pela Microsoft remove a carga de gerenciamento para os desenvolvedores manterem e atualizarem o agente de build.

Para obter mais informações sobre o Azure Pipelines, consulte O que é o Azure Pipelines?.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: implantações de infraestrutura como código

Implantação: atualizações sem tempo de inatividade

A estratégia de atualização com zero tempo de inatividade na arquitetura de referência é central para o aplicativo crítico de missão como um todo. A metodologia de substituir em vez de fazer upgrade dos carimbos garante uma nova instalação do aplicativo em um carimbo de infraestrutura. A arquitetura de referência utiliza uma abordagem azul/verde e permite ambientes de teste e desenvolvimento separados.

Há dois componentes principais da arquitetura de referência:

• Infraestrutura - serviços e recursos do Azure. Implantado com o Terraform e suas configurações associadas.

• Application – o serviço ou aplicativo hospedado que atende aos usuários. Com base em contêineres do Docker e artefatos npm criados em HTML e JavaScript para a interface do usuário do aplicativo de página única (SPA).

Em muitos sistemas, há uma suposição de que as atualizações de aplicativos são mais frequentes do que as atualizações de infraestrutura. Como resultado, diferentes procedimentos de atualização são desenvolvidos para cada um. Com uma infraestrutura de nuvem pública, as alterações podem ocorrer em um ritmo mais rápido. Um processo de implantação para atualizações de aplicativos e atualizações de infraestrutura foi escolhido. Uma abordagem garante que a infraestrutura e as atualizações de aplicativos estejam sempre em sincronia. Essa abordagem permite:

• Um processo consistente – menos chances de erros se as atualizações de infraestrutura e aplicativo forem misturadas em uma versão, intencionalmente ou não.

• Habilita a implantação azul/verde - Cada atualização é implantada usando uma migração gradual do tráfego para a nova versão.

• Implantação e depuração mais fáceis do aplicativo - O carimbo inteiro nunca hospeda várias versões do aplicativo lado a lado.

• Reversão simples - O tráfego pode ser revertido para os carimbos que executam a versão anterior se forem encontrados erros ou problemas.

• Eliminação de alterações manuais e descompasso de configuração - Cada ambiente é uma nova implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: implantações efêmeras azul/verde

Estratégia de ramificação

A base da estratégia de atualização é o uso de branches no repositório Git. A arquitetura de referência usa três tipos de branches:

Ramo	Descrição
feature/* e fix/*	Os pontos de entrada para qualquer alteração. Os desenvolvedores criam esses branches, que devem receber um nome descritivo, como feature/catalog-update ou fix/worker-timeout-bug. Quando as alterações estiverem prontas para serem mescladas, uma solicitação pull (PR) em relação à ramificação main. Pelo menos um revisor deve aprovar todas as pull requests. Com exceções limitadas, cada alteração proposta em uma PR deve ser executada pelo pipeline de validação de ponta a ponta (E2E). Os desenvolvedores devem usar o pipeline E2E para testar e depurar alterações em um ambiente completo.
main	A ramificação em constante avanço e estável. Usado principalmente para testes de integração. As alterações em main são feitas somente por meio de solicitações de pull. Uma política de ramificação proíbe gravações diretas. As liberações noturnas no ambiente permanente integration (int) são executadas automaticamente a partir da ramificação main. A ramificação main é considerada estável. Deve ser seguro presumir que, a qualquer momento, uma versão pode ser criada a partir dela.
release/*	As ramificações de versão são criadas somente a partir da ramificação main. As ramificações seguem o formato release/2021.7.X. As políticas de branch são usadas para que apenas os administradores de repositório possam criar release/* branches. Somente estas ramificações são usadas para implantar no ambiente prod.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: estratégia de ramificação

Correções Rápidas

Quando um hotfix é necessário urgentemente devido a um bug ou outro problema e não pode passar pelo processo de versão regular, um caminho de hotfix está disponível. Atualizações de segurança críticas e correções para a experiência do usuário que não foram descobertas durante o teste inicial são consideradas exemplos válidos de hotfixes.

O hotfix deve ser criado em uma nova ramificação fix e, em seguida, mesclado para main usando uma PR regular. Em vez de criar uma nova ramificação de versão, o hotfix é "escolhido a dedo" em uma ramificação de versão existente. Essa ramificação já está implantada no ambiente prod. O pipeline de CI/CD que implantou originalmente a ramificação de versão com todos os testes é executado novamente e agora implanta o hotfix como parte do pipeline.

Para evitar problemas maiores, é importante que o hotfix contenha algumas confirmações isoladas que podem ser facilmente selecionadas e integradas à ramificação da versão. Se não for possível escolher commits isoladas a dedo para integrar à ramificação de versão, isso indica que a alteração não se qualifica como um hotfix. Implante a alteração como uma nova versão completa. Combine-o com uma reversão para uma versão estável anterior até que a nova versão possa ser implantada.

Ambientes de Implantação

A arquitetura de referência usa dois tipos de ambientes para a infraestrutura:

• Curta duração - O pipeline de validação do E2E é usado para implantar ambientes de curta duração. Ambientes de curta duração são usados para ambientes de validação ou depuração pura para desenvolvedores. Os ambientes de validação podem ser criados a partir do branch feature/*, submetidos a testes e, em seguida, destruídos se todos os testes tiverem sido bem-sucedidos. Os ambientes de depuração são implantados da mesma forma que a validação, mas não são destruídos imediatamente. Esses ambientes não devem existir por mais do que alguns dias e devem ser excluídos quando a PR correspondente da ramificação do recurso for mesclado.

• Permanente – nos ambientes permanentes há versões integration (int) e production (prod). Esses ambientes vivem continuamente e não são destruídos. Os ambientes usam nomes de domínio fixos como int.mission-critical.app. Em uma implementação do mundo real da arquitetura de referência, um ambiente staging (preprod) deve ser adicionado. O ambiente staging é usado para implantar e validar ramificações release com o mesmo processo de atualização que prod (implantação Azul/Verde).

  • Integração (int) - A versão int é implantada todas as noites a partir da ramificação main com o mesmo processo que prod. A alternância de tráfego é mais rápida do que a unidade de versão anterior. Em vez de alternar gradualmente o tráfego ao longo de vários dias, como em prod, o processo para int é concluído em poucos minutos ou horas. Essa mudança mais rápida garante que o ambiente atualizado esteja pronto até a manhã seguinte. Os carimbos antigos são excluídos automaticamente se todos os testes no pipeline forem bem-sucedidos.

  • Produção (prod) - A versão prod só é implantada a partir de ramificações release/*. A transição de tráfego usa etapas mais granulares. Uma porta de aprovação manual está entre cada etapa. Cada versão cria novos selos regionais e implanta a nova versão do aplicativo nos selos. Os selos existentes permanecem intocados durante o processo. A consideração mais importante sobre prod é que ele deve estar "sempre ligado". Nenhum tempo de inatividade planejado ou não planejado deve ocorrer. A única exceção são as alterações fundamentais na camada de banco de dados. Uma janela de manutenção planejada pode ser necessária.

Implantação: recursos compartilhados e dedicados

Os ambientes permanentes (int e prod) dentro da arquitetura de referência têm diferentes tipos de recursos, dependendo de serem compartilhados com toda a infraestrutura ou dedicados a um carimbo individual. Os recursos podem ser dedicados a uma versão específica e existir somente até que a próxima unidade de lançamento assuma o controle.

Unidades de versão

Uma unidade de lançamento são vários selos regionais por versão de lançamento específica. Os selos contêm todos os recursos que não são compartilhados com os outros selos. Esses recursos são redes virtuais, cluster do Serviço de Kubernetes do Azure, Hubs de Eventos e Azure Key Vault. O Azure Cosmos DB e o ACR são configurados com fontes de dados do Terraform.

Recursos compartilhados globalmente

Todos os recursos compartilhados entre unidades de versão são definidos em um modelo do Terraform independente. Esses recursos são Front Door, Azure Cosmos DB, Registro de contêiner (ACR) e os espaços de trabalho do Log Analytics e outros recursos relacionados ao monitoramento. Esses recursos são implantados antes que o primeiro carimbo regional de uma unidade de lançamento seja implantado. Os recursos são referenciados nos modelos do Terraform para os selos.

porta da frente

Embora o Front Door seja um recurso compartilhado globalmente entre selos, sua configuração é ligeiramente diferente dos outros recursos globais. É necessário reconfigurar o Front Door depois que um novo carimbo é implantado. O Front Door deve ser reconfigurado para alternar o tráfego gradativamente para os novos carimbos.

A configuração de back-end do Front Door não pode ser definida diretamente no modelo do Terraform. A configuração é inserida por meio de variáveis Terraform. Os valores de variável são construídos antes da implantação do Terraform ser iniciada.

A configuração de componente individual para a implantação do Front Door é definida como:

• Front-end - A afinidade de sessão é configurada para garantir que os usuários não alternem entre diferentes versões da interface do usuário durante uma única sessão.

• Origens - O Front Door é configurado com dois tipos de grupos de origem:

  1. Um grupo de origem para armazenamento estático que atende à interface do usuário. O grupo contém as contas de armazenamento do site de todas as unidades de lançamento ativas no momento. Diferentes pesos podem ser atribuídos às origens de diferentes unidades de lançamento para mover o tráfego gradualmente para uma unidade mais nova. Cada origem de uma unidade de lançamento deve ter o mesmo peso atribuído.

  2. Um grupo de origem para a API, que está hospedada no Serviço de Kubernetes do Azure. Se houver unidades de lançamento com versões de API diferentes, um grupo de origem da API existirá para cada unidade de versão. Se todas as unidades de versão oferecerem a mesma API compatível, todas as origens serão adicionadas ao mesmo grupo e receberão pesos diferentes.

• regras de roteamento – há dois tipos de regras de roteamento:

  1. Uma regra de roteamento para a interface do usuário que está vinculada ao grupo de origem do armazenamento da mesma.

  2. Uma regra de roteiro para cada API atualmente compatível com as origens. Por exemplo: /api/1.0/* e /api/2.0/*.

  Se uma versão introduzir uma nova versão das APIs de back-end, as alterações refletirão na interface do usuário implantada como parte da versão. Uma versão específica da interface do usuário sempre chama uma versão específica da URL da API. Os usuários atendidos por uma versão da interface do usuário usam automaticamente a respectiva API de back-end. Regras de roteamento específicas são necessárias para instâncias diferentes da versão da API. Essas regras estão vinculadas aos grupos de origem correspondentes. Se uma nova API não tiver sido introduzida, todas as regras de roteamento relacionadas à API serão vinculadas ao grupo de origem única. Nesse caso, não importa se um usuário recebe a interface de uma versão diferente da API.

Implantação: processo de implantação

Uma implantação azul/verde é a meta do processo de implantação. Um novo lançamento de uma ramificação release/* é implantado no ambiente prod. O tráfego de usuários é alternado gradualmente para os carimbos do novo lançamento.

Como uma primeira etapa no processo de implantação de uma nova versão, a infraestrutura da nova unidade de lançamento é implantada com o Terraform. A execução do pipeline de implantação de infraestrutura implanta a nova infraestrutura a partir de uma ramificação de lançamento selecionada. Em paralelo ao provisionamento de infraestrutura, as imagens de contêiner são criadas ou importadas e enviadas para o registro de contêiner globalmente compartilhado (ACR). Quando os processos anteriores são concluídos, o aplicativo é implantado nos selos. Do ponto de vista de implementação, é um pipeline com vários estágios dependentes. O mesmo pipeline pode ser executado novamente para implantações de hotfix.

Depois que a nova unidade de lançamento é implantada e validada, a nova unidade é adicionada ao Front Door para receber o tráfego do usuário.

É necessário planejar um switch/parâmetro que distingua entre lançamentos que introduzem e não introduzem uma nova versão da API. Com base em se a versão introduzir uma nova versão de API, um novo grupo de origem com os back-ends da API deverá ser criado. Como alternativa, novos back-ends de API podem ser adicionados a um grupo de origem existente. Novas contas de armazenamento de interface do usuário são adicionadas ao grupo de origem existente correspondente. Os pesos para novas origens devem ser definidos de acordo com a divisão de tráfego desejada. Uma nova regra de roteamento, conforme descrito anteriormente, deve ser criada que corresponda ao grupo de origem apropriado.

Como parte da adição da nova unidade de lançamento, os pesos das novas origens devem ser definidos para o tráfego mínimo de usuário desejado. Se nenhum problema for detectado, a quantidade de tráfego do usuário deverá ser aumentada para o novo grupo de origem durante um período de tempo. Para ajustar os parâmetros de peso, as mesmas etapas de implantação devem ser executadas novamente com os valores desejados.

Desmontagem da unidade de lançamento

Como parte do pipeline de implantação de uma unidade de lançamento, há um estágio de destruição que remove todos os carimbos quando uma unidade de lançamento não é mais necessária. Todo o tráfego é movido para uma nova versão de lançamento. Esta etapa inclui a remoção de referências de unidade de liberação do Front Door. Essa remoção é essencial para habilitar o lançamento de uma nova versão posteriormente. O Front Door deve apontar para uma única unidade de lançamento, a fim de estar preparado para o próximo lançamento no futuro.

Listas de Verificação

Como parte da cadência de lançamento, uma lista de verificação pré e pós-lançamento deve ser usada. O exemplo a seguir é de itens que devem estar em qualquer lista de verificação no mínimo.

• lista de verificação de pré-lançamento - Antes de iniciar uma versão, verifique o seguinte:

  • Verifique se o estado mais recente da ramificação de main foi implantado e testado com êxito no ambiente int.

  • Atualize o arquivo de log de alterações por meio de uma PR na ramificação main.

  • Crie uma ramificação release/ a partir da ramificação main.

• Lista de verificação pós-lançamento - Antes que os carimbos antigos sejam destruídos e suas referências sejam removidas do Front Door, verifique se:

  • Os clusters não estão mais recebendo tráfego de entrada.

  • Os Hubs de Eventos e outras filas de mensagens não contêm mensagens não processadas.

Implantação: limitações e riscos da estratégia de atualização

A estratégia de atualização descrita nesta arquitetura de referência tem algumas limitações e riscos que devem ser mencionados:

• Custo mais alto – ao liberar atualizações, muitos dos componentes de infraestrutura ficam ativos duas vezes durante o período de lançamento.

• Complexidade do Front Door – O processo de atualização no Front Door é complexo de implementar e manter. A capacidade de executar implantações azul/verde eficazes sem tempo de inatividade depende de ela funcionar corretamente.

• Pequenas alterações demoradas – o processo de atualização resulta em um processo de lançamento mais longo para pequenas alterações. Essa limitação pode ser parcialmente atenuada com o processo de hotfix descrito na seção anterior.

Implantação: considerações de compatibilidade futura de dados do aplicativo

A estratégia de atualização pode dar suporte a várias versões de uma API e componentes de trabalho em execução simultaneamente. Como o Azure Cosmos DB é compartilhado entre duas ou mais versões, há a possibilidade de que os elementos de dados alterados por uma versão nem sempre correspondam à versão da API ou aos trabalhadores que a consomem. As camadas e os trabalhadores da API devem implementar o design de compatibilidade direta. Versões anteriores da API ou componentes de trabalho processam dados inseridos por uma versão posterior da API ou do componente de trabalho. Ignora partes que não entende.

Teste

A arquitetura de referência contém diferentes testes usados em diferentes estágios na implementação do teste.

Estes testes incluem:

• Testes de unidade - Esses testes validam se a lógica de negócios do aplicativo funciona conforme o esperado. A arquitetura de referência contém um conjunto de exemplos de testes de unidade executados automaticamente antes de cada build de contêiner pelo Azure Pipelines. Se algum teste falhar, o pipeline será interrompido. A construção e a implantação são interrompidas. O desenvolvedor deve corrigir o problema antes que o pipeline possa ser executado novamente.

• Testes de carga - Esses testes ajudam a avaliar a capacidade, a escalabilidade e os possíveis gargalos de uma determinada carga de trabalho ou pilha. A implementação de referência contém um gerador de carga do usuário para criar padrões de carga sintéticos que podem ser usados para simular o tráfego real. O gerador de carga também pode ser usado independentemente da implementação de referência.

• Testes de fumaça - Esses testes identificam se a infraestrutura e a carga de trabalho estão disponíveis e agem conforme o esperado. Os testes de fumaça são executados como parte de cada implantação.

• testes de interface do usuário – esses testes validam que a interface do usuário foi implantada e funciona conforme o esperado. A implementação atual captura apenas capturas de tela de várias páginas após a implantação sem nenhum teste real.

• Testes de injeção de falha - Esses testes podem ser automatizados ou executados manualmente. O teste automatizado na arquitetura integra o Azure Chaos Studio como parte dos pipelines de implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: validação e teste contínuos

Testes: estruturas

A implementação de referência online para recursos de teste atuais e estruturas sempre que possível.

Estrutura	Teste	Descrição
NUnit	Unidade	Essa estrutura é usada para testar a parte do .NET Core da implementação. O Azure Pipelines executa testes de unidade automaticamente antes do build do contêiner.
JMeter com Teste de Carga do Azure	Carregar	O Teste de Carga do Azure é um serviço gerenciado usado para executar definições de teste de carga do Apache JMeter .
Locust	Carregar	O Locust é uma estrutura de teste de carga de software livre escrita em Python.
dramaturgo	IU e Fumaça	Playwright é uma biblioteca de Node.js de código aberto para automatizar o Chromium, Firefox e WebKit com uma única API. A definição de teste do Playwright também pode ser usada independentemente da implementação de referência.
Azure Chaos Studio	Injetar falhas	A implementação de referência usa o Azure Chaos Studio como uma etapa opcional no pipeline de validação E2E para injetar falhas para validação de resiliência.

Testes: testes de Injeção de Falhas e Engenharia do Chaos

Os aplicativos distribuídos devem ser resilientes a interrupções de serviço e componente. O teste de injeção de falhas (também conhecido como Injeção de Falhas ou Engenharia do Caos) é a prática de submeter aplicativos e serviços a estresses e falhas do mundo real.

Resiliência é uma propriedade de um sistema inteiro e a injeção de falhas ajuda a encontrar problemas no aplicativo. Resolver esses problemas ajuda a validar a resiliência do aplicativo para condições não confiáveis, dependências ausentes e outros erros.

Testes manuais e automáticos podem ser executados na infraestrutura para localizar falhas e problemas na implementação.

Automático

A arquitetura de referência integra o Azure Chaos Studio para implantar e executar um conjunto de experimentos do Azure Chaos Studio para injetar várias falhas no nível de carimbo. Os experimentos do Chaos podem ser executados como uma parte opcional do pipeline de implantação do E2E. Quando os testes são executados, o teste de carga opcional sempre é executado em paralelo. O teste de carga é usado para criar carga no cluster para validar o efeito das falhas injetadas.

Manual

O teste de injeção manual de falhas deve ser feito em um ambiente de validação E2E. Esse ambiente garante testes representativos completos sem o risco de interferência de outros ambientes. A maioria das falhas geradas com os testes pode ser observada diretamente em Métricas em tempo real do Application Insights. As falhas restantes estão disponíveis na exibição Falhas e nas tabelas de log correspondentes. Outras falhas exigem uma depuração mais profunda, como o uso de kubectl para observar o comportamento dentro do Serviço de Kubernetes do Azure.

Dois exemplos de testes de injeção de falha executados na arquitetura de referência são:

• DNS (Serviço de Nome de Domínio) – injeção de falhas baseada em DNS – Um caso de teste que pode simular vários problemas. Falhas de resolução de DNS devido à falha de um servidor DNS ou DNS do Azure. O teste baseado em DNS pode ajudar a simular problemas gerais de conexões entre um cliente e um serviço, por exemplo, quando o BackgroundProcessor não consegue se conectar aos Hubs de Eventos.

  Em cenários de host único, você pode modificar o arquivo hosts local para substituir a resolução DNS. Em um ambiente maior com vários servidores dinâmicos, como o AKS, um arquivo hosts não é viável. zonas DNS privadas do Azure podem ser usadas como uma alternativa para testar cenários de falha.

  Os Hubs de Eventos do Azure e o Azure Cosmos DB são dois dos serviços do Azure usados na implementação de referência que podem ser usados para injetar falhas baseadas em DNS. A resolução de DNS dos Hubs de Eventos pode ser manipulada com uma zona de DNS Privado do Azure vinculada à rede virtual de um dos carimbos. O Azure Cosmos DB é um serviço replicado globalmente com pontos de extremidade regionais específicos. A manipulação dos registros DNS para esses pontos de extremidade pode simular uma falha para uma região específica e testar o failover de clientes.

• Bloqueio do firewall – a maioria dos serviços do Azure dá suporte a restrições de acesso por firewall com base em redes virtuais e/ou endereços IP. Na infraestrutura de referência, essas restrições são usadas para restringir o acesso ao Azure Cosmos DB ou aos Hubs de Eventos. Um procedimento simples é remover regras de Permissão existentes ou adicionar novas regras de Bloqueio. Este procedimento pode simular configurações incorretas de firewall ou interrupções de serviço.

  Os seguintes serviços de exemplo na implementação de referência podem ser testados com um teste de firewall:

  Serviço	Resultado
  Key Vault	Quando o acesso ao Key Vault é bloqueado, o efeito mais direto foi a falha de novos pods para desovar. O driver CSI do Key Vault que busca segredos na inicialização do pod não pode executar suas tarefas e impede que o pod seja iniciado. Mensagens de erro correspondentes podem ser observadas com kubectl describe po CatalogService-deploy-my-new-pod -n workload. Os pods existentes continuam funcionando, embora a mesma mensagem de erro seja observada. Os resultados da verificação de atualização periódica para segredos geram a mensagem de erro. Embora não tenha sido testado, a execução de uma implantação não funciona enquanto o Key Vault está inacessível. As tarefas do Terraform e da CLI do Azure na execução do pipeline fazem solicitações ao Key Vault.
  Hubs de Evento	Quando o acesso ao Event Hubs é bloqueado, novas mensagens enviadas pelo CatalogService e HealthService falham. As recuperações de mensagens pelo BackgroundProcess falham lentamente, com falha total em poucos minutos.
  Azure Cosmos DB	A remoção da política de firewall existente para uma rede virtual faz com que o Serviço de Saúde comece a falhar com o menor atraso possível. Este procedimento simula apenas um caso específico, uma interrupção inteira do Azure Cosmos DB. A maioria dos casos de falha que ocorrem em um nível regional é atenuada automaticamente com failover transparente do cliente para uma região diferente do Azure Cosmos DB. O teste de injeção de falha baseado em DNS descrito anteriormente é um teste mais significativo para o Azure Cosmos DB.
  Registro de Contêiner (ACR)	Quando o acesso ao ACR é bloqueado, a criação de novos pods que foram puxados e armazenados em cache anteriormente em um nó AKS continuará a funcionar. A criação ainda funciona devido ao sinalizador implantação K8spullPolicy=IfNotPresent. Os nós não poderão gerar um novo pod e falharão imediatamente com erros de ErrImagePull se o nó não tiver puxado e armazenado em cache uma imagem antes do bloco. kubectl describe pod exibe a mensagem correspondente de 403 Forbidden.
  Balanceador de carga de entrada do AKS	A alteração das regras de entrada para HTTP(S)(portas 80 e 443) no NSG (Network Security Group) gerenciado pelo AKS para resultados de Negar no tráfego de teste de usuário ou investigação de integridade não alcançam o cluster. É difícil de identificar a causa raiz dessa falha por meio do teste, o que foi simulado como bloqueio entre o caminho de rede do Front Door e um carimbo regional. O Front Door detecta imediatamente essa falha e tira o carimbo da rotação.