J’arrive un peu après la bataille, mais à la suite d’une récente discussion entre collègues j’ai ressenti le besoin d’écrire mon avis sur la mouvance DevOps apparue il y a quelques années, et qu’on retrouve désormais partout.

Note de l’auteur : ceci est un billet d’humeur qui reflète un avis personnel.

À moins d’avoir vécu dans une grotte depuis un certain temps, si vous travaillez dans les environnements de production informatique vous avez inévitablement entendu parler de DevOps. Il est probable que vous ayez été décrit par ce terme dans votre intitulé de poste, et/ou dans le nom de l’équipe au sein de laquelle vous évoluez. Peut-être avez-vous utilisé des outils DevOps, voire fait du DevOps. C’est là tout le problème : il n’y a pas de définition officielle, seulement un vague consensus sur ses principe fondamentaux. Bien qu’il existe une page Wikipédia, cela ne signifie pas pour autant que tout le monde soit d’accord sur ce que cela signifie en pratique. C’est le sujet de ce billet : mon observation du DevOps dans la vraie vie ces dernières années.

Avant de vous relater mon expérience du DevOps, je vais commencer par vous en exposer ma vision :

Le DevOps n’est pas un titre de poste.
Le DevOps n’est pas un nom d’équipe.
Le DevOps n’est pas un outil.
Le DevOps n’est pas un synonyme de sysadmin.
Le DevOps n’est pas un synonyme de développeur.

Pour moi, le DevOps c’est ce qui arrive lorsque développeurs et opérateurs (communément appelés administrateurs système, ou sysadmins) parviennent à travailler ensemble en bonne intelligence, en ayant conscience de leurs contraintes respectives. C’est une situation dans laquelle ces deux domaines coopèrent au lieu de s’affronter, où ils comprennent et tiennent compte des enjeux l’un de l’autre. C’est une culture, une ambiance. Des outils peuvent y contribuer, mais pas les titres de poste ni les noms d’équipe.

Je n’ai eu la chance d’être témoin qu’une seule fois de la mentalité DevOps à l’oeuvre, et c’était beau. À l’origine, la situation était le typique « devs vs ops » : des développeurs qui développent et déploient du code avec peu voire aucune considération quant à son comportement une fois en production, et des ops qui se font aléatoirement réveiller par le pager la nuit en astreinte parce que le service est en panne ou lent – sans avoir la moindre idée de pourquoi, redémarrant au petit bonheur la chance des instances applicatives back-end dans l’espoir que cela résolve le problème. Des développeurs n’ayant pratiquement aucune idée d’à quoi ressemble l’infrastructure qui fait tourner leur code. Des sysadmins qui interdisent l’accès shell aux développeurs, même en lecture seule. Des besoins en nouveaux composants d’infrastructure – tels qu’une nouvelle technologie de base de données – introduits en effet de bord d’une nouvelle fonctionnalité du produit, formulés à la dernière minute, typiquement après que le code ait été implémenté et soit prêt à être déployé. Au fait : c’est aux sysadmins d’appréhender, de déployer et de gérer ces nouveaux composants à l’échelle, d’astreinte et en l’espace de quelques jours.

Comme vous pouvez l’imaginer cette situation mena à la frustration des deux équipes, toutefois elle a heureusement fini par être désamorcée avant d’atteindre le point de non-retour. Le responsable de l’ingénierie venait tout juste de rejoindre l’entreprise, et après une période d’observation décida de mener une série d’entretiens individuels avec les membres des équipes respectives afin de leur demander de s’exprimer leur ressenti sur leur cadre de travail actuel, puis convia ensuite les deux équipes à participer à une réunion commune. Au cours de cette session, tous les participants furent invités à identifier les problèmes perçus et les écrire sur des Post-it. Une fois ramassés, tous les Post-it furent expliqués aux participants présents par leurs auteurs, puis répartis selon des thèmes globaux tels que « confiance », « responsabilité », « outillage » ou encore « documentation ». À l’issue de la réunion, plusieurs binômes constitués d’un développeur et d’un sysadmin furent formés et se virent attribuer un groupe de problèmes écrits sur les Post-it, et chargés de les résoudre ou de présenter des solution à l’assemblée la semaine suivante. Chaque semaine, les mêmes personnes se réunirent de nouveau pour discuter de l’avancement de leurs tâches respectives et présenter les progrès réalisés, ou les raisons expliquant pourquoi un problème ne pourrait pas être résolu. Cela prit des semaines, mais la plupart des problèmes identifiés furent résolus à mesure que la communication entre les membres des deux équipes s’améliorait.

En tant que responsable de l’équipe « ops » j’ai pris cette démarche d’amélioration très à cœur, car elle nécessitait des changements culturels significatifs : cesser d’infantiliser mes collègues développeurs mais plutôt leur faire confiance par défaut, à commencer par leur mettre à disposition un accès shell aux serveurs de production – leur permettant d’explorer librement l’infrastructure et voir par eux-même comment tourne leur code en situation réelle. En retour, j’ai exigé leur implication : j’attendais d’eux qu’ils se soucient de leur code en production, qu’ils consultent régulièrement les logs et métriques applicatives lorsqu’ils déploient du nouveau code – et même lorsqu’ils n’en déploient pas. L’équipe « ops » se mit à travailler sur un outil de déploiement de code pratique et fiable pour remplacer la collection de scripts shell rudimentaires qui leur avait été mise à disposition des années auparavant, qui une fois implémenté rendit le processus de déploiement de code plus convivial. En échange, j’ai demandé aux développeurs de nous fournir une documentation à jour et pertinente de leurs applications back-end (liste des dépendances de services, descriptions de métriques utiles…) ; au bout du compte, ils finirent par gérer et déployer eux-même sur les serveurs de production les configurations de collecte de métriques applicatives en utilisant les outils de gestion d’infrastructure.

Quelques semaines avant de quitter l’entreprise, un de mes derniers projets a consisté à concevoir et implémenter un système de monitoring de nos services back-end basé sur des SLA, pour lequel les développeurs identifiant les métriques de performance clé ainsi qu’un seuil au-delà duquel une notification serait envoyée sur le channel Slack de ces derniers pour les informer qu’un éventuel problème nécessite leur attention. Pour moi, nous avions atteint le summum du DevOps : des développeurs et des sysadmins collaborant activement pour atteindre un but commun et partager la responsabilité d’un service exposé à des utilisateurs. Au-delà des outils, cela requiert de la communication, de l’empathie mais aussi le soutien du management.

La triste réalité est que pour une implémentation correcte de la mentalité DevOps, j’ai pu observer beaucoup d’autres tentatives dysfonctionnelles voire toxiques. La vaste majorité consistait à renommer le titre de bon vieux de sysadmin en DevOps sans en changer les prérogatives, ou pire à créer une nouvelle équipe nommée DevOps « transverse » pour faire passerelle entre les développeurs et les sysadmins dans l’espoir de réduire les frictions.

Ne reste aujourd’hui du DevOps qu’un terme galvaudé et omniprésent, sur le point de se faire éclipser par une nouvelle étiquette à la mode : le SRE – pour Site Reliability Engineering, un concept inventé par Google au sujet duquel un livre entier a été écrit. De ce que j’ai pu voir ces dernières annés, SRE est destiné à devenir le prochain DevOps, car il est plus facile pour les entreprises de renommer des titres de postes ou des équipes que de changer leur culture.