Passer en revue et comparer les modèles courants d’exploitation du cloud

Article
03/22/2023

Les modèles d’exploitation sont uniques et spécifiques de l’organisation qui les met en œuvre, en fonction de ses propres exigences et contraintes. Toutefois, les modèles d’exploitation ne sont pas des flocons de neige. Il existe plusieurs modèles courants dans les modèles d’exploitation des clients. Cet article décrit les quatre modèles les plus courants.

Comparaison des modèles d’exploitation

L’illustration suivante schématise les modèles d’exploitation courants en fonction de leur complexité, du moins complexe (décentralisé) au plus complexe (opérations globales). Les tableaux suivants comparent les mêmes modèles d’exploitation en fonction de la valeur relative d’autres attributs.

Diagramme montrant les degrés de complexité du modèle d’exploitation.

Priorités ou étendue

Un modèle d’exploitation du cloud est principalement guidé par deux facteurs :

Priorités ou motivations stratégiques
Étendue du portefeuille à gérer

	Opérations (ops) décentralisées	Opérations (opd) centralisées	Opérations (ops) d’entreprise	Opérations (ops) distribuées
Priorités ou motivations stratégiques	Innovation	Control	Démocratisation	Intégration
Étendue du portefeuille	Charge de travail	Zone d'atterrissage	Plateforme cloud	Portefeuille complet
Environnement de la charge de travail	Complexité élevée	Complexité réduite	Complexité moyenne	Complexité moyenne ou variable
Zone d'atterrissage	N/A	Complexité élevée	Complexité moyenne à réduite	Complexité réduite
Utilitaires de fondation	N/A	N/A ou support réduit	Support centralisé et supérieur	Support maximal
Fondation du cloud	N/A	N/A	Fondations hybrides, spécifiques du fournisseur ou régionales	Distribuées et synchronisées

Priorités ou motivations stratégiques : Chaque modèle d'exploitation fournit les motivations stratégiques typiques pour l'adoption du cloud. Toutefois, certains modèles d’exploitation simplifient les motivations spécifiques.
Étendue du portefeuille : l’étendue du portefeuille identifie la plus grande étendue que peut prendre en charge un modèle d’exploitation spécifique. Par exemple, les opérations centralisées sont conçues pour quelques zones d’atterrissage. Toutefois, la décision du modèle d’exploitation peut engendrer des risques opérationnels pour une organisation. Les risques opérationnels apparaissent quand vous essayez de gérer un grand portefeuille complexe. Ces portefeuilles peuvent nécessiter de nombreuses zones d’atterrissage ou une complexité variable de la conception de la zone d’atterrissage.

Important

L’adoption du cloud déclenche souvent une réflexion sur le modèle d’exploitation actuel et peut conduire à un changement de modèle. Cependant, l’adoption du cloud n’est pas le seul déclencheur. Les priorités de l’entreprise et l’étendue de l’adoption du cloud peuvent changer la manière dont le portefeuille doit être pris en charge. Par ailleurs, il peut y avoir d’autres changements dans le modèle d’exploitation le plus aligné. Quand la direction ou d’autres équipes exécutives développent des plans commerciaux sur 5 à 10 ans, ces plans impliquent souvent (explicitement ou implicitement) l’ajustement du modèle d’exploitation. Les modèles d’exploitation sont une bonne référence pour guider les décisions. Ces modèles peuvent changer ou doivent être personnalisés pour répondre à vos exigences et contraintes.

Alignement de la responsabilité

De nombreuses équipes et personnes sont responsables de la prise en charge de différentes fonctions. Toutefois, chaque modèle d’exploitation courant attribue à une équipe ou un individu la responsabilité finale des résultats de la décision. Cette approche affecte la manière dont le modèle d’exploitation est financé et le niveau de support fourni pour chaque fonction.

	Ops décentralisées	Ops centralisées	Ops d’entreprise	Ops distribuées
Alignement de l’entreprise	Équipe de charge de travail	Stratégie cloud centrale	CCoE	Variables – Constituer une équipe de stratégie cloud étoffée ?
Opérations cloud	Équipe de charge de travail	Équipe informatique centrale	CCoE	En fonction de l’analyse du portefeuille – consultez Alignement de l’entreprise et Engagements de l’entreprise
Gouvernance cloud	Équipe de charge de travail	Équipe informatique centrale	CCoE	Couches de gouvernance multiples
Sécurité du cloud	Équipe de charge de travail	Centre des opérations de sécurité	CCoE + SOC	Mixtes – Voir définir une stratégie de sécurité
Automatisation du cloud et DevOps	Équipe de charge de travail	Équipe informatique centrale ou N/A	CCoE	En fonction de l’analyse du portefeuille – consultez Alignement de l’entreprise et Engagements de l’entreprise

Accélérer l’implémentation du modèle d’exploitation dans Azure

Comme expliqué dans Définir votre modèle d’exploitation, chaque méthodologie du Cloud Adoption Framework fournit un chemin structuré pour développer votre modèle d’exploitation. Ces méthodologies peuvent vous aider à surmonter les blocages qui résultent de lacunes dans l’adoption du modèle d’exploitation du cloud.

Le tableau suivant décrit les différentes façons d’accélérer l’implémentation de votre modèle d’exploitation.

	Ops décentralisées	Ops centralisées	Ops d’entreprise	Ops distribuées
Point de départ	Well-Architected Framework (WAF) Azure	Zones d’atterrissage Azure : options pour démarrage à une échelle modeste	Zones d’atterrissage Azure : Cloud Adoption Framework à l’échelle de l’entreprise	Alignement de l’entreprise
Itérations	L’accent mis sur les charges de travail permet à l’équipe d’itérer à l’intérieur du WAF.	L’option de démarrage à petite échelle nécessite une itération supplémentaire sur chaque méthodologie, mais qui peut être effectuée à mesure que mûrissent les efforts d’adoption du cloud.	Comme l’illustrent les implémentations de référence, les itérations subséquentes se concentrent généralement sur des ajouts de configuration mineurs.	Passez en revue les options d’implémentation de zone d’atterrissage Azure pour commencer par l’option qui correspond le mieux à votre ligne de base d’exploitation. Suivez le chemin d’itération défini dans les principes de conception de cette option.

Opérations décentralisées

Les opérations sont toujours complexes. Vous pouvez contrôler cette complexité en limitant l’étendue des opérations à une charge de travail ou à un petit groupe de charges de travail. Le modèle d’exploitation des opérations décentralisées est le moins complexe des modèles courants. Dans cette forme d’opérations, toutes les charges de travail sont gérées de façon indépendante par des équipes de charge de travail dédiées.

Priorités : Votre équipe privilégie l'innovation au contrôle centralisé ou à la normalisation de plusieurs charges de travail.
Avantage distinct : maximise la vitesse de l’innovation en confiant aux équipes commerciales et de charge de travail le contrôle total de la conception, de la compilation et des opérations.
Inconvénient distinct : réduction de la standardisation des charges de travail, économies d’échelle via des services partagés et efforts constants de conformité centralisée de la gouvernance.
Risque : cette approche présente un risque en lien avec la gestion d’un portefeuille de charges de travail. Les équipes de charge de travail peuvent avoir d’autres équipes spécialisées dédiées aux fonctions informatiques centrales. Ce modèle d’exploitation est considéré comme une option à haut risque par certaines organisations, en particulier pour les entreprises qui doivent respecter des exigences de conformité tierces.
Conseils : les opérations décentralisées sont limitées à des décisions en lien avec la charge de travail. Microsoft Azure Well-Architected Framework aide à prendre des décisions au sein de cette étendue. Les processus et orientations du Cloud Adoption Framework sont susceptibles d’ajouter une surcharge qui n’existe pas avec les opérations décentralisées.

Avantages des opérations décentralisées

Gestion des coûts : il est facile de rattacher le coût des opérations à une seule unité commerciale. Les opérations spécifiques de la charge de travail permettent d’optimiser celle-ci davantage.
Responsabilités : en règle générale, cette forme d’opérations dépend fortement de l’automatisation pour réduire au maximum la surcharge. Les responsabilités tendent à se concentrer sur le DevOps et les pipelines pour la gestion des mises en production. Ce type d’opérations prend en charge des déploiements plus rapides et des cycles de commentaires plus courts pendant le développement.
Standardisation : le code source et le pipeline de déploiement doivent être utilisés pour standardiser l’environnement d’une mise en production à l’autre.
Support des opérations : les décisions qui affectent les opérations ont uniquement pour objectif de répondre aux besoins de cette charge de travail et à simplifier ces décisions. Les membres de la communauté DevOps indiquent que le support des opérations est la forme d’opérations la plus pure en raison de l’étendue opérationnelle plus stricte.
Expertise : en vertu de cette approche, les équipes de DevOps et de développement sont les plus habilitées, et rencontrent la plus faible résistance à la stimulation d’une évolution du marché.
Conception de zone d’atterrissage : aucun avantage opérationnel spécifique.
Utilitaires de base : aucun avantage opérationnel spécifique.
Séparation des tâches : aucun avantage opérationnel spécifique.

Inconvénients des opérations décentralisées

Gestion des coûts : les coûts pour l’entreprise sont plus difficiles à calculer. L’absence d’équipe de gouvernance centralisée complique l’implémentation de contrôles ou d’optimisation des coûts uniformes. À grande échelle, ce modèle peut s’avérer coûteux, car chaque charge de travail peut doubler les ressources déployées et les attributions de personnel.
Responsabilités : l’absence d’un support centralisé signifie que l’équipe de charge de travail est entièrement responsable de la gouvernance, de la sécurité, des opérations et de la gestion des changements. L’absence de support est problématique quand ces tâches ne sont pas automatisées dans des pipelines de révision de code et de mise en production.
Standardisation : la standardisation dans un portefeuille de charges de travail peut être variable et incohérente.
Support des opérations : les économies d’échelle sont souvent négligées dans la création de bonnes pratiques pour plusieurs charges de travail.
Expertise : les membres de l’équipe ont davantage de responsabilités dans la prise de décisions judicieuses et éthiques concernant la gouvernance, la sécurité, les opérations et la gestion des changements dans la conception et la configuration de l’application. Consultez fréquemment les ressources Microsoft Azure Well-Architected Review et Well-Architected Framework pour améliorer l’expertise requise.
Conception des zones d’atterrissage : les zones d’atterrissage ne sont pas spécifiques à la charge de travail et ne sont pas prises en compte dans cette approche.
Utilitaires fondamentaux : peu (voire pas) de services fondamentaux sont partagés entre les charges de travail, ce qui limite les économies d’échelle.
Séparation des tâches : les exigences plus élevées pour les équipes DevOps et de développement augmentent l’utilisation de privilèges élevés par ces équipes. Si vous avez besoin de séparation des tâches, vous devrez peut-être investir fortement dans la maturité DevOps pour fonctionner avec cette approche.

Opérations centralisées

Des environnements avec un état stable peuvent ne pas avoir besoin de se concentrer sur l’architecture ou les exigences opérationnelles distinctes de chaque charge de travail. Les opérations centrales tendent être la norme pour les environnements technologiques qui se composent principalement de charges de travail en état stable. Voici des exemples d’opérations à état stable : applications informatiques standard ou applications personnalisées bien établies, avec une cadence de mise en production lente. Quand le taux de changement est défini par des mises à jour et des patchs appliqués régulièrement, la centralisation des opérations est un moyen efficace de gérer le portefeuille.

Priorités : les priorités sont le contrôle central de l’innovation et mesurent les processus opérationnels existants par rapport au changement de culture vers les opérations modernes du cloud.
Avantage distinct : la centralisation introduit des économies d’échelle, des contrôles hors pair et des opérations standardisées, et fonctionne mieux avec l’environnement cloud. Ces environnements nécessitent des configurations spécifiques pour intégrer les opérations cloud dans les opérations et processus existants. La centralisation est particulièrement avantageuse si vous avez un portefeuille de quelques centaines de charges de travail avec une complexité architecturale et des exigences de conformité modérées.
Inconvénient distinct : la mise à l’échelle en réponse aux demandes d’un vaste portefeuille de charges de travail peut faire peser une charge importante sur les équipes centralisées qui prennent des décisions opérationnelles pour les charges de travail de production. Si vous prévoyez de faire évoluer vos ressources techniques au-delà de 1 000 machines virtuelles, applications ou sources de données, vous pouvez envisager un modèle d'entreprise si cela se fait dans les 18 à 24 mois.
Risque : cette approche limite la centralisation à un plus petit nombre d’abonnements (souvent un seul abonnement de production). Vous prenez un risque important quand vous refactorisez plus tard dans votre parcours cloud et ce risque peut interférer avec vos plans d’adoption. Pour éviter de refaire le travail, essayez de vous concentrer sur la segmentation, les limites environnementales, les outils d’identité et d’autres éléments fondamentaux.
Conseils : les options d’implémentation de zone d’atterrissage Azure qui sont alignées sur la vitesse de développement « démarrage à petite échelle et expansion » sont un bon point de départ. Ces options permettent d’accélérer les efforts d’adoption. Pour réussir, établissez des stratégies claires pour guider les efforts d’adoption précoce moyennant des tolérances de risque acceptables. Les méthodologies de gouvernance et de gestion vous aident à créer des processus pour faire mûrir les opérations en parallèle. Ces étapes sont autant de phases de décision à accomplir avant d’autoriser un risque accru pendant le développement des opérations.

Avantages des opérations centralisées

Gestion des coûts : la centralisation des services partagés sur un certain nombre de charges de travail crée des économies d’échelle et élimine les tâches en double. Les équipes centrales peuvent réduire rapidement les coûts avec des optimisations d’échelle et de dimensionnement au niveau de l’entreprise.
Responsabilités : l’expertise et la standardisation centralisées peuvent entraîner une plus grande stabilité et de meilleures performances opérationnelles, et limiter au minimum les pannes liées au changement. Cela a pour effet de réduire la pression exercée sur les talents disponibles au sein des équipes dédiées à la charge de travail.
Standardisation : en général, la standardisation et le coût des opérations sont les plus faibles avec un modèle centralisé, car il y a moins de systèmes ou de tâches en double.
Support des opérations : la réduction de la complexité et la centralisation des opérations facilitent les opérations de support pour les équipes informatiques de plus petite taille.
Expertise : la centralisation des équipes de support permet aux experts de la sécurité, des risques, de la gouvernance et des opérations d’orienter des décisions vitales pour l’entreprise.
Conception de zone d’atterrissage : l’équipe informatique centrale réduit la complexité en minimisant le nombre de zones d’atterrissage et d’abonnements. La conception des zones d’atterrissage tend à imiter celle des centres de données précédents, ce qui réduit le temps de transition. À mesure que l’adoption progresse, les ressources partagées peuvent être déplacées dans un autre abonnement ou une autre fondation de plateforme.
Utilitaires de base : le portage de conceptions de centres de données existantes vers le cloud produit des services partagés fondamentaux qui imitent les outils et opérations locaux. Si les opérations locales sont votre modèle d’exploitation principal, vous avez des avantages, mais aussi des inconvénients. Les opérations locales réduisent le temps de transition, capitalisent sur les économies d’échelle et permettent d’avoir des processus opérationnels cohérents entre les charges de travail locales et hébergées dans le cloud. Cette approche peut réduire les efforts et la complexité à court terme, et permettre à des équipes de plus petite taille de prendre en charge les opérations cloud avec des courbes d’apprentissage réduites.
Séparation des tâches : la séparation des tâches est claire dans les opérations centrales. L’équipe informatique centrale conserve le contrôle des environnements de production, ce qui contribue à diminuer le besoin d’autorisations élevées des autres équipes. Cette approche réduit les violations en limitant le nombre de comptes disposant de privilèges élevés.

Inconvénients des opérations centralisées

Gestion des coûts : les équipes centrales ne comprennent pas toujours les architectures de charge de travail pour pouvoir produire des optimisations significatives au niveau de la charge de travail. Ce manque de compréhension limite la réduction des coûts pouvant résulter d’opérations de charge de travail bien réglées. Une architecture de charge de travail mal comprise peut affecter les optimisations de coûts centralisées, ce qui affecte les performances, la mise à l’échelle et d’autres piliers d’une charge de travail bien conçue. Avant d’appliquer des modifications de coût à l’échelle de l’entreprise aux charges de travail de haut profil, votre équipe informatique centrale doit comprendre et terminer la révision de Microsoft Azure Well-Architected.
Responsabilités : la centralisation du support de la production et des accès place un fardeau opérationnel lourd sur les épaules d’un petit nombre de personnes et plus de pression sur chaque individu. La pression sur ces personnes impose d’effectuer des révisions plus approfondies des charges de travail déployées pour valider le respect des exigences de sécurité, de gouvernance et de conformité.
Standardisation : les approches choisies par l’équipe informatique centrale compliquent la mise à l’échelle de la standardisation sans mise à l’échelle linéaire du personnel informatique central.
Support des opérations : les inconvénients majeurs de cette approche sont liés à une mise à l’échelle et des changements significatifs qui mesurent l’innovation.
Expertise : dans ce type d’environnement, les experts en développement et en DevOps risquent d’être sous-évalués ou entravés.
Conception de zone d’atterrissage : les conceptions de centres de données sont basées sur les contraintes des approches précédentes, qui ne sont pas toujours pertinentes pour le cloud. L’adoption de cette approche réduit les opportunités de réinventer la segmentation de l’environnement et de dégager des opportunités d’innovation. L’absence de segmentation de la zone d’atterrissage accentue également l’impact potentiel d’une violation, la complexité du respect de la gouvernance/conformité, et peut créer des blocages à l’adoption dans le parcours du cloud. Consultez la section à propos des risques ci-dessus.
Utilitaires de base : durant la transformation numérique, le cloud pourrait devenir le modèle d’exploitation principal. Les outils centraux, créés pour les opérations locales, limitent les opportunités de modernisation des opérations et d’amélioration de l’efficacité opérationnelle. Choisir de ne pas moderniser les opérations trop tôt dans le processus d’adoption est également une option. La modernisation peut être obtenue en créant un abonnement à une fondation de plateforme dans le parcours d’adoption du cloud. Cet effort peut être complexe, coûteux et chronophage sans une planification avancée.
Séparation des tâches : les opérations centrales suivent généralement l’une des deux voies suivantes, qui peuvent faire obstacle à l’innovation.
- Option 1 : les équipes en dehors de l’équipe informatique centrale bénéficient d’un accès limité aux environnements de développement qui imitent un environnement de production. Cette option entrave l’expérimentation.
- Option 2 : les équipes développent et testent dans des environnements non pris en charge. Cette option entrave les processus de déploiement et ralentit les tests d’intégration post-déploiement.

Opérations d’entreprise

Les opérations d’entreprise sont l’état cible suggéré pour toutes les opérations de cloud. Les opérations d’entreprise contrebalancent le besoin de contrôle et d’innovation par la simplification des décisions et des responsabilités. L’informatique centrale est remplacée par un centre cloud d’excellence ou une équipe CCoE qui facilite les opérations et apporte un support aux équipes de charge de travail. L’équipe CCoE donne aux équipes de charge de travail la responsabilité des décisions, au lieu de contrôler ou limiter leurs actions. Les équipes de charge de travail se voient accorder davantage de pouvoir et de responsabilités pour stimuler l’innovation dans le cadre de garde-fous bien définis.

Priorités : les priorités sont la démocratisation des décisions techniques. La démocratisation des décisions techniques confie les responsabilités précédemment exercées par l’équipe informatique centrale aux équipes de charge de travail. Pour répondre à cette évolution des priorités, les décisions deviennent moins tributaires des processus de révision de l’exécution humaine. Cette approche permet d’utiliser des outils natifs cloud pour automatiser la révision, la gouvernance et l’application.
Avantage distinct : la segmentation des environnements et la séparation des tâches permettent de trouver un équilibre entre contrôle et innovation. Les opérations centralisées gèrent les charges de travail qui nécessitent une augmentation de la conformité et des opérations à état stable, ou qui représentent de plus grands risques de sécurité. À l’inverse, cette approche permet de réduire le contrôle centralisé des charges de travail et des environnements qui nécessitent davantage d’innovation. Les plus grands portefeuilles peuvent avoir des difficultés à trouver l’équilibre entre contrôle et innovation. Cette flexibilité facilite la mise à l’échelle de milliers de charges de travail en réduisant les difficultés opérationnelles.
Inconvénient distinct : ce qui fonctionne localement peut ne pas fonctionner correctement dans les opérations cloud d’entreprise ? Cette approche des opérations requiert des modifications sur de nombreux fronts. Des changements culturels sur les plans du contrôle et de la responsabilité constituent souvent le défi majeur. Les changements opérationnels liés au changement culturel nécessitent du temps et des efforts soutenus dans les phases d’implémentation, de maturation et de stabilisation. Des changements architecturaux peuvent être nécessaires dans les charges de travail stables, mais des changements d’outils sont obligatoires pour mettre en place et supporter les changements culturels, opérationnels et architecturaux. Ces changements peuvent impliquer de s’engager auprès d’un fournisseur de cloud principal. Les efforts d’adoption consentis avant ces modifications peuvent nécessiter un retravail conséquent qui va au-delà des efforts de refactorisation classiques.
Risque : cette approche nécessite que la direction s’engage en faveur de la stratégie de changement. Elle requiert également un engagement des équipes techniques afin de surmonter les courbes d’apprentissage et de fournir le changement requis. Une coopération à long terme entre l’entreprise, le centre d’excellence du cloud/l’équipe informatique centrale, et les équipes de charge de travail est requise pour obtenir des avantages à long terme.
Conseils : les options de zone d’atterrissage Azure sont définies à l’échelle de l’entreprise. Ces options fournissent des implémentations de référence pour décrire comment les changements techniques sont appliqués en utilisant des outils natifs cloud dans Azure. L’approche à l’échelle de l’entreprise guide les équipes au fil des évolutions opérationnelles et culturelles nécessaires pour tirer pleinement parti de ces implémentations. Cette même approche permet d’adapter l’architecture de référence pour configurer l’environnement conformément à votre stratégie d’adoption et à vos contraintes de conformité. Une fois que l’approche à l’échelle de l’entreprise est implémentée, des méthodologies de gestion et de gouvernance peuvent aider à définir les processus. Ces processus peuvent étendre vos capacités de conformité et opérationnelles pour répondre à vos besoins.

Avantages des opérations d’entreprise

Gestion des coûts : les équipes centrales agissent sur des optimisations inter-portefeuilles et donne aux équipes de charge de travail individuelles la responsabilité d’une optimisation plus profonde de la charge de travail. Les équipes dédiées aux charges de travail sont habilitées à prendre des décisions et sont informées si ces décisions ont un impact négatif sur les coûts. Les équipes centrales et de charge de travail partagent la responsabilité des décisions en matière de coût au niveau approprié.
Responsabilités : les équipes centrales utilisent des outils natifs cloud pour définir, appliquer et automatiser des garde-fous. Les efforts des équipes de charge de travail sont accélérés avec l’automatisation et les pratiques du centre d’excellence du cloud. Les équipes de charge de travail sont habilitées à diriger l’innovation et à prendre des décisions dans le cadre de ces garde-fous.
Standardisation : les garde-fous et les services fondamentaux centralisés créent une cohérence dans tous les environnements.
Support des opérations : les charges de travail qui nécessitent un support des opérations centralisé sont segmentées en environnements avec des contrôles d’état stable. La segmentation et la séparation des tâches permettent aux équipes de charge de travail d’assumer la responsabilité du support opérationnel dans leurs propres environnements dédiés. Les outils natifs cloud automatisés garantissent une base de référence minimale des opérations pour tous les environnements avec un support opérationnel centralisé.
Expertise : la centralisation des services de base, tels que la sécurité, les risques, la gouvernance et les opérations, garantit une expertise centrale. Des processus et des gardes-fous clairs éduquent les équipes de charge de travail et leur permettent de prendre des décisions plus détaillées. Ces décisions étendent l’effet des experts centralisés sans avoir à augmenter la masse salariale en même temps que la technologie.
Conception de zone d’atterrissage : la conception de zone d’atterrissage réplique les besoins du portefeuille en créant des limites claires en matière de sécurité, de gouvernance et de responsabilité. Ces limites sont nécessaires pour faire fonctionner les charges de travail dans le cloud. Il est peu probable que les pratiques de segmentation ressemblent aux contraintes créées par les conceptions de centres de données précédentes. Dans les opérations d’entreprise, la conception de zone d’atterrissage est moins complexe, ce qui permet une mise à l’échelle plus rapide et une réduction des obstacles à la demande en libre-service.
Utilitaires fondamentaux : les utilitaires fondamentaux sont hébergés dans des abonnements séparés contrôlés de manière centralisée, que l’on appelle la fondation de plateforme. Les outils centraux sont ensuite « canalisés » vers chaque zone d’atterrissage comme des services utilitaires. La séparation des utilitaires de base des zones d’atterrissage optimise la cohérence et l’économie d’échelle. Ces utilitaires créent également des distinctions claires entre les responsabilités gérées de manière centralisée et les responsabilités au niveau de la charge de travail.
Séparation des tâches : la séparation claire des tâches entre les utilitaires fondamentaux et les zones d’atterrissage est l’un des plus grands avantages de cette approche des opérations. Les outils et processus natifs cloud permettent l’accès ainsi qu’une bonne répartition du contrôle entre les équipes centralisées et les équipes de charge de travail. Cette approche est basée sur les exigences de chaque zone d’atterrissage et les charges de travail hébergées dans les segments de zone d’atterrissage.

Inconvénients des opérations d’entreprise

Gestion des coûts : les équipes centrales dépendent davantage des équipes de charge de travail pour introduire des changements de production dans les zones d’atterrissage. Ce changement crée un risque de dépassement de budget et un ralentissement de l’ajustement des dépenses réelles. Des processus de contrôle des coûts, des budgets clairs, des contrôles automatisés et des révisions régulières doivent être mis en place à un stade précoce pour éviter les surprises en matière de coûts.
Responsabilités : les opérations d’entreprise impliquent des exigences culturelles et opérationnelles plus importantes. Ces exigences garantissent une répartition claire des responsabilités entre les équipes centrales et de charge de travail.
Les processus de gestion des changements ou les comités consultatifs sur les modifications (CAB) traditionnels risquent de ne pas suivre le rythme et l’équilibre nécessaires dans ce modèle d’exploitation. Ces processus sont reflétés dans l’automatisation des processus et des procédures qui adapte l’échelle d’adoption du cloud de manière sécurisée.
Le manque d’engagement en faveur du changement se traduit par une négociation et un alignement des responsabilités. L’incapacité à s’aligner sur les glissements de responsabilité constitue une indication que des modèles d’exploitation de l’équipe informatique centrale peuvent être nécessaires dans le cadre des efforts d’adoption du cloud à court terme.
Standardisation : le manque d’investissements dans des garde-fous centralisés ou l’automatisation expose à des risques en matière de standardisation, qui est plus difficile à mettre en place avec des processus de révision manuelle. Les dépendances opérationnelles entre les charges de travail dans les zones d’atterrissage et les services partagés créent des risques plus grands. Ces risques se développent à partir de la standardisation pendant les cycles de mise à niveau ou les futures versions des utilitaires fondamentaux. Pendant les révisions de la fondation de plateforme, des tests améliorés, voire automatisés, sont nécessaires pour toutes les zones d’atterrissage prises en charge et les charges de travail qu’elles hébergent.
Support des opérations : la base de référence des opérations fournie par l’automatisation et les opérations centralisées peut être suffisante pour des charges de travail à faible impact ou peu critiques. Toutefois, les équipes de charge de travail ou d’autres formes d’opérations dédiées peuvent être nécessaires pour les charges de travail complexes ou très critiques. Cela peut créer un changement dans les budgets des opérations, obligeant les divisions à allouer des dépenses à ces formes d’opérations avancées. Si l’équipe informatique centrale doit assumer seule le coût des opérations, il est difficile d’implémenter les opérations d’entreprise.
Expertise : les membres de l’équipe informatique centrale peuvent devoir développer une expertise en matière d’automatisation des contrôles centraux qui étaient précédemment effectués par des processus manuels. Ces équipes peuvent devoir également acquérir une maîtrise des approches d’infrastructure en tant que code pour définir l’environnement, et comprendre la création de branches, la fusion et les pipelines de déploiement. Au minimum, une équipe d’automatisation de la plateforme peut avoir besoin de compétences en matière de prise de décision pour comprendre les décisions prises par le centre d’excellence du cloud ou les équipes centrales chargées des opérations. Les équipes de charge de travail peuvent devoir améliorer leur connaissance des contrôles et processus qui régissent leurs décisions.
Conception de la zone d’atterrissage : la conception de la zone d’atterrissage dépend des utilitaires fondamentaux. Les équipes de charge de travail doivent comprendre en quoi consiste la conception et ce qui est interdit. Cette compréhension peut aider à éviter de répéter des efforts, des erreurs ou des conflits. Pour créer une flexibilité, vous pouvez prendre en compte les processus d’exception à vos conceptions de zone d’atterrissage.
Utilitaires fondamentaux : la centralisation des utilitaires fondamentaux prend du temps. Ces utilitaires envisagent éventuellement des options et développent des solutions qui peuvent être mises à l’échelle pour répondre à différents plans d’adoption. Des retards dans les efforts d’adoption précoce sont possibles. Les retards peuvent être compensés à long terme grâce à des accélérations et à l’élimination des obstacles plus tard dans le processus.
Séparation des tâches : garantir une séparation claire des tâches nécessite des processus de gestion des identités matures. Il se peut qu’une maintenance supplémentaire soit associée à l’alignement correct des utilisateurs, des groupes et des activités d’intégration et de départ. De nouveaux processus seront probablement nécessaires pour prendre en charge l’accès juste-à-temps via des privilèges élevés.

Opérations distribuées

Il se peut que le modèle d’exploitation existant soit trop enraciné pour que l’ensemble de l’organisation passe à un nouveau modèle d’exploitation. Pour d’autres organisations, des opérations globales et diverses exigences de conformité pourraient empêcher des unités commerciales spécifiques d’apporter une modification. Dans ce cas, une approche de distribution des opérations peut être nécessaire. Il s’agit de loin de l’approche la plus complexe, car elle nécessite l’intégration d’un ou plusieurs des modèles d’exploitation mentionnés précédemment.

Bien qu’elle soit fortement déconseillée, cette approche des opérations peut être nécessaire pour certaines organisations. Elle s’adresse principalement aux organisations qui ont un groupe de divisions disparates, ou une base diversifiée de segments de clientèle ou d’opérations régionales.

Priorités : intégration de plusieurs modèles d’exploitation existants.
État transitoire axé sur la migration de l’organisation entière vers l’un des modèles d’exploitation mentionnés précédemment.
Approche opérationnelle à plus long terme lorsque l’organisation est de trop grande taille ou trop complexe pour s’aligner sur un seul modèle d’exploitation.
Avantage distinct : intégration d’éléments de modèles d’exploitation courants de chaque unité commerciale. Cela crée un moyen de regrouper des unités opérationnelles dans une hiérarchie et de les aider à faire maturer les opérations en utilisant des processus répétables cohérents.
Inconvénient distinct : la cohérence et la standardisation de plusieurs modèles d’exploitation sont difficiles à maintenir sur des périodes prolongées. Cette approche opérationnelle requiert une connaissance approfondie du portefeuille et de la manière dont les différents segments du portefeuille de technologies sont exploités.
Risque : l’absence d’engagement en faveur d’un modèle d’exploitation principal peut semer la confusion entre les équipes. Utilisez ce modèle d’exploitation lorsqu’il n’existe aucun moyen de s’aligner sur un seul modèle d’exploitation.
Conseils : commencez par une révision complète du portefeuille en utilisant l’approche décrite dans les articles sur l’alignement de l’entreprise. Essayez de regrouper le portefeuille par modèle d’exploitation d’état (décentralisé, centralisé ou entreprise).
Développez une hiérarchie de groupes d’administration qui reflète les regroupements de modèles d’exploitation. Cet arrangement comprend d’autres modèles organisationnels pour la région, la division ou d’autres critères qui mappent les clusters de charge de travail des compartiments les moins courants aux compartiments les plus courants.
Évaluez l’alignement des charges de travail sur les modèles d’exploitation pour trouver le cluster de modèles d’exploitation le plus approprié pour commencer. Suivez les conseils qui correspondent à ce modèle d’exploitation pour toutes les charges de travail sous ce nœud et la hiérarchie des groupes d’administration.
Utilisez les méthodologies de gouvernance et de gestion pour rechercher les stratégies d’entreprise courantes et les pratiques de gestion opérationnelle requises en différents points de la hiérarchie. Appliquez des stratégies Azure courantes pour automatiser les stratégies d’entreprise partagées.
Lorsque vous testez ces stratégies Azure avec différents déploiements, essayez de les déplacer plus haut dans la hiérarchie des groupes d’administration. Les stratégies peuvent être appliquées à de nombreuses charges de travail, qui peuvent avoir des points communs et des besoins opérationnels distincts.
Au fil du temps, cette approche peut vous aider à définir un modèle qui s’adapte à plusieurs modèles d’exploitation. Cette approche peut aussi unifier les équipes à travers un ensemble de stratégies et de procédures communes.

Les avantages et les inconvénients de cette approche sont intentionnellement laissés vides. Une fois que vous avez terminé l’alignement métier de votre portefeuille, consultez la section sur le modèle d’exploitation prédominant ci-dessus pour plus de clarté sur les avantages et les inconvénients.

Étapes suivantes

Découvrez la terminologie associée aux modèles d’exploitation. Cette terminologie vous aide à comprendre comment un modèle d’exploitation s’intègre dans le thème plus vaste de la planification d’entreprise.

Terminologie du modèle d'exploitation

Découvrez en quoi les zones d’accueil constituent les éléments constitutifs de tout environnement d’adoption du cloud.

Qu’est-ce qu’une zone d’accueil ?

Partager via