Le DevOps n'est pas un métier

"On cherche un DevOps." Tu as sûrement déjà vu cette phrase dans une offre d'emploi, et peut-être même que tu as postulé. Je la lis à chaque fois avec un petit pincement. Le mot désignait au départ une façon de bosser à plusieurs, et on en a fait un poste à pourvoir.

Je reviens ici sur l'origine du mot, sur ce qu'il change dans le quotidien d'une équipe et sur la manière de mesurer si ça marche. Si tu es dev et que ces offres te laissent perplexe, ou si c'est toi qui les rédiges, ça devrait t'aider à y voir plus clair.

Le mot naît en 2009, entre deux conférences

DevOps, c'est Development plus Operations : ceux qui écrivent le code, et ceux qui le font tourner en production.

En juin 2009, John Allspaw et Paul Hammond, qui travaillent chez Flickr, montent sur scène à la conférence Velocity. Leur présentation s'appelle 10+ Deploys per Day: Dev and Ops Cooperation at Flickr. Plus de dix mises en production par jour, et le sous-titre donne la recette : la coopération entre devs et ops.

En octobre de la même année, Patrick Debois organise à Gand, en Belgique, les premiers devopsdays. Le nom de la conférence devient celui du mouvement.

L'idée de départ est simple : casser le mur entre ceux qui codent et ceux qui gèrent l'infra. Avant, les devs balançaient leur code par-dessus la barrière et les ops se débrouillaient pour le faire tourner. Quand ça cassait en prod, chacun regardait l'autre.

Le DevOps, c'est dire : et si on bossait ensemble dès le départ ?

Une culture d'équipe, avec quatre piliers

Un métier, c'est un ensemble de tâches qu'une personne fait. Le DevOps, c'est une culture d'équipe. Tu ne peux pas être "le DevOps" de la boîte comme tu serais "le comptable". Si une seule personne porte le sujet, le mur n'a pas bougé, il a juste changé de place.

En 2010, John Willis et Damon Edwards résument le mouvement en quatre lettres, CAMS :

• Culture : devs et ops partagent les mêmes objectifs et la même responsabilité.
• Automatisation : ce qui se répète est confié à une machine.
• Mesure : on regarde des chiffres pour savoir si on progresse.
• Sharing, le partage : les connaissances et les outils circulent entre les équipes.

On croise aussi la variante CALMS, avec un L pour Lean. Dans les deux cas, une seule lettre parle d'outillage. Les autres parlent de la façon dont les gens travaillent ensemble, et ça ne s'achète pas en embauchant quelqu'un. Ça se construit, avec les gens déjà là.

L'automatisation comme point de départ

Une équipe qui bosse en mode DevOps automatise tout ce qui peut l'être : les tests, les déploiements, le provisioning de l'infra, le monitoring. La raison est très terre à terre : une tâche manuelle, c'est une tâche qu'une seule personne sait faire, qu'on a peur de lancer un vendredi, et qui finit par rater un jour.

Prends la création d'un serveur. Faite à la main dans une console web, elle dépend de la mémoire de celui qui clique. Décrite dans un fichier versionné, elle devient relisible, rejouable, et n'importe qui dans l'équipe peut la modifier via une pull request. C'est le principe de l'infrastructure as code, que je détaille dans l'introduction à TerraformInfrastructure Scaleway avec Terraform · partie 19 minIntroduction à Terraform avec DockerApprendre Terraform sans compte cloud, avec le provider Docker : un premier container, puis PostgreSQL et Adminer, les variables et le cycle plan/apply.Lire l'articleNouvel ongletUn bandeau t'y proposera de reprendre ici, section 3..

Moins de manuel, c'est moins d'erreurs humaines, et surtout plus de temps pour ce qui est intéressant.

Ce que ça change dans le quotidien

Quand la culture DevOps prend, les frontières s'effacent. Un dev apprend à déployer son app et à lire les logs de prod. Un ops apprend à lire du code et à ouvrir une pull request. Tout le monde finit par comprendre le cycle de vie complet d'une application, du commit à l'incident.

Werner Vogels, le CTO d'Amazon, l'a résumé dès 2006 par "you build it, you run it" : l'équipe qui écrit un service est aussi celle qui l'exploite. Concrètement, ça donne des pratiques faciles à reconnaître :

• le pipeline de déploiement vit dans le même dépôt que le code, et tout le monde peut le modifier ;
• les devs participent aux astreintes et aux analyses d'incident ;
• les ops sont associés à la conception d'une fonctionnalité, bien avant sa livraison.

Ce n'est pas confortable au début. Personne n'aime se sentir débutant dans le domaine du voisin. Mais c'est comme ça qu'on construit des équipes qui tiennent.

Cinq chiffres pour savoir si ça marche

Le M de CAMS a son programme de recherche : DORA (DevOps Research and Assessment), aujourd'hui rattaché à Google Cloud. Ses enquêtes, menées auprès de milliers de professionnels, ont abouti à cinq métriques de livraison logicielle :

Le résultat qui m'intéresse le plus tient en une phrase du guide : « speed and stability are not tradeoffs ». Les équipes les plus performantes sont bonnes sur les cinq métriques à la fois : elles livrent souvent et cassent peu. Déployer rarement pour limiter les risques, l'intuition de beaucoup d'organisations, ne protège donc pas.

Remarque qu'aucune de ces métriques ne peut être tenue par une seule personne. Elles dépendent toutes de la façon dont le code passe de main en main.

Le titre d'ingénieur DevOps existe quand même

Oui, le titre existe, et je ne vais pas prétendre qu'il va disparaître. Les boîtes ont besoin de recruter, donc elles mettent des mots sur les fiches de poste.

En pratique, derrière ce titre, tu trouves souvent un dev qui s'est mis à l'infra, un sysadmin qui s'est mis au code, ou quelqu'un qui fait le pont entre les deux mondes. C'est un profil utile. Mais une personne, aussi bonne soit-elle, ne remplace pas une culture d'équipe.

Matthew Skelton et Manuel Pais ont catalogué les organisations possibles dans DevOps Topologies. Deux de leurs anti-patterns décrivent ce qui arrive quand on traite le DevOps comme un poste :

• L'équipe DevOps en silo : on crée une équipe DevOps entre les devs et les ops. Elle devient un troisième silo, et les deux autres se parlent encore moins.
• Le sysadmin rebaptisé : on recrute des "ingénieurs DevOps" pour l'équipe ops sans rien changer aux relations entre équipes. Seul l'intitulé a bougé.

Ce que j'en retiens

Devant une offre "on cherche un DevOps", ce qui compte est dans la suite de l'annonce. Si elle décrit une équipe où devs et ops partagent déjà les déploiements et les incidents, peu importe le titre. Si elle cherche quelqu'un pour s'occuper seul de la CI, du cloud et des alertes pendant que les autres continuent comme avant, le mur est toujours là.

Faire tomber les silos et automatiser prend du temps, et ça se fait avec toute l'équipe.