- PagerDuty /
- Blog /
- Meilleures pratiques et perspectives /
- Guide pour structurer des équipes de propriétaires à service complet
Blog
Guide pour structurer des équipes de propriétaires à service complet
Les études du secteur informatique ont montré à maintes reprises que les équipes orientées DevOps, capables de livrer des logiciels rapidement et efficacement, surpassent systématiquement leurs homologues plus lentes en termes de rentabilité, de parts de marché et de presque tous les indicateurs concurrentiels importants. Ce type de réussite repose sur la restructuration des équipes, leur permettant d'agir plus rapidement et de se rapprocher de leurs clients. Mais l'un des plus grands défis pour les équipes existantes est de comprendre précisément comment passer de leur situation actuelle à ces structures plus compétitives.
Le épisode de la mi-février de la Page It jusqu'à la limite Le podcast est là pour vous aider.
Propriété à service complet
Chez PagerDuty, nous appelons ce type de modèle opérationnel « Propriété à service complet .” C'est une façon élégante de dire que la propriété des services nécessite une approche globale (aussi appelée « service complet »). Pour être agiles, les équipes de livraison et d'exploitation des logiciels doivent avoir la maîtrise totale de tous les aspects des services qu'elles prennent en charge : de la conception et du développement à la production, jusqu'à la fin de vie de leurs logiciels.
Aller vite signifie généralement être petit. Ou plutôt, cela signifie que le niveau de profondeur nécessaire pour maîtriser pleinement les opérations logicielles et de livraison est si profond que le compromis nécessaire est de réduire la surface de responsabilité de cette équipe (voir : la popularité de microservices ).
Le problème pour la plupart des organisations de plus de quelques années est que ce mode de fonctionnement n'est tout simplement pas celui de la plupart d'entre elles. À la fin des années 2000 et au début des années 2010, les économies d'échelle ont incité de nombreuses entreprises à centraliser leurs opérations informatiques dans des structures monolithiques plus grandes et plus consolidées. Cette taille accrue a certes permis de réduire les coûts, mais a considérablement ralenti les performances, ouvrant ainsi la voie à des entreprises plus petites et plus agiles pour perturber les acteurs établis du secteur.
Aujourd'hui, nombre de ces acteurs historiques peinent à repenser leurs organisations monolithiques en composants plus petits et plus agiles. Nous progressons peut-être dans la refonte d'applications web monolithiques en microservices, mais comment transformer des équipes informatiques centralisées, avec des silos et des séparations de tâches bien ancrés, en propriétaires multidisciplinaires offrant des services complets ?
Guides d'opérations PagerDuty
L'équipe communautaire PagerDuty rédige un certain nombre de Guides d'opérations : des manuels conçus pour décomposer des tâches procédurales complexes et de grande envergure en concepts concis, avec des méthodes concrètes pour vous mettre en pratique. Ces guides sont des cadres de travail indépendants du produit, axés sur la théorie fondamentale et la pratique pragmatique. Ils illustrent généralement comment PagerDuty et nos clients ont relevé des défis opérationnels courants.
Notre nouvelle version du Guide des opérations de propriété à service complet offre un aperçu approfondi des concepts qui sous-tendent la création d'équipes interfonctionnelles qui possèdent cycle de vie complet du logiciel d'un service. Il vous propose également des mesures concrètes et concrètes pour redéfinir les structures d'équipe et préparer ces nouvelles équipes à éviter les pièges courants.
La refonte des structures d'équipe fait généralement partie intégrante de la plupart des initiatives de transformation numérique. C'est lors de ces projets que les équipes commencent à réfléchir à la manière précise d'aborder la prise en charge complète des services. Le nouveau Guide des opérations commence par montrer comment réaliser une analyse de rentabilité mesurable en faveur des équipes de prise en charge complète des services.
L'étape suivante consiste à définir les limites spécifiques de chaque « service ». Un service est une fonctionnalité distincte qui apporte de la valeur et qui appartient entièrement à une équipe. Cette affirmation est complexe (consultez le guide pour une exploration plus approfondie), mais il est essentiel de commencer par une compréhension commune des limites d'un service donné et d'identifier ses principales parties prenantes. Ce guide fournit quelques éléments essentiels à prendre en compte pour déterminer ces limites au sein de votre organisation.
Nous décrivons ensuite tous les rôles fonctionnels individuels nécessaires au soutien d'un modèle de propriété de services complets. Plutôt que de classer ces rôles par intitulé de poste (par exemple, les développeurs de logiciels sont responsables de tel élément, les chefs de produit de tel autre, etc.), le guide répertorie les fonctions qui doivent être prises en compte dans la structure globale de l'équipe. Certaines organisations choisissent d'affecter des personnes possédant ces compétences à chaque équipe, tandis que d'autres créent des rôles intégrés où les membres d'équipes transversales se répartissent le temps entre plusieurs équipes pour apporter ces compétences. Quelle que soit la méthode choisie par votre organisation, l'important est que les fonctions décrites dans ce guide soient clairement définies et prises en charge au sein de chaque équipe de propriété de services complets.
La section « Cycle de vie » d'une section de service décrit les différents éléments à prendre en compte à chaque phase du processus de livraison et d'exploitation du logiciel : conception, exécution et fin de vie. La section sur les politiques d'escalade décrit une préoccupation courante pour les équipes de développement logiciel qui n'ont jamais exploité leur logiciel en production : comment concevoir un processus de réponse en cas de problème. La section « Poste d'astreinte » prépare ensuite les équipes à leur première astreinte.
Comme tous nos guides opérationnels, il ne s'agit pas d'un organigramme prescriptif détaillant les étapes à suivre. Il s'agit plutôt d'un guide de réflexion pratique, d'une liste de questions à poser pour vous aider à élaborer un plan détaillé et à développer votre propre processus, ainsi que d'exemples de la manière dont des entreprises comme PagerDuty ont mis en place ces mêmes types de processus. Les guides opérationnels sont des cadres conçus pour vous aider à démarrer votre organisation en partageant les enseignements tirés de ces expériences.
Page It jusqu'à la limite
Nous a lancé un nouveau podcast Page It to the Limit, en décembre (merci à tous pour votre écoute et votre soutien !). L'objectif de ce podcast est d'aborder les défis courants auxquels nous sommes tous confrontés lors de l'exécution de logiciels en production, de manière concise et accessible. Nous le faisons généralement en interviewant des invités issus de différents secteurs de l'informatique, lors de courts segments de 30 minutes.
La semaine dernière, nous avons publié un épisode d'un genre différent. Scott McAllister et moi avons discuté de la propriété à service complet, de sa signification, de l'utilisation de ce guide et des enseignements tirés de son développement. Cet épisode est une brève introduction à un guide plus approfondi. Découvrez-le ici :
Pour un aperçu plus approfondi de la manière de créer des équipes de livraison et d'exploitation de logiciels plus autonomes, plus performantes et plus agiles qui contribuent à obtenir des résultats commerciaux compétitifs, consultez le Guide des opérations de propriété à service complet .
Dites-nous ce que vous pensez du Guide des opérations ou du podcast en nous contactant sur Twitter @PageIt2theLimit .