Compromis de fiabilité pour les charges de travail Power Platform
Une charge de travail fiable répond systématiquement aux objectifs de fiabilité définis. Il doit atteindre les objectifs de résilience définis, idéalement en contournant les événements qui affectent la fiabilité. Cependant, en réalité, une charge de travail doit tolérer et contrôler l’impact de tels événements et maintenir les opérations à un niveau prédéterminé pendant un dysfonctionnement actif. Même en cas de catastrophe, une charge de travail fiable doit retrouver un état spécifique dans un délai donné, deux délais convenus entre les parties prenantes. Un plan de réponse aux incidents qui vous permet d’obtenir une détection et une récupération rapides est essentiel.
Au cours de la phase de conception d’une charge de travail, vous devez considérer comment les décisions basées sur les principes de conception du pilier Fiabilité et les recommandations de la liste de contrôle d’examen de la conception du pilier Fiabilité peuvent influencer les objectifs et les optimisations d’autres piliers. Certaines décisions peuvent bénéficier à certains piliers, mais constituer un compromis pour d’autres. Cet article décrit des exemples de compromis qu’une équipe de charge de travail peut rencontrer lors de la conception de l’architecture et des opérations de charge de travail pour le pilier Fiabilité.
Compromis du pilier Fiabilité pour le pilier Sécurité
Compromis : augmentation de la surface de charge de travail. Le pilier Sécurité privilégie une surface réduite et confinée pour minimiser les vecteurs d’attaque et réduire la gestion des contrôles de sécurité.
La fiabilité est souvent obtenue par réplication. La réplication peut avoir lieu au niveau des composants, au niveau des données ou même au niveau géographique. Les répliques, de par leur conception, augmentent le périmètre d’une charge de travail. Du point de vue du pilier Sécurité, un périmètre réduit et confiné est préférable pour minimiser les vecteurs d’attaque potentiels et simplifier la gestion des contrôles de sécurité.
De même, les solutions de reprise après sinistre, comme les sauvegardes, augmentent le périmètre d’une charge de travail. Cependant, ils sont souvent isolés du temps d’exécution de la charge de travail. Cela nécessite la mise en œuvre de contrôles de sécurité supplémentaires, qui peuvent être spécifiques à la solution de reprise après sinistre.
Dans un souci de fiabilité, des composants supplémentaires peuvent être nécessaires pour l’architecture, ce qui augmente le périmètre. Cette complexité accrue augmente le périmètre de la charge de travail en ajoutant de nouveaux composants qui doivent être sécurisés, éventuellement d’une manière qui n’est pas déjà utilisée dans le système. Généralement, ces composants sont accompagnés de code supplémentaire pour prendre en charge leur utilisation ou leurs modèles de fiabilité généraux, ce qui augmente également le périmètre de l’application.
Lorsqu’une charge de travail est confrontée à un événement de fiabilité traité dans le cadre d’une réponse active aux incidents, l’urgence peut créer une pression sur les équipes chargées de la charge de travail pour qu’elles contournent les contrôles de sécurité optimisés pour les accès de routine.
Les activités de résolution des problèmes peuvent amener l’équipe à désactiver temporairement les protocoles de sécurité, laissant un système déjà sollicité potentiellement exposé à des risques de sécurité supplémentaires. Il existe également un risque que les protocoles de sécurité ne soient pas rétablis rapidement.
Les implémentations granulaires de contrôles de sécurité, comme les attributions de contrôle d’accès en fonction du rôle ou les règles de pare-feu, introduisent la caractère complexe et sensible de la configuration, augmentant ainsi les risques de mauvaise configuration. Réduire cet impact potentiel sur la fiabilité en utilisant des règles générales érode les trois principes de l’architecture Zero Trust.
L’application de mises à jour de vagues de versions ou de mises à jour de bibliothèques de fournisseurs, telles que des composants ou des solutions tiers, peut potentiellement perturber le composant cible, entraînant une indisponibilité pendant la modification. Retarder ou éviter l’application des correctifs peut éviter les risques potentiels de fiabilité, mais cela laisse le système sans protection contre l’évolution des menaces.
La considération précédente s’applique également au code de la charge de travail. Par exemple, cela s’applique au code d’application qui utilise d’anciennes bibliothèques et composants. Si la mise à jour et le déploiement du code de l’application sont considérés comme un risque de fiabilité absolu, l’application est exposée à des risques de sécurité supplémentaires au fil du temps.
Compromis du pilier Fiabilité avec le pilier Excellence opérationnelle
Disposer d’une stratégie de surveillance complète d’une charge de travail est un élément clé de l’excellence opérationnelle. L’introduction de composants supplémentaires dans une architecture pour mettre en œuvre des modèles de conception du pilier Fiabilité entraîne davantage de sources de données à gérer, augmentant ainsi la complexité de la mise en œuvre du traçage et de l’observabilité distribués.
L’utilisation de plusieurs régions pour surmonter les contraintes de capacité des ressources d’une seule région et/ou mettre en œuvre une architecture active/active augmente la complexité de la gestion opérationnelle de la charge de travail. Cette complexité est introduite par la nécessité de gérer plusieurs régions et la nécessité de gérer la réplication des données entre elles.
À mesure qu’une charge de travail devient plus robuste grâce à l’ajout de composants et de modèles de pilier Fiabilité, la maintenance des procédures opérationnelles et de la documentation des artefacts prend plus de temps.
La formation devient plus complexe à mesure que le nombre de composants dans la charge de travail augmente. Cette complexité affecte le temps requis pour l’intégration et augmente les connaissances nécessaires pour suivre les feuilles de route des produits et les conseils en matière de niveau de service.
Compromis du pilier Fiabilité avec le pilier Optimisation de l’expérience
Mettre l’accent sur des tests rigoureux peut retarder la publication de fonctionnalités d’expérience essentielles à l’adoption.
L’optimisation de la fiabilité peut surindexer la minimisation de la complexité, ce qui prive les fonctionnalités d’expériences utilisateur plus attrayantes, telles que les composants personnalisés et les intégrations.
Compromis entre fiabilité et efficacité des performances
Les modèles de fiabilité intègrent souvent la réplication des données pour survivre aux dysfonctionnements des répliques. La réplication introduit une latence supplémentaire pour les opérations d’écriture de données fiables, ce qui consomme une partie du budget de performances pour un utilisateur ou un flux de données spécifique.
La fiabilité utilise parfois diverses formes d’équilibrage des ressources pour distribuer ou redistribuer la charge aux répliques saines. Un composant dédié utilisé pour l’équilibrage affecte généralement les performances de la demande ou du processus en cours d’équilibrage.
La distribution de composants au-delà des limites géographiques ou des zones de disponibilité pour survivre à un impact limité introduit une latence réseau dans la communication entre les composants qui dépassent ces limites de disponibilité.
Des processus étendus sont utilisés pour observer l’état d’une charge de travail. Bien que la surveillance soit essentielle à la fiabilité, l’instrumentation peut affecter les performances du système. À mesure que l’observabilité augmente, les performances peuvent diminuer.
Les opérations de mise à l’échelle automatique ne sont pas instantanées et ne peuvent donc pas gérer de manière fiable une augmentation soudaine et spectaculaire de la demande qui ne peut être ni façonnée ni lissée. Par conséquent, le surprovisionnement via des instances plus grandes ou plus d’instances est une tactique de fiabilité essentielle pour tenir compte du décalage entre le signal de demande et la création de l’offre. La capacité inutilisée va à l’encontre des objectifs d’efficacité des performances.
Parfois, un composant ne peut pas être mis à l’échelle en réaction à la demande, et cette demande n’est pas entièrement prévisible. L’utilisation d’instances volumineuses pour couvrir le pire des cas conduit à un gaspillage de surprovisionnement dans des situations qui sont en dehors de ce cas d’utilisation.