The Devops Handbook

S’il n’y avait qu’un livre sur le DevOps à lire – et il faut en effet n’en lire qu’un seul, la vie est trop courte – ce serait celui-là. Enfin non ce n’est pas vrai, je dis déjà des bêtises, si on a un peu de temps et que l’on travaille dans ce domaine, il faut aussi lire Site Reliability Engineering¹. Ce Devops Handbook n’est pas passionnant à lire – on ne peut pas dire que ce soit la grosse poilade –, mais ce n’est pas ce que l’on attend d’un tel livre. Si on cherche une introduction plus divertissante sur ce sujet, il faut lire son pendant en roman. Ecrit par les mêmes auteurs, il a précédé la parution de cet opus technique et a connu un succès retentissant, le désormais célèbre: The Phoenix Project².

The Devops Handbook comme son titre le suggère n’est pas un roman, mais il excelle dans son domaine en étant irréprochable sur le plan de l’exhaustivité et de la pertinence. Il est entre dans le registre de ce que l’on appelle communément un livre de référence. Il embrasse l’ensemble des sujets en n’oubliant pas grand chose et en l’illustrant par des exemples tirés des plus grands acteurs de l’industrie – on retrouve ici les habituels Netflix et consorts. Mais voilà, il faut soit piocher à droite à gauche, soit faire preuve de beaucoup d’abnégation pour arriver au bout du livre – je suis dans le second cas, car je m’étais mis dans la tête de le lire de bout en bout (cover to cover). L’absence d’attrait dans la lecture vient peut-être du fait que beaucoup de choses compilées dans ce livre sont déjà connues des professionnels travaillant dans le domaine – c’est mon cas, nous entendons parler et mettons en pratique un grand nombre des éléments évoqués dans le livre. Mais il n’empêche que cette lecture m’a permis de reconsidérer certains points et poussé à mettre plusieurs choses en application. Certaines rubriques raisonnent et permettent de prendre du recul par rapport à notre activité quotidienne. Un exemple tout simple parmi d’autres. Ça paraît évident quand on le dit, mais j’ai pris conscience que les pull request (PR) pouvaient être une façon simple, moderne et efficace d’implémenter les peer reviews y compris au sein d’une même équipe – je sais, je sais, mais je ne l’avais pas forcément vu sous cet angle. Enfin là ou il pèche par une certaine austérité, il brille par sa structure sans faille étayée par les 3 piliers du DevOps.

• “The First Way: The Principles of Flow”: Comment et pourquoi livrer et déployer en continue.
• “The Second Way: The Principles of Feedback”: Comment obtenir des retours sur ce que l’on a livré: monitoring, performance, statistiques, etc.
• “The Third Way: The Principles of Continual Learning and Experimentation”: Comment s’améliorer en continue et laisser de la place à l’innovation dans cet objectif.

---

Gene Kim, John Willis, Patrick Debois, Jez Humble & John Allspaw, The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, IT Revolution Press, 2016, 480 p, Amazon.