Construire une culture d’astreinte saine
(developers.soundcloud.com)- Conseils de SoundCloud sur l’« on-call », qui consiste à désigner un ingénieur chargé d’être appelé (paging) et de résoudre les problèmes qui surviennent en dehors des heures de travail
-
Les astreintes sont facultatives (optional, réservées aux volontaires)
-
Comme il s’agit d’un travail effectué en dehors des heures normales, il est rémunéré à l’heure, avec un paiement horaire supplémentaire en cas de réponse à un paging
-
Les ingénieurs d’astreinte sont organisés en plusieurs rotations
-
Chaque rotation
→ est composée d’un groupe d’ingénieurs représentant une ou plusieurs équipes
→ a toujours 1 ingénieur de garde chargé du support de premier niveau pour les problèmes de toutes les équipes de la rotation
→ les autres ingénieurs restent disponibles pour fournir un support de second niveau sur les problèmes liés aux services de leurs propres équipes
→ le support de second niveau repose sur le principe du best-effort : ils peuvent être pagés à tout moment et feront de leur mieux pour intervenir si possible, mais n’ont pas l’obligation de répondre s’ils ne le peuvent pas
Pourquoi l’astreinte est-elle bénéfique pour les ingénieurs ?
-
Faire participer à l’astreinte des profils variés au-delà du DevOps et des SRE (Site Reliability Engineers) est bénéfique à la fois pour l’entreprise et pour les ingénieurs eux-mêmes
-
Cela réduit la charge des ingénieurs d’exploitation, souvent sursollicités en dehors des heures normales
-
Cela motive les ingénieurs à construire des systèmes stables et bien documentés
→ voir directement les problèmes lorsqu’ils surviennent permet d’obtenir des insights sur la manière d’améliorer et de renforcer le système
- Assurer le support à la fois de ses propres systèmes et de ceux des autres est une excellente occasion d’apprentissage pour les ingénieurs
Bonnes pratiques procédurales : chaque organisation est différente, mais voici le processus optimal identifié par SoundCloud
-
Chaque rotation a un rythme différent, mais la plupart fonctionnent avec une relève tous les 1 à 2 jours
-
Environ 3 jours d’astreinte par mois semblent optimaux. Au-delà, on risque le burnout ; en dessous, ce n’est pas très efficace.
→ En d’autres termes, la taille idéale d’une rotation est de 8 à 12 personnes. 10, c’est parfait.
- Choisir dans chaque rotation un responsable formel ou informel pour gérer la rotation, notamment le planning des relèves et les changements d’effectif
→ Exemple : ajuster le planning des relèves pendant les périodes de vacances
Les équipes de rotation et l’organisation
-
L’organisation de SoundCloud a évolué au fil du temps, avec des fusions, des divisions, la création de nouvelles équipes et des transferts entre départements
-
Mais les équipes de rotation d’astreinte n’ont pas évolué au même rythme que l’organisation d’ingénierie
-
Aujourd’hui, de nombreuses rotations ressemblent parfois à des groupes aléatoires d’équipes sans lien entre elles
-
Mais cela ne pose pas problème, et les tentatives de changement ont été abandonnées après l’opposition des ingénieurs
Bonnes pratiques culturelles : pour le bénéfice des ingénieurs d’astreinte et de l’entreprise dans son ensemble, encourager les normes et attitudes suivantes
-
Les personnes d’astreinte veulent être d’astreinte. Les ingénieurs qui assument cette responsabilité volontairement (et sont rémunérés pour cela) sont plus motivés lorsqu’ils doivent répondre à un incident
-
Les questions comme le rythme des relèves sont décidées par concertation entre les ingénieurs de chaque rotation. L’entreprise ne fournit pas de procédure standard sur les schémas de rotation, les horaires de relève ou le transfert d’astreinte entre individus
-
Les ingénieurs d’astreinte passent souvent du temps pendant les heures normales à enquêter sur ces problèmes afin qu’ils ne s’aggravent pas et n’obligent pas à pager quelqu’un en dehors des heures de travail
-
Lors d’une réponse à incident, les ingénieurs peuvent appeler d’autres ingénieurs à l’aide. Personne n’aime recevoir un appel de support de second niveau en pleine nuit, mais répondre et aider quand c’est possible permet de former les autres afin qu’ils puissent gérer seuls une situation similaire plus tard
-
Après un délai raisonnable, il doit être possible de transmettre librement le travail à quelqu’un d’autre. En cas d’incident grave ou prolongé, si les ingénieurs sont trop fatigués pour travailler efficacement, il vaut mieux passer le relais après 4 heures, voire avant
-
Le plus important, c’est de « favoriser une culture de l’apprentissage plutôt qu’une culture du blâme ». On ne le répétera jamais assez
→ les erreurs sont une part inévitable de la réponse à incident, et apprendre de ces erreurs permet de construire une organisation d’ingénierie plus solide et techniquement plus compétente
→ si l’on punit les gens pour leurs erreurs, les ingénieurs auront peur d’agir face à des situations nouvelles, peur de demander de l’aide et peur de la transparence
→ au final, dans une culture du blâme, les gens finissent par quitter la rotation d’astreinte ou l’entreprise
Lorsqu’un incident majeur se produit
-
Répondre à une panne générale du site ou à un incident grave est stressant pour tout le monde
-
C’est aussi un test de résistance pour la culture d’astreinte de l’entreprise
-
Il est plus important que tout que les ingénieurs travaillent ensemble et se fassent confiance
-
Si l’on peut reconnaître ce qu’on ne sait pas, demander de l’aide aux autres, parler honnêtement de ses erreurs et dire qu’on est trop fatigué pour continuer, alors on peut résoudre les problèmes plus rapidement
-
Il faut encourager ces comportements avant qu’un incident majeur ne survienne. Les ingénieurs apprennent par l’expérience en répondant à de petits incidents et en collaborant avec leurs collègues.
→ les petits incidents sont un entraînement pour les grands
1 commentaires
La culture d’astreinte mise en place par GitHub https://fr.news.hada.io/topic?id=3551
Runbooks d’astreinte de GitLab https://fr.news.hada.io/topic?id=966
Dans une startup, comme il n’y a pas beaucoup de monde, on a souvent l’impression d’être toujours d’astreinte…
Mais dès que l’organisation commence à grandir un peu, on voit que seules certaines personnes finissent par rester d’astreinte en permanence, au point de résoudre des problèmes le soir et le week-end, jusqu’au burn-out.
Je pense qu’il faut avant tout bien construire cette culture (et à vrai dire, je me remets aussi en question, car j’ai l’impression de ne pas avoir su bien le faire…)