Modelagem de integridade para cargas de trabalho de missão crítica

O monitoramento de aplicativos e infraestrutura é uma parte importante de qualquer implantação de infraestrutura. Para uma carga de trabalho de missão crítica, o monitoramento é uma parte crítica da implantação. O monitoramento da integridade do aplicativo e das principais métricas dos recursos do Azure ajuda você a entender se o ambiente está funcionando conforme o esperado.

Para entender completamente essas métricas e avaliar a integridade geral de uma carga de trabalho, é necessária uma compreensão holística de todos os dados monitorados. Um modelo de integridade pode ajudar na avaliação do estado geral de saúde, exibindo uma indicação clara da integridade da carga de trabalho em vez de métricas brutas. O status é frequentemente apresentado como indicadores de "semáforo", como vermelho, verde ou amarelo. A representação de um modelo de integridade com indicadores claros torna intuitivo para um operador entender a integridade geral da carga de trabalho e responder rapidamente aos problemas que surgem.

A modelagem de integridade pode ser expandida para as seguintes tarefas operacionais para a implantação de missão crítica:

• Serviço de Integridade do Aplicativo - Componente de aplicativo no cluster de computação que fornece uma API para determinar a integridade de um carimbo.

• Monitoramento - Coleta de contadores de desempenho e aplicativos que avaliam a integridade e o desempenho do aplicativo e da infraestrutura.

• Alertas - Alertas acionáveis de problemas ou interrupções na infraestrutura e no aplicativo.

• Análise de falhas - Avaria e análise de quaisquer falhas, incluindo documentação da causa raiz.

Estas tarefas constituem um modelo de saúde abrangente para a infraestrutura de missão crítica. O desenvolvimento de um modelo de saúde pode e deve ser uma parte exaustiva e integrante de qualquer implantação de missão crítica.

Para obter mais informações, consulte Modelagem de integridade e observabilidade de cargas de trabalho de missão crítica no Azure.

Serviço de Integridade do Aplicativo

O Serviço de Integridade do Aplicativo (HealthService) é um componente de aplicativo que reside com o Serviço de Catálogo (CatalogService) e o Processador em Segundo Plano (BackgroundProcessor) dentro do cluster de computação. O HealthService fornece uma API REST para o Azure Front Door chamar para determinar a integridade de um carimbo. O HealthService é um componente complexo que reflete o estado das dependências, além do seu próprio.

Quando o cluster de computação estiver inativo, o serviço de integridade não responderá. Quando os serviços estão em funcionamento, ele executa verificações periódicas em relação aos seguintes componentes na infraestrutura:

• Ele tenta fazer uma consulta no Azure Cosmos DB.

• Ele tenta enviar uma mensagem para Hubs de Eventos. A mensagem é filtrada pelo trabalhador em segundo plano.

• Ele procura um arquivo de estado na conta de armazenamento. Esse arquivo pode ser usado para desativar uma região, mesmo enquanto as outras verificações ainda estão funcionando corretamente. Este arquivo pode ser usado para se comunicar com outros processos. Por exemplo, se o carimbo for desocupado para fins de manutenção, o arquivo pode ser excluído para forçar um estado insalubre e redirecionar o tráfego.

• Ele consulta o modelo de integridade para determinar se todas as métricas operacionais estão dentro dos limites predeterminados. Quando o modelo de integridade indica que o carimbo não está íntegro, o tráfego não deve ser roteado para o carimbo, mesmo que os outros testes que o HealthService executa retornem com êxito. O Modelo de Integridade leva em conta uma visão mais completa do status de integridade.

Todos os resultados da verificação de integridade são armazenados em cache na memória por um número configurável de segundos, por padrão 10. Essa operação potencialmente adiciona uma pequena latência na deteção de interrupções, mas garante que nem todas as consultas HealthService exijam chamadas de back-end, reduzindo assim a carga no cluster e nos serviços downstream.

Esse padrão de cache é importante, porque o número de consultas HealthService cresce significativamente ao usar um roteador global como o Azure Front Door: cada nó de borda em cada datacenter do Azure que atende solicitações chamará o Serviço de Integridade para determinar se ele tem uma conexão de back-end funcional. O armazenamento em cache dos resultados reduz a carga extra do cluster gerada pelas verificações de integridade.

Configuração

O HealthService e o CatalogService têm definições de configuração comuns entre os componentes, exceto para as seguintes configurações usadas exclusivamente pelo HealthService:

Definição	valor
HealthServiceCacheDurationSeconds	Controla o tempo de expiração do cache de memória, em segundos.
HealthServiceStorageConnectionString	Cadeia de conexão para a Conta de Armazenamento onde o arquivo de status deve estar presente.
HealthServiceBlobContainerName	Contêiner de armazenamento onde o arquivo de status deve estar presente.
HealthServiceBlobName	Nome do ficheiro de estado - a verificação de estado de funcionamento procurará este ficheiro.
HealthServiceOverallTimeoutSeconds	Tempo limite para toda a verificação - o padrão é de 3 segundos. Se a verificação não for concluída nesse intervalo, o serviço informará que não está íntegro.

Implementação

Todas as verificações são realizadas de forma assíncrona e em paralelo. Se qualquer um deles falhar, todo o carimbo será considerado indisponível.

Os resultados da verificação são armazenados em cache na memória, usando o ASP.NET Core MemoryCachepadrão, não distribuído. A expiração do cache é controlada por e é definida como 10 segundos por SysConfig.HealthServiceCacheDurationSeconds padrão.

Nota

A SysConfig.HealthServiceCacheDurationSeconds definição de configuração reduz a carga adicional gerada pelas verificações de integridade, pois nem todas as solicitações resultarão em chamadas downstream para os serviços dependentes.

A tabela a seguir detalha as verificações de integridade dos componentes na infraestrutura:

Componente	Verificação de estado de funcionamento
Blob da conta de armazenamento	A verificação de blob atualmente serve a dois propósitos: 1. Teste se é possível alcançar o Armazenamento de Blobs. A conta de armazenamento é usada por outros componentes no carimbo e é considerada um recurso crítico. 2. "Desligue" manualmente uma região excluindo o arquivo de estado. Foi tomada uma decisão de design de que a verificação procuraria apenas a presença de um arquivo de estado no contêiner de blob especificado. O conteúdo do ficheiro não é processado. Há a possibilidade de configurar um sistema mais sofisticado que lê o conteúdo do arquivo e retornar status diferente com base no conteúdo do arquivo. Exemplos de conteúdo são HEALTHY, UNHEALTHY, e MAINTENANCE. A remoção do arquivo de estado desativará o carimbo. Verifique se o arquivo de integridade está presente após a implantação do aplicativo. A ausência do arquivo de saúde fará com que o serviço sempre responda com INSAUDÁVEL. O Front Door não reconhece o back-end como disponível. O arquivo é criado pela Terraform e deve estar presente após a implantação da infraestrutura.
Hub de Eventos	Os relatórios de integridade dos Hubs de Eventos são manipulados pelo EventHubProducerService. Este serviço reporta a integridade se for capaz de enviar uma nova mensagem para Hubs de Eventos. Para filtragem, esta mensagem tem uma propriedade de identificação adicionada a ela: HEALTHCHECK=TRUE Esta mensagem é ignorada na extremidade recetora. A AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() definição de configuração verifica a HEALTHCHECK propriedade.
BD do Cosmos para o Azure	Os relatórios de integridade do CosmosDbServiceAzure Cosmos DB são manipulados pelo , que relata íntegro se for: 1. Capaz de se conectar ao banco de dados do Azure Cosmos DB e executar uma consulta. 2. Capaz de escrever um documento de teste no banco de dados. O documento de teste tem um curto conjunto de tempo de vida, o Azure Cosmos DB o remove automaticamente. O HealthService executa duas sondas separadas. Se o Azure Cosmos DB estiver em um estado em que as leituras funcionam e as gravações não, os dois testes garantem que um alerta seja acionado.

Consultas do Azure Cosmos DB

Para a consulta Somente leitura, está sendo usada a seguinte consulta, que não busca dados e não tem um grande efeito na carga geral:

SELECT GetCurrentDateTime ()

A consulta de gravação cria um manequim ItemRating com conteúdo mínimo:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Monitorização

O Azure Log Analytics é usado como o repositório central de logs e métricas para todos os componentes de aplicativo e infraestrutura. O Azure Application Insights é usado para todos os dados de monitoramento de aplicativos. Cada carimbo na infraestrutura tem um espaço de trabalho dedicado do Log Analytics e uma instância do Application Insights. Um espaço de trabalho separado do Log Analytics é usado para os recursos compartilhados globalmente, como Front Door e Azure Cosmos DB.

Todos os selos são de curta duração e continuamente substituídos a cada novo lançamento. Os espaços de trabalho do Log Analytics por carimbo são implantados como um recurso global em um grupo de recursos de monitoramento separado como os recursos do Log Analytics de carimbo . Esses recursos não compartilham o ciclo de vida de um selo.

Para obter mais informações, consulte Coletor de dados unificado para análise correlacionada.

Monitorização: Fontes de dados

• Configurações de diagnóstico: todos os serviços do Azure usados para o Azure Mission-Critical são configurados para enviar todos os seus dados de diagnóstico, incluindo logs e métricas, para o espaço de trabalho de análise de log específico da implantação (global ou carimbo). Este processo acontece automaticamente como parte da implantação do Terraform. Novas opções serão identificadas automaticamente e adicionadas como parte do terraform apply.

• Monitoramento do Kubernetes: as configurações de diagnóstico são usadas para enviar logs e métricas do AKS para o Log Analytics. O AKS está configurado para usar o Container Insights. O Container Insights implanta o OMSAgentForLinus por meio de um DaemonSet Kubernetes em cada nó nos clusters AKS. O OMSAgentForLinux é capaz de coletar logs e métricas extras de dentro do cluster Kubernetes e enviá-los para seu espaço de trabalho correspondente do Log Analytics. Esses logs e métricas extras contêm dados mais granulares sobre pods, implantações, serviços e a integridade geral do cluster. Para obter mais informações dos vários componentes, como ingress-nginx, cert-manager e outros componentes implantados no Kubernetes ao lado da carga de trabalho de missão crítica, é possível usar a raspagem do Prometheus. A raspagem do Prometheus configura o OMSAgentForLinux para coletar métricas do Prometheus de vários pontos de extremidade dentro do cluster.

• Telemetria do Application Insights: o Application Insights é usado para coletar dados de telemetria do aplicativo. O código foi instrumentado para coletar dados sobre o desempenho do aplicativo com o SDK do Application Insights. Informações críticas, como o código de status resultante e a duração das chamadas de dependência e contadores para exceções não tratadas, são coletadas. Essas informações são usadas no Modelo de Integridade e estão disponíveis para alertas e solução de problemas.

Monitoramento: testes de disponibilidade do Application Insights

Para monitorar a disponibilidade dos selos individuais e da solução geral de um ponto de vista externo, os testes de disponibilidade do Application Insights são configurados em dois locais:

• Testes de disponibilidade regional: esses testes são configurados nas instâncias regionais do Application Insights e são usados para monitorar a disponibilidade dos selos. Esses testes visam diretamente os clusters e as contas de armazenamento estático dos selos. Para chamar os pontos de entrada dos clusters diretamente, as solicitações precisam ter o cabeçalho de ID da porta frontal correto, caso contrário, elas serão rejeitadas pelo controlador de entrada.

• Teste de disponibilidade global: esses testes são configurados na instância global do Application Insights e são usados para monitorar a disponibilidade da solução geral executando ping no Front Door. Dois testes são usados: um para testar uma chamada de API em relação ao CatalogService e outro para testar a página inicial do site.

Monitoramento: Consultas

O Azure Mission-Critical usa diferentes consultas KQL (Kusto Query Language) para implementar consultas personalizadas como funções para recuperar dados do Log Analytics. Essas consultas são armazenadas como arquivos individuais em nosso repositório de código, separados para implantações globais e de carimbo. Eles são importados e aplicados automaticamente via Terraform como parte de cada pipeline de infraestrutura executado.

Essa abordagem separa a lógica de consulta da camada de visualização. As consultas do Log Analytics são chamadas diretamente do código, por exemplo, da API HealthService. Outro exemplo é de uma ferramenta de visualização, como Painéis do Azure, Pastas de Trabalho do Monitor ou Grafana.

Monitoramento: Visualização

Para visualizar os resultados de nossas consultas de integridade do Log Analytics, usamos o Grafana em nossa implementação de referência. O Grafana é usado para mostrar os resultados das consultas do Log Analytics e não contém nenhuma lógica em si. A pilha Grafana não faz parte do ciclo de vida de implantação da solução, mas é lançada separadamente.

Para obter mais informações, consulte Visualização.

Alertas

Os alertas são uma parte importante da estratégia geral de operações. O monitoramento proativo, como o uso de painéis, deve ser usado com alertas que levantem atenção imediata aos problemas.

Esses alertas formam uma extensão do modelo de integridade, alertando o operador sobre uma mudança no estado de integridade, seja para o estado degradado/amarelo ou para o estado insalubre/vermelho. Ao definir o alerta para o nó raiz do Modelo de Integridade, o operador está imediatamente ciente de qualquer efeito de nível de negócios no estado da solução: Afinal, esse nó raiz ficará amarelo ou vermelho se qualquer um dos fluxos de usuários ou recursos subjacentes relatar métricas amarelas ou vermelhas. O operador pode direcionar sua atenção para a visualização do Modelo de Integridade para solução de problemas.

Para obter mais informações, consulte Resposta automatizada a incidentes.

Análise de falhas

Compor a análise de falhas é, na sua maioria, um exercício de planeamento teórico. Este exercício teórico deve ser usado como entrada para as injeções automáticas de falhas que fazem parte do processo de validação contínua. Ao simular os modos de falha definidos aqui, podemos validar a resiliência da solução contra essas falhas para garantir que elas não levem a interrupções.

A tabela a seguir lista exemplos de casos de falha dos vários componentes da implementação de referência de Missão Crítica do Azure.

Service	Risco	Impacto/Mitigação/Comentário	Indisponibilidade
Microsoft Entra ID	Microsoft Entra ID torna-se indisponível.	Atualmente, não existe qualquer atenuação possível. Uma abordagem multirregional não atenuará nenhuma paralisação, pois é um serviço global. Este serviço é uma dependência difícil. O Microsoft Entra ID é usado para operações de plano de controle, como a criação de novos nós AKS, extração de imagens de contêiner do ACR ou para acessar o Cofre de Chaves na inicialização do pod. Espera-se que os componentes existentes em execução possam continuar em execução quando o Microsoft Entra ID tiver problemas. É provável que novos pods ou nós AKS sejam incapazes de desovar. Em operações de escala são necessárias durante esse tempo, isso pode levar a uma diminuição da experiência do usuário e, potencialmente, a interrupções.	Parcial
Azure DNS	O DNS do Azure torna-se indisponível e a resolução de DNS falha.	Se o DNS do Azure ficar indisponível, a resolução DNS para solicitações de usuário e entre diferentes componentes do aplicativo provavelmente falhará. Atualmente, não há mitigação possível em vigor para este cenário. Uma abordagem multirregional não atenuará nenhuma paralisação, pois é um serviço global. O DNS do Azure é uma dependência difícil. Serviços DNS externos como backup não ajudariam, já que todos os componentes PaaS usados dependem do DNS do Azure. Ignorar o DNS mudando para IP não é uma opção. Os serviços do Azure não têm endereços IP estáticos e garantidos.	Total
Porta da frente	Interrupção geral da porta da frente.	Se a porta da frente cair completamente, não há mitigação. Este serviço é uma dependência difícil.	Sim
Porta da frente	Erros de configuração de roteamento/frontend/backend.	Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser apanhado em fases de teste. A configuração de frontend com DNS é específica para cada ambiente. Atenuação: Reverter para a configuração anterior deve corrigir a maioria dos problemas. Como as alterações levam alguns minutos no Front Door para serem implantadas, isso causará uma interrupção.	Total
Porta da frente	O certificado TLS/SSL gerenciado é excluído.	Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser apanhado em fases de teste. Tecnicamente, o site ainda funcionaria, mas erros de certificado TLS/SSL impedirão os usuários de acessá-lo. Mitigação: a reemissão do certificado pode levar cerca de 20 minutos, além de corrigir e executar novamente o pipeline.	Total
BD do Cosmos para o Azure	O banco de dados/coleção é renomeado.	Pode acontecer devido a incompatibilidade na configuração durante a implantação – Terraform substituiria todo o banco de dados, o que poderia resultar em perda de dados. A perda de dados pode ser evitada usando bloqueios de nível de banco de dados/coleta. O aplicativo não poderá acessar nenhum dado. A configuração do aplicativo precisa ser atualizada e os pods reiniciados.	Sim
BD do Cosmos para o Azure	Interrupção regional	O Azure Mission-Critical tem gravações em várias regiões habilitadas. Se houver uma falha em uma leitura ou gravação, o cliente tentará novamente a operação atual. Todas as operações futuras são permanentemente encaminhadas para a próxima região por ordem de preferência. Caso a lista de preferências tenha uma entrada (ou estivesse vazia), mas a conta tenha outras regiões disponíveis, ela será encaminhada para a próxima região na lista de contas.	Não
BD do Cosmos para o Azure	Limitação extensiva devido à falta de RUs.	Dependendo do número de RUs e do balanceamento de carga empregado no nível da Porta da Frente, certos carimbos podem ficar quentes na utilização do Azure Cosmos DB, enquanto outros carimbos podem atender a mais solicitações. Mitigação: melhor distribuição de carga ou mais RUs.	Não
BD do Cosmos para o Azure	Partição cheia	O limite de tamanho da partição lógica do Azure Cosmos DB é de 20 GB. Se os dados de uma chave de partição dentro de um contêiner atingirem esse tamanho, solicitações de gravação adicionais falharão com o erro "Chave de partição atingiu o tamanho máximo".	Parcial (gravações de banco de dados desabilitadas)
Azure Container Registry	Interrupção regional	O registro de contêiner usa o Gerenciador de Tráfego para fazer failover entre regiões de réplica. Qualquer solicitação deve ser automaticamente redirecionada para outra região. Na pior das hipóteses, as imagens do Docker não podem ser extraídas por alguns minutos pelos nós AKS enquanto o failover de DNS acontece.	Não
Azure Container Registry	Imagem(ns) apagada(s)	Nenhuma imagem pode ser puxada. Essa interrupção deve afetar apenas os nós recém-gerados/reinicializados. Os nós existentes devem ter as imagens armazenadas em cache. **Mitigação: Se detetado rapidamente, a reexecução dos pipelines de compilação mais recentes deve trazer as imagens de volta para o registro.	Não
Azure Container Registry	Limitação	A limitação pode atrasar as operações de expansão, o que pode resultar em um desempenho temporariamente degradado. Mitigação: o Azure Mission-Critical usa o Premium SKU que fornece 10 mil operações de leitura por minuto. As imagens de contêiner são otimizadas e têm apenas um pequeno número de camadas. ImagePullPolicy é definido como IfNotPresent para usar versões armazenadas em cache localmente primeiro. Comentário: Puxar uma imagem de contêiner consiste em várias operações de leitura, dependendo do número de camadas. O número de operações de leitura por minuto é limitado e depende do tamanho do ACR SKU.	Não
Serviço Kubernetes do Azure	Falha na atualização do cluster	As atualizações do nó AKS devem ocorrer em momentos diferentes nos selos. Se uma atualização falhar, o outro cluster não deverá ser afetado. As atualizações de cluster devem ser implantadas de forma contínua entre os nós para evitar que todos os nós fiquem indisponíveis.	Não
Serviço Kubernetes do Azure	O pod de aplicação é morto ao atender a solicitação.	Isso pode resultar em erros de enfrentamento do usuário final e má experiência do usuário. Mitigação: o Kubernetes por padrão remove pods de forma graciosa. Os pods são removidos dos serviços primeiro e a carga de trabalho recebe um SIGTERM com um período de carência para concluir solicitações abertas e gravar dados antes de terminar. O código do aplicativo precisa entender o SIGTERM e o período de carência pode precisar ser ajustado se a carga de trabalho demorar mais para ser desligada.	Não
Serviço Kubernetes do Azure	Capacidade de computação indisponível na região para adicionar mais nós.	As operações de expansão/redução falharão, mas isso não deve afetar os nós existentes e sua operação. Idealmente, o tráfego deve mudar automaticamente para outras regiões para balanceamento de carga.	Não
Serviço Kubernetes do Azure	A assinatura atinge a cota principal da CPU para adicionar novos nós.	As operações de expansão/redução falharão, mas isso não deve afetar os nós existentes e sua operação. Idealmente, o tráfego deve mudar automaticamente para outras regiões para balanceamento de carga.	Não
Serviço Kubernetes do Azure	Vamos criptografar certificados TLS/SSL que não podem ser emitidos/renovados.	Cluster deve relatar insalubridade em direção à Front Door e o tráfego deve mudar para outros selos. Atenuação: investigue a causa raiz do problema/falha de renovação.	Não
Serviço Kubernetes do Azure	Quando as solicitações/limites de recursos são configurados incorretamente, os pods podem atingir 100% de utilização da CPU e falhar solicitações. O mecanismo de repetição do aplicativo deve ser capaz de recuperar solicitações com falha. Repetições podem causar uma maior duração da solicitação, sem revelar o erro para o cliente. A carga excessiva acabará por causar falhas.	Não (se a carga não for excessiva)
Serviço Kubernetes do Azure	Imagens de contêiner de 3ª parte / registro indisponível	Alguns componentes, como cert-manager e ingress-nginx, exigem o download de imagens de contêiner e gráficos de leme de registros de contêineres externos (tráfego de saída). Caso um ou mais desses repositórios ou imagens não estejam disponíveis, novas instâncias em novos nós (onde a imagem ainda não está armazenada em cache) podem não ser capazes de iniciar. Possível atenuação: Em alguns cenários, pode fazer sentido importar imagens de contêiner de terceiros para o registro de contêiner por solução. Isto acrescenta complexidade adicional e deve ser planeado e operacionalizado cuidadosamente.	Parcialmente (durante operações de dimensionamento e atualização/atualização)
Hub de Eventos	Não é possível enviar mensagens para os Hubs de Eventos	O carimbo torna-se inutilizável para operações de escrita. O serviço de saúde deve detetar automaticamente isso e tirar o carimbo do rodízio.	Não
Hub de Eventos	As mensagens não podem ser lidas pelo BackgroundProcessor	As mensagens ficarão na fila. As mensagens não devem se perder, pois persistem. Atualmente, esta falha não é coberta pelo Serviço de Saúde. Deve haver monitoramento/alerta no trabalhador para detetar erros na leitura de mensagens. Atenuação: O carimbo deve ser desativado manualmente até que o problema seja corrigido.	Não
Conta de armazenamento	A conta de armazenamento torna-se inutilizável pelo trabalhador para o apontamento de verificação dos Hubs de Eventos	O carimbo não processará mensagens dos Hubs de Eventos. A conta de armazenamento também é usada pelo HealthService. Espera-se que problemas com o armazenamento sejam detetados pelo Serviço de Saúde e o carimbo seja retirado do rodízio. Pode-se esperar que outros serviços no selo sejam afetados simultaneamente.	Não
Conta de armazenamento	O site estático encontra problemas.	Se o serviço do site estático encontrar problemas, essa falha deve ser detetada pela Front Door. O tráfego não será enviado para esta conta de armazenamento. O cache na Front Door também pode aliviar esse problema.	Não
Key Vault	Cofre de chaves indisponível para GetSecret operações.	No início dos novos pods, o driver AKS CSI buscará todos os segredos do Key Vault e falhará. Os pods não poderão ser iniciados. Atualmente, há uma atualização automática a cada 5 minutos. A atualização falhará. Os erros devem aparecer, kubectl describe pod mas o pod continua funcionando.	Não
Key Vault	Cofre de chaves indisponível para GetSecret ou SetSecret operações.	Novas implantações não podem ser executadas. Atualmente, essa falha pode fazer com que todo o pipeline de implantação pare, mesmo que apenas uma região seja afetada.	Não
Key Vault	Limitação do Cofre de Chaves	O Key Vault tem um limite de 1000 operações por 10 segundos. Por causa da atualização automática de segredos, você poderia, em teoria, atingir esse limite se tivesse muitos (milhares) de pods em um selo. Possível atenuação: diminua ainda mais a frequência de atualização ou desative-a completamente.	Não
Aplicação	Configuração incorreta	Cadeias de conexão incorretas ou segredos injetados no aplicativo. Deve ser atenuado pela implantação automatizada (o pipeline lida com a configuração automaticamente) e pela distribuição azul-verde das atualizações.	Não
Aplicação	Credenciais expiradas (recurso de carimbo)	Se, por exemplo, o token SAS do hub de eventos ou a chave da conta de armazenamento foi alterado sem atualizá-los corretamente no Cofre da Chave para que os pods possam usá-los, o respetivo componente do aplicativo falhará. Esta falha deve então afetar o Serviço de Saúde, e o carimbo deve ser retirado do rodízio automaticamente. Atenuação: use a autenticação baseada em ID do Microsoft Entra para todos os serviços que a suportam. O AKS requer que os pods se autentiquem usando o ID de carga de trabalho do Microsoft Entra (visualização). O uso de Pod Identity foi considerado na implementação de referência. Descobriu-se que o Pod Identity não era estável o suficiente atualmente e foi decidido contra o uso para a arquitetura de referência atual. A identidade do pod pode ser uma solução no futuro.	Não
Aplicação	Credenciais expiradas (recurso compartilhado globalmente)	Se, por exemplo, a chave da API do Azure Cosmos DB foi alterada sem atualizá-la corretamente em todos os Cofres de Chaves de carimbo para que os pods possam usá-los, os respetivos componentes do aplicativo falharão. Essa falha derrubaria todos os carimbos ao mesmo tempo e causaria uma interrupção em toda a carga de trabalho. Para uma possível maneira de contornar a necessidade de chaves e segredos usando o Microsoft Entra auth, consulte o item anterior.	Total
Rede virtual	Espaço de endereço IP da sub-rede esgotado	Se o espaço de endereço IP em uma sub-rede estiver esgotado, nenhuma operação de expansão, como a criação de novos nós ou pods AKS, poderá acontecer. Isso não levará a uma interrupção, mas pode diminuir o desempenho e afetar a experiência do usuário. Mitigação: aumentar o espaço IP (se possível). Se isso não for uma opção, pode ajudar a aumentar os recursos por nó (SKUs de VM maiores) ou por pod (mais CPU/memória), para que cada pod possa lidar com mais tráfego, diminuindo assim a necessidade de expansão.	Não

Próximos passos

Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usados nessa arquitetura.

Implementação: Missão Crítica Online