Compromis de l’excellence opérationnelle

L’excellence opérationnelle fournit la qualité de la charge de travail grâce à l’implémentation de normes d’équipe claires, à une responsabilité et à une responsabilisation comprises, à l’attention portée aux résultats clients et à la cohésion de l’équipe. L’implémentation de ces objectifs est enracinée dans DevOps, qui recommande de réduire la variance des processus, de réduire les erreurs humaines et, au final, d’augmenter le retour de valeur pour la charge de travail. Cette valeur n’est pas seulement mesurée par rapport aux exigences fonctionnelles prises en charge par les composants de la charge de travail. Il est également mesuré par la valeur que l’équipe apporte dans ses efforts d’amélioration.

Pendant la phase de conception d’une charge de travail et tout au long de son cycle de vie, à mesure que des étapes d’amélioration continue sont prises, il est important de considérer comment les décisions basées sur les principes de conception d’excellence opérationnelle et les recommandations de la liste de contrôle de la révision de la conception pour l’excellence opérationnelle peuvent influencer les objectifs et les optimisations d’autres piliers. Certaines décisions peuvent profiter à certains piliers, mais constituer des 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.

Compromis entre l’excellence opérationnelle et la fiabilité

Compromis : complexité accrue. La fiabilité privilégie la simplicité, car la conception simple réduit les erreurs de configuration et réduit les interactions inattendues.

  • Les stratégies de déploiement sécurisées nécessitent souvent une certaine compatibilité avant et descendante entre la logique d’application et les données de la charge de travail. Cette complexité accrue augmente la charge de test et peut entraîner des problèmes de complexité ou d’intégrité avec les données de la charge de travail.

  • Une infrastructure hautement multicouche, modulaire ou paramétrable en tant que code peut augmenter le risque de mauvaise configuration accidentelle en raison de la complexité de l’interaction entre les composants de code.

  • Les modèles de conception cloud qui profitent aux opérations nécessitent parfois l’introduction de composants supplémentaires, par exemple l’utilisation d’un magasin de configuration externe ou la coordination des déploiements de side-car dans une plateforme d’application conteneurisée. Les composants supplémentaires augmentent les points d’interaction dans le système, ce qui augmente la surface d’exposition en cas de défaillance ou de configuration incorrecte.

  • Les composants de charge de travail conçus pour évoluer indépendamment pour prendre en charge le développement et l’hébergement agiles introduisent des dépendances sur la découverte de services, voire le DNS en tant que couche d’indirection. La découverte de service peut ne pas être réactive aux changements et les dysfonctionnements peuvent être difficiles à diagnostiquer.

Compromis : Augmentation des activités potentiellement déstabilisantes. Le pilier fiabilité encourage l’évitement des activités ou des choix de conception qui peuvent déstabiliser un système et entraîner des interruptions, des pannes ou des dysfonctionnements.

  • Le déploiement de petites modifications incrémentielles est une technique d’atténuation des risques, mais ces petites modifications devraient également être livrées plus fréquemment en production. Les déploiements peuvent déstabiliser un système, de sorte que le taux de déploiement augmente, il en va de même pour ce risque.

  • Une culture qui se mesure à l’aide de métriques de vélocité comme les déploiements par semaine et qui utilise l’automatisation qui peut faciliter l’introduction des modifications à un rythme plus rapide est également susceptible d’effectuer davantage de déploiements dans une période plus courte.

  • L’augmentation de la densité pour simplifier les opérations en réduisant le nombre de surfaces de contrôle et d’observabilité peut également entraîner un risque de disponibilité accru, car un dysfonctionnement ou une mauvaise configuration augmente le rayon d’impact d’un événement déstabilisant.

Compromis entre l’excellence opérationnelle et la sécurité

Compromis : surface d’exposition accrue. Le pilier Sécurité recommande une surface de charge de travail réduite en termes de composants et d’exposition aux opérations. Cette réduction réduit les vecteurs d’attaque et produit une plus petite étendue de contrôle et de test de sécurité.

  • Les composants qui entourent la charge de travail et prennent en charge ses opérations, comme l’automatisation ou un plan de contrôle personnalisé, doivent également être dans l’étendue du renforcement et des tests de sécurité réguliers.

  • Les opérations de routine, ad hoc et d’urgence augmentent les points de contact avec la charge de travail. Une approche de confiance zéro nécessite que ces processus soient considérés comme des vecteurs d’attaque et qu’ils soient inclus dans les contrôles de sécurité et la validation de la charge de travail.

  • La plateforme d’observabilité du système collecte des journaux et des métriques sur la charge de travail, qui peuvent être une source précieuse de divulgation d’informations. Par conséquent, la sécurité de la charge de travail doit s’étendre pour protéger les récepteurs de données contre les menaces internes et externes.

  • Les agents de build, les magasins bascules de configuration et de fonctionnalités externalisés et les approches de déploiement côte à côte augmentent tous la surface d’exposition de l’application qui nécessite la sécurité.

  • Une fréquence de déploiement plus élevée due à de petites modifications incrémentielles ou à des efforts de « mise à jour, rester à jour » entraîne davantage de tests de sécurité dans le cycle de vie du développement de logiciels.

Compromis : Un désir accru de transparence. Une charge de travail sécurisée est basée sur des conceptions qui protègent la confidentialité des données qui transitent par les composants du système.

Les plateformes d’observabilité ingèrent des données de tous types pour obtenir des insights sur l’intégrité et le comportement d’une charge de travail. À mesure que les équipes tentent d’obtenir une plus grande fidélité dans les données d’observabilité, il existe un risque accru que les contrôles de classification des données, tels que le masquage des données, des systèmes sources ne s’étendent pas aux journaux et aux récepteurs de journaux de la plateforme d’observabilité.

Compromis : segmentation réduite. Une approche de sécurité clé pour isoler l’accès et la fonction consiste à concevoir une stratégie de segmentation forte. Cette conception est implémentée via l’isolation des ressources et les contrôles d’identité.

  • La colocalisation de composants d’application disparates dans des ressources de calcul, de réseau et de données partagées pour faciliter la gestion inverse la segmentation ou rend la segmentation basée sur les rôles plus difficile à réaliser. Les composants colocalisés peuvent également avoir besoin de partager une identité de charge de travail, ce qui peut entraîner une sur-attribution des autorisations ou un manque de traçabilité.

  • La collecte de tous les journaux à partir de l’ensemble du système dans un récepteur de journaux unifié peut faciliter l’interrogation et la création d’alertes. Toutefois, cela peut également rendre plus difficile, voire impossible, la sécurité basée sur les lignes afin de traiter des données sensibles avec les contrôles d’audit requis.

  • La simplification de la gestion de la sécurité basée sur les attributs ou sur les rôles en réduisant la granularité des rôles et de leurs attributions peut entraîner des autorisations d’étendues inappropriées.

Compromis entre l’excellence opérationnelle et l’optimisation des coûts

Le pilier Excellence opérationnelle ne recommande jamais d’activités qui réduisent la productivité ou mettent en péril le retour sur investissement d’une charge de travail. Les recommandations qui semblent se concentrer sur les activités de livraison tiennent compte des meilleurs intérêts à long terme pour la charge de travail et l’équipe. Si votre charge de travail approche de sa date de fin, il n’est probablement pas judicieux d’investir fortement dans des recommandations qui déclenchent ces compromis.

Compromis : augmentation des dépenses en ressources. Un facteur de coût majeur pour une charge de travail est le coût de ses ressources. Le déploiement de moins de ressources, le dimensionnement approprié des ressources et la réduction de la consommation permettent généralement de réduire les coûts.

  • L’implémentation de pratiques de déploiement sécurisées, même si les modifications sont relativement faibles, peut entraîner une augmentation du nombre de ressources déployées simultanément. Ces modèles nécessitent le déploiement de plusieurs instances simultanées du composant d’application ou d’infrastructure afin que le trafic puisse être déplacé de manière contrôlée. Cette augmentation est plus prononcée dans une charge de travail qui utilise une approche d’infrastructure immuable.

  • L’équipe peut avoir besoin d’introduire des composants de charge de travail supplémentaires afin d’implémenter des modèles de conception cloud alignés sur les opérations ou l’automatisation de la charge de travail. Par exemple, pour prendre en charge l’agilité de déploiement, ils peuvent ajouter un composant de routage de passerelle. Pour prendre en charge une meilleure gestion de la configuration, ils peuvent ajouter un magasin de configuration externe. Pour prendre en charge les événements de cycle de vie des locataires, ils peuvent créer un plan de contrôle. Ces ressources influencent également les coûts des environnements de préproduction.

  • L’augmentation du nombre d’environnements de préproduction pour améliorer l’expérience de développement et de test par le biais de l’isolation augmente également le nombre de ressources. Ces ressources, qui ne sont pas utilisées pour fournir l’offre par rapport à la demande de production, augmentent le coût de la solution.

  • L’augmentation de la parité des environnements de préproduction avec l’environnement de production, en termes de nombre de ressources, de références SKU et de volumes de données, améliore le processus d’assurance qualité. Le coût augmente à mesure que la parité augmente.

  • Bien que les données de télémétrie ne soient pas directement une ressource, pour permettre l’efficacité des plateformes d’observabilité, ces données doivent être conservées. La plupart des magasins de données opérationnels ont des tarifs basés sur une combinaison de taux d’ingestion et de volume. En règle générale, à mesure que la quantité de données de télémétrie à faible latence et à haute diversité augmente, les coûts augmentent également. Pour les déploiements multirégions, ces récepteurs de données opérationnels sont censés être déployés par région, de sorte que tous les coûts par ressource deviennent un facteur.

Compromis : réduction de l’accent mis sur les activités de livraison. Les membres de l’équipe de charge de travail offrent une valeur de charge de travail accrue en effectuant efficacement des tâches alignées sur leurs capacités.

  • Les équipes de charge de travail qui passent du temps à créer et à affiner une structure de support saine et responsable et une réponse aux incidents fournissent un service précieux aux utilisateurs de la charge de travail. À mesure que l’effort de support augmente (par exemple, les rotations formelles sur appel), généralement en raison d’un changement de criticité métier, les coûts de ces activités augmentent. Cette augmentation des coûts peut être le résultat d’une augmentation du personnel ou peut être engagée indirectement sous la forme d’une attention qui passe des activités d’exécution aux fonctions de soutien.

  • La formation est un élément essentiel du processus d’amélioration continue personnelle d’une équipe de charge de travail. Cette formation peut être formelle ou auto-dirigée pendant le temps d’enrichissement personnel. À mesure que le temps d’entraînement augmente, le temps disponible pour le développement direct de la charge de travail diminue. L’investissement dans la formation est diminué lorsque la formation n’est pas basée sur les rôles ou n’est pas spécifiquement pertinente pour la charge de travail ou son avenir.

  • Les tâches opérationnelles de routine normalisées pour protéger la fiabilité, la sécurité et l’efficacité des performances d’une charge de travail prennent du temps pour définir, affiner et effectuer. Ce temps n’est pas directement consacré à la livraison. Voici quelques exemples de ces tâches : analyse complète de l’impact des modifications, processus de contrôle des modifications, tests approfondis et gestion accrue des correctifs. À mesure que la fréquence, l’exhaustivité ou la charge opérationnelle de ces tâches augmentent, le temps investi augmente également.

Compromis : augmentation de la demande d’outils et de la diversité. Le pilier Optimisation des coûts recommande la réduction de la prolifération des outils, la consolidation des fournisseurs et une approche adaptée à tous les achats d’outils.

Une équipe de charge de travail achète des outils et du matériel pour prendre en charge les activités effectuées tout au long du cycle de vie du développement logiciel (SDLC), y compris la planification et la conception, le développement et les tests et la surveillance. La place de marché des outils dans cet espace est en pleine croissance. Les outils sont proposés à différents prix qui correspondent généralement aux fonctionnalités des outils. À l’exception des offres gratuites, ces outils entraînent des coûts de licence initiaux, qui peuvent être par siège ou à l’échelle du site. Ils nécessitent souvent aussi des contrats de maintenance continus. Il peut être nécessaire d’établir de nouvelles relations avec les fournisseurs. Voici quelques exemples de dépenses attendues en outils ou en matériel associées aux principes d’excellence opérationnelle :

  • Configuration requise et gestion du backlog
  • Outils de conception d’architecture
  • Outils de conception d’interface utilisateur/expérience utilisateur
  • Hébergement de code et de ressources
  • Environnements de développement code et à faible code
  • Outils d’automatisation
  • Stations de travail de développement et d’assurance qualité
  • Pipelines de développement et de déploiement
  • Exécution et suivi des tests
  • Outils d’observabilité

Compromis entre l’excellence opérationnelle et l’efficacité des performances

Compromis : utilisation accrue des ressources. Le pilier Efficacité des performances recommande l’allocation de la plus grande partie possible du calcul et du réseau disponibles aux exigences de la charge de travail.

  • L’infrastructure d’observabilité d’une charge de travail nécessite que les composants de l’architecture allouent du temps et des ressources pour créer, collecter et diffuser en continu des journaux et des métriques. Ces points de données permettent de garantir que des alertes et une surveillance efficaces sont possibles pour la fiabilité, la sécurité et les performances. À mesure que le niveau d’instrumentation augmente, la contrainte sur les ressources système peut également augmenter.

  • Certains modèles de déploiement, comme le déploiement bleu/vert, qu’une charge de travail peut utiliser pour un déploiement sécurisé, peuvent introduire des déploiements côte à côte sur la plateforme d’application de production. Ces déploiements nécessitent une mise à l’échelle préventive pour fournir suffisamment d’offre pour répondre à la demande future, ou laisser un déploiement principalement dormant en place pendant une période de temps pour prendre en charge la restauration.

Compromis : latence accrue. Pour créer des charges de travail performantes, les équipes cherchent des moyens de réduire le temps et les ressources que les charges de travail consomment pour effectuer leurs tâches.

  • De nombreux modèles de déploiement nécessitent l’utilisation de modèles d’accès de routage de passerelle, ce qui peut introduire une latence. Cette latence s’appuie sur le budget cible de performances pour les flux associés.

  • Certains modèles de conception cloud qui prennent en charge les approches de « changement indépendant au fil du temps » pour prendre en charge les idéaux d’amélioration incrémentielle peuvent introduire une latence due à la traversée de composants supplémentaires. Cette latence peut être introduite par les passerelles, les répartiteurs de messagerie ou les couches anti-corruption.

Explorez les compromis pour les autres piliers :