La conférence de Flickr sur les « 10+ déploiements par jour » met fin à la guerre entre développeurs et opérations

En 2009, Flickr, le site de partage de photos au sein de Yahoo, mettait constamment à jour son service, et le clivage par défaut du secteur — les développeurs livrent des fonctionnalités, les opérations maintiennent la stabilité du site — faisait de chaque changement un combat. Le changement est la cause première de la plupart des pannes, si bien que les équipes qui « protègent » le plus durement le site sont celles qui livrent le plus lentement.

Rendre le changement sûr plutôt que rare : des outils partagés — drapeaux de fonctionnalités, déploiements en une étape, métriques partagées, robots de messagerie — et une culture sans blâme rendent routine la cadence de plus de 10 déploiements par jour.

Le responsable côté opérations John Allspaw et le responsable côté ingénierie Paul Hammond ont reconstruit les livraisons autour d'une responsabilité conjointe : infrastructure automatisée, un tronc de gestion de versions partagé, compilation et déploiement en une étape, drapeaux de fonctionnalités, tableaux de bord de métriques partagés et robots de messagerie IRC — le tout assorti d'une liste culturelle explicite : respect, confiance, attitude saine face à l'échec et refus du blâme.

Leur session à Velocity en juin 2009 a attiré plus d'attention que toute autre conférence de l'événement, et le cadrage outils-plus-culture est devenu le cœur du manuel DevOps : quelques mois plus tard, le mouvement s'est nommé lors du premier devopsdays à Gand, et les « déploiements par jour » sont devenus un repère du secteur.

En 2009, Flickr, le site photo au sein de Yahoo, livrait constamment : un jour normal, il effectuait dix déploiements complets ou plus du site web en production. À la conférence Velocity d'O'Reilly à San Jose ce mois de juin, les deux responsables qui dirigeaient les opérations et l'ingénierie chez Flickr, John Allspaw et Paul Hammond, ont expliqué comment ils y parvenaient, dans une conférence intitulée « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ». Le compte rendu de la conférence par Data Center Knowledge l'a qualifiée de présentation ayant suscité le plus d'engouement de l'événement.

Leur argument s'attaquait à l'organigramme par défaut du secteur. Le stéréotype — les développeurs ajoutent des fonctionnalités, les opérations maintiennent le site stable et rapide — fait du changement l'ennemi, puisque le changement cause la plupart des pannes. Allspaw et Hammond l'ont inversé : le rôle des opérations est de permettre l'activité, l'activité exige du changement, donc le vrai travail consiste à réduire le risque du changement par les outils et la culture. La boîte à outils : infrastructure automatisée, un tronc de gestion de versions partagé, compilation et déploiement en une étape, drapeaux de fonctionnalités qui livrent le code en mode invisible, métriques partagées et robots IRC qui permettent à chacun de suivre les mises en production.

L'autre moitié était culturelle : respect, confiance, attitude saine face à l'échec et refus du blâme — y compris des exercices de crise pour que même les ingénieurs juniors aient pratiqué des incidents de production avant un vrai, car l'échec surviendra. Ce mois d'octobre-là, Patrick Debois a organisé le premier devopsdays à Gand, en Belgique ; le mouvement qui a pris son nom à cet événement a porté le cadrage de la conférence Flickr — des livraisons petites, sûres et fréquentes par des équipes qui partagent les outils et ne blâment personne — dans les organisations d'ingénierie du monde entier.

Cela nommait la vraie contrainte : dans une activité web, le train des livraisons est l'activité elle-même, et une équipe capable de déployer en sécurité dix fois par jour apprend simplement plus vite qu'une équipe qui livre une fois par mois.

Les outils partagés fabriquaient un destin partagé — un tronc, un tableau de bord, un bouton de déploiement — si bien qu'aucun camp ne pouvait gagner en faisant perdre l'autre.

Cela redéfinissait les opérations, de gardiennes de la stabilité à facilitatrices du changement, permettant de juger l'automatisation et la culture à une seule question : à quelle fréquence pouvons-nous livrer en sécurité ?

Cela traitait le blâme comme un défaut d'ingénierie, non comme un défaut de caractère : si les gens cachent leurs erreurs, le risque s'accumule en silence ; les exercices de crise et les revues sans blâme maintiennent l'information en circulation.

Le débit vient du fait de rendre le changement sûr, non rare. Les outils partagés créent un destin partagé ; le blâme apprend aux ingénieurs à cacher le risque ; les opérations permettent l'activité, elles ne protègent pas la disponibilité contre l'activité.

L'enregistrement de la session est toujours en ligne et toujours présenté comme un artefact fondateur du DevOps. Ce mois d'octobre-là, le premier devopsdays de Debois à Gand a donné son nom au mouvement, et « combien de déploiements par jour ? » est devenu à la fois un repère et un défi. Allspaw a porté l'approche chez Etsy, où ses cousines — les post-mortems sans blâme et le déploiement continu — sont devenues célèbres à leur tour. Une décennie et demie plus tard, la fréquence de déploiement est une métrique d'ingénierie standard, et « dev contre ops » ne survit guère que comme l'homme de paille que cette conférence a démoli.