Gestion des incidents pour les équipes haute vélocité
L'approche « Vous le concevez, vous en êtes responsable » est-elle à la hauteur des attentes ?
Après 13 années d'existence, a-t-elle tenu ses promesses ?
Il y a 13 ans, lors d'un entretien, un nouveau maître-mot a vu le jour dans le domaine du déploiement et de l'exploitation de logiciels et a bouleversé les processus informatiques à travers le monde. Aujourd'hui, les entreprises sont plus nombreuses que jamais à adopter l'approche DevOps collaborative et l'état d'esprit « you build it, you run it » (Vous le concevez, vous en êtes responsable) qui l'accompagne généralement. Mais maintenant que nous avons plus de dix années de changements à notre actif, le concept est-il toujours pertinent ? A-t-il apporté les avantages promis ?
L'histoire du changement
Tout a commencé en 2006 lors d'un entretien avec Werner Vogels, DSI d'Amazon :
« L'attribution de responsabilités opérationnelles aux développeurs a grandement amélioré la qualité des services, tant du point de vue du client que du point de vue technologique. Le modèle traditionnel consiste à amener votre logiciel jusqu'au mur qui sépare les équipes de développement et opérationnelles, à le jeter par-dessus et à ne plus vous en soucier. Pas chez Amazon. Chez nous, si vous le concevez, vous en êtes responsable. Les développeurs observent ainsi le fonctionnement de leur logiciel au quotidien. À cette occasion, ils sont quotidiennement en contact avec le client. Cette boucle de feedback client est essentielle pour améliorer la qualité du service. »
C'est ainsi qu'est née l'approche « you build it, you run it » (vous le concevez, vous en êtes responsable), une nouvelle méthode qui s'imbriquait parfaitement avec la montée consécutive du mouvement DevOps collaboratif, pour lequel il était primordial de faire tomber le mur entre les équipes chargées de la conception et du support.
L'idée a fait son chemin, et pour cause. Combler le fossé entre le développement et les opérations a beaucoup de sens. Pourquoi l'équipe qui a écrit le code (et qui connaît donc très bien le produit) ne serait-elle pas celle qui enfile sa cape de super-héros en cas d'incident ? Cette pratique ne fait pas que raccourcir le délai de résolution. Elle permet également aux développeurs d'expérimenter au plus près le feedback des clients et les tickets en temps réel, ce qui simplifie les services en continu.
Des avantages et des défis clairs
Comme pour tout changement de processus, les avantages se sont accompagnés d'une série de défis et d'une forte résistance de la part des entreprises à la structure plus traditionnelle.
Parmi les avantages, citons : moins de pression sur les équipes informatiques, un design prêt pour la production, des délais de réponse plus rapides et un code testé de manière plus approfondie (après tout, si c'est vous qui êtes appelé à 1 heure du matin pour résoudre un bug, la probabilité que vous revérifierez le prochain déploiement ne peut qu'augmenter). Cela a également permis de former de meilleurs développeurs, plus complets, chargés d'acquérir de nouvelles compétences et d'envisager l'entreprise sous un angle nouveau.
Étant donné que la responsabilité du code reste confiée à la même équipe, cette approche a également un impact positif sur la prévention des incidents. Un rapport a révélé que les entreprises dont les revues de code sont réalisées par des équipes externes avant le déploiement ont le même taux de réussite que celles qui ne réalisent pas de revue de code. Lorsqu'elle est gérée par des développeurs qui connaissent déjà le produit, la revue par les pairs a un impact positif sur la prévention des incidents.
Notre équipe a abordé ici les défis que représente cette approche changeante de la gestion des incidents : « Le défi [lié à la gestion décentralisée des incidents] ? Les organisations ont encore besoin d'un certain degré de centralisation. La direction doit avoir accès aux rapports et à la documentation. Les parties prenantes des entreprises veulent des mises à jour. Elles veulent voir des métriques d'incident comme la durée moyenne de résolution et le temps moyen d'accusé de réception. Elles attendent des mises à jour claires des incidents, des rapports post-mortem d'incident et des tâches de remédiation.
Pour de nombreuses entreprises qui s'orientent brillamment vers la décentralisation [et une approche « Vous le concevez, vous en êtes responsable »], la réponse à ce défi est la suivante : une technologie permettant la décentralisation et l'autonomie de l'équipe. Il est ainsi possible de rester agile lors de la résolution des incidents tout en centralisant l'information afin de communiquer avec l'entreprise. »
L'autre défi fondamental est que, pour de nombreuses entreprises, l'adoption de cette approche implique des changements dans les structures d'équipe et la culture interne. Elle exige une ouverture à la collaboration, de nouvelles façons de penser au produit et de nouvelles structures d'équipe qui éliminent les obstacles à la communication. De tels changements sont difficiles et requièrent une approche très spécifique si l'on veut réussir.
Alors, l'approche « Vous le concevez, vous en êtes responsable » est-elle à la hauteur des attentes ?
Malgré les défis et selon notre expérience, oui. L'approche « Vous le concevez, vous en êtes responsable » est encore en train de transformer le secteur, et même les équipes informatiques traditionnelles s'y mettent peu à peu.
Aucune étude n'est disponible sur l'adoption de cette approche, mais selon notre expérience, elle va souvent de pair avec l'adoption des principes DevOps en général comme le montrent les chiffres. En 2017, 63 % des organisations ont déclaré avoir implémenté DevOps, selon un rapport Forrester. 27 % de ces organisations prévoyaient de prendre le train en marche au cours de l'année. Et seulement 1 % n'ont exprimé aucun intérêt à apporter un changement.
Plus intéressant encore, les entreprises ont signalé une augmentation moyenne de 45 % de la satisfaction des clients et une hausse de 43 % de la productivité des employés suite à l'adoption des principes DevOps.
Lancez-vous avec l'approche « Vous le concevez, vous en êtes responsable »
Il est impossible d'adopter une approche « Vous le concevez, vous en êtes responsable » sans une plateforme flexible et très collaborative. Le but est que les équipes de développement et opérationnelles puissent travailler ensemble de manière transparente. Ce type de collaboration peut uniquement être obtenu grâce aux bons outils.
Jira Service Management réunit les équipes grâce à une communication intégrée et collaborative. Celles-ci peuvent dès lors établir une connexion avec leur méthode de communication préférée, des canaux de chat (Slack, Microsoft Teams) aux outils de vidéoconférence (via un pont vidéo natif ou Zoom). La plupart des aspects de Jira Service Management sont personnalisables pour s'adapter aux besoins de chaque équipe, des alertes aux règles de routage, et plus encore. Il est ainsi possible d'impliquer les intervenants nécessaires et de fournir du contexte à toutes les parties dès les phases de réponse initiales jusqu'aux rapports post-mortem et à la gestion des problèmes.
Découvrez comment Jira Service Management peut libérer le potentiel collaboratif de votre équipe.
Configuration d'un planning d'astreinte grâce à Opsgenie
Ce tutoriel vous apprendra à configurer un planning d'astreinte, à appliquer des règles de remplacement, à configurer les notifications d'astreinte, etc. Et tout cela, sans quitter Opsgenie.
Lire ce tutorielAvantages et inconvénients des différentes approches de gestion des astreintes
Les équipes d'astreinte évoluent rapidement. Découvrez les avantages et inconvénients des différentes approches de gestion des astreintes.
Lire cet article