Topologies d’équipes DevOps
La distribution des rôles, responsabilités et confiance entre les équipes informatiques et les équipes d’applications est primordiale pour la transformation opérationnelle impliquée dans 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 finalement entre ces deux objectifs influence considérablement le succès 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 l’autonomie et le contrôle. Toute organisation qui conçoit un système (défini à grande échelle) produit une structure de conception qui est une copie de la structure de communication de cette organisation.
Du point de vue de DevOps, les organisations doivent optimiser la réponse rapide aux besoins des clients. Les équipes qui possèdent, conçoivent et implémentent leurs applications et systèmes trouvent leur niveau d’autonomie le plus élevé dans les architectures avec les caractéristiques suivantes :
- Architecture évolutive qui prend en charge les modifications constantes
- Déployabilité
- Testabilité
La solution de Conway est de contourner la loi de Conway. Si votre organisation suit une structure particulière pour produire des services et des produits et cherche à optimiser, vous devez repenser votre structure organisationnelle. Faites évoluer votre équipe et votre structure organisationnelle pour obtenir votre architecture souhaitée.
Ce principe mène à des topologies d’équipe intentionnellement conçues dans lesquelles les équipes sont responsables de la gestion complète de bout en bout de toutes les applications, systèmes ou plateformes dont elles ont la charge, afin d'atteindre une pleine maîtrise des pratiques DevOps.
Le tableau suivant fournit une catégorisation simplifiée de ces équipes.
Type d’équipe | Définition |
---|---|
Équipes responsables des charges de travail des applications | Ces équipes créent des applications qui favorisent les résultats métier directs pour un segment du domaine métier. Dans le contexte des zones d’atterrissage Azure, ces équipes sont responsables du cycle de vie de bout en bout des charges de travail d’application. |
Équipes de plateforme | Ces équipes créent des plateformes internes attrayantes pour accélérer la livraison et réduire la charge cognitive des équipes de charge de travail d’application. Dans le contexte des zones d’atterrissage Azure, ces équipes sont responsables du cycle de vie de bout en bout de la zone d’atterrissage Azure. |
Soutien aux équipes | Ces équipes aident à surmonter les lacunes des compétences en aidant d’autres équipes avec des fonctionnalités spécialisées telles que DevOps. |
Considérations relatives à la conception
Établissez une équipe de plateforme interfonctionnelle pour concevoir, créer, provisionner, gérer 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 vous assurer qu’un large éventail de votre entreprise est représenté. Veillez à éviter les antimodèles.
Envisagez d’établir une équipe d’activation qui peut fournir des fonctions DevOps pour prendre en charge les applications et les plateformes qui n’ont pas de fonctionnalités DevOps existantes, ou un cas métier pour en é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 en fonction du rôle Azure (Azure RBAC) pour appliquer des configurations de base cohérentes et garantir que les équipes d’application (unité métier) sont suffisamment flexibles pour innover et toujours en mesure de tirer parti d’un ensemble prédéfini de modèles.
Ne forcez pas vos équipes d’application à utiliser un processus central ou un pipeline d’approvisionnement 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 d’applications peuvent toujours 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 globale d’un modèle DevOps n’établit pas instantanément des équipes DevOps compatibles.
L’investissement dans les capacités d’ingénierie et les ressources est essentiel.
Les équipes d’applications pour certaines applications héritées peuvent ne pas avoir les ressources d’ingénierie requises pour s’aligner sur une stratégie DevOps.
Recommandations en matière de conception
Les sections suivantes contiennent des recommandations de conception pour vous guider lors de la conception de 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 de l’architecture
- Approvisionnement en abonnements et délégation des politiques requises de gestion des réseaux, des identités et des accès
- Gestion et surveillance de la plateforme (holistique)
- Gestion des coûts (holistique)
- Plateforme en tant que code (gestion des modèles, des scripts et d’autres ressources)
- Opérations globales 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ôles)
- RBAC Azure (holistique)
- Gestion des clés pour les services centraux (protocole de transfert de messagerie simple et contrôleurs de domaine)
- Gestion et application des stratégies (holistique)
- Surveillance et audits de sécurité (holistiques)
- Gestion du 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 des bases de données
- Migration ou transformation d’application
- Gestion et surveillance des applications (ressources d’application)
- RBAC Azure (ressources d’application)
- Surveillance et audits de sécurité (ressources d’application)
- Gestion des secrets et des clés (clés d’application)
- Gestion des coûts (ressources d’application)
- Gestion du réseau (ressources d’application)
Définir des fonctions pour activer les équipes
La liste suivante fournit un ensemble recommandé de fonctions pour une équipe d’activation responsable de l’assistance de vos autres équipes :
- Définition des conseils et fonctionnalités horizontaux (inter-fonctions) pour vous aider à acquérir l’expertise appropriée au sein de votre organisation, ce qui garantit l’alignement avec votre modèle d’exploitation cloud cible global (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 encouragement de l'InnerSourcing, tels que les modules vérifiés Azure tels que et.
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 le temps perdu
- Éviter les goulots d’étranglement
Topologies d’équipe décrit trois modes d’interaction d’équipe :
Mode d’interaction | Description |
---|---|
Collaboration | Les équipes travaillent en étroite collaboration. |
X en tant que service | Des équipes consomment ou fournissent quelque chose à d'autres équipes avec une collaboration minimale, similaire à celle des interactions avec des fournisseurs tiers. |
Facilitation | Les équipes aident ou sont aidées par une autre équipe pour éliminer les obstacles. |