La culture d’astreinte construite par GitHub

GitHub était un vaste système monolithique construit avec Ruby on Rails.

La partie la plus difficile de la structure d’astreinte du monolithe

• Comme il incluait de nombreux grands produits et fonctionnalités, la plupart des ingénieurs ne se sentaient pas capables de bien comprendre la base de code ni de gérer un incident pendant leur astreinte. Lorsqu’ils étaient appelés, ils avaient l’impression d’être davantage des opérateurs de mise en relation que des ingénieurs, car ils devaient escalader vers d’autres équipes.

• L’intervalle entre deux astreintes était long, et chaque période d’astreinte durait 24 heures. Les ingénieurs assuraient l’astreinte au plus quatre fois par an et n’acquéraient pas suffisamment de contexte pendant cette période.

• Les systèmes de monitoring et d’alerte étaient répartis entre plusieurs équipes, et comme chacun ne faisait l’expérience de l’astreinte que pendant 24 heures, le monitoring et la documentation liés à l’astreinte n’étaient pas bien maintenus.

• Comme la plupart des ingénieurs n’étaient pas à l’aise avec l’astreinte sur le monolithe, les 5 à 10 personnes qui connaissaient bien l’ensemble du système finissaient par intervenir sur tous les incidents de production, ce qui créait un déséquilibre dans la responsabilité d’astreinte.

Une nouvelle culture d’astreinte

Obstacles organisationnels

• Ils ont créé un catalogue de services pour clarifier la propriété des fichiers, en mappant les fichiers aux services, puis les services aux équipes.

• Comme le monitoring et les alertes étaient configurés à l’échelle de tout le monolithe, chaque équipe a été amenée à créer le monitoring de la zone dont elle était responsable.

• Comme il y avait beaucoup d’équipes devant effectuer ce travail, une issue GitHub a été créée pour chaque équipe et une checklist leur a été fournie.

Obstacles culturels et pédagogiques

• La pandémie ayant eu un impact négatif sur les gens, il a fallu adopter une approche centrée sur l’empathie encore plus forte que prévu initialement.

• La plupart des ingénieurs n’avaient pas d’expérience d’astreinte et peu d’expérience en opérations, donc des formations ont été créées et proposées. Des créneaux avec des experts de l’astreinte ont été mis en place, ainsi que des outils, de la documentation et un canal Slack où demander de l’aide.

• Beaucoup d’ingénieurs s’inquiétaient de l’impact de l’astreinte sur leur vie. Quand on a peu d’expérience, il peut être difficile d’ajuster son quotidien pendant une période d’astreinte. Pour y répondre, ils ont rassemblé des conseils et astuces d’experts de l’astreinte et mis en place des mesures comme la possibilité pour quelqu’un d’autre de prendre le relais si un appel est manqué. Comme il s’agit surtout d’un problème lié au manque d’habitude, le sentiment d’aisance viendra probablement avec le temps et la répétition des astreintes plutôt qu’avec la seule formation.

• Comme beaucoup craignaient de ne pas bien gérer l’astreinte, l’objectif est aussi de donner un sentiment de sécurité : faire des erreurs est acceptable, et même en faisant de son mieux, des incidents peuvent malgré tout se produire.

• Le niveau de sévérité diffère selon les produits : certaines équipes doivent répondre en moins de 5 minutes, tandis que pour d’autres, cela peut attendre le lendemain. Certaines personnes trouvent cela injuste, mais cela reflète simplement des centres d’intérêt différents selon les ingénieurs.

• Lors de l’application des changements, chaque équipe ne peut pas consacrer énormément de temps à améliorer l’expérience d’astreinte. Il faut améliorer le processus d’astreinte quand celui-ci ne fonctionne pas correctement. Il a été demandé aux équipes d’utiliser ~20% de leur temps pour rembourser la dette technique et ~20% pour améliorer l’expérience d’astreinte, ce qui nécessite une vision de long terme de la part du leadership.

[galadbran]

Je ne vois pas très bien en quoi consiste l'astreinte... Peut-être une demande de support ? J'imagine que ce n'est pas comme en Corée, où il s'agit de répondre au téléphone...

[andrewchaa]

Dans notre entreprise, on appelle généralement cela l’astreinte : pendant environ une semaine tous les deux mois, on doit réagir en temps réel aux incidents système en dehors des heures de travail. On utilise souvent une application appelée PagerDuty ; lorsqu’un incident de gravité élevée survient — par exemple si des dead letters apparaissent ou si le taux d’échec des API dépasse un certain seuil — une alerte arrive immédiatement sur le téléphone, puis on se connecte avec l’ordinateur portable de l’entreprise pour vérifier les logs et prendre les mesures nécessaires.

[sukso96100]

On peut considérer cela comme un système d’astreinte.

[bach80]

On dirait quelque chose comme un roulement d’astreinte ou une permanence hebdomadaire. La gestion des incidents se fait à tour de rôle...