Il s’agit du livre de référence dans le domaine, celui qui a lancé et donné son nom – enfin je crois – à la discipline visant à mettre le software engineering au service de la production ou des opérations. Avant cela, il y avait les développeurs en charge de concevoir les applications et ceux que l’on appelait les administrateurs s’occupaient de les déployer et de les superviser en production. Le problème avec ce modèle est que les uns ne connaissent rien – ou presque – au travail des autres et le résultat était au mieux chaotique et au pire donnait lieu à des querelles assez animées qui se transformaient vite en guerre de tranchées. Ça semble aberrant, mais c’était le modèle et c’est cette fracture que la mouvance DevOps s’est efforcée de résorber. Difficile de différencier clairement les deux mouvances, mais je dirais – ce n’est que mon point de vue – que le DevOps peut être atteint en constituant des équipes mixtes (développeurs + administrateurs) alors que les SRE possèdent des compétences mixtes (développement et administration), et mettent l’une au service de l’autre, l’Infrastructure as Code en est le parfait exemple.

Ce livre est une collection d’articles de plusieurs auteurs relatant divers aspects de leur discipline mise en pratique au sein de Google. Pour cette raison, le livre manque un peu de consistance et les articles sont inégaux de par leur intérêt ou leur format. Certains sont fondamentaux, comme ceux consacrés au monitoring, alors que d’autres valent plus pour leur côté retour d’expérience. Il est plus qu’intéressant pour comprendre un choix d’une technologie de comprendre les raisons qui ont poussé Google à développer l’outil Borg1 dont la version open source n’est autre que l’une des technologies dont on parle le plus en ce moment, Kubernetes. Revenir à la genèse d’un tel outil permet d’en comprendre le but ultime, pouvoir faire tourner du code de façon complètement indépendante de l’infrastructure, et ce besoin semble parfaitement louable lorsque l’on dispose comme Google d’un nombre colossal de serveurs qui peuvent être parfois hétérogènes – je me doute que c’est au moins le cas pour des générations différentes. J’ai trouvé d’autres articles moins intéressants, mais ce ne sera pas forcément le cas pour tout le monde, c’est en fonction de son expérience, de ses attentes et de ses intérêts. Tout le monde n’est pas Google et n’a pas les mêmes problématiques à résoudre, mais il est toujours intéressant de connaître la façon dont elles ont été adressées, pour tenter de comprendre la démarche et de peut-être, très modestement s’en inspirer. Un livre de référence que l’on peut – qu’il vaut mieux – lire par petits bouts d’autant plus qu’il est disponible en intégralité en ligne – merci Google.


Beyer, Betsy, et al. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly, 2016.


  1. Google’s Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines ((source)[https://research.google/pubs/pub43438/]). ↩︎