Princípios de design de uma carga de trabalho de nível de operadora no Azure

A carga de trabalho de nível de operadora deve ser projetada de acordo com os princípios orientadores dos pilares de qualidade do Well-Architected Framework:

• Confiabilidade
• Eficiência de desempenho
• Excelência operacional
• Segurança
• Otimização de custos

Este artigo descreve os princípios de design de nível de operadora que ressoam e estendem os princípios de design críticos da missão. Esses princípios coletivos servem como um roteiro para decisões de design subsequentes nas áreas de design críticas. É altamente recomendável que você conheça esses princípios para entender melhor seus efeitos e as compensações associadas à não adesão.

Há compensações de custo óbvias associadas à introdução de maior confiabilidade, que devem ser cuidadosamente consideradas no contexto dos requisitos de carga de trabalho.

Importante

Este artigo faz parte da série de cargas de trabalho de nível de operadora do Azure Well-Architected . Se você não estiver familiarizado com esta série, recomendamos que você comece com O que é uma carga de trabalho de nível de operadora?

Tenha esse modelo de arquitetura de alto nível em mente ao considerar esses pontos.

Presumir falha

Comece com a suposição de que tudo pode e falhará. O design do aplicativo deve permitir essas falhas com tolerância a falhas para que um aplicativo possa continuar a operar em algum nível.

• Minimize pontos únicos de falha e implemente uma abordagem federada.

• Implante o aplicativo em várias regiões com o gerenciamento de dados adequado nessas regiões, permitindo os impactos do teorema CAP.

• Detecte problemas automaticamente e responda em segundos. Para obter mais informações, consulte monitoramento de integridade.

• Teste a solução completa, incluindo a implementação do aplicativo, a integração da plataforma e a implantação. Esse teste deve incluir testes de caos em sistemas de produção para evitar o viés de teste.

Não compartilhar nada

Não compartilhar nada é uma abordagem comum e simples para obter alta disponibilidade. Use essa abordagem quando um aplicativo puder ser atendido por vários elementos distintos, que são intercambiáveis. Os elementos individuais devem ter uma métrica de disponibilidade bem compreendida, mas não precisam ser altos. No entanto, os elementos devem ser combinados de forma a permanecer independentes, sem nenhuma infraestrutura ou dependência compartilhada.

Não compartilhar nada muitas vezes é impossível. Para começar da posição de que nada deve ser compartilhado e adicionar apenas o menor conjunto possível de dependências compartilhadas, deve resultar em uma solução ideal.

Exemplo

Dado um único sistema que tem seis horas de inatividade por ano (cerca de 3,5*9s), uma solução que combina quatro sistemas em que os períodos de inatividade não são associados experimentará menos de 30 anos de tempo de inatividade por ano. Assim que esses quatro sistemas dependem de um serviço comum, como o DNS global, o tempo de inatividade não está mais relacionado. O tempo de inatividade resultante será maior.

Próxima etapa

Examine a área de design de tolerância a falhas para cargas de trabalho de nível de operadora.

Área de design: tolerância a falhas