Compensações de confiabilidade para Power Platform cargas de trabalho
Uma carga de trabalho fiável cumpre consistentemente os seus objetivos de fiabilidade definidos. Deve atingir os objetivos de resiliência estabelecidos, idealmente contornando eventos que afetam a fiabilidade. Realisticamente, no entanto, uma carga de trabalho deve tolerar e controlar o impacto de tais eventos e manter as operações num nível predeterminado durante o mau funcionamento ativo. Mesmo durante um desastre, uma carga de trabalho fiável deve ser recuperada para um estado específico dentro de um determinado período de tempo, ambos acordados entre as partes interessadas. Um plano de resposta a incidentes que permita uma deteção e recuperação rápidas é vital.
Durante a fase de projeto de uma carga de trabalho, precisa de ter em consideração como as decisões baseadas nos Princípios design de fiabilidade e as recomendações na Lista de verificação de revisão da estrutura para Fiabilidade podem influenciar as metas e as otimizações de outros pilares. Certas decisões podem beneficiar alguns pilares, mas constituir um compromisso para outros. Este artigo descreve exemplos de compromissos que uma equipa de carga de trabalho pode encontrar ao projetar a arquitetura e as operações de carga de trabalho para a fiabilidade.
Compromissos da fiabilidade com Segurança
Compromisso: aumento da superfície de trabalho. O pilar Segurança prioriza uma área de superfície reduzida e contida para minimizar os vetores de ataque e reduzir a gestão de controlos de segurança.
A fiabilidade é frequentemente obtida através da replicação. A replicação pode ocorrer no nível do componente, ao nível de dados ou até mesmo a um nível geográfico. Por predefinição, as réplicas aumentam a área de superfície de uma carga de trabalho. Do ponto de vista da segurança, é preferível uma área de superfície reduzida e contida para minimizar os potenciais vetores de ataque e simplificar a gestão dos controlos de segurança.
Do mesmo modo, as soluções de recuperação após desastre, tal como as cópias de segurança, aumentam a área de superfície de uma carga de trabalho. No entanto, muitas vezes são isolados do runtime da carga de trabalho. Isso requer a implementação de controlos de segurança adicionais, que podem ser específicos para a solução de recuperação após desastre.
Por uma questão de objetivos de fiabilidade, poderão ser necessários componentes adicionais para a arquitetura, o que aumenta a área de superfície. Este aumento da complexidade aumenta a área de superfície da carga de trabalho ao adicionar novos componentes que têm de ser protegidos, possivelmente de formas que não são já utilizadas no sistema. Normalmente, esses componentes são acompanhados por código adicional para suportar a sua utilização ou padrões gerais de fiabilidade, o que também aumenta a área de superfície da aplicação.
Quando uma carga de trabalho está ter um evento de fiabilidade que está a ser tratado na resposta ativa a incidentes, a urgência pode criar pressão para que as equipas de carga ignorem os controlos de segurança otimizados para acesso de rotina.
As atividades de resolução de problemas podem fazer com que a equipa desative temporariamente os protocolos de segurança, deixando um sistema já stressado potencialmente exposto a riscos de segurança adicionais. Também existe o risco de os protocolos de segurança não serem restabelecidos imediatamente.
Implementações granulares de controlos de segurança, como atribuições de controlo de acesso baseado na função ou regras de firewall, introduzem complexidade de configuração e sensibilidade, o que aumenta a probabilidade de configuração incorreta. A mitigação desse potencial impacto na fiabilidade através de regras amplas corrói os três princípios da arquitetura Confiança Zero.
A aplicação de atualizações de onda de versão ou atualizações a bibliotecas de fornecedores, como componentes ou soluções de terceiros, pode potencialmente interromper o componente de destino, causando indisponibilidade durante a alteração. Atrasar ou evitar a aplicação de patches pode evitar os riscos potenciais de fiabilidade, mas deixa o sistema desprotegido contra ameaças em evolução.
A consideração anterior também se aplica ao código da carga de trabalho. Por exemplo, aplica-se ao código de aplicação que utiliza bibliotecas e componentes antigos. Se a atualização e a implementação do código da aplicação forem vistas como um risco de fiabilidade não mitigado, a aplicação estará exposta a riscos de segurança adicionais ao longo do tempo.
Compromissos de fiabilidade com excelência operacional
Ter uma estratégia de monitorização abrangente para uma carga de trabalho é uma parte fundamental da excelência operacional. A introdução de componentes adicionais numa arquitetura para implementar padrões de projeto de fiabilidade resulta em mais fontes de dados para gerir, o que aumenta a complexidade da implementação de rastreamento distribuído e observabilidade.
A utilização de várias regiões para ultrapassar as restrições de capacidade de recursos de região única e/ou implementar uma arquitetura ativa/ativa aumenta a complexidade da gestão operacional da carga de trabalho. Esta complexidade é introduzida pela necessidade de gerir várias regiões e pela necessidade de gerir a replicação de dados entre elas.
À medida que uma carga de trabalho se torna mais robusta através da adição de componentes e padrões de fiabilidade, demora mais tempo a manter os procedimentos operacionais e a documentação de artefactos.
A formação se torna mais complexa à medida que o número de componentes na carga de trabalho aumenta. Esta complexidade afeta o tempo necessário para a integração e aumenta o conhecimento necessário para monitorizar os roteiros dos produtos e a orientação ao nível do serviço.
Compromissos da fiabilidade com Otimização da Experiência
Enfatizar testes rigorosos pode atrasar o lançamento de recursos de experiência que são essenciais para a adoção.
A otimização pela fiabilidade pode sobre-indexar na minimização da complexidade, o que retira prioridade às funcionalidades para experiências de utilizador mais cativantes, tais como componentes e integrações personalizados.
Compensações de confiabilidade com eficiência de desempenho
Os padrões de confiabilidade geralmente incorporam a replicação de dados para sobreviver ao mau funcionamento da réplica. A replicação introduz latência adicional para operações confiáveis de gravação de dados, o que consome uma parte do orçamento de desempenho para um usuário ou fluxo de dados específico.
Às vezes, a confiabilidade emprega várias formas de balanceamento de recursos para distribuir ou redistribuir a carga para réplicas íntegras. Um componente dedicado usado para balanceamento geralmente afeta o desempenho da solicitação ou do processo que está sendo balanceado.
A distribuição de componentes entre limites geográficos ou zonas de disponibilidade para sobreviver a um impacto de escopo introduz latência de rede na comunicação entre componentes que abrangem esses limites de disponibilidade.
Processos extensivos são usados para observar a integridade de uma carga de trabalho. Embora o monitoramento seja crítico para a confiabilidade, a instrumentação pode afetar o desempenho do sistema. À medida que a observabilidade aumenta, o desempenho pode diminuir.
As operações de dimensionamento automático não são instantâneas e, portanto, não podem lidar de forma confiável com um pico repentino e dramático na demanda que não pode ser moldado ou suavizado. Portanto, o provisionamento excessivo por meio de instâncias maiores ou mais instâncias é uma tática crítica de confiabilidade para explicar a defasagem entre o sinal de demanda e a criação de oferta. A capacidade não utilizada contraria os objetivos de eficiência de desempenho.
Às vezes, um componente não pode ser dimensionado em reação à demanda, e essa demanda não é totalmente previsível. O uso de grandes instâncias para cobrir o pior caso leva ao excesso de provisionamento de resíduos em situações que estão fora desse caso de uso.