Compartilhar via

Modelagem de integridade para cargas de trabalho de nível de operadora

  • Artigo

A alta disponibilidade requer um monitoramento de integridade cuidadoso para detectar e responder automaticamente a problemas em segundos. Esse monitoramento requer telemetria interna de dependências de chave para detectar a falha de forma confiável. O próprio aplicativo requer telemetria adicional (Indicadores de Nível de Serviço) que relatam com precisão a integridade do aplicativo de uma maneira percebida pelos usuários do aplicativo. A avaliação em relação aos SLOs pode ser necessária.

A análise de taxa de falha e a modelagem geral de integridade do aplicativo devem gerar métricas claras que indicam o serviço e a integridade de seus elementos constituintes. Essas métricas devem ser incluídas no design para que a verdadeira disponibilidade do serviço possa ser monitorada. Ao incluir métricas, você pode acompanhar os indicadores líderes mais úteis para disparar as respostas de falha automatizadas e gerar os alertas necessários para a intervenção humana.

Importante

Mais detalhes sobre como criar um modelo de integridade para sua carga de trabalho crítica estão disponíveis aqui.

Gerenciamento e monitoramento

O monitoramento e o gerenciamento exigem os seguintes processos de pensamento:

  • Como o aplicativo lidará com bugs na estrutura?
  • Como o aplicativo é atualizado?
  • Quais ações devem ser executadas durante um incidente?

Por exemplo, uma solução pode depender do ADO (Azure DevOps) para hospedar seu repositório Git para todas as configurações. Se a região do Azure que hospeda esse repositório do ADO falhar, o tempo de recuperação será de duas horas. Se a solução for implantada na mesma região, não será possível modificar a configuração para adicionar capacidade em outro lugar durante todo esse período de duas horas. Como resultado, o arquiteto de aplicativos deve considerar modos de falha correlacionados para os principais serviços, como:

Os modos de falha correlacionados para esses serviços principais podem ser uma parte necessária da resposta no nível do aplicativo à falha. É vital criar planos de controle que não são afetados pela mesma falha do aplicativo.

As ferramentas de gerenciamento necessárias para emitir diagnóstico e solução de problemas devem ser as mesmas usadas para tarefas normais de operações diárias. Ferramentas semelhantes garantem que ela seja familiar e comprovada para funcionar. Ferramentas semelhantes também maximizam a familiaridade dos usuários com a interface do usuário e as etapas de processo. Exigir que os operadores mudem para um conjunto de ferramentas diferente para resolve uma interrupção de alta pressão não é propício para identificar e resolver o problema com eficiência.

Modelo federado

Um aplicativo ou serviço altamente disponível deve ter uma infraestrutura de gerenciamento e monitoramento altamente disponível criada usando os mesmos princípios bem arquitetos de federação e tolerância a falhas. As infraestruturas criadas com base nesses princípios bem arquitetos garantem que regiões individuais possam ser auto-suficientes se desconectadas.

Se houver um evento de desconexão, o sistema será degenerado em ilhas em funcionamento individualmente, em vez de usar um sistema primário/de backup. O modelo federado é flexível e resiliente e se adapta automaticamente a eventos de partição e reconexão.

Por exemplo, logs e métricas são armazenados na Zona de Disponibilidade (AZ) em que são gerados. Uma consulta de métricas usa um processo opaco de pesquisa federada para consultar os repositórios de métricas em todas as AZs acessíveis. Trata-se dos requisitos do aplicativo específico sobre qual nível de logs, métricas e dados de alarmes devem ser replicados para outras regiões. Normalmente, os alarmes devem ser replicados, mas pode não haver justificativa suficiente para replicar logs e métricas.

Integridade e métricas não íntegras

As métricas internas são úteis como métricas não íntegras . Essas métricas indicam de forma confiável a presença de um problema, mas o inverso não é verdadeiro. Nenhuma evidência de saúde ruim não é evidência de boa saúde, pois o cliente percebe a saúde.

Por exemplo, um problema de DNS indica que as solicitações não estão chegando ao serviço de banco de dados. O erro DNS não afeta a métrica de êxito de leitura do banco de dados porque essa métrica não está vendo erros. No entanto, o usuário final percebe uma interrupção total porque não consegue acessar o banco de dados. Pelo menos uma parte das métricas de integridade deve ser medida externamente, para que essas métricas incluam tudo o que o usuário final experimentará.

Monitoramento e rastreamento

A capacidade da equipe de suporte de detectar, diagnosticar e resolve problemas é uma parte importante do fornecimento de um aplicativo altamente disponível. Para garantir o sucesso, o elemento de monitoramento e rastreamento deve fornecer altos níveis de visibilidade, para que um em cada mil eventos de tipo possa ser encontrado e resolvido.

Uma solução de rastreamento que registra apenas 0,1% das solicitações tem apenas uma chance em um milhão de registrar esses eventos, o que significa que o diagnóstico e a resolução são altamente improváveis. No entanto, a falha em resolve esses problemas terá um impacto significativo na disponibilidade.

Próxima etapa

Examine a área de design de teste e validação para cargas de trabalho de nível de operadora.

Área de design: teste e validação