# Modèle d’exploitation
Dans cette section, nous vous proposons de comprendre le modèle opérationnel dans lequel vous travaillez, comment ce modèle peut être visualisé et comment, au niveau de l’équipe, vous devez évoluer pour tirer le maximum de valeur de votre investissement dans les services en nuage. Ce faisant, vous pouvez améliorer vos pratiques opérationnelles, créer des équipes et des charges de travail agiles et contribuer de manière positive aux résultats commerciaux.
Il est courant que votre équipe existe au sein de plusieurs niveaux organisationnels, et ces niveaux ont des méthodes de travail existantes. Pour participer avec votre équipe à l’atteinte des résultats commerciaux, vous devez comprendre où se situent vos équipes dans ces couches, la position des équipes avec lesquelles vous interagissez et leur mode de travail. De plus, les équipes doivent comprendre leur rôle dans la réussite des autres équipes, connaître le rôle des autres équipes dans leur réussite, et avoir des objectifs communs.
Ces couches constituent le modèle opérationnel global de l’organisation. La manière dont l’organisation fonctionne pour obtenir des résultats commerciaux dépend de nombreux facteurs, tels que le type, le secteur d’activité, la géographie, la taille et le niveau d’autonomie. Cependant, il se divise probablement en trois grandes catégories :
+ Centralisée
+ Décentralisée
+ Fédérée
Ces topologies au niveau de l’organisation sont décrites dans [Organiser pour réussir](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize).
Votre équipe et votre charge de travail s’inscrivent dans le modèle opérationnel de votre organisation. Il n’est toutefois pas raisonnable de penser qu’un seul modèle d’exploitation puisse prendre en charge toutes les équipes et leurs charges de travail. Par conséquent, votre équipe a également besoin de son propre modèle de fonctionnement. Cette façon de travailler est façonnée par votre organisation, votre service, la composition de votre équipe et les caractéristiques de la charge de travail elle-même.
La plupart des entreprises qui migrent vers le cloud le font dans le cadre d’un programme de transformation d’entreprise qui vise à découvrir de nouvelles méthodes de travail (le modèle opérationnel) afin de soutenir des objectifs stratégiques à long terme. Ce voyage n’est pas un exercice ponctuel, mais un processus qui nécessite une évolution continue et des progrès progressifs vers l’objectif stratégique. Cela permet aux responsables des charges de travail de s’adapter à l’évolution du modèle d’exploitation avec un minimum de perturbations.
Amazon est souvent cité comme exemple de la capacité d’une grande entreprise à innover à grande échelle en permettant aux équipes de rester proches des clients, de lancer rapidement des produits et services innovants et de tirer parti d’architectures techniques qui favorisent rapidité et agilité. Cela nous a obligés à restructurer l’organisation de nos équipes, désormais connues sous le nom *d’équipes à deux pizzas*. Une équipe composée de deux personnes dispose de toutes les ressources nécessaires (ingénierie, tests, gestion des produits et des programmes, opérations) pour gérer et gérer une charge de travail de bout en bout.
Nous conseillons d’adopter ce modèle opérationnel comme moyen éprouvé pour les équipes chargées de la charge de travail d’agir rapidement et de contribuer aux résultats commerciaux globaux de la manière qui répond au mieux aux besoins de leurs clients.
Organisations qui cherchent à imiter ce succès peuvent avoir besoin d’adapter leur modèle opérationnel tout au long de leur parcours de transformation. Au niveau de l’organisation comme au niveau de l’équipe, cela nécessite de la réflexion, de la planification et de la communication. La section suivante fournit un moyen de visualiser ces modèles opérationnels au niveau de l’équipe et leur évolution au fur et à mesure *que vous les créez et que vous les exécutez*.
# 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.
# Relations et propriété
Votre modèle d’exploitation définit les relations entre les équipes et permet l’identification des propriétés et responsabilités.
**Topics**
+ [OPS02-BP01 Les ressources ont identifié les propriétaires](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Des mécanismes sont en place pour gérer les responsabilités et qui est responsable de quoi](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 Des mécanismes sont en place pour demander des ajouts, des modifications et des dérogations](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 Les responsabilités entre les équipes sont prédéfinies ou négociées](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 Les ressources ont identifié les propriétaires
Les ressources de votre charge de travail doivent disposer de propriétaires identifiés pour le contrôle des modifications, le dépannage et d’autres fonctions. Des propriétaires sont désignés pour les charges de travail, les comptes, l’infrastructure, les plateformes et les applications. La propriété est enregistrée à l’aide d’outils tels qu’un registre central ou des métadonnées attachées aux ressources. La valeur commerciale des composants informe les processus et les procédures qui leur sont appliqués.
**Résultat escompté :**
+ Les ressources disposent de propriétaires identifiés à l’aide de métadonnées ou d’un registre central.
+ Les membres de l’équipe peuvent identifier le propriétaire des ressources.
+ Les comptes disposent d’un propriétaire unique dans la mesure du possible.
**Anti-modèles courants :**
+ Les contacts alternatifs pour vous ne Comptes AWS sont pas renseignés.
+ Les ressources manquent de balises permettant d’identifier les équipes qui les possèdent.
+ Vous avez une ITSM file d'attente sans mappage d'e-mails.
+ Deux équipes se partagent la propriété d’un élément d’infrastructure critique.
**Avantages liés au respect de cette bonne pratique :**
+ Le contrôle des modifications pour les ressources est simple et la propriété est attribuée.
+ Vous pouvez impliquer les bons propriétaires lors du dépannage des problèmes.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Définissez ce que signifie la propriété pour les cas d’utilisation des ressources dans votre environnement. La propriété peut signifier qui supervise les modifications apportées à la ressource, qui prend en charge la ressource pendant le dépannage, ou qui est financièrement responsable. Précisez et enregistrez les propriétaires des ressources, y compris, le nom, les coordonnées, l’organisation et l’équipe.
**Exemple client**
AnyCompany Le commerce de détail définit la propriété comme l'équipe ou l'individu responsable des changements et du soutien aux ressources. Ils tirent parti AWS Organizations de leur Comptes AWS. Les autres contacts de comptes sont configurés via des boîtes de réception de groupe. Chaque ITSM file d'attente est mappée à un alias d'e-mail. Les balises identifient les propriétaires AWS des ressources. Pour les autres plateformes et infrastructures, ces personnes disposent d’une page wiki qui identifie les propriétaires et les informations de contact.
### Étapes d’implémentation
1. Commencez par définir la propriété dans votre organisation. La propriété peut impliquer qui est responsable du risque pour la ressource, qui est responsable des modifications apportées à la ressource, ou qui prend en charge la ressource lors du dépannage. La propriété peut également impliquer la propriété financière ou administrative de la ressource.
1. Utilisez [AWS Organizations](https://aws.amazon.com/organizations/) pour gérer les comptes. Vous pouvez gérer les autres contacts de vos comptes de manière centralisée.
1. Grâce aux adresses e-mail et aux numéros de téléphone appartenant à l’entreprise, vous pourrez y accéder même si les personnes qui les consultent ne font plus partie de votre entreprise. Par exemple, créez des listes de distribution d’e-mails distinctes pour la facturation, les opérations et la sécurité, et configurez-les en tant que contacts Facturation, Sécurité et Opérations dans chaque Compte AWS actif. Plusieurs personnes recevront des AWS notifications et pourront y répondre, même si une personne est en vacances, change de rôle ou quitte l'entreprise.
1. Si un compte n’est pas géré par [AWS Organizations](https://aws.amazon.com/organizations/), d’autres contacts de compte aident AWS à contacter le personnel approprié si nécessaire. Configurez les autres contacts du compte pour qu’ils pointent vers un groupe plutôt que vers un individu.
1. Utilisez des balises pour identifier les propriétaires des AWS ressources. Vous pouvez indiquer les deux propriétaires et leurs coordonnées dans des balises distinctes.
1. Vous pouvez utiliser des règles [AWS Config](https://aws.amazon.com/config/) pour garantir que les ressources possèdent les balises de propriété requises.
1. Pour obtenir des conseils détaillés sur la façon d’élaborer une stratégie de balisage pour votre organisation, consultez le [livre blanc sur les bonnes pratiques en matière de balisage AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
1. Utilisez [Amazon Q Business](https://aws.amazon.com/q/business/), un assistant conversationnel qui utilise l’IA générative pour améliorer la productivité du personnel, répondre aux questions et effectuer des tâches en fonction des informations contenues dans les systèmes de votre entreprise.
1. Connectez Amazon Q Business à la source de données de votre entreprise. Amazon Q Business propose des connecteurs prédéfinis vers plus de 40 sources de données prises en charge, notamment Amazon Simple Storage Service (Amazon S3), SharePoint Microsoft, Salesforce et Atlassian Confluence. Pour plus d’informations, consultez la section [Connecteurs Amazon Q Business](https://aws.amazon.com/q/business/connectors/).
1. Pour les autres ressources, plateformes et infrastructures, créez une documentation qui identifie la propriété. Tous les membres de l’équipe doivent y avoir accès.
**Niveau d’effort du plan d’implémentation :** faible Utilisez les informations de contact et les tags du compte pour attribuer la propriété des AWS ressources. Pour les autres ressources, vous pouvez utiliser quelque chose d'aussi simple qu'un tableau dans un wiki pour enregistrer les informations de propriété et de contact, ou utiliser un ITSM outil pour cartographier les propriétaires.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP02 Les processus et les procédures ont identifié les propriétaires](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 Des mécanismes existent pour gérer les responsabilités et la propriété](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**Documents connexes :**
+ [Gestion des comptes AWS : mise à jour des informations de contact](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Mise à jour des contacts alternatifs au sein de votre organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [Livre blanc des Bonnes pratiques de balisage AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Créez des applications d'IA génératives d'entreprise privées et sécurisées avec Amazon Q Business and AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, désormais disponible pour le grand public, contribue à améliorer la productivité du personnel grâce à l’IA générative](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS Cloud Blog sur les opérations et les migrations - Mise en œuvre de contrôles de balisage automatisés et centralisés avec AWS Config et AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Blog de sécurité - Étendez vos hooks de pré-validation avec AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Intégration AWS CloudFormation Guard dans les pipelines CI/CD](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Ateliers connexes :**
+ [Atelier AWS : étiquetage](https://catalog.workshops.aws/tagging/)
**Exemples connexes :**
+ [AWS Config Rules - Amazon EC2 avec les balises obligatoires et les valeurs valides](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**Services connexes :**
+ [AWS Config Rules - étiquettes obligatoires](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 Les processus et procédures ont des propriétaires identifiés
Déterminez qui est propriétaire de la définition des différents processus et procédures individuels, pourquoi ces processus et procédures sont utilisés et pourquoi cette propriété existe. La compréhension des raisons pour lesquelles des processus et des procédures spécifiques sont utilisés permet d’identifier les possibilités d’amélioration.
**Résultat escompté :** votre organisation dispose d’un ensemble défini et géré de processus et de procédures pour les tâches opérationnelles. Le processus et les procédures sont stockés dans un emplacement central et mis à la disposition des membres de votre équipe. Le processus et les procédures sont fréquemment mis à jour, par un propriétaire clairement désigné. Dans la mesure du possible, les scripts, les modèles et les documents d’automatisation sont implémentés sous forme de code.
**Anti-modèles courants :**
+ Les processus ne sont pas documentés. Des scripts fragmentés peuvent exister sur les postes de travail d’opérateurs isolés.
+ La connaissance de l’utilisation des scripts est détenue par quelques personnes ou de manière informelle en tant que connaissance d’équipe.
+ Un ancien processus doit être actualisé, mais la propriété de l’actualisation est incertaine et l’auteur d’origine ne fait plus partie de l’organisation.
+ Les processus et les scripts ne sont pas détectables, ils ne sont donc pas facilement disponibles en cas de besoin (par exemple, pour répondre à un incident).
**Avantages liés au respect de cette bonne pratique :**
+ Les processus et les procédures dynamisent vos efforts pour gérer vos charges de travail.
+ Les nouveaux membres de l’équipe deviennent efficaces plus rapidement.
+ Réduction du temps nécessaire pour atténuer les incidents.
+ Différents membres de l’équipe (et différentes équipes) peuvent utiliser les mêmes processus et procédures de manière cohérente.
+ Les équipes peuvent mettre à l’échelle leurs processus à l’aide de processus reproductibles.
+ Les processus et procédures normalisés contribuent à atténuer l’impact du transfert des responsabilités liées à la charge de travail entre les équipes.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
+ Les processus et procédures ont un propriétaire identifié qui est responsable de leur définition.
+ Identifiez les activités des opérations réalisées à l’aide de vos charges de travail. Documentez ces activités dans un emplacement détectable.
+ Identifiez de façon unique l’individu ou l’équipe responsable de la spécification d’une activité. Il incombe à l’individu ou à l’équipe de vérifier qu’elle peut être exécutée avec succès par un membre de l’équipe disposant des autorisations, des accès et des outils appropriés. En cas de problème lié à l’exécution de l’activité, les membres de l’équipe chargés de cette tâche sont tenus de fournir les commentaires détaillés nécessaires à son amélioration.
+ Capturez la propriété des métadonnées de l’artefact d’activité par le biais de services tels qu’AWS Systems Manager, via des documents, et AWS Lambda. Capturez la propriété des ressources à l’aide de balises ou de groupes de ressources, en spécifiant les informations de propriété et de contact. Utilisez AWS Organizations pour créer des stratégies de balisage et capturer les informations de propriété et de contact.
+ Au fil du temps, ces procédures doivent évoluer pour être exécutables sous forme de code, ce qui réduit la nécessité d’une intervention humaine.
+ Réfléchissez par exemple aux fonctions AWS Lambda, aux modèles CloudFormation ou aux documents d’automatisation AWS Systems Manager.
+ Effectuez le contrôle des versions dans les référentiels appropriés.
+ Incluez un balisage approprié des ressources afin que les propriétaires et la documentation puissent être facilement identifiés.
**Exemple client**
AnyCompany Retail définit la propriété comme l’équipe ou la personne qui possède les processus d’une application ou de groupes d’applications (qui partagent des pratiques et des technologies architecturales communes). Dans un premier temps, le processus et les procédures sont documentés sous forme de guides détaillés dans le système de gestion de documents, détectables à l’aide de balises sur le Compte AWS qui héberge l’application et sur des groupes spécifiques de ressources du compte. Ces personnes utilisent AWS Organizations pour gérer leurs Comptes AWS. Au fil du temps, ces processus sont convertis en code et les ressources sont définies à l’aide de l’infrastructure sous forme de code (par exemple, les modèles CloudFormation ou AWS Cloud Development Kit (AWS CDK)). Les processus opérationnels deviennent des documents d’automatisation dans AWS Systems Manager ou des fonctions AWS Lambda, que vous pouvez lancer en tant que tâches planifiées, en réponse à des événements tels que des alarmes AWS CloudWatch ou des événements AWS EventBridge, ou que vous pouvez démarrer par des demandes au sein d’une plateforme de gestion des services informatiques (ITSM). Tous les processus comportent des balises pour identifier leur propriété. La documentation relative à l’automatisation et au processus est conservée dans les pages wiki générées par le référentiel de code pour le processus.
### Étapes d’implémentation
1. Documentez les processus et procédures existants.
1. Révisez-les et veillez à leur actualisation.
1. Identifiez un propriétaire pour chaque processus ou procédure.
1. Placez-les sous le contrôle des versions.
1. Dans la mesure du possible, partagez les processus et les procédures entre les charges de travail et les environnements qui ont des conceptions architecturales en commun.
1. Mettez en place des mécanismes de commentaires et d’amélioration.
1. Définissez des politiques relatives à la fréquence à laquelle les processus doivent être révisés.
1. Définissez les processus pour les réviseurs et les approbateurs.
1. Consignez les problèmes ou établissez des files d’attente de tickets afin que les commentaires puissent être transmis et faire l’objet d’un suivi.
1. Dans la mesure du possible, les processus et procédures doivent faire l’objet d’une approbation préalable et d’une classification des risques par un comité d’approbation des modifications (CAB).
1. Vérifiez que les processus et les procédures sont accessibles et détectables par ceux qui ont besoin de les exécuter.
1. Utilisez des balises pour indiquer où accéder au processus et aux procédures pour la charge de travail.
1. Utilisez des messages d’erreur et d’événements significatifs afin d’indiquer les processus ou procédures appropriés pour résoudre un problème.
1. Utilisez les wikis et la gestion des documents, et veillez à ce que les processus et les procédures puissent être consultés par l’ensemble de l’organisation.
1. Utilisez [Amazon Q Business](https://aws.amazon.com/q/business/), un assistant conversationnel qui utilise l’IA générative pour améliorer la productivité du personnel, répondre aux questions et effectuer des tâches en fonction des informations contenues dans les systèmes de votre entreprise.
1. Connectez Amazon Q Business à la source de données de votre entreprise. Amazon Q Business propose des connecteurs prédéfinis vers plus de 40 sources de données prises en charge, notamment Amazon S3, Microsoft SharePoint, Salesforce et Atlassian Confluence. Pour plus d’informations, consultez [Connecteurs Amazon Q](https://aws.amazon.com/q/business/connectors/).
1. Automatisez le cas échéant.
1. Les automatisations doivent être développées lorsque les services et les technologies fournissent une API.
1. Formez de manière adéquate aux processus. Développez les témoignages d’utilisateurs et les exigences pour automatiser ces processus.
1. Mesurez l’utilisation réussie de vos processus et procédures, et créez des problèmes ou des tickets pour soutenir l’amélioration itérative.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées:**
+ [OPS02-BP01 Les ressources ont des propriétaires identifiés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Des mécanismes sont en place pour gérer les responsabilités et qui est responsable de quoi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 Gestion des connaissances](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documents connexes:**
+ [AWS Livre blanc : présentation du DevOps sur AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Livre blanc AWS : bonnes pratiques en matière de balisage des ressources AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Livre blanc AWS : organisation de votre environnement AWS à l’aide de comptes multiples](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Blog sur les migrations et opérations cloud AWS Cloud : utilisation d’Amazon Q Business pour rationaliser vos opérations ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS Cloud Blog sur les opérations et les migrations : Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Blog sur les opérations et les migrations AWS Cloud : mise en œuvre de contrôles de balisage automatisés et centralisés avec AWS Config et AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Blog de sécurité : extension de vos hooks de pré-validation avec AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [Blog DevOps AWS : intégration de AWS CloudFormation Guard dans des pipelines CI/CD](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Ateliers connexes:**
+ [AWS Atelier sur l’excellence opérationnelle Well-Architected](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS Atelier : étiquetage](https://catalog.workshops.aws/tagging/)
**Vidéos connexes:**
+ [Comment automatiser des opérations informatiques sur AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Supports You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**Services connexes:**
+ [AWS Systems Manager - automatisation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Connecteur AWS Service Management](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances
Déterminez qui est chargé d’exécuter des activités spécifiques sur des charges de travail définies et pourquoi cette responsabilité existe. La détermination de la personne responsable de l’exécution des activités indique qui va mener l’activité, valider le résultat et fournir des commentaires au propriétaire de l’activité.
**Résultat escompté :**
Votre organisation définit clairement les responsabilités relatives à l’exécution d’activités spécifiques sur des charges de travail définies et répond aux événements générés par la charge de travail. L’organisation documente la propriété des processus et de leur exécution et rend ces informations détectables. Vous passez en revue et mettez à jour les responsabilités lorsque des changements organisationnels se produisent, et les équipes suivent et mesurent les performances des activités d’identification des défauts et des inefficacités. Vous mettez en œuvre des mécanismes de rétroaction pour suivre les défauts et les améliorations et soutenir l’amélioration itérative.
**Anti-modèles courants :**
+ Vous ne documentez pas les responsabilités.
+ Des scripts fragmentés existent sur les postes de travail des opérateurs isolés. Seules quelques personnes savent comment les utiliser ou les qualifier de manière informelle de *connaissances d’équipe*.
+ Un ancien processus doit être mis à jour, mais personne ne sait qui en a la responsabilité, et l’auteur d’origine ne fait plus partie de l’organisation.
+ Les processus et les scripts ne sont pas détectables, ils ne sont donc pas facilement disponibles en cas de besoin (par exemple, pour répondre à un incident).
**Avantages liés au respect de cette bonne pratique :**
+ Vous savez qui est responsable de l’exécution d’une activité, qui avertir lorsqu’une action est nécessaire et qui exécute l’action, qui valide le résultat et qui fournit des commentaires au responsable de l’activité.
+ Les processus et les procédures dynamisent vos efforts pour gérer vos charges de travail.
+ Les nouveaux membres de l’équipe deviennent efficaces plus rapidement.
+ Vous réduisez le temps nécessaire pour atténuer les incidents.
+ Les différentes équipes utilisent les mêmes processus et procédures pour effectuer les tâches de manière cohérente.
+ Les équipes peuvent mettre à l’échelle leurs processus à l’aide de processus reproductibles.
+ Les processus et procédures normalisés contribuent à atténuer l’impact du transfert des responsabilités liées à la charge de travail entre les équipes.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Pour commencer à définir les responsabilités, commencez par la documentation existante, comme les matrices de responsabilité, les processus et les procédures, les rôles et les responsabilités, ainsi que les outils et l’automatisation. Passez en revue et animez des discussions sur les responsabilités relatives aux processus documentés. Passez en revue les responsabilités avec les équipes pour identifier les incohérences entre les responsabilités et les processus des documents. Discutez des services proposés avec les clients internes de cette équipe afin d’identifier les écarts entre les équipes en matière d’attentes.
Analysez et corrigez les écarts. Identifiez les opportunités d’amélioration et recherchez les activités gourmandes en ressources et fréquemment demandées, qui sont généralement de bonnes candidates à l’amélioration. Explorez les bonnes pratiques, les modèles et les conseils prescriptifs pour simplifier et standardiser les améliorations. Enregistrez les opportunités d’amélioration et suivez les améliorations jusqu’à leur achèvement.
Au fil du temps, ces procédures doivent évoluer pour être exécutées sous forme de code, ce qui réduit la nécessité d’une intervention humaine. Par exemple, les procédures peuvent être lancées sous forme de fonctions AWS Lambda, de modèles CloudFormation ou de documents AWS Systems Manager Automatisation. Vérifiez que ces procédures sont contrôlées par version dans les référentiels appropriés et incluez un balisage des ressources adéquat afin que les équipes puissent identifier facilement les personnes responsables et la documentation. Documentez la responsabilité de l’exécution des activités, puis surveillez les automatisations pour garantir un démarrage et un fonctionnement réussis, ainsi que la performance des résultats souhaités.
**Exemple client**
AnyCompany Retail définit la propriété comme l’équipe ou la personne qui possède les processus d’une application ou de groupes d’applications (qui partagent des pratiques et des technologies architecturales communes). Dans un premier temps, l’entreprise documente les processus et les procédures sous forme de guides détaillés dans le système de gestion des documents. Elle fait en sorte que les procédures soient détectables à l’aide de balises sur le Compte AWS qui héberge l’application et sur des groupes spécifiques de ressources dans ce compte, en utilisant AWS Organizations pour gérer ses Comptes AWS. Au fil du temps, AnyCompany Retail convertit ces processus en code et définit les ressources en utilisant l’infrastructure sous forme de code (via des services tels que CloudFormation ou des modèles AWS Cloud Development Kit (AWS CDK)). Les processus opérationnels deviennent des documents d’automatisation dans AWS Systems Manager ou des fonctions AWS Lambda, que vous pouvez lancer en tant que tâches planifiées, en réponse à des événements tels que des alarmes Amazon CloudWatch ou des événements Amazon EventBridge, ou que vous pouvez démarrer par des demandes au sein d’une plateforme de gestion des services informatiques (ITSM). Tous les processus ont des balises pour identifier leur propriétaire. Les équipes gèrent la documentation relative à l’automatisation et au processus dans les pages wiki générées par le référentiel de code pour ce processus.
### Étapes d’implémentation
1. Documentez les processus et procédures existants.
1. Passez-les en revue et vérifiez qu’ils sont à jour.
1. Vérifiez que chaque processus ou procédure est associé à un responsable.
1. Placez les procédures sous contrôle des versions.
1. Dans la mesure du possible, partagez les processus et les procédures entre les charges de travail et les environnements qui ont des conceptions architecturales en commun.
1. Mettez en place des mécanismes de commentaires et d’amélioration.
1. Définissez des politiques relatives à la fréquence à laquelle les processus doivent être révisés.
1. Définissez les processus pour les réviseurs et les approbateurs.
1. Mettez en œuvre une file d’attente de problèmes ou de tickets pour fournir et suivre les commentaires.
1. Dans la mesure du possible, fournissez une approbation préalable et une classification des risques pour les processus et procédures effectuées par un comité d’approbation des modifications.
1. Rendez les processus et les procédures accessibles et détectables par les utilisateurs qui ont besoin de les exécuter.
1. Utilisez des balises pour indiquer où accéder au processus et aux procédures pour la charge de travail.
1. Utilisez des messages d’erreur et d’événements significatifs afin d’indiquer les processus ou procédures appropriés pour résoudre le problème.
1. Utilisez les wikis ou la gestion de documents pour rendre les processus et les procédures consultables de manière cohérente dans l’ensemble de l’organisation.
1. Recourez à l’automatisation lorsque cela est approprié.
1. Lorsque les services et les technologies fournissent une API, développez des automatisations.
1. Vérifiez que les processus sont bien compris et développez les témoignages d’utilisateurs et les exigences pour automatiser ces processus.
1. Mesurez l’utilisation réussie des processus et des procédures, avec un suivi des problèmes pour favoriser une amélioration itérative.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP01 Les ressources ont des propriétaires identifiés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Des mécanismes sont en place pour gérer les responsabilités et qui est responsable de quoi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 Des mécanismes sont en place pour identifier la responsabilité et la propriété](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 Gestion des connaissances](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documents connexes :**
+ [Livre blanc AWS \$1 Présentation du DevOps sur AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Livre blanc AWS \$1 Bonnes pratiques en matière de balisage des ressources AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Livre blanc AWS \$1 Organisation de votre environnement AWS à l’aide de comptes multiples](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Blog sur les opérations et les migrations AWS Cloud \$1 Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Atelier AWS : étiquetage](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**Vidéos connexes :**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Supports You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 Des mécanismes sont en place pour gérer les responsabilités et qui est responsable de quoi
L’identification des responsabilités de votre rôle et de la manière dont vous contribuez aux résultats de l’entreprise permet de définir les priorités de vos tâches et de comprendre pourquoi votre rôle est important. Cette approche permet aux membres de l’équipe d’identifier les besoins et d’y répondre de manière appropriée. Lorsque les membres de l’équipe connaissent leur rôle, ils savent qui est propriétaire, ils identifient les opportunités d’amélioration et ils comprennent comment influencer ou apporter les changements appropriés.
Il arrive qu’une responsabilité ne soit pas clairement attribuée à une personne en particulier. Dans ce cas, concevez un mécanisme permettant de combler cette lacune. Créez un chemin hiérarchique bien défini qui renvoie vers une personne habilitée à attribuer la responsabilité à un rôle spécifique ou à prévoir le nécessaire pour répondre à ce besoin.
**Résultat escompté :** les équipes de votre organisation ont des responsabilités clairement définies qui incluent la manière dont elles sont liées aux ressources, aux actions à effectuer, aux processus et aux procédures. Ces responsabilités correspondent aux responsabilités et aux objectifs de l’équipe, ainsi qu’à celles des autres équipes. Vous documentez les chemins hiérarchiques de manière cohérente et transparente, et vous intégrez ces décisions dans des artefacts de documentation, tels que des matrices de responsabilité, des définitions d’équipes ou des pages wiki.
**Anti-modèles courants :**
+ Les responsabilités de l’équipe sont ambiguës ou mal définies.
+ L’équipe n’attribue pas les responsabilités à des rôles spécifiques.
+ L’équipe n’aligne pas ses buts et ses objectifs sur ses responsabilités, ce qui rend difficile la mesure du succès.
+ Les responsabilités des membres de l’équipe ne correspondent pas à celles de l’équipe et de l’organisation dans son ensemble.
+ Votre équipe ne tient pas les responsabilités à jour, ce qui les rend incompatibles avec les tâches qu’elle effectue.
+ Les chemins hiérarchiques permettant de déterminer les responsabilités ne sont pas définis ou ne sont pas clairs.
+ Les chemins hiérarchiques n’ont pas de responsable de thread unique pour garantir une réponse rapide.
+ Les rôles, les responsabilités et les chemins hiérarchiques ne sont pas détectables, et ils ne sont donc pas facilement disponibles en cas de besoin (par exemple, en réponse à un incident).
**Avantages liés au respect de cette bonne pratique :**
+ Lorsque vous savez qui est responsable ou propriétaire, vous pouvez contacter l’équipe ou le membre de l’équipe concerné pour faire une demande ou transférer une tâche.
+ Pour réduire le risque d’inaction et de besoins non satisfaits, vous avez identifié une personne habilitée à attribuer la responsabilité ou la propriété.
+ Lorsque vous définissez clairement l’étendue d’une responsabilité, les membres de votre équipe gagnent en autonomie et en propriété.
+ Vos responsabilités éclairent les décisions que vous prenez, les actions que vous effectuez et vos activités de transfert à leurs véritables propriétaires.
+ Il est facile d’identifier des responsabilités abandonnées, car vous comprenez clairement ce qui ne relève pas de la responsabilité de votre équipe, ce qui vous permet de demander des éclaircissements.
+ Les équipes évitent la confusion et les tensions, et elles gèrent leurs charges de travail et leurs ressources de manière plus adéquate.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Identifiez les rôles et responsabilités des membres de l’équipe et assurez-vous qu’ils comprennent les attentes de leur rôle. Rendez ces informations accessibles afin que les membres de votre organisation sachent qui contacter, que ce soit une équipe ou une personne, pour des besoins spécifiques. Lorsque les organisations cherchent à tirer parti des opportunités de migration et de modernisation sur AWS, les rôles et les responsabilités peuvent également changer. Tenez vos équipes et leurs membres conscients de leurs responsabilités et formez-les de manière appropriée pour qu’ils s’acquittent de leurs tâches pendant ce changement.
Déterminez le rôle ou l’équipe qui doit recevoir les remontées hiérarchiques afin d’identifier les responsabilités et la propriété. Cette équipe peut dialoguer avec différentes parties prenantes pour prendre une décision. Cependant, elle doit être responsable de la gestion du processus de prise de décision.
Fournissez des mécanismes accessibles aux membres de votre organisation pour découvrir et identifier la propriété et la responsabilité. Ces mécanismes leur indiquent à qui s’adresser pour des besoins spécifiques.
**Exemple client**
AnyCompany Retail a récemment effectué une migration des charges de travail d’un environnement sur site vers sa zone de destination dans AWS en utilisant une approche de type « lift-and-shift ». Cette société a effectué un examen des opérations afin de réfléchir à la manière d’accomplir les tâches opérationnelles courantes, et a vérifié que sa matrice de responsabilité existante reflétait les opérations dans le nouvel environnement. Lors de la migration de l’infrastructure sur site vers AWS, elle a réduit les responsabilités de l’équipe chargée de l’infrastructure en ce qui concerne le matériel et l’infrastructure physique. Cette décision a également révélé de nouvelles opportunités de faire évoluer le modèle opérationnel pour ses charges de travail.
Tout en identifiant, en abordant et en documentant la majorité des responsabilités, elle a également défini des chemins hiérarchiques pour toutes les responsabilités qui n’ont pas été respectées ou qui pourraient changer à mesure que les pratiques opérationnelles évoluent. Pour explorer de nouvelles opportunités de standardisation et d’amélioration de l’efficacité de vos charges de travail, donnez accès à des outils opérationnels comme AWS Systems Manager et à des outils de sécurité comme AWS Security Hub CSPM et Amazon GuardDuty. L’entreprise AnyCompany Retail organise une révision de ses responsabilités et de sa stratégie en fonction des améliorations qu’elle souhaite apporter en premier lieu. Au fur et à mesure que l’entreprise adopte de nouvelles méthodes de travail et de nouveaux modèles technologiques, elle met à jour sa matrice de responsabilité en conséquence.
### Étapes d’implémentation
1. Commencez par la documentation existante. Certains documents sources classiques peuvent inclure les éléments suivants :
1. Matrices de responsabilité ou matrices RACI (Responsible, Accountable, Consulted, and Informed)
1. Définitions des équipes ou pages wiki
1. Définitions et offres de services
1. Descriptions de rôle ou de poste
1. Passez en revue les responsabilités documentées et organisez des discussions à ce sujet :
1. Passez en revue les responsabilités avec les équipes pour identifier les incohérences entre les responsabilités documentées et les responsabilités que l’équipe assume habituellement.
1. Discutez des services potentiels proposés par les clients internes afin d’identifier les écarts d’attentes entre les équipes.
1. Analysez et corrigez les écarts.
1. Identifiez les opportunités d’amélioration.
1. Identifiez les demandes fréquentes gourmandes en ressources, qui sont généralement de bonnes candidates à l’amélioration.
1. Recherchez les bonnes pratiques, comprenez les modèles, suivez les conseils prescriptifs, et simplifiez et standardisez les améliorations.
1. Enregistrez les opportunités d’amélioration et suivez-les jusqu’à leur réalisation.
1. Si aucune équipe n’est encore chargée de la gestion et du suivi de l’attribution des responsabilités, identifiez un membre de l’équipe qui assumera cette responsabilité.
1. Définissez un processus permettant aux équipes de demander des éclaircissements sur les responsabilités.
1. Passez en revue le processus et vérifiez qu’il est clair et simple à utiliser.
1. Assurez-vous que quelqu’un contrôle les remontées hiérarchiques et en assure le suivi jusqu’à leur conclusion.
1. Établissez des métriques opérationnelles pour mesurer l’efficacité.
1. Créez un mécanisme de rétroaction pour vérifier que les équipes peuvent mettre en avant les opportunités d’amélioration.
1. Mettez en place un mécanisme de vérification périodique.
1. Stockez les documents à un endroit détectable et accessible.
1. Les wikis ou les portails de documentation sont des choix courants.
**Niveau d’effort du plan d’implémentation :** moyen
## Ressources
**Bonnes pratiques associées :**
+ [OPS01-BP06 Évaluation des compromis](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 Les membres de l’équipe sont habilités à agir lorsque les résultats sont remis en cause](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 La remontée hiérarchique est encouragée](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 Fournir aux équipes les ressources appropriées](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 Mesure des objectifs opérationnels et des KPI à l’aide de métriques](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 Vérification des métriques des opérations et définition de la priorité des améliorations](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 Définition d’un processus d’amélioration continue](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**Documents connexes :**
+ [Livre blanc AWS : présentation du DevOps sur AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Livre blanc AWS : cadre d’adoption AWS Cloud : point de vue des opérations](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [Excellence opérationnelle du cadre AWS Well-Architected : topologies du modèle d’exploitation au niveau de la charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [Conseils prescriptifs AWS : création de votre modèle d’exploitation cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWSConseils prescriptifs : création d’une matrice RACI ou RASCI pour un modèle d’exploitation cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [Blog sur les opérations et les migrations AWS Cloud : création de valeur commerciale grâce aux équipes de la plateforme cloud](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [Blog sur les opérations et les migrations AWS Cloud : pourquoi un modèle d’exploitation dans le cloud ?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [Blog DevOps AWS : comment les entreprises se modernisent pour les opérations cloud](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**Vidéos connexes :**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 Des mécanismes sont en place pour demander des ajouts, des modifications et des dérogations
Vous pouvez adresser des demandes aux propriétaires des processus, des procédures et des ressources. Les demandes comprennent les ajouts, les modifications et les exceptions. Ces demandes sont soumises à un processus de gestion des modifications. Prenez des décisions avisées pour approuver les demandes lorsque celles-ci sont viables et appropriées après une évaluation des avantages et des risques.
**Résultat escompté :**
+ Vous pouvez faire des demandes de modification des processus, des procédures et des ressources en fonction de la propriété attribuée.
+ Les modifications sont réalisées de manière délibérée, en pesant les avantages et les risques.
**Anti-modèles courants :**
+ Vous devez mettre à jour la façon dont vous déployez votre application, mais il n’existe aucun moyen de demander à l’équipe chargée des opérations de modifier le processus de déploiement.
+ Le plan de reprise après sinistre doit être mis à jour, mais il n’y a aucun propriétaire désigné à qui demander des modifications.
**Avantages liés au respect de cette bonne pratique :**
+ Les processus, les procédures et les ressources peuvent évoluer au fur et à mesure que les exigences évoluent.
+ Les propriétaires peuvent décider en connaissance de cause du moment où il convient d’apporter des modifications.
+ Les modifications sont réalisées de manière délibérée.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Pour mettre en œuvre cette bonne pratique, vous devez être en mesure de demander des modifications des processus, des procédures et des ressources. Le processus de gestion des modifications peut être léger. Documentez le processus de gestion des modifications.
**Exemple client**
AnyCompany Retail utilise une matrice d’attribution des responsabilités (RACI) pour identifier qui est responsable des modifications des processus, des procédures et des ressources. La société dispose d’un processus de gestion des modifications documenté, léger et facile à suivre. En utilisant la matrice RACI et le processus, n’importe qui peut soumettre des demandes de modification.
**Étapes d’implémentation**
1. Identifiez les processus, les procédures et les ressources pour votre charge de travail et les responsables de chacun d’entre eux. Documentez-les dans votre système de gestion des connaissances.
1. Si vous n’avez pas implémentés [OPS02-BP01 Les ressources ont identifié les propriétaires](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](ops_ops_model_def_proc_owners.md) ou [OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances](ops_ops_model_def_activity_owners.md), commencez par là.
1. Travaillez avec les parties prenantes de votre organisation pour élaborer un processus de gestion des modifications. Le processus doit couvrir les ajouts, les modifications et les exceptions pour les ressources, les processus et les procédures.
1. Vous pouvez utiliser [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) comme plateforme de gestion des modifications pour les ressources de charge de travail.
1. Documentez le processus de gestion des modifications dans votre système de gestion des connaissances.
**Niveau d’effort du plan d’implémentation :** moyen. L’élaboration d’un processus de gestion des modifications nécessite un alignement avec les multiples parties prenantes de votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP01 Les ressources ont identifié les propriétaires](ops_ops_model_def_resource_owners.md) : les ressources ont besoin de propriétaires identifiés avant la mise en place d’un processus de gestion du changement.
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](ops_ops_model_def_proc_owners.md) : les processus ont besoin de propriétaires identifiés avant la mise en place d’un processus de gestion du changement.
+ [OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances](ops_ops_model_def_activity_owners.md) : les activités opérationnelles ont besoin de propriétaires identifiés avant la mise en place d’un processus de gestion du changement.
**Documents connexes :**
+ [Conseils prescriptifs AWS : manuel de base pour les grandes migrations AWS : création de matrices RACI](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [Livre blanc sur la gestion des modifications dans le cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Services connexes :**
+ [Gestionnaire des modifications AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 Les responsabilités entre les équipes sont prédéfinies ou négociées
Utilisez des accords définis ou négociés entre les équipes, accords qui décrivent la manière dont elles travaillent ensemble et se soutiennent mutuellement (par exemple, les temps de réponse, les objectifs de niveau de service ou les contrats de niveau de service). Les canaux de communication entre équipes sont documentés. La compréhension de l’impact du travail des équipes sur les résultats opérationnels et les résultats des autres équipes et organisations indique la priorité de leurs tâches et les aide à répondre de manière appropriée.
Lorsque la responsabilité et la propriété ne sont pas définies ou sont inconnues, vous risquez de ne pas traiter les activités nécessaires en temps opportun et de déployer des efforts redondants et potentiellement contradictoires pour répondre à ces besoins.
**Résultat escompté :**
+ Des accords de travail ou de soutien entre équipes sont convenus et documentés.
+ Les équipes qui se soutiennent ou travaillent les unes avec les autres ont défini des canaux de communication et des attentes en matière de réponse.
**Anti-modèles courants :**
+ Un problème survient en production et deux équipes distinctes commencent à le résoudre indépendamment l’une de l’autre. Leurs efforts cloisonnés prolongent la panne.
+ L’équipe chargée des opérations a besoin de l’aide de l’équipe de développement mais aucun délai de réponse n’a été convenu. La demande est bloquée dans le backlog.
**Avantages liés au respect de cette bonne pratique :**
+ Les équipes savent comment interagir et se soutenir mutuellement.
+ Les attentes en matière de réactivité sont connues.
+ Les canaux de communication sont clairement définis.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** bas
## Directives d’implémentation
La mise en œuvre de cette bonne pratique signifie qu’il n’y a aucune ambiguïté sur la façon dont les équipes travaillent les unes avec les autres. Les accords formels codifient la manière dont les équipes travaillent ensemble ou se soutiennent mutuellement. Les canaux de communication entre équipes sont documentés.
**Exemple client**
L’équipe SRE d’AnyCompany Retail a conclu un contrat de niveau de service avec son équipe de développement. Chaque fois que l’équipe de développement émet une demande dans son système de tickets, elle peut s’attendre à recevoir une réponse dans les quinze minutes. En cas de panne du site, l’équipe SRE mène l’enquête avec le soutien de l’équipe de développement.
**Étapes d’implémentation**
1. En collaboration avec les parties prenantes de votre organisation, élaborez des accords entre les équipes sur la base de processus et de procédures.
1. Si un processus ou une procédure est partagé entre deux équipes, élaborez un runbook sur la manière dont les équipes travailleront ensemble.
1. S’il existe des dépendances entre les équipes, convenez d’un accord de niveau de service pour la réponse aux demandes.
1. Documentez les responsabilités dans votre système de gestion des connaissances.
**Niveau d’effort du plan d’implémentation :** moyen. Si rien n’est convenu entre les équipes, il peut être difficile de parvenir à un accord avec les parties prenantes de votre organisation.
## Ressources
**Bonnes pratiques associées :**
+ [OPS02-BP02 Les processus et procédures ont des propriétaires identifiés](ops_ops_model_def_proc_owners.md) : la propriété du processus doit être identifiée avant la conclusion d’accords entre les équipes.
+ [OPS02-BP03 Les activités opérationnelles ont des propriétaires identifiés responsables de leurs performances](ops_ops_model_def_activity_owners.md) : la propriété des activités opérationnelles doit être identifiée avant la conclusion d’accords entre les équipes.
**Documents connexes :**
+ [AWS Executive Insights : favoriser l’innovation avec l’équipe de Two-Pizza](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [Présentation de DevOps sur AWS : équipes de Two-Pizza](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)