# Représentations de modèles d’exploitation deux par deux
Ces représentations de modèles d’exploitation deux par deux vous aident à comprendre les relations entre les équipes dans votre environnement. Ces diagrammes se concentrent sur les tâches et sur les relations entre les équipes, mais nous aborderons également la gouvernance et la prise de décision dans le contexte de ces exemples.
Nos équipes peuvent avoir des responsabilités à différents niveaux de plusieurs modèles, en fonction des charges de travail qu’elles prennent en charge. Il se peut que vous souhaitiez mettre en avant des domaines de discipline plus spécialisés que ceux de haut niveau décrits. Ces modèles offrent un potentiel de variation infini, à mesure que vous séparez ou regroupez des activités, ou que vous superposez des équipes et définissez des détails plus spécifiques.
Vous pouvez constater que les capacités de certaines équipes se chevauchent ou ne sont pas reconnues, ce qui peut apporter un avantage supplémentaire ou entraîner des gains d’efficacité. Vous pouvez également identifier des besoins non satisfaits au sein de votre entreprise auxquels vous pouvez envisager de répondre.
Lors de l’évaluation du changement organisationnel, examinez les compromis entre les modèles, la place des différentes équipes au sein des modèles (maintenant et après le changement), comment les relations et les responsabilités de vos équipes évolueront et si les avantages qui en seront tirés justifient l’impact sur votre entreprise.
Chacun des quatre modèles d’exploitation suivants peut améliorer vos performances. Certains modèles sont plus adaptés à des cas d’utilisation spécifiques ou à des étapes spécifiques de votre développement. Certains de ces modèles peuvent fournir des avantages par rapport à ceux utilisés dans votre environnement.
**Topics**
+ [Modèle d’exploitation entièrement séparé](fully-separated-operating-model.md)
+ [DevOps avec un fournisseur de services gérés dans le cloud](devops-with-cloud-managed-service-provider.md)
+ [Opérations cloud et habilitation de plateforme (COPE)](cloud-operations-and-platform-enablement.md)
+ [DevOps distribué](distributed-devops.md)
+ [DevOps décentralisé](decentralized-devops.md)
+ [Évolution de votre modèle d’exploitation](evolving-your-ops-model.md)
# Modèle d’exploitation entièrement séparé
Dans le graphique suivant, l’axe vertical représente les applications et plateformes. Les applications font référence à la charge de travail servant un résultat métier et peuvent être des logiciels personnalisés développés ou achetés. La plateforme fait référence à l’infrastructure physique et virtuelle, ainsi qu’à d’autres logiciels prenant en charge cette charge de travail.
L’ingénierie et les opérations se trouvent sur l’axe horizontal. L’ingénierie fait référence au développement, à la conception et aux tests d’applications et d’infrastructures. Les opérations font référence au déploiement, à la mise à jour et à la prise en charge continue des applications et de l’infrastructure.
![\[Schéma de modèle traditionnel\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
Historiquement, les organisations ont adopté des cadres tels que l’ITIL ou des normes telles que l’ISO et ont façonné leurs activités opérationnelles en fonction de ceux-ci, ce qui a souvent abouti à une topologie totalement séparée. Dans ce modèle, les activités de chaque quadrant sont effectuées par une équipe distincte. Le travail est transmis entre les équipes via des mécanismes tels que des demandes de travail, des files d’attente, des tickets ou à l’aide d’un système de gestion des services informatiques (ITSM).
La transition des tâches vers ou entre les équipes est facteur de complexité et crée des goulots d’étranglement et des retards. Les demandes peuvent être retardées jusqu’à ce qu’elles deviennent urgentes. Les défauts identifiés tardivement peuvent nécessiter une refonte importante et peuvent avoir à passer à nouveau par les mêmes équipes et leurs fonctions. Si certains incidents nécessitent une action de la part des équipes d’ingénierie, leurs réponses sont retardées par l’activité de transfert.
Il existe un risque plus élevé de décalage lorsque les équipes métier, de développement et d’opérations sont organisées autour des activités ou des fonctions qui sont exécutées. Les équipes peuvent ainsi se concentrer sur leurs responsabilités spécifiques au lieu de se concentrer sur l’obtention de résultats métier. Les équipes peuvent être très spécialisées, physiquement ou logiquement isolées, ce qui empêche la communication et la collaboration.
# DevOps avec un fournisseur de services gérés dans le cloud
Le modèle DevOps avec fournisseur de services gérés dans le cloud suit la méthodologie « *vous le créez, vous l’exécutez » pour les équipes* d’application. Cependant, il se peut que votre organisation ne dispose pas des compétences ou des membres de l’équipe nécessaires pour soutenir une équipe dédiée à l’ingénierie et aux opérations de la plateforme, ou que vous ne soyez pas en mesure d’investir le temps et les efforts nécessaires pour le faire.
Il se peut aussi que vous souhaitiez disposer d’une équipe chargée de la plateforme qui se concentre sur la création de capacités qui différencient votre entreprise, mais que vous souhaitiez externaliser les opérations quotidiennes indifférenciées.
Les fournisseurs de services gérés tels que [AWS Managed Services](https://aws.amazon.com/managed-services/) ou les fournisseurs de [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) apportent leur expertise dans la mise en œuvre d’environnements cloud, et soutiennent vos exigences en matière de sécurité et de conformité ainsi que vos objectifs commerciaux.
![\[DevOps avec un fournisseur de services gérés dans le cloud\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
Pour cette variation, nous considérons la gouvernance comme centralisée et gérée par l’équipe en charge de la plateforme, avec la création de comptes et les stratégies gérées avec AWS Organizations et AWS Control Tower.
Ce modèle nécessite que vous modifiiez vos mécanismes pour qu’ils soient compatibles avec ceux de votre fournisseur de services. Il ne pallie pas les problèmes de goulots d’étranglement et les retards créés par la transition des tâches entre les équipes, y compris votre fournisseur de services, ni la nécessité potentielle de retraitement liée à l’identification tardive des défauts.
Vous tirez parti des normes, des bonnes pratiques, des processus et de l’expertise de vos fournisseurs. Vous bénéficiez également des avantages du développement continu de leurs offres de services.
L’ajout de services gérés à votre modèle d’exploitation peut vous faire gagner du temps et économiser des ressources, et maintenir vos équipes internes réduites et concentrées sur les résultats stratégiques qui différencieront votre entreprise, plutôt que de développer de nouvelles compétences et capacités. Cela peut également vous donner le temps de développer et de développer les capacités de votre propre plateforme sans ralentir vos programmes de migration vers le cloud.
# Opérations cloud et habilitation de plateforme (COPE)
Ce modèle d’activation des opérations et des plateformes dans le cloud (COPE) vise à établir une méthodologie « *vous le créez, vous l’exécutez* » en aidant les équipes d’application à effectuer les activités d’ingénierie et d’exploitation relatives à leurs charges de travail, en adoptant une culture DevOps.
Vos équipes d’application peuvent être chargées de migrer, d’adopter le cloud ou de moderniser vos charges de travail, mais n’ont pas forcément les compétences existantes pour prendre en charge de manière adéquate l’architecture et les opérations du cloud. Ce manque de compétences et de familiarité de l’équipe chargée des applications est susceptible de ralentir l’agilité de votre organisation et d’avoir un impact sur les résultats commerciaux.
Pour résoudre ce problème, utilisez l’expertise opérationnelle existante au sein de votre organisation pour aider les équipes d’application dans leur transition vers les opérations cloud. Il peut s’agir d’une équipe d’experts dédiée ou d’une équipe virtuelle dont les participants sont sélectionnés au sein de votre organisation. Cependant, l’objectif reste le même, à savoir fournir un soutien opérationnel qui renforce les capacités de l’équipe chargée de la charge de travail, en utilisant les principes d’automatisation basés sur le cloud, en supprimant le levage indifférencié de charges lourdes, en fournissant des modèles standardisés et en promouvant l’autonomie. L’objectif est de développer une maturité suffisante dans l’ensemble des fonctionnalités du cloud et de réduire la barrière des responsabilités opérationnelles afin que les équipes chargées des applications n’aient plus besoin d’un support supplémentaire.
Le modèle COPE met l’accent sur le niveau de charge de travail. Si cette approche est nécessaire pour plusieurs équipes à la fois, si vous réalisez un projet de migration complexe, à grande échelle et pluriannuel, ou si vous créez une plateforme pour soutenir ces initiatives, pensez à utiliser un Centre d’excellence cloud (CCoE). Il s’agit d’un mécanisme que beaucoup ont trouvé efficace lorsqu’ils cherchaient à accélérer leurs migrations vers le cloud et à transformer globalement leur organisation.
![\[Diagramme Opérations cloud et habilitation de plateforme (COPE)\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
Votre équipe d’ingénierie de plateforme crée une fine couche de fonctionnalités de base de plateforme partagée, qui sont basées sur des normes prédéfinies que les équipes d’application doivent adopter et sont fournies par l’équipe COPE. L’équipe d’ingénierie de la plateforme codifie les architectures et les modèles de référence de l’entreprise qui sont fournis aux équipes d’application par le biais d’un mécanisme en libre-service. À l’aide d’un service comme AWS Service Catalog, les équipes d’application peuvent déployer des architectures, des modèles, des services et des configurations de référence approuvés, conformes par défaut aux normes de gouvernance et de sécurité centralisées.
L’équipe d’ingénierie de la plateforme fournit également un ensemble normalisé de services (par exemple, des outils de développement, des outils d’observabilité, des outils de sauvegarde et de récupération, et des réseaux) aux équipes d’application.
L’équipe COPE gère et soutient les services standardisés et fournit une assistance aux équipes d’application pour établir leur présence dans le cloud sur la base des architectures et modèles de référence. Ils travaillent avec les équipes chargées des applications pour les aider à établir des opérations de base. Au cours de ce processus, les équipes d’application assument progressivement une plus grande responsabilité de leurs systèmes et de leurs ressources au fil du temps. L’équipe COPE est à l’origine d’une amélioration continue en collaboration avec l’équipe d’ingénierie de la plateforme et agit en tant que promoteur pour les équipes d’application.
Les équipes d’application reçoivent de l’aide pour mettre en place des environnements, des pipelines CI/CD, la gestion des changements, l’observabilité et la surveillance, et pour établir des processus de gestion des incidents et des événements, l’équipe COPE étant intégrée si nécessaire. L’équipe COPE travaille avec les équipes d’application à l’exécution de ces activités opérationnelles, en supprimant progressivement son implication, à mesure que les équipes d’application gagnent en responsabilités.
L’équipe d’application bénéficie des compétences de l’équipe COPE et des enseignements appris par l’organisation. Elle est protégée par les mécanismes de sécurité établis par la gouvernance centralisée. L’équipe d’application s’appuie sur des succès reconnus et bénéficie du développement continu des normes organisationnelles qu’elle a adoptées. Elle acquiert une meilleure compréhension du fonctionnement de sa charge de travail grâce au processus d’établissement de l’observabilité et de la surveillance, et est mieux à même de comprendre l’impact des changements qu’elle apporte à ses charges de travail.
L’équipe COPE conserve l’accès nécessaire pour soutenir les activités d’exploitation, pour fournir une vue des opérations d’entreprise couvrant les équipes d’application et pour apporter son aide dans la gestion des incidents critiques. Elle conserve la responsabilité des activités indifférenciées critiques, qu’elle satisfait grâce à des solutions standard applicables à grande échelle. Elle continue également à gérer les activités liées aux opérations automatisées et programmatiques standard pour les équipes d’application afin qu’elles puissent se concentrer sur la différenciation de leurs applications.
Vous bénéficiez des normes, des bonnes pratiques, des processus et de l’expertise de votre organisation grâce aux accomplissements de vos équipes. Vous établissez un mécanisme pour reproduire ces modèles fructueux avec les nouvelles équipes qui adopteront ou moderniseront dans le cloud. Ce modèle met l’accent sur la capacité de l’équipe COPE à aider l’équipe d’application à se consolider et à lui transmettre ses connaissances et artefacts. Il réduit les charges opérationnelles des équipes d’application qui les empêchent souvent de devenir indépendantes. Il établit des relations entre l’ingénierie de la plateforme, le COPE et les équipes d’application, créant ainsi une boucle de retour d’information pour soutenir l’évolution et l’innovation.
La mise en place de vos équipes d’ingénierie de plateforme et de COPE, tout en définissant des normes à l’échelle de l’organisation, peut faciliter l’adoption du cloud et soutenir les efforts de modernisation. En apportant le soutien supplémentaire d’une équipe COPE agissant en tant que consultants et partenaires de vos équipes d’application, vous pouvez éliminer les obstacles au niveau de la charge de travail qui ralentissent l’adoption par les équipes d’application des capacités bénéfiques du cloud.
# DevOps distribué
Le modèle DevOps distribué sépare (ou répartit) les responsabilités des opérations d’ingénierie des applications et des opérations d’ingénierie d’infrastructure entre les équipes d’ingénierie, conformément à la [méthodologie COPE](cloud-operations-and-platform-enablement.md).
Vos ingénieurs d’applications effectuent à la fois l’ingénierie et l’exploitation de leurs charges de travail. De même, vos ingénieurs d’infrastructure effectuent à la fois l’ingénierie et l’exploitation des plateformes qu’ils utilisent pour soutenir les équipes en charge des applications.
![\[Schéma du modèle DevOps distribué\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)
Dans cet exemple, nous considérons que la gouvernance est centralisée ailleurs au sein de l’organisation. Les normes sont distribuées, fournies ou partagées avec les équipes en charge des applications et des plateformes.
Utilisez des outils ou des services qui vous permettent de gérer de manière centralisée vos environnements sur plusieurs comptes, tels qu’[AWS Organizations](https://aws.amazon.com/organizations/). Des services tels que [AWS Control Tower](https://aws.amazon.com/controltower/features/) élargissent cette fonctionnalité de gestion en vous permettant de définir des plans (soutenant vos modèles d’exploitation) pour la configuration des comptes, d’appliquer une gouvernance continue en utilisant AWS Organizations et d’automatiser l’allocation de nouveaux comptes.
La méthodologie « *Vous le créez, vous l’exploitez* » ne signifie pas que l’équipe en charge des applications est responsable de l’ensemble de la pile, de la chaîne d’outils et de la plateforme.
L’équipe d’ingénierie de la plateforme fournit un ensemble normalisé de services (par exemple, des outils de développement, des outils de surveillance, des outils de sauvegarde et de récupération, et des réseaux) à l’équipe chargée de l’application. L’équipe en charge de la plateforme peut également fournir à l’équipe en charge des applications l’accès aux services de fournisseur de cloud approuvés, à des configurations spécifiques de ces derniers, ou aux deux.
Les mécanismes qui fournissent une fonctionnalité en libre-service pour déployer des services et des configurations approuvés, tels que Service Catalog, peuvent contribuer à limiter les délais associés aux demandes de traitement tout en renforçant la gouvernance.
L’équipe en charge de la plateforme permet une visibilité complète des piles afin que les équipes en charge des applications puissent faire la différence entre les problèmes liés à leurs composants d’application et les services et composants d’infrastructure consommés par leurs applications. L’équipe en charge de la plateforme peut également vous aider à configurer ces services et à améliorer les opérations de l’équipe en charge des applications.
Comme indiqué précédemment, il est essentiel qu’il existe des mécanismes permettant aux équipes chargées des applications de demander des ajouts, des modifications et des exceptions aux normes afin de soutenir les activités et l’innovation de leur application.
Le modèle DevOps distribué fournit de solides boucles de rétroaction aux équipes d’application. Les opérations quotidiennes d’une charge de travail augmentent les contacts avec les clients, soit par une interaction directe, soit indirectement par le biais de l’assistance et des demandes de fonctionnalités. Cette visibilité accrue permet aux équipes en charge des applications de résoudre les problèmes plus rapidement. L’engagement plus profond et les relations plus étroites permettent de mieux comprendre les besoins des clients et d’accélérer l’innovation.
Tout cela est également vrai pour l’équipe de la plateforme qui soutient les équipes d’application, car l’équipe de la plateforme doit considérer ces équipes d’application comme ses clients.
Les normes adoptées peuvent faire l’objet d’une approbation préalable, ce qui réduit la quantité de vérifications nécessaires pour la mise en production. La consommation des normes prises en charge et testées fournies par l’équipe en charge de la plateforme peut réduire la fréquence des problèmes liés à ces services. L’adoption de normes permet aux équipes chargées des applications de se concentrer sur la différenciation de leurs charges de travail.
# DevOps décentralisé
Le modèle DevOps décentralisé est une variante de la méthodologie « *vous le créez, vous l’exécutez »,* dans laquelle les opérations sont principalement gérées par les équipes chargées de la charge de travail.
Vos ingénieurs d’application s’occupent à la fois de l’ingénierie et de l’exploitation de leurs charges de travail. De même, vos ingénieurs d’infrastructure s’occupent à la fois de l’ingénierie et de l’exploitation des plateformes qu’ils utilisent pour soutenir les équipes d’application.
![\[Diagramme DevOps décentralisé\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
Pour cet exemple, nous considérons la gouvernance comme décentralisée. Les normes sont toujours soient partagées, soient distribuées ou fournies aux équipes en charge des applications par l’équipe en charge de la plateforme. Cependant, les équipes en charge des applications sont libres de concevoir et d’exploiter de nouvelles fonctionnalités de plateforme pour soutenir leur charge de travail.
Dans ce modèle, moins de contraintes pèsent sur l’équipe en charge des applications, mais cela entraîne une augmentation significative des responsabilités. Des compétences (et éventuellement des membres d’équipe supplémentaires) sont nécessaires pour prendre en charge les fonctionnalités supplémentaires de la plateforme. Le risque de retraitement important est accru si les ensembles de compétences ne sont pas appropriés et si les défauts ne sont pas reconnus rapidement.
Appliquez des stratégies qui ne sont pas spécifiquement déléguées aux équipes en charge des applications. Utilisez des outils ou des services qui vous permettent de gérer de manière centralisée vos environnements sur plusieurs comptes, tels qu’[AWS Organizations](https://aws.amazon.com/organizations/). Des services tels que [AWS Control Tower](https://aws.amazon.com/controltower/features/) élargissent cette fonctionnalité de gestion en vous permettant de définir des plans (soutenant vos modèles d’exploitation) pour la configuration des comptes, d’appliquer une gouvernance continue en utilisant AWS Organizations et d’automatiser l’allocation de nouveaux comptes.
Il est avantageux de disposer de mécanismes permettant à l’équipe en charge des applications de demander des ajouts aux normes ou leur modification. Ils peuvent ainsi contribuer à la conception de nouvelles normes qui peuvent être utiles à d’autres équipes en charge des applications. Les équipes en charge des plateformes peuvent décider que la prise en charge directe de ces fonctionnalités supplémentaires peut aider à l’obtention des résultats métier.
Ce modèle limite les obstacles à l’innovation avec des exigences importantes en matière de compétences et de membres d’équipe. Il pallie un grand nombre des goulets d’étranglement et de retards créés par la transition des tâches entre les équipes, tout en continuant à promouvoir le développement de relations efficaces entre les équipes et les clients.
# Évolution de votre modèle d’exploitation
Les modèles proposés évoluent progressivement vers une plus grande autonomie au niveau de la charge de travail, conformément au principe de l’équipe à deux pizzas. Il est important de comprendre que le passage d’une approche traditionnelle à un DevOps décentralisé (comme base d’une évolution continue vers un modèle d’équipe à deux pizzas) risque de prendre du temps et de nécessiter le renforcement de la maturité dans un certain nombre de fonctionnalités. Nous avons donc fourni un exemple de la manière dont vous pouvez passer d’un modèle à un autre au fur et à mesure que votre équipe et votre organisation progressent dans le processus de transformation de l’entreprise. À chaque changement ou modèle, vous évoluez vers une équipe plus autonome, mais toujours alignée sur le plan organisationnel.
![\[Schéma d’évolution du modèle d’exploitation cloud, des flux de valeur et des processus sur site aux flux de valeur et processus automatisés\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
Lorsque vous évaluez la manière dont votre équipe peut soutenir l’évolution de votre organisation, examinez les compromis entre les modèles, la place de vos équipes individuelles dans les modèles (au fur et à mesure de leur transition et de leur évolution), la manière dont les relations et les responsabilités de votre équipe pourraient changer, et si les avantages méritent l’impact sur votre organisation. N’oubliez pas que le changement n’est jamais linéaire. Certains modèles sont plus adaptés à des cas d’utilisation ou à des étapes spécifiques du parcours, et certains de ces modèles peuvent présenter des avantages par rapport à ceux de votre environnement.