Topologies des équipes DevOps

La distribution des rôles, des responsabilités et de la confiance entre les équipes informatiques et les équipes d’applications est primordiale pour la transformation opérationnelle impliquée lors de l’adoption du cloud à grande échelle.

Les équipes informatiques s’efforcent de maintenir le contrôle. Les propriétaires d’applications cherchent à optimiser l’agilité. L’équilibre que vous établissez entre ces deux objectifs influence considérablement la réussite de votre modèle d’exploitation cloud.

Selon la loi de Conway, les équipes produisent des architectures basées sur leur structure de communication. Comprendre ce principe est essentiel lorsque vous travaillez pour obtenir l’équilibre nécessaire entre autonomie et contrôle. Toute organisation qui conçoit un système (défini de manière générale) va produire un design dont la structure est une copie de la structure de communication de cette organisation.

Du point de vue DevOps, les organisations doivent optimiser la réponse rapide aux besoins des clients. Les équipes qui possèdent, conçoivent et mettent en œuvre leurs applications et systèmes trouvent leur plus haut niveau d’autonomie dans les architectures présentant les caractéristiques suivantes :

• Architecture évolutive qui prend en charge les modifications constantes
• Déployabilité
• Testabilité

La solution de Conway est de déjouer la loi de Conway. Si votre organisation suit une structure particulière pour produire des services et des produits et cherche à l’optimiser, vous devez repenser votre structure organisationnelle. Faites évoluer votre équipe et votre structure organisationnelle pour obtenir votre architecture souhaitée.

Ce principe conduit à des topologies d’équipe conçues avec intention, dans lesquelles les équipes sont responsables de bout en bout de l’ensemble des applications, systèmes ou plateformes qu’elles possèdent afin d’atteindre la discipline complète de DevOps.

Le tableau suivant fournit une catégorisation simplifiée de ces équipes.

Remarques relatives à la conception

• Établissez une équipe de plateforme interfonctionnelle pour concevoir, créer, provisionner et gérer votre cycle de vie de zone d’atterrissage Azure. Cette équipe peut inclure des membres de votre équipe informatique centrale, de la sécurité, de la conformité et des unités commerciales pour s’assurer qu’une portion importante de votre entreprise est représentée. Veillez à éviter les antimodèles.

• Envisagez d’établir une équipe d’activation qui peut fournir des fonctions DevOps pour prendre en charge des applications et des plateformes qui n’ont pas de fonctionnalités DevOps existantes, ou un cas métier pour établir un (par exemple, des applications héritées avec des fonctionnalités de développement minimales).

• Ne limitez pas vos équipes de charge de travail d’application aux artefacts centraux, car cela pourrait entraver leur agilité. Vous pouvez utiliser la gouvernance basée sur des stratégies et le contrôle d’accès basé sur les rôles Azure (Azure RBAC) pour appliquer des configurations de base cohérentes et faire en sorte que les équipes chargées des applications (unités commerciales) soient suffisamment flexibles pour innover tout en étant capables de puiser dans un ensemble prédéfini de modèles.

• Ne forcez pas vos équipes d’applications à utiliser un processus ou un pipeline de provisionnement centraux pour l’instanciation ou la gestion des ressources d’application. Les équipes existantes qui s’appuient déjà sur un pipeline DevOps pour la livraison des applications peuvent continuer à utiliser leurs outils actuels. N’oubliez pas que vous pouvez utiliser Azure Policy afin d’appliquer des normes organisationnelles, d’évaluer la conformité à grande échelle et de répondre aux Considérations relatives à la sécurité pour vos processus DevOps.

• L’application sans discernement d’un modèle de DevOps n’a pas pour effet de mettre en place instantanément des équipes de DevOps compétentes.

• L’investissement dans des ressources et capacités d’ingénierie est essentiel.

• Pour certaines applications héritées, il se peut que les équipes d’application associées ne disposent pas des ressources d’ingénierie requises pour s’aligner sur une stratégie de DevOps.

Recommandations de conception

Les sections suivantes contiennent des recommandations de conception pour vous guider lorsque vous concevez vos topologies d’équipe.

Aligner les topologies d’équipe avec votre modèle d’exploitation cloud

Veillez à aligner vos topologies d’équipe avec votre modèle d’exploitation cloud souhaité.

Établissez un processus de base pour les examens d’aptitude opérationnelle afin de bien comprendre les problèmes qui peuvent résulter de vos structures d’équipe.

Définir des fonctions pour votre équipe de plateforme

La liste suivante fournit un ensemble recommandé de fonctions pour l’équipe de plateforme responsable de vos zones d’atterrissage Azure :

• Gouvernance d’architecture
• Approvisionnement d’abonnement et délégation de la gestion requise du réseau, des identités et des accès, des stratégies
• Gestion et surveillance de la plateforme (holistique)
• Gestion des coûts (holistique)
• Plateforme en tant que code (gestion de modèles, de scripts et d’autres ressources)
• Opérations générales sur Microsoft Azure au sein de votre locataire Microsoft Entra (gestion des principaux de service, inscription de l’API Microsoft Graph et définitions de rôle)
• RBAC Azure (holistique)
• Gestion des clés (pour les services centraux, le protocole de transfert de courrier simple et contrôleur de domaine)
• Gestion et application de stratégie (holistique)
• Surveillance et audit de la sécurité (holistique)
• Gestion de réseau (holistique)

Définir des fonctions pour vos équipes de charge de travail d’application

La liste suivante fournit un ensemble recommandé de fonctions pour vos équipes d’application responsables des charges de travail d’application :

• Création et gestion des ressources d’application via un modèle DevOps
• Gestion de bases de données
• Migration ou transformation d’application
• Gestion et supervision d’applications (ressources d’applications)
• RBAC Azure (ressources d’application)
• Supervision et audits de la sécurité (ressources d’application)
• Gestion des secrets et des clés (clés d’application)
• Gestion des coûts (ressources d’application)
• Gestion de réseau (ressources d’application)

Définir des fonctions pour habiliter les équipes

La liste suivante fournit un ensemble recommandé de fonctions pour une équipe d’habilitation responsable de l’assistance de vos autres équipes :

• Définition d’orientations et de capacités horizontales (inter-fonctionnelles) pour aider à acquérir l’expertise appropriée dans votre organisation, ce qui garantit l’alignement avec votre modèle opérationnel cible global pour le cloud (comme DevOps)
• Soutien, formation et coaching pour d’autres équipes afin d’atteindre le niveau d’expertise nécessaire
• Établissement d’un ensemble commun de modèles et de bibliothèques réutilisables pour vos équipes d’application ou de plateforme, et promotion des ressources internes, comme les modules vérifiés Azure.

Définir des modes d’interaction entre les équipes

Les objectifs des interactions entre vos équipes sont les suivants :

• Atteindre l’autonomie
• Débloquer les dépendances
• Réduire les pertes de temps
• Éviter les goulots d’étranglement

Les topologies d’équipe décrivent trois modes d’interaction d’équipe :