Les recherches menées dans le secteur informatique ont montré à maintes reprises que les équipes orientées DevOps, capables de livrer des logiciels rapidement et efficacement, surpassent régulièrement leurs homologues plus lentes en termes de rentabilité de l’entreprise, de parts de marché et de presque tous les indicateurs commerciaux concurrentiels qui comptent. Ce type de réussite est le résultat d’une restructuration des équipes qui leur permet 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 exactement comment passer de leur situation actuelle à ces structures plus compétitives.

Le épisode de la mi-février de la Allez 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 (c'est-à-dire « service complet »). Pour être agiles, les équipes de livraison et d'exploitation des logiciels doivent avoir la pleine propriété de tous les aspects des services qu'elles prennent en charge : de la conception et du développement à l'exploitation en production et à la fin éventuelle de leurs logiciels.

Aller vite signifie généralement être petit. Ou plutôt, cela signifie que le niveau de profondeur nécessaire pour posséder pleinement les logiciels et les opérations 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 entreprises qui existent depuis plus de quelques années est que ce n'est tout simplement pas la façon dont elles fonctionnent. À 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 monolithes plus grands et plus consolidés. Cette taille plus importante a peut-être permis de réduire les coûts, mais elle a considérablement ralenti les performances, ce qui a ouvert la voie à des entreprises plus petites et plus agiles pour perturber les acteurs établis du secteur.

Aujourd’hui, nombre de ces entreprises ont du mal à trouver comment repenser leurs organisations monolithiques en composants plus petits et plus agiles. Nous nous améliorons peut-être dans la refonte d’applications Web monolithiques en microservices, mais comment repenser des équipes informatiques centralisées avec des silos et des séparations de tâches bien établis en propriétaires de services complets interfonctionnels ?

Guides des opérations PagerDuty

L'équipe de la communauté PagerDuty écrit un certain nombre de Guides d'opérations : manuels conçus pour diviser les tâches procédurales complexes et à grande échelle en concepts réduits, avec des méthodes concrètes que vous pouvez utiliser pour vous entraîner à les réaliser. Ces guides sont des cadres indépendants du produit qui se concentrent sur la fourniture à la fois de théorie fondamentale et de pratique pragmatique. Généralement, ils le font en vous montrant comment PagerDuty et nos clients ont relevé des défis opérationnels communs.

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 la cycle de vie complet du logiciel d'un service. Il vous donne également des mesures concrètes que vous pouvez prendre 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 de la plupart des initiatives de transformation numérique. C'est au cours de ce type d'initiatives que les équipes commencent à réfléchir à la manière exacte d'aborder la propriété de services complets. Le nouveau guide des opérations commence par montrer comment réaliser une analyse de rentabilisation mesurable en faveur des équipes de propriété de services complets.

L’étape suivante consiste à définir les limites spécifiques de tout « service » donné. Un service est un élément fonctionnel distinct qui apporte de la valeur et qui appartient entièrement à une équipe. Cette déclaration est assez complexe (consultez le guide pour une exploration plus approfondie), mais il faut en tirer la conclusion qu’une première étape essentielle consiste à parvenir à une compréhension commune des limites d’un service donné et à déterminer qui sont ses principales parties prenantes. Le guide fournit quelques considérations essentielles pour déterminer ces limites dans votre organisation.

Nous décrivons ensuite tous les rôles fonctionnels individuels nécessaires pour soutenir un modèle de propriété à service complet. Plutôt que d'étiqueter ces rôles par intitulé de poste (par exemple, les développeurs de logiciels sont propriétaires de telle partie, les chefs de produit sont propriétaires de telle autre, etc.), le guide énumère les fonctions qui doivent être prises en compte dans la structure globale de l'équipe. Certaines organisations choisissent de dédier des personnes possédant ces compétences à chaque équipe, tandis que d'autres créent des rôles intégrés dans lesquels les personnes des équipes interfonctionnelles se répartissent le temps entre plusieurs équipes pour apporter ces compétences. Quelle que soit la manière dont votre organisation décide de procéder, l'important est que les fonctions décrites dans ce guide soient clairement abordées et prises en charge au sein de chaque équipe de propriété à service complet.

La section sur le cycle de vie d'un service décrit les différentes considérations à prendre en compte à chaque phase du processus de livraison et d'exploitation du logiciel : conception, exécution et extinction. La section sur les politiques d'escalade décrit un domaine de préoccupation commun aux équipes de développement de logiciels qui n'ont jamais exploité leur logiciel en production : comment concevoir un processus permettant de réagir en cas de problème. La section sur les équipes d'astreinte prépare ensuite les équipes à être d'astreinte pour la première fois.

Comme tous nos guides opérationnels, il ne s’agit pas d’un organigramme prescriptif des étapes exactes à suivre. Au lieu de cela, il s'agit d'une introduction à des considérations pratiques, des listes de questions auxquelles répondre pour vous aider à préparer un plan détaillé pour construire votre propre processus, et des exemples de la façon dont des entreprises comme PagerDuty ont construit ces mêmes types de processus. Les guides Ops sont des cadres conçus pour aider à relancer votre organisation en partageant les leçons que nous avons apprises en nous lançant dans ces mêmes voyages.

Allez jusqu'à la limite

Nous a lancé un nouveau podcast , Page It to the Limit, en décembre (merci pour toutes les écoutes et le soutien !). L'objectif de ce podcast est de parler des défis communs auxquels nous sommes tous confrontés lors de l'exécution de logiciels en production, de manière accessible et de petite taille. En général, nous le faisons en interviewant des invités issus de nombreuses facettes différentes du secteur informatique dans de courts segments de 30 minutes.

La semaine dernière, nous avons publié un autre type d'épisode. Scott McAllister et moi-même avons discuté de la propriété à service complet, de ce que cela signifie, de la façon d'utiliser ce guide et de ce que nous avons appris au cours de son développement. Cet épisode est une introduction rapide à 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 .