Boucles de feedback : déploiement sûr, hypothèses et revues

Automatiser le déploiement ne suffit pas. Pour qu'un changement soit réellement « terminé », il doit fonctionner comme prévu en production, sous trafic réel, sans imposer de travail non planifié à ceux qui en assurent l'exploitation. Ce chapitre rassemble les mécanismes de feedback qui rendent les déploiements plus sûrs (télémétrie, astreinte partagée, observation des utilisateurs), qui valident que les fonctionnalités servent vraiment à quelque chose (développement piloté par les hypothèses, A/B testing), et qui élèvent la qualité des changements avant qu'ils n'atteignent la production grâce à la revue par les pairs plutôt qu'à des comités d'approbation lointains.

Utiliser la télémétrie pour des déploiements plus sûrs

En 2006, Nick Galbreath dirige l'ingénierie chez Right Media, une plateforme publicitaire en ligne qui sert plus de dix milliards d'impressions par jour. Les niveaux d'inventaire varient en permanence ; il faut réagir au marché en quelques minutes. Disposer d'un groupe séparé pour les tests et le déploiement était tout simplement trop lent : toutes ces fonctions ont été fusionnées en une seule équipe, aux responsabilités et aux objectifs partagés. Et le plus grand défi, raconte Galbreath, fut « d'amener les développeurs à surmonter leur peur de déployer leur propre code ».

L'ironie est savoureuse : les développeurs reprochent souvent aux opérations (Ops) leur frilosité à déployer ; mais une fois qu'on leur donne le pouvoir de déployer eux-mêmes, ils deviennent tout aussi craintifs. La progression observée par Galbreath est éclairante : au départ, personne n'ose appuyer sur le bouton « déployer », paralysé à l'idée de faire tomber toute la production. Puis quelqu'un se lance ; faute de télémétrie (telemetry) suffisante, le déploiement se passe mal et l'on n'apprend les problèmes que lorsque les clients les signalent. L'équipe corrige en urgence, mais cette fois en ajoutant de la télémétrie pour confirmer le rétablissement et détecter ce type de panne avant le client. De plus en plus de développeurs déploient ; on casse encore des choses, mais on voit immédiatement ce qui est cassé et l'on décide vite de revenir en arrière (rollback) ou de corriger en avançant (fix forward). Les développeurs réclament alors davantage de revues, s'aident à écrire de meilleurs tests et — ayant compris que de petits changements provoquent moins de problèmes — intègrent des incréments toujours plus fins, toujours plus souvent.

Concrètement, dès qu'un déploiement a lieu — peu importe que ce soit Dev ou Ops qui l'effectue — nous surveillons activement les métriques associées à la fonctionnalité pour confirmer qu'elle se comporte comme prévu, et que nous n'avons pas dégradé un autre service. Comme le rappelle Part III, l'objectif est de capturer les erreurs dans le pipeline de déploiement avant la production ; mais certaines passeront entre les mailles, et c'est la télémétrie de production qui permet de rétablir le service vite. Trois leviers sont disponibles :

Réaction à un déploiement défaillant	En quoi cela consiste	Quand le privilégier
Bascule de fonctionnalité (feature toggle)	Désactiver la fonctionnalité fautive sans redéployer	Souvent l'option la plus simple et la moins risquée (aucun déploiement)
Correction en avançant (fix forward)	Pousser un correctif via le pipeline de déploiement	Sûr si les tests sont automatisés, le déploiement rapide et la télémétrie abondante
Retour en arrière (rollback)	Revenir à la version précédente (toggle, sortie de rotation, blue-green, canary)	Restaurer immédiatement un état connu et stable

Chaque événement de déploiement est en outre superposé aux graphes de métriques — comme cet incident chez Etsy où un changement de code PHP provoqua un pic d'avertissements à l'exécution, repéré en quelques minutes et corrigé en moins de dix minutes. Les déploiements étant l'une des premières causes d'incidents, annoter les graphes garantit que toute la chaîne de valeur voit l'activité pertinente, ce qui accélère détection et rétablissement.

  Déploiement  ──►  PRODUCTION
       │
       └── événement annoté sur les graphes de métriques
                 │
                 ▼
        Télémétrie active (taux d'erreur, latence, métrique métier…)
                 │
        ┌────────┴─────────┐
   tout va bien        anomalie détectée
        │                  │
   « terminé »      ┌──────┼─────────┐
                 toggle  fix forward  rollback
                    │       │           │
                    └───────┴───────────┘
                            ▼
                  Service rétabli (objectif : minutes)

Partager la responsabilité en aval

Même un déploiement impeccable laisse subsister, dans tout système complexe, des incidents inopportuns — ceux qui surviennent à 2 h du matin. Laissés sans correction, ils se répètent et font souffrir les ingénieurs d'exploitation, surtout quand ils restent invisibles pour les ingénieurs en amont qui les ont causés. Le défaut, assigné à l'équipe de la fonctionnalité, est souvent priorisé sous les nouvelles fonctionnalités ; le problème peut alors revenir des semaines, des mois, des années. C'est un cas typique d'optimisation locale d'un centre de travail amont qui dégrade la performance globale de toute la chaîne de valeur.

La contre-mesure : faire partager à tous les responsabilités d'exploitation en aval. On met les développeurs, les chefs de projet et les architectes dans la rotation d'astreinte (pager rotation), comme Pedro Canahuati, directeur de l'ingénierie de production chez Facebook, l'a fait en 2009. Chacun reçoit ainsi un retour viscéral sur ses propres décisions d'architecture et de code. Patrick Lightbody, de New Relic, le constatait dès 2011 : « quand on réveillait les développeurs à 2 h du matin, les défauts étaient corrigés plus vite que jamais ». Effet de bord notable : le management du développement comprend qu'un objectif métier n'est pas atteint sous prétexte qu'une fonctionnalité est marquée « faite » — elle ne l'est que lorsqu'elle se comporte comme prévu en production, sans escalades excessives. Comme l'observait Arup Chakrabarti (PagerDuty) en 2014, « il devient de moins en moins courant d'avoir des équipes d'astreinte dédiées ; désormais, quiconque touche au code et aux environnements de production est censé être joignable en cas de panne ».

Suivre son travail en aval

Une des techniques les plus puissantes de la conception d'expérience utilisateur (UX) est l'enquête contextuelle (contextual inquiry) : l'équipe produit observe un client utiliser l'application dans son environnement naturel. On découvre alors des façons stupéfiantes dont les clients luttent contre le logiciel — des dizaines de clics pour une tâche simple, des copier-coller entre écrans, des notes griffonnées sur papier, autant de comportements de contournement face à des problèmes d'ergonomie. La réaction la plus fréquente des développeurs est la consternation : « c'était affreux de voir toutes les façons dont nous infligeons de la douleur à nos clients ».

Le même principe vaut pour les clients internes : les développeurs devraient suivre leur travail en aval pour voir comment les centres de travail aval doivent interagir avec leur produit pour le mettre en production. On crée ainsi du feedback sur les aspects non fonctionnels du code — déployabilité, gérabilité, opérabilité — et l'on codifie des exigences non fonctionnelles à intégrer au backlog partagé, partie essentielle d'une culture DevOps.

Auto-gérer son service avant la transition vers Ops

Même lorsque les développeurs travaillent dans des environnements proches de la production, les Ops subissent parfois des mises en production désastreuses, parce que les apprentissages opérationnels arrivent trop tard dans le cycle de vie. Un ingénieur système anonyme témoigne : « dans notre équipe, la plupart des administrateurs ne tenaient que six mois. Tout cassait en production… le pire était d'apparier les grappes de serveurs applicatifs, ce qui prenait six heures. On avait le sentiment que les développeurs nous détestaient personnellement ».

La contre-mesure adoptée par Google : faire auto-gérer leurs services en production par les équipes de développement avant qu'un groupe Ops centralisé ne devienne éligible pour les reprendre. En rendant les développeurs responsables du déploiement et du support, la transition vers les opérations devient bien plus fluide. Pour éviter qu'un service auto-géré problématique ne crée un risque organisationnel, on définit des exigences de lancement (launch guidance) qui capitalisent l'expérience collective de toute l'organisation :

Critère de lancement	Question posée
Nombre et gravité des défauts	L'application se comporte-t-elle réellement comme prévu ?
Type et fréquence des alertes	Génère-t-elle un volume d'alertes ingérable en production ?
Couverture du monitoring	Suffit-elle à rétablir le service quand tout va mal ?
Architecture	Le service est-il assez faiblement couplé pour supporter des déploiements fréquents ?
Processus de déploiement	Est-il prévisible, déterministe et suffisamment automatisé ?
Hygiène de production	Les bonnes habitudes permettent-elles à un tiers de reprendre le support ?

À cette occasion, on évalue aussi les obligations réglementaires : le service génère-t-il une part significative du chiffre d'affaires (au-delà de 5 % du revenu d'une société américaine cotée, il devient un « compte significatif » dans le périmètre de la section 404 de Sarbanes-Oxley) ? Présente-t-il un fort trafic ou des coûts d'indisponibilité élevés ? Stocke-t-il des données de carte de paiement ou des données personnelles, exposant à des risques PCI-DSS, HIPAA, etc. ? Cette information nourrit la conception de l'environnement de contrôle.

Pour les services déjà en production, il faut un autre mécanisme : la rétrocession de service (service handback). Lorsqu'un service devient trop fragile, les opérations peuvent rendre la responsabilité du support au développement ; le rôle d'Ops bascule alors du support vers le conseil, pour aider l'équipe à rendre le service prêt pour la production. Cette soupape de sécurité garantit qu'on ne piège jamais les opérations dans la gestion d'un service fragile pendant que la dette technique les enterre. Pratique de longue date chez Google, elle illustre le respect mutuel entre Dev et Ops.

Étude de cas : LRR et HRR chez Google (2010)

Les SRE étant rares, ils ne sont affectés qu'aux produits les plus stratégiques ou soumis à la réglementation — et seulement si leur charge opérationnelle est faible. Mieux : même devenu important, un produit doit avoir été auto-géré en production pendant au moins six mois avant qu'un SRE ne lui soit assigné. Pour que ces équipes bénéficient quand même de l'expérience collective, Google a créé deux contrôles de sécurité :

• la revue d'aptitude au lancement (Launch Readiness Review, LRR), réalisée et signée avant qu'un service ne soit exposé au trafic public réel ; elle est auto-déclarée par l'équipe produit ;
• la revue d'aptitude à la cession (Hand-Off Readiness Review, HRR), réalisée lors du passage à un état géré par Ops, des mois plus tard ; ses critères sont bien plus stricts.

Un SRE accompagne chaque équipe à travers la LRR ou la HRR. Les check-lists évoluent à chaque lancement : « à chaque lancement, on apprend quelque chose », notait Tom Limoncelli en 2012 ; « les check-lists LRR et HRR sont une façon de créer cette mémoire organisationnelle ». Et les équipes qui obtiennent l'approbation HRR la plus rapide sont celles qui ont sollicité les SRE le plus tôt, dès la conception. Aider les équipes produit en amont est d'ailleurs un « investissement de long terme » et une forme de « service à la communauté » valorisée lors des promotions de SRE.

Développement piloté par les hypothèses et A/B testing

Trop souvent, les développeurs travaillent des mois sur une fonctionnalité sans jamais vérifier qu'elle atteint le résultat métier visé — voire qu'elle est utilisée. Et si l'on découvre qu'elle sous-performe, sa correction est priorisée sous d'autres nouveautés, condamnant la fonctionnalité à ne jamais atteindre son but. Comme l'observe Jez Humble, « la façon la plus inefficace de tester un modèle économique ou une idée de produit, c'est de construire le produit complet pour voir si la demande prédite existe vraiment ». Avant de construire, demandons-nous rigoureusement : « devons-nous le construire, et pourquoi ? », puis menons les expériences les moins chères et les plus rapides possibles pour le valider.

Intuit en offre l'exemple le plus frappant. Son fondateur Scott Cook prône depuis longtemps une culture de l'expérimentation : « au lieu de se concentrer sur le vote du chef… l'accent est mis sur le fait d'obtenir que de vraies personnes se comportent vraiment dans de vraies expériences, et de fonder ses décisions là-dessus » — l'épitomé d'une approche scientifique du produit. Concrètement, la division grand public qui exploite le site TurboTax menait environ sept expériences par an à l'arrivée de Dan Maurer. Après l'installation d'une « culture d'innovation effrénée » en 2010, l'équipe en réalisait 165 sur les trois mois de la saison fiscale américaine — et le taux de conversion du site grimpa de 50 %. Plus surprenant : ces expériences avaient lieu pendant le pic de trafic, là où l'on imposait jadis des gels de changement (change freeze) d'octobre à janvier. En rendant déploiements et mises en production rapides et sûrs, l'équipe a fait de l'expérimentation une activité à faible risque, exécutable durant la période la plus génératrice de revenus — précisément quand l'expérimentation a le plus de valeur.

Intégrer l'A/B testing dans les fonctionnalités, les releases et la planification

L'A/B testing consiste à montrer aléatoirement à chaque visiteur l'une de deux versions d'une page — un témoin (le « A ») ou un traitement (le « B ») — puis à établir, par analyse statistique du comportement des deux cohortes, un lien causal entre le traitement (texte ou couleur d'un bouton, délai de réponse artificiel…) et le résultat (taux de conversion, panier moyen). On peut ainsi attribuer une valeur en euros à une amélioration de performance. Pionnière du marketing en réponse directe — où chaque test coûtait des dizaines de milliers de dollars et des semaines d'attente —, la technique est devenue triviale en ligne.

L'A/B testing rapide repose sur des déploiements à la demande, des bascules de fonctionnalité pour contrôler la proportion d'utilisateurs voyant le traitement, et une télémétrie riche à tous les étages. Etsy a ouvert son framework d'expérimentation Feature API (anciennement Etsy A/B API), qui gère aussi la montée en charge progressive. Lacy Rhoades, d'Etsy, décrit le parcours : « trop souvent, nous avions des fonctionnalités qui prenaient beaucoup de temps et qu'il fallait maintenir sans aucune preuve de leur succès ni de leur popularité. L'A/B testing nous permet de dire qu'une fonctionnalité vaut la peine d'être développée dès qu'elle est en cours ». Pour intégrer cela à la planification, les responsables produit doivent penser chaque fonctionnalité comme une hypothèse. Barry O'Reilly propose ce gabarit :

NOUS CROYONS QUE         agrandir les images d'hôtels sur la page de réservation
ENTRAÎNERA               un meilleur engagement et une meilleure conversion
NOUS AURONS CONFIANCE     quand nous verrons +5 % de clients qui consultent
QUAND                     les images puis réservent dans les 48 heures

L'étude de cas de Yahoo! Answers illustre l'effet du tempo. En 2009, Jim Stoneham dirige une communauté de 140 millions de visiteurs mensuels, mais l'engagement décline. Le problème : « les autres acteurs du marché avaient une boucle de feedback dix fois plus rapide que nous » — Twitter, Facebook et Zynga expérimentaient au moins deux fois par semaine, tandis qu'Answers ne pouvait sortir qu'une version toutes les quatre à six semaines. En passant à des déploiements hebdomadaires puis pluri-hebdomadaires, l'équipe obtint en douze mois +72 % de visites mensuelles, un engagement triplé et un revenu doublé. Stoneham conclut : « nous sommes passés d'une équipe d'employés à une équipe de propriétaires. Quand vous avancez à cette vitesse et que vous regardez les chiffres chaque jour, votre niveau d'investissement change radicalement ».

Revue et coordination pour accroître la qualité

Traditionnellement, on réduit le risque d'un changement par des inspections et des approbations juste avant le déploiement — souvent données par des équipes externes trop éloignées du travail pour juger du risque, ce qui allonge les délais. L'échec de Knight Capital en est l'illustration tragique : une erreur de déploiement de quinze minutes a généré 440 millions de dollars de perte, forçant la vente de l'entreprise. John Allspaw observe que deux récits contrefactuels émergent toujours après de tels incidents — « échec du contrôle des changements » ou « échec des tests » — et que, dans des cultures de faible confiance et de commandement-contrôle, les contre-mesures associées augmentent en réalité la probabilité que le problème se reproduise, en pire.

Le danger des approbations lourdes

Quand un contrôle de changement échoue, le réflexe est d'ajouter des questions au formulaire, des niveaux d'autorisation (le DSI en plus du VP), des parties prenantes (comités d'architecture), du délai d'évaluation. Ces contrôles multiplient les étapes, gonflent la taille des lots et les délais — ce qui réduit la probabilité de succès et affaiblit le feedback. Or un principe central du système de production Toyota veut que « les personnes les plus proches d'un problème en savent le plus à son sujet ». Comme le confirme le State of DevOps Report 2014 de Puppet Labs, plus une organisation s'appuie sur des approbations externes, pire est sa performance — à la fois en stabilité (MTTR, taux d'échec) et en débit (délai et fréquence de déploiement). Mettez-vous à la place d'un comité consultatif des changements (change advisory board, CAB) face à des centaines de milliers de lignes modifiées par des centaines d'ingénieurs : ni une description de cent mots ni l'épluchage des lignes ne révéleront le risque réel. La meilleure pratique est donc de remplacer ces organes externes par la revue par les pairs.

Aspect	Approbation lourde (CAB externe)	Revue par les pairs
Qui décide	Comité éloigné du travail	Ingénieurs proches du code
Moment	Inspection périodique, juste avant le déploiement	En continu, intégrée au travail quotidien
Effet sur le délai	Allonge les délais d'attente	Réduit fortement les délais
Taille des lots	Encourage de gros lots groupés	Encourage de petits changements
Performance constatée	Stabilité ET débit dégradés	High performers : meilleurs sur les deux
Effet culturel	Faible confiance, contrôle	Apprentissage croisé, montée en compétence

La revue par les pairs : petite, continue, contextualisée

Plutôt qu'une approbation externe, exigeons une revue par les pairs (peer review) — appelée revue de code (code review) en développement, mais applicable à tout changement de serveur, réseau ou base de données. Le lieu logique est juste avant le commit dans le tronc commun. Le principe des petits lots s'y applique pleinement. Randy Shoup le formule ainsi : « la relation entre la taille d'un changement et son risque n'est pas linéaire — passer de dix à cent lignes multiplie le risque par bien plus que dix ». Et Giray Özil résume, sarcastique : « demandez à un programmeur de revoir dix lignes, il trouvera dix problèmes ; demandez-lui cinq cents lignes, il dira que ça a l'air bon ». Quelques règles : chacun doit faire revoir ses changements avant commit ; chacun surveille le flux de commits de ses collègues ; les zones à haut risque (changements de base de données, authentification) exigent un expert ou une double revue (« +2 » plutôt que « +1 ») ; tout changement trop gros pour être compris d'un coup d'œil doit être découpé.

La revue prend plusieurs formes : programmation en binôme (pair programming), revue « par-dessus l'épaule », passe par e-mail, ou outils dédiés (Gerrit, pull requests GitHub). L'exemple le plus marquant reste GitHub, qui a inventé la demande de fusion (pull request) : un ingénieur signale ses changements, les parties intéressées discutent, et la fusion sert aussi de mécanisme de déploiement via le GitHub Flow :

1. Créer une branche au nom descriptif depuis master (« new-oauth2-scopes »)
2. Commiter localement, pousser régulièrement sur la branche distante
3. Ouvrir une pull request (pour du feedback, de l'aide, ou prête à fusionner)
4. Obtenir les revues et approbations nécessaires (@mention, « +1/+2 »)
5. Fusionner dans master, puis déployer en production

Ces pratiques ont permis à GitHub 12 602 déploiements en 2012 — dont, un 23 août, 563 builds et 175 déploiements en une seule journée. Chez Google, le développement en tronc commun à grande échelle reposait en 2013 sur plus de 5 500 commits par semaine par treize mille développeurs, avec revue de code obligatoire couvrant la lisibilité, la propriété des sous-arbres et la transparence inter-équipes. Randy Shoup y apprit à ses dépens à garder ses changements petits : ayant soumis près de trois mille lignes, il s'entendit dire par le relecteur, après des jours de travail : « ne me refaites jamais ça ».

Programmation en binôme et coupe de la bureaucratie

La programmation en binôme fait travailler deux ingénieurs au même poste : l'un conduit (driver) et écrit le code, l'autre navigue (navigator) et le revoit en temps réel, anticipant la direction stratégique et les problèmes futurs. Jeff Atwood y voit « de la revue de code sous stéroïdes » : impossible d'ignorer un relecteur assis à côté de soi. L'étude de Laurie Williams (2001) montre que les binômes sont 15 % plus lents que deux individus séparés, mais que le code sans erreur passe de 70 % à 85 % — un gain considérable puisque tests et débogage coûtent bien plus cher que l'écriture initiale ; 96 % des sondés prenaient en outre davantage de plaisir. Chez Pivotal Labs en 2011, Elisabeth Hendrickson a remplacé un processus de revue Gerrit devenu un goulot d'étranglement « frustrant et démoralisant » — où une revue prenait une semaine entière — par la programmation en binôme, ramenant le délai « de semaines à heures ». Elle précise que la revue de code fonctionne très bien là où la culture valorise autant relire qu'écrire ; à défaut, le binôme est un excellent palier intermédiaire.

Enfin, il faut couper sans crainte les processus bureaucratiques. Adrian Cockcroft suggère de publier largement « le nombre de réunions et de tickets obligatoires pour faire une mise en production — l'objectif étant de réduire sans relâche l'effort exigé ». Capital One a son équipe Got Goo? dédiée à retirer les obstacles ; Disney son programme Join The Rebellion. Chez Target en 2012, le processus TEAP-LARB imposait des délais d'approbation interminables pour toute nouvelle technologie. Heather Mickman, voulant introduire Tomcat et Cassandra, appliqua la technique des « cinq pourquoi » et découvrit que personne ne savait pourquoi le processus existait — « tout le monde se souvenait vaguement d'un désastre passé que plus personne ne savait nommer ». En assumant elle-même le support opérationnel, elle contourna le processus, fit adopter Cassandra largement, et le TEAP-LARB fut finalement démantelé.

À retenir

• Automatiser le déploiement ne suffit pas : il faut surveiller la télémétrie en production à chaque déploiement et annoter les graphes des événements, pour détecter vite et rétablir vite — toggle, fix forward ou rollback. On optimise le MTTR, pas le MTBF.
• La responsabilité de la production se partage : développeurs et architectes en astreinte, suivi du travail en aval et observation UX rapprochent la chaîne de valeur du client et créent un feedback viscéral sur les décisions amont.
• Faire auto-gérer leurs services aux développeurs avant la transition vers Ops, encadré par des exigences de lancement (LRR/HRR chez Google), rend la cession plus prévisible ; la rétrocession de service est la soupape qui protège les opérations d'un service trop fragile.
• Traiter chaque fonctionnalité comme une hypothèse et la valider par A/B testing évite de construire ce que personne n'utilise : selon Kohavi, deux fonctionnalités sur trois n'apportent aucune valeur, voire en détruisent.
• Plus une organisation multiplie les approbations externes, pire est sa performance, en stabilité comme en débit : les comités éloignés du travail ne peuvent juger du risque réel et allongent les délais.
• La revue par les pairs (pull requests, GitHub Flow, programmation en binôme), continue et portant sur de petits changements, élève la qualité sans bureaucratie — Google et GitHub le prouvent à grande échelle.
• Tout cela exige une culture de haute confiance : l'implémentateur est propriétaire de la qualité de son changement, et l'on coupe sans crainte les processus dont plus personne ne connaît la raison d'être.