Gestion des incidents pour les équipes haute vélocité
Guide du responsable sur l'amélioration des astreintes
À l'instar des services d'urgences qui ont besoin de plannings d'astreinte pour les médecins afin de prendre en charge les urgences vitales, les équipes DevOps ont besoin de ces plannings pour réagir efficacement aux problèmes logiciels et système qui ont un impact sur les performances, le déploiement et la disponibilité.
Mais développer une pratique de gestion des astreintes est plus facile à dire qu'à faire. Être d'astreinte peut être une expérience déconcertante et perturbante pour les employés. Trouver le parfait équilibre entre couverture, évolutivité et qualité de vie pour l'équipe est un défi permanent.
Au fur et à mesure que les bonnes pratiques évoluent et que les entreprises se développent, les équipes à haute vélocité les plus agiles implémentent de nouvelles approches et réussissent grâce à ces dernières.
Vous le concevez, vous gérez sa maintenance
Il y a encore dix ans, la réponse aux incidents informatiques était la tâche principale des équipes opérationnelles. Les organisations avaient généralement une structure d'équipe par niveaux (c.-à-d. Niveau 1, Niveau 2, Niveau 3, avec des niveaux de compétences, et de rémunération plus élevés pour les niveaux les plus élevés).
L'objectif en adoptant cette structure était de réduire les coûts de fonctionnement. Généralement, le Niveau 1 implique les employés débutants. Si le Niveau 1 ne parvenait pas à résoudre le ticket, il le faisait remonter au Niveau 2, composé d'employés plus expérimentés (et donc plus coûteux). Et ce processus continuait jusqu'à résolution du ticket.
Mais avec l'essor des services disponibles en continu, les interdépendances entre les systèmes et les attentes client en matière de temps d'activité ont également augmenté. De nos jours, une réponse lente peut coûter plus cher à l'entreprise (en termes de réputation, de satisfaction client et de pertes de chiffre d'affaires) que le recours anticipé à des développeurs expérimentés.
Conséquences de cet environnement technologique changeant ? La structure des équipes de réponse devait évoluer. Découvrez le courant de pensée DevOps et le concept de « you built it, you maintain it » (Vous l'avez conçu, vous en êtes responsable).
L'idée ici est simple : le développeur qui connaît le mieux le code est la personne la plus qualifiée pour résoudre des tickets connexes dans les plus brefs délais. Grâce à DevOps, cette logique explique pourquoi il est maintenant courant pour les développeurs d'être d'astreinte, de s'assurer que le code fonctionne correctement et de réduire le temps moyen d'accusé de réception (MTTA) et la durée moyenne de résolution (MTTR) des incidents.
L'autre avantage de cette approche ? Des tests plus rigoureux avant le déploiement. Maintenant que le développeur en charge du code peut être alerté en dehors des heures de bureau, il y a un sentiment plus profond de responsabilité, une incitation supplémentaire à vérifier, et à revérifier, le code. De plus en plus d'entreprises estiment que les systèmes n'en sont que plus fiables et plus résilients.
Développez une pratique de gestion des astreintes qui plaira à vos équipes
Les astreintes ont mauvaise réputation, parfois à juste titre. Les programmes d'astreinte qui ne sont pas équilibrés peuvent avoir un effet négatif sur l'équilibre entre vie professionnelle et vie privée, la santé et le sommeil. Les employés ayant vécu de mauvaises expériences lors d'astreintes ou n'ayant pas d'expérience dans ce domaine peuvent imaginer leur vie sociale et leur équilibre travail-vie privée s'envoler sous leurs yeux.
Mais, en réalité, les astreintes ne doivent pas nécessairement se traduire par une qualité de vie moindre. En équilibrant les tâches d'astreinte, en tenant compte des préférences de l'équipe, et en mettant en place des systèmes puissants pour éviter et réduire les incidents et les alertes d'astreinte dans la mesure du possible, vous pouvez créer une pratique qui réduit et répartit la charge entre vos équipes.
Pour que les responsables y parviennent, il faut être transparent avec les équipes dès le départ, leur proposer de nombreuses formations, fixer des attentes équitables en matière d'astreinte et de développement, mettre au point des processus solides, sonder les équipes en demandant leur avis ou leur adhésion et améliorer constamment les choses.
Soyez transparents avec vos équipes
La transparence est la clé d'une communication fructueuse. Lors du déploiement d'un système de gestion des astreintes ou en cas de changement apporté à un système existant, il est essentiel de clarifier les attentes en matière de disponibilité. Assurez-vous de réfléchir et de répondre clairement aux questions courantes des employés, telles que :
- Les ingénieurs seront-ils d'astreinte du jour au lendemain ?
- S'ils sont d'astreinte du jour au lendemain, ont-ils la possibilité de faire du télétravail le lendemain ? Les employés d'astreinte peuvent-ils commencer plus tard le jour suivant s'ils ont besoin de rattraper leur sommeil ?
- Les développeurs doivent-ils réaliser des tâches de développement durant les périodes d'astreinte ?
- À quelle fréquence mensuelle un développeur sera-t-il d'astreinte ? Quel est le nombre maximum de fois où une personne peut être d'astreinte ?
- Comment allez-vous indemniser les employés d'astreinte ?
Dispensez une formation appropriée
Voici quelques bonnes pratiques pour la formation des équipes d'astreinte :
- Élaborer un programme de formation qui aborde à la fois les processus et les tickets courants
- Fournir des runbooks à jour
- Faire en sorte que les nouveaux employés observent des ingénieurs d'astreinte expérimentés
- Fournir aux employés un accès aux rapports d'incident passés afin qu'ils puissent voir comment des incidents similaires à celui qu'ils traitent ont été résolus avec succès
Il est également judicieux de disposer de plusieurs canaux de remontée. La bonne pratique consiste généralement à faire intervenir les ingénieurs junior sur la première rotation d'astreinte et à planifier les ingénieurs senior comme remplaçant ou rotation secondaire. Les ingénieurs junior peuvent alors développer les compétences d'astreinte nécessaires tout en évitant de paniquer lorsqu'un ticket dépasse leur expertise.
Les astreintes et le développement sont deux tâches distinctes
Les tâches de développement durant les astreintes sont souvent synonymes de nombreux changements de contexte et d'interruptions, notamment pour les entreprises avec de fréquents incidents et besoins d'astreinte.
Cela signifie généralement un développement moins efficace et un stress accru pour les ingénieurs d'astreinte, qui peut mener au burn-out, à la fatigue d'alerte et au mécontentement professionnel. Cela peut également avoir un effet négatif sur les sprints de développement, car il est difficile d'estimer à quel point une personne d'astreinte peut et va contribuer à un sprint.
C'est pourquoi nous vous recommandons de séparer les tâches d'astreinte et de développement. Lorsque les employés d'astreinte ont du temps libre, ils peuvent travailler à l'amélioration de la documentation d'astreinte et à l'automatisation afin d'améliorer la durabilité des systèmes et services.
Affinez votre processus de gestion des astreintes
Un système de gestion des astreintes sain n'est possible que s'il est constamment amélioré en affinant les processus et systèmes. Personnalisez les calendriers d'astreinte, les règles d'acheminement et les politiques de remontée des incidents avec une solution de gestion des incidents telle que Jira Service Management pour gérer efficacement les alertes. Pour atteindre cet objectif, voici nos recommandations :
- Évaluez la priorité et l'urgence des alertes, et configurez les systèmes en fonction. Les alertes peu urgentes peuvent attendre le lendemain matin, ce qui laisse la possibilité aux employés d'astreinte de bénéficier d'un sommeil bien mérité.
- Réduisez les faux positifs en classant les alertes en fonction de facteurs tels que la cause profonde, le système d'origine, le message, ou encore les seuils. Cela permet de différencier les alertes exploitables des autres alertes.
- Dédupliquez les alertes associées pour éviter la fatigue d'alerte.
- Concevez des alertes riches qui décrivent clairement un problème et permettent aux ingénieurs d'astreinte de prendre des décisions efficaces et d'appliquer les connaissances consignées dans les runbooks.
- Fournissez des rapports d'alerte et des métriques aux équipes d'astreinte afin d'identifier les faiblesses des systèmes et de les pallier. (En d'autres termes : ne laissez pas les équipes d'astreinte s'enliser dans les mêmes problèmes, encore et encore.)
Examinez les rapports d'astreinte et faites des ajustements si besoin
Pour maintenir l'équité et éviter le burn-out des employés, les responsables devraient examiner les rapports d'astreinte pour se faire une idée de :
- la fréquence à laquelle chaque membre de l'équipe est appelé ou réveillé ;
- la durée d'astreinte de chaque membre de l'équipe ;
- la distribution horaire et journalière des tâches d'astreinte pour chaque personne ;
- l'adaptation des plannings si besoin pour répartir équitablement les tâches.
Écoutez vos employés
La direction devrait organiser régulièrement des assemblées générales en présence des ingénieurs d'astreinte afin d'aborder les problèmes, les doléances et les points faibles, puis prendre des mesures pour résoudre ces problèmes.
Quand il est question d'astreintes, les systèmes, outils, processus, personnes, documents et formations ne sont pas des éléments statiques que vous pouvez oublier aussitôt après les avoir définis. À mesure que l'entreprise se développe, les équipes apprennent et changent, et les incidents évoluent au fil du temps. La direction devrait constamment réévaluer et améliorer les programmes de gestion des astreintes.
Les personnes les mieux équipées pour vous dire ce qui fonctionne ou non sont les ingénieurs d'astreinte. Écoutez-les. Implémentez les changements. Et surtout, assurez-vous que la direction n'est pas le seul décideur en matière d'organisation et de protocole des astreintes. Plus vous donnez aux équipes les moyens d'améliorer leurs processus et pratiques, plus elles accepteront les astreintes.
Développez une culture des astreintes dans la bonne humeur
Il incombe aux ingénieurs d'astreinte une responsabilité importante dans la réussite des entreprises. Sans surprise, le stress et les tensions sont des problèmes courants, notamment lors de problèmes majeurs aux causes inconnues.
La culture d'astreinte instaurée par les ingénieurs d'astreinte expérimentés et les équipes dirigeantes définit la façon dont les personnes gèrent ce stress et ces tensions et la manière dont ils ressentent le fait d'être d'astreinte.
Que cela soit pour l'intérêt des ingénieurs d'astreinte ou la culture d'astreinte de l'entreprise, les équipes dirigeantes devraient s'attacher à développer une culture des astreintes dans la bonne humeur et indiquer clairement que l'objectif devrait toujours être d'identifier les problèmes, risques et faiblesses dans les systèmes et de les résoudre.
Chez Atlassian, cela signifie non seulement améliorer constamment nos systèmes de gestion des astreintes, mais également mener des post-mortems sans reproches où l'accent est mis sur l'amélioration et non sur la recherche d'un bouc émissaire.
Découvrez Jira Service Management, une solution qui favorise une culture d'astreinte positive. Construisez un système doté de capacités de communication améliorées, d'alertes centralisées, d'automatisation flexible et de rapports avancés, et faites passer la réponse aux incidents au niveau supérieur.
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 tutorielAdopter une approche optimale des plannings d'astreinte
Un planning d'astreinte efficace est essentiel pour garantir une culture d'astreinte saine. Découvrez les erreurs courantes, les types de plannings de rotation et la marche à suivre.
Lire cet article