Ce livre écrit par des employé·e·s de Google parle de leur vision de la gestion des opérations, et des personnes qui s’en occupent.
La grande idée du livre est que Google n’emploie pas d’ops mais des « ingénieur·e·s de la disponibilité » (SRE en anglais). Leur vision est que les opérations doivent être vus comme une branche du développement logiciel, et donc avec le prisme de l’ingénierie. À savoir qu’il faut autant que possible limiter les tâches manuelles qui prennent du temps et introduisent des risques d’erreurs et pour cela s’outiller pour être efficace et industriel.
Les SRE sont en charge de ce travail. Distincts des équipes de développement, leurs tâches consistent à concevoir et opérer des plateformes et des systèmes de manière à assurer la disponibilité du parc d’applications.
Un des enjeux est de parvenir à limiter le temps passé sur les opérations manuelles pour permettre d’investir dans l’automatisation.
Cela couvre des briques d’infrastructures comme les conteneurs d’exécution mais aussi l’équivalent de middlewares comme le transfert de fichier.
Le livre est assez long et couvre de nombreux sujets, plutôt que de le résumer je vais me concentrer sur les éléments qui m’ont le plus marqué.
Google parle de Google
La première chose qui marque est la vision de Google qui est projetée dans le livre.
Publier un livre sur sa culture interne est une opération de soft power, le portrait de Google par Google est donc intéressant à étudier, dans ce qu’il dit et ce qu’il ne dit pas.
D’après les textes Google est la terre des héro·ïne·s : on n’embauche que les meilleur·e·s et on passe son temps sur des questions qui ne se posent à personne d’autres, au point que l’autosatisfaction est parfois pesante.
Par contre les problèmes et les dysfonctionnements sont poliment éludés où font l’objet de courtes allusions.
Cela montre les limites de la véracité du portrait, mais aussi parce que cela empêche de parler de certains sujets sur lesquels l’expérience de Google serait précieuse : le burn-out, la question des objectifs et des salaires, ou la gestion du rapport de force entre les équipes SRE et les équipes de développement.
Ops chez Google : quand même des personnes qui n’ont pas le niveau
Le livre s’ouvre sur une description des profils des SRE très parlante de la vision de Google.
Les équipes de SRE sont constituées de deux types de profils :
-
50% à 60% d’ingénieur·e·s logiciels de plein droit ;
-
40% à 50% de personnes qui ont échoués aux tests d’entrées pour être embauché·e·s comme ingénieur·e·s logiciels (mais de peu : Google ne prend quand même pas n’importe qui), mais qui savent faire de l’administration système ou du réseau, car leurs compétences sont nécessaires.
La manière dont la chose est présentée est éloquente : il y a les ingénieur·e·s de développement, et les presque ingénieur·e·s de développement qu’on est forcé d’embaucher quand même car on ne peut pas complètement se passer d’expertise.
Il me paraît évident que cette vision affecte le fonctionnement des équipes, mais le livre n’en parle pas.
SRE et DevOps
Google ne suit pas la mode d’intégrer les ops dans les équipes de développement pour augmenter la capacité d’adaptation.
Leur vision est que leur niveau de “packaging” des différents composants d’infrastructure et le découplage qu’elle permet vis-à-vis du système sous-jacent limite le besoin en compétence ops des projets.
Cela est complété par un effort important sur la documentation pour limiter le besoin pour les SRE de faire du support aux équipes.
La dernière étape est que la validation des SRE est nécessaire pour qu’un projet significatif soit déployé en production. Pour cela le projet doit valider une checklist pour prouver qu’il suit les obligations et les bonnes pratiques Google : gestion de la disponibilité, redondance, procédure en cas de défaillance d’un composant.
On retrouve donc une organisation dev/ops classique, mais qui d’après Google n’a pas les défauts qu’on retrouve ailleurs grâce au niveau de qualité des différents composants et à l’excellence des personnes et des pratiques.
L’approche Google m’a fait réfléchir au modèle “ops dans les équipe de dev”. Il est vrai que dans beaucoup de contextes ce fonctionnement est souhaitable car des compétences en ops sont nécessaires pour le projet d’une manière régulière. Et dans un certain nombre de cas, quand le projet a une complexité raisonnable et s’appuie sur des outils du marché, ces compétences sont nécessaires parce que la plateforme de production n’est pas au niveau où elle devrait être : on contourne un problème systémique par des solutions locales.
Les progrès des plateformes de cloud et des solutions de cloud privés verront peut-être la fin de cette mode.
Pilotage de la qualité par la qualité de service
Le livre insiste beaucoup sur la nécessité de s’appuyer sur les métriques pour piloter un système d’information de la taille de celui de Google. Les SRE sont en charge de la disponibilité, la mesure de la qualité de service (SLO) est donc une métrique fondamentale dans leur travail.
Lorsque les projets ont des objectifs de SLO il s’agit d’objectifs trimestriels sur lesquels ils doivent s’engager.
Pour cela les SRE ont le pouvoir d’imposer à un projet qui surconsomme son “budget disponibilité” de limiter le développement de nouvelles fonctionnalités pour se concentrer sur la fiabilisation jusqu’à être revenu à un niveau satisfaisant.
Par ailleurs lorsqu’un projet est particulièrement incidentogène, il est possible pour les SRE de se délester d’une partie de leur travail de support sur le projet afin de dégager le temps permettant d’automatiser ce qui peut l’être pour diminuer la charge sur le moyen-terme.
Process & documentation
La complexité des systèmes ainsi que la croissance rapide des équipes (sans parler du turn-over) justifient un important accent mis sur les process et la documentation écrite.
Pour Google la construction d’une mémoire collective passe par l’écrit, et la diffusion de ces écrits, par exemple des séances de discussion après lectures de post-mortems d’incidents.
Capacité à faire
Dans les discussions sur la redondance ou les temps de réponses, j’ai été frappé par la capacité à faire de Google.
En effet, par rapport à une entreprise classique dont la bibliothèque de logiciels est limitée à quelques composants standards ce qui limite les possibles, la taille et la stratégie de Google leur permet de créer un écosystème très riche.
Par exemple un projet qui a besoin d’un système de stockage distribué pourra choisir parmi de nombreuses solutions suivant ses besoins de performance, de disponibilité…
En creux on reconnaît le syndrome du not invented here : les auteur·e·s martèlent en permanence le fait que les spécificités de Google les empêchent absolument d’utiliser des solutions créees par d’autres, mais leurs justifications sont parfois un peu douteuses.
Pour conclure
Le fonctionnement décrit par le livre est intéressant, et le levier que représente un haut niveau d’automatisation est séduisant.
Mais les zones d’ombres du livre ainsi que le niveau de rigueur que cette approche suppose me font penser qu’elle sera rarement transposable tel-quel, et que le mieux sera d’essayer d’en reprendre quelques idées sans essayer de voir trop grand.