Note 4 ; Les bases d’une nouvelle discipline au milieu d’essais assez hétéroclites.

Le SRE est l’une des nouvelles tendances du moment. Elle figure le pendant « run » du devops de manière générale, mais reste parfois difficile à distinguer aussi clairement. Le présent ouvrage a mis en lumière cette nouvelle discipline, aussi pourrait-on le qualifier « d’historique ». Dans les faits, il s’agit avant tout d’un recueil d’articles. Malgré le travail éditorial effectué, il ne faut pas en attendre le niveau de cohérence d’un ouvrage classique.

Avec ses 475 pages rythmés sur 34 chapitres et structurés en 5 parties, l’ouvrage est une belle bête, au moins au niveau du volume. La première partie ne compte que deux d’entre-eux sur une vingtaine de pages et sert d’introduction aux parties suivantes. « Introduction » est d’ailleurs le titre du 1er chapitre. Celui-ci nous esquisse en quelques lignes ce qu’est le SRE chez Google. Car j’ai oublié de préciser qu’il s’agit d’articles en provenance de Google. Le second chapitre ne se situe guère en continuité car il évoque l’environnement de production. Cette infrastructure est gérée par « Borg » qui n’est pas moins que l’ancêtre de Kubernetes !

La seconde partie assoie les principes du SRE. Elle compte 7 chapitres pour un total de 75 pages. Elle débute par un chapitre 3 qui a pour but de nous donner un éclairage « risques ». C’est surtout la notion de budget d’erreur qui y est important. Le chapitre 4 aborde une notion clé du SRE : le SLO pour Service Agreement Objective, que Google préfère au SLA. Les auteurs nous expliquent comment construire ces SLO par rapport aux SLI (« I » pour indicateur), et ce par l’exemple. Un bon chapitre. Le chapitre 5 est consacré au labeur, que l’on pourrait aussi appeler travail de m… Surtout ce chapitre entrouvre un aspect majeur du RSE : Google emploie pour ce travail des développeurs plutôt que des ingénieurs système car l’objectif est d’éliminer ou automatiser tout cela plus que d’effectuer des corrections !

Changement de direction avec le chapitre 6 qui évoque les principes du monitoring. Ce sont vraiment des principes très généraux et l’intérêt du texte est hélas limité, alors que le sujet est intéressant. Le chapitre 7 va s’inscrire dans la continuité du chapitre 5, il s’agit d’un plaidoyer pour l’automatisation. Il revient sur le travail de développement des SREs et nous dévoile des aspects de la genèse de Borg, pour automatiser en tâches récurrentes ce qui étaient autrefois des tâches d’ingénierie système.

Le release engineering abordé au chapitre 8 évoque sans ambiguïté les choix de l’entreprise : déploiement continu et développement « trunk-based ». Un chapitre qui risque de me servir beaucoup. Cette seconde partie se clôt par un chapitre 9 résolument tourné vers les principes de conception, et surtout d’un en particulier : la simplicité. Il n’est à la fois pas très utile et un peu en décalage ici.

La 3ème partie est plus qu’une partie : elle couvre 280 pages avec 17 chapitres et a trait aux pratiques. Le chapitre 10 qui ouvre le bal est même presque plus de l’outil que de la pratique, car s’il s’agit (de nouveau) de monitoring, c’est de Borgmon dont il est question. Mais le propos est surtout centré sur la gestion des « time series ». Le propos, illustré par du code manque hélas de clarté. Le chapitre 11 est plutôt court, il nous explique les choix opérés pour rendre résiliente la gestion des astreintes. Le troubleshooting est assurément une des pratiques importantes du run. Mais je ne suis pas certain que ce chapitre fût mérité. On n’y apprend peu de chose, l’approche est des plus classique. S’inscrivent dans la continuité de ce chapitre : La réponse d’urgence et la gestion des incidents.

Petit détour par une pratique agile au chapitre 15 : le postmortem. Il est au cœur du boulot du SRE qui cherche à améliorer et automatiser le système. La pratique des tests a droit à un gros chapitre (le 17), ce seront surtout ici les tests de configuration qui ont retenu mon attention. Le sujet avait été évoqué précédemment, mais c’est spécifiquement à l’ingénierie qu’est consacré le chapitre 18 et à la manière dont l’équilibre des tâches s’opère entre le traitement des incidents et l’amélioration via le travail d’ingénierie. Les 3 chapitres qui suivent ont trait à des problématiques d’architecture d’infrastructure. Difficile de raccrocher cela au propos principal. Le problème des échecs en cascades au chapitre 22 est un classique pour lequel les auteurs proposent plusieurs stratégies de traitement. Ce n’est pas mon chapitre préféré, mais il fait le boulot.

La question du consensus distribué traité au chapitre 23 a peu à faire dans cet ouvrage à mon avis, et est de toute manière mieux traitée dans le texte de Martin Klipmann. Mais il sert à introduire Paxos, l’outil de gestion des Cron distribués qui est au menu du chapitre 24. Les pipelines de données distribués sont désormais la norme du big data et leur gestion est un sujet à part entière. Leur traitement au chapitre 25 est quelque peu frustrant. Ce n’est pas le cas du chapitre 26 dévolu à l’exploration des stratégies pour assurer l’intégrité des données : de nombreuses stratégies pouvant se combinées y sont décrites avec leurs contraintes et leurs bénéfices. Cette 3ème partie se referme sur un chapitre 27 consacré au déploiement de produits à l’échelle. A très grande échelle ! Un propos tout à fait unique.

La 4ème partie est dédiée au management, sur 5 chapitres et près de 70 pages. Le chapitre 28 expose la manière dont les nouveaux venus sont onboardés sur les astreintes, à la fois en montée en compétence et en accompagnement par des séniors. Tout bonnement excellent. Les deux chapitres suivants adressent la question de la gestion du temps et des interruptions entre gestion d’incidents et développement. On y trouve de bonnes réflexions sur des questions de surcharge d’incidents et de sacralisation de temps de développement.

Si vous attendez des révélations du chapitre 31 traitant de la collaboration, vous allez être déçus. Illustré par le projet « Viceroy » on y trouve plus ou moins ce que l’on trouve dans un texte consacré à l’agilité. Cette partie se conclut sur un chapitre sur le modèle d’engagement : le PRR model. C’est très bien d’avoir une sorte de contrat avec les équipes produit, mais je n’ai guère été ébloui par celui-ci.

La dernière partie sert de conclusion à l’ouvrage. Il faut encore compter 2 chapitres sur 18 pages. Le chapitre 33 focalise notre attention sur quelques points clés (ce serait dommage de les rater) : « l’espoir n’est pas une stratégie » et il faut être préparé à ce qui peut arriver, il faut progresser et s’améliorer grâce aux postmortems et enfin il faut automatiser autant que faire se peut.

Le texte étant une compilation d’articles, malgré le travail d’édition, il reste très hétéroclite, avec certains articles que j’ai trouvé très à la marge du thème. C’est à la charge du lecteur de compiler et synthétiser les enseignements et conseils du texte pour se faire une compréhension de ce qu’est le SRE. En saisir les points clés, c’est un peu le « cherchez Charlie » de ce texte de 500 pages. S’il s’était agi d’un véritable livre, la prose aurait pu tenir dans la moitié du volume, voire moins. Mais avec des choix éditoriaux délibérés qui manquent ici.

Référence complète : Site Reliability Engineering – Betsy Beyer, Chris Jones, Jennifer Petoff & Niall Richard Murphy edt. – O’Reilly 2016 – ISBN : 978 1 491 92912 4