Les réunions causées par des déploiements lents (2015)
(tidyfirst.substack.com)- Dans les situations où les ingénieurs ont l’impression de « ne pas pouvoir livrer du code à cause des réunions », la véritable cause peut être la capacité de déploiement lente, qui crée de l’overhead organisationnel
- Chuck Rossi de Facebook estime que le nombre de changements qu’un seul déploiement peut absorber semble presque fixe, et que pour augmenter le volume de changements, il faut augmenter la fréquence des déploiements
- Facebook a fait passer les déploiements de code PHP d’un rythme hebdomadaire à quotidien, puis à 3 fois par jour, et a aussi réduit le cycle de publication des applications mobiles de 6 semaines à 4 puis 2 semaines, sous l’impulsion principalement de l’équipe release engineering
- Quand le volume de changements produits dépasse la limite de déploiement, le nombre de changements par déploiement n’augmente pas facilement ; l’organisation s’adapte alors en augmentant l’overhead comme les réunions, les revues et les handoffs, ce qui réduit le volume global de changements
- Pour faire passer davantage de changements, il ne suffit pas de réduire les réunions : il faut augmenter la capacité de déploiement en améliorant le cycle de déploiement, les tests, le monitoring, l’isolation et les relations sociales au sein des équipes
Les réunions peuvent être non pas la cause, mais la conséquence
- La plainte fréquente « il y a trop de réunions, donc on ne peut pas déployer de code » peut inverser le lien de causalité
- Il est relativement facile d’ajouter ou de supprimer de l’overhead organisationnel, mais beaucoup plus difficile d’augmenter la capacité d’une organisation à déployer du code
- Les réunions et les revues peuvent être le résultat d’une adaptation de l’organisation pour éviter de surcharger le système de déploiement
- Chuck Rossi a observé chez Facebook qu’il semblait y avoir une limite au nombre de changements qu’un déploiement pouvait traiter
- Si l’on veut davantage de changements, il faut davantage de déploiements
- Les déploiements de code PHP sont passés d’un rythme hebdomadaire à quotidien, puis à 3 fois par jour
- Le cycle de publication des applications mobiles est passé de 6 semaines à 4 puis 2 semaines
- Cette amélioration a été portée principalement par l’équipe de release engineering
Sans augmentation de la capacité de déploiement, l’overhead augmente
- Le « nombre de changements par déploiement » ressemble à une mesure inélastique qui ne s’améliore pas facilement et exige de gros efforts
- Si le nombre de changements produits dépasse la limite actuelle, une pression apparaît pour réduire le volume total de changements plutôt que pour augmenter le nombre de changements par déploiement
- Les réunions, les revues, les handoffs et les autres formes d’overhead augmentent
- Avec le temps, l’enthousiasme et l’esprit d’initiative peuvent aussi diminuer
- L’augmentation de l’overhead peut créer une boucle de rétroaction positive
- Moins de travail est effectivement traité
- La pression augmente
- Les erreurs se multiplient
- Le nombre de changements par déploiement diminue encore
- L’overhead augmente à nouveau
- Une tentative isolée de réduire uniquement l’overhead peut accroître la pression et finir par recréer plus d’overhead
- Pour faire passer davantage de changements, il faut élargir la capacité de déploiement, c’est-à-dire « l’extrémité éloignée du tuyau »
- Méthode difficile : réduire le cycle de déploiement et gérer le chaos qui en découle
- Méthode encore plus difficile : augmenter le nombre de changements par déploiement grâce à de meilleurs tests, un meilleur monitoring, une meilleure isolation entre les composants et de meilleures relations sociales dans l’équipe
- Essayer seulement de réduire les réunions peut mener à une « réunion pour discuter de comment réduire les réunions »
- On peut y voir un exemple de Thinkie de causalité inversée, qui consiste à envisager une idée paraissant d’abord erronée
2 commentaires
C'est une bonne opinion.
Avis sur Hacker News
C’est dommage, mais la conclusion de cet article me semble un peu à l’envers. Il est important de réduire le risque des déploiements en améliorant les tests et les caractéristiques organisationnelles, mais ce n’est pas la seule approche qui fonctionne.
L’auteur dit que le nombre de changements par déploiement est fixe et difficile à augmenter, mais le « Reversie Thinkie » dont il est question ici consiste plutôt, à mon avis, à réduire le nombre de changements par déploiement. Les réunions de déploiement existent à cause du risque, et plus un déploiement contient de changements, plus il a de chances d’introduire des bugs ou des problèmes opérationnels. Déployer souvent de petits changements permet de livrer de la valeur plus vite et de rendre les échecs plus limités.
Si l’on combine cela avec des déploiements canary et des sorties progressives, le déploiement cesse d’être une affaire d’interrupteur qui casse ou ne casse pas : on entre dans un monde où les incidents se transforment en dégradation de performance ou en impact limité. Cette approche est bien traitée dans les travaux DORA[0], Accelerate[1], The Phoenix Project[2], ainsi que dans son ancêtre spirituel, The Goal[3].
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
Le point central est le temps et les ressources que l’organisation investit dans les tests automatisés. Les réunions de release apparaissent parce qu’il n’existe pas d’infrastructure pour valider avant et après le déploiement, ni pour revenir en arrière lorsqu’un changement échoue ; on compense alors le manque de validation automatique par des contrôles manuels ponctuels. Si l’organisation QA manque de compétences techniques, elle poussera des procédures manuelles par réflexe de préservation.
Pire encore, le fait de passer par ces réunions est parfois présenté comme un signe d’excellence et de bonnes pratiques. Les personnes embauchées pour atténuer un problème n’ont pas d’incitation à l’éliminer à la racine. Quand un bug fuit en production, cela devient « un problème créé par les développeurs que la QA n’a pas attrapé pour telle ou telle raison » ; avec des tests automatisés, il serait difficile de le laisser passer dès l’étape de PR.
Les réunions n’existent pas à cause du risque, mais parce qu’il faut du risque pour justifier l’existence de certains rôles dans l’organisation, rôles qui n’ont pas la technologie nécessaire pour le réduire. Si l’on peut automatiser un minimum de vérifications après déploiement pour s’assurer que le changement s’exécute et fonctionne, et déclencher un rollback automatique en cas d’échec, les réunions deviennent inutiles.
Je considère beaucoup de ces processus comme des réponses raisonnables mais non techniques visant à rendre une mauvaise situation aussi supportable que possible en l’absence de solution de fond. Cela dit, ils ne sont pas totalement inoffensifs. Dans certaines organisations, même pour de nouveaux projets ou des projets visant à supprimer des inefficacités existantes, les décideurs continuaient à proposer des processus centrés sur les personnes comme solution.
C’est soit un manque d’imagination technique, soit le fait d’être enfermé dans le cadre du problème existant ; les personnes qui ont cette imagination doivent prendre la parole et dire que, là où c’est possible, il faut minimiser les processus humains par des changements techniques. On ne peut pas éliminer tous les processus humains par la technologie, mais je n’ai pas envie de me disperser sur des choses inutiles.
On peut supposer que modifier plus de 2 % de l’ensemble des processus sur une période donnée est « trop », et cette valeur peut être ajustée. Cela variera aussi selon les domaines : l’équipe en charge du code de paiement et celle du code RH devraient donc avoir des critères différents, et il peut être logique de faire tourner les releases ou les équipes.
Pendant cette période, telle équipe s’attaque à un sujet difficile, puis, une fois en production, elle revient à des tâches plus simples. Le même principe s’applique aux attaques de tranchées, aux avancées de bataillon et aux opérations interarmes.
Bien sûr, c’est un problème de management, mais une grande partie peut être automatisée, et des signaux comme savoir quelle équipe a récemment commité sur un module sensible peuvent être utiles. Enfin, ce point de vue rend les sprints Agile/Scrum un peu étranges. On sait qu’on ne peut pas courir tout un marathon à fond ; alors comment organiser la rotation de la préparation aux sprints ?
On peut utiliser des feature flags, mais cela crée alors un « backlog de fonctionnalités non activées ». Au final, les fonctionnalités sont le plus souvent consommées par des humains, et les humains ont besoin de formation face au changement.
Il travaillait sur les flux, traduisait les principes du Toyota Production System et appliquait la physique aux processus métier bien avant que quelqu’un n’écrive The Phoenix Project. J’aime aussi The Phoenix Project, mais comparé à The Goal, c’est presque une adaptation bon marché destinée à empêcher les gens de l’IT de lire une histoire de chaîne de production puis de s’enfuir en disant « je suis PrOgrAmmEr, donc le travail créatif ne peut pas être optimisé comme une usine ».
Par conséquent, The Phoenix Project est le successeur spirituel de The Goal, et non l’inverse.
J’essaie d’expliquer le concept de « littératie logicielle ». L’idée est que, tout comme une entreprise peut aujourd’hui fonctionner au moyen de phrases en anglais — documents de politique interne, e-mails, etc. —, une activité peut aussi fonctionner au moyen de code.
De là découlent des conclusions du genre : « si ce sont les GPU qui font le travail, alors les codeurs sont les nouveaux managers », ou encore qu’il faut un dispositif de test à l’échelle de toute l’entreprise pour que l’impact des changements soit clair. Cela me semble directement lié à cet excellent article. Si tous les décideurs ne considèrent pas le code, plutôt que Jira ou un plan projet, comme un objet de première classe du processus de changement, alors ces décideurs sont illettrés sur le plan logiciel.
La question « comment en discuter avec des dirigeants non techniques » revient souvent, mais la réponse est : on ne peut pas. Ces dirigeants doivent changer. C’est une immense barrière générationnelle que je voyais déjà comme un problème il y a 30 ans, tout en pensant naïvement qu’elle disparaîtrait quand les codeurs monteraient en puissance. Mais comme il n’est pas nécessaire de coder pour « diriger » une entreprise, il sera difficile de la franchir tant qu’il ne sera pas aussi honteux de ne pas savoir coder que, pour un rédacteur en chef, de ne pas savoir écrire.
Le point central, ce ne sont pas les SOP, les tests ou les réunions, mais la nécessité d’entreprises capables de fonctionner avec un nouvel ensemble de concepts qui se renforcent mutuellement, comme des systèmes en tant que communication.
Cela dit, je ne sais pas pourquoi appeler cela de la « littératie ». Le terme autopoiesis de Maturana & Varela me semble plus proche du cœur du sujet, et les Autopoietic Systems de Stafford Beer offriraient aussi une bonne base théorique.
Mais à un certain point, une « activité » purement logicielle ne finit-elle pas simplement par ressembler à du SaaS ?
Les organisations s’opposeront activement aux tentatives d’améliorer les déploiements. Elles diront très sérieusement des choses comme : « il ne faut pas mettre Jenkins près de l’environnement de production », « on ne peut pas mettre en ligne sans QA », « il faut ce temps-là pour garantir suffisamment la qualité logicielle ».
Pendant ce temps, il y a des centaines de bugs en production et le produit répond à peine aux besoins des utilisateurs. Au final, dans la plupart des organisations, lutter contre la bureaucratie est pratiquement impossible. Surtout si l’on ne fait pas partie des 200 couches de management qui produisent ce genre de réunions.
J’aurais envie de ne garder que deux programmeurs et designers environ, de renvoyer tout le monde, puis de les laisser se débrouiller sans coach agile, product owner, scrum master ni expert produit. Les déploiements lents sont un problème, mais ce n’est pas le problème en soi.
Si l’on se retrouve sans cesse dans des endroits qui semblent impossibles à faire évoluer, il faut poser davantage de questions à ce sujet en entretien. Dans les petites entreprises, j’en ai trouvé beaucoup qui n’avaient pas de bureaucratie délirante, selon mes préférences ; et aujourd’hui, je suis dans une grande entreprise, mais en avançant de façon cohérente et convaincante, beaucoup de choses finissent lentement par aller dans la bonne direction.
Il faut comprendre que les choses prennent du temps, comprendre pourquoi les gens ont construit le système ainsi, puis trouver des arguments convaincants pour l’améliorer. Il existe aussi des endroits vraiment mauvais, et il vaut mieux ne pas y rester, mais le désespoir n’aide pas beaucoup.
Il y aurait beaucoup de choses à démêler, mais mon biais penche en faveur de cet argument.
Jenkins, c’est le Wordpress du développement logiciel. Une énorme boucle d’état qui exécute des plugins sans séparation des privilèges. Donner à une instance Jenkins des identifiants d’administrateur de production peut revenir à donner les clés root à une personne en Roumanie qui a créé un plugin jamais audité. On comprend très bien que tout le monde n’en ait pas envie.
« On ne peut pas mettre en ligne sans QA » aussi. Si vous déployez en production quelque chose qui n’a jamais passé la QA, à quoi sert la QA ? À corriger plus tard ? Si on ne lui donne aucun pouvoir, la QA n’a ni l’occasion de bien faire son travail, ni celle d’en être fière.
Dès le premier jour de n’importe quelle initiative, Jenkins menait jusqu’à la production, souvent directement avec du développement trunk-based, et la qualité relevait de la responsabilité de chaque développeur. Au niveau des contributeurs individuels, il n’y avait pas de « lutte contre la bureaucratie », même si, lorsque des partenaires externes et des parties prenantes étaient fortement impliqués, les dirigeants ont sans doute parfois eu des discussions animées entre eux.
Ne garder que des programmeurs et des designers me conviendrait, mais cela ne passe pas à l’échelle. Il faut au moins un « owner », « expert » ou « manager » produit pour mettre en file d’attente les priorités des parties prenantes. Ce rôle peut être porté à tour de rôle comme une « casquette » par des développeurs et des designers, mais certaines personnes sont particulièrement douées pour cette compétence.
Je comprends aussi que beaucoup d’organisations ne fonctionnent pas ainsi. Pour transformer une entreprise dans cette direction, ce qui a aidé a été de créer une équipe expérimentale unique, composée de volontaires engagés dans ces pratiques, et de la protéger par une autorité venue d’en haut, sans lui dicter quoi faire. Bien sûr, ici, c’est la Californie.
Sujet un peu lié : j’ai travaillé dans un endroit où le pipeline CI prenait environ 25 minutes, dont 18 minutes pour plus de 3 000 tests unitaires et d’intégration.
Chaque fois qu’un problème survenait en production, on ajoutait davantage de tests, et évidemment, quand les choses tournaient mal, il fallait au minimum 50 minutes pour rétablir la situation. Après beaucoup de réflexion, nous avons décidé de nous concentrer sur la reprise : nous avons assoupli et simplifié certains tests pour faire passer l’ensemble sous les 5 minutes, et utilisé des déploiements canary au lieu de rolling updates.
Pour nous, c’était vraiment rafraîchissant, même si, d’une certaine manière, cela donnait aussi l’impression d’être une erreur.
Bien sûr, cette vitesse de déploiement englobe toutes sortes de facteurs, mais presque tous sont de bons facteurs.
C’est un peu à côté du sujet, mais pourquoi CloudFormation est-il aussi lent ?
J’ai eu le cas d’une Lambda dans un VPC supprimée et connectée à EFS : le déploiement lui-même a été assez rapide, mais CloudFormation a mis environ 20 minutes à nettoyer et terminer
Chaque fois qu’un changement d’état est déployé sous forme de transaction, il faut vérifier les préconditions et les postconditions à chaque étape. Pour livrer un ensemble de changements ayant ne serait-ce qu’un peu de dépendances entre eux, on n’a pas d’autre choix que de déployer chaque changement en étapes séquentielles. Chaque étape effectue plusieurs appels réseau pour appliquer le changement, authentifier et interroger l’état, chacun prenant de 50 à 200 ms environ, et ça s’accumule vite
Si l’on déploie la même application chez un autre fournisseur cloud avec Terraform ou Ansible, on obtient des résultats similaires. Déployer les mêmes changements manuellement transforme une affaire de quelques minutes en corvée d’une journée
Le plus gros problème de l’IaC est que c’est trop haut niveau et que ça fait trop de choses en interne, si bien que certaines personnes ne savent plus quels changements sont réellement appliqués ni ce qui est en train de se passer. Et elles se plaignent ensuite que c’est long
J’ai vécu quelque chose de similaire au travail. Il y avait un gros changement avant les congés de Noël, et beaucoup d’appréhension. L’organisation a répondu en ajoutant des tests, autrement dit en augmentant les tests de régression et donc la surcharge
Cela a accru le risque qu’un changement dans dev casse les changements de ma branche. Ce n’était pas un conflit de merge de code, mais un risque au sens d’un système adaptatif complexe. Pour gérer ce risque, j’ai créé une réunion et, en présentant le planning du projet, j’ai expliqué à mes collègues ce à quoi ils devaient s’attendre : les commentaires de style de code laissés sur une PR seraient repoussés à une PR ultérieure, puis finiraient par être ignorés
Ce qu’il fallait, c’étaient des tests plus granulaires, avec une meilleure isolation entre composants. Le problème est que la direction regarde les choses à un niveau trop élevé et considère les réunions non pas comme un moyen, mais comme un objectif ayant une valeur en soi. Plus de réunions signifierait plus de collaboration, donc ce serait bien. J’aimerais voir des conseils sur la manière de conduire des changements techniques avec une direction non technique
Article lié : Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - novembre 2015, 26 commentaires
Avec les microservices, on peut aussi scaler horizontalement la fréquence de déploiement
Avec une application monolithique composée de modules indépendants, on peut déployer tout autant sans microservices, tout en évitant la complexité d’infrastructure/CI·CD et le principal inconvénient consistant à transformer les appels de fonctions de l’application en problèmes de communication de système distribué peu fiable. Il faut résister à la complexité accidentelle inutile
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
Et un nouveau problème amusant apparaît : la planification des déploiements et la synchronisation de la livraison des fonctionnalités
Sinon, vous obtenez à la fois les problèmes des données distribuées et davantage de couches de complexité, c’est-à-dire encore plus de réunions qu’avec un monolithe
Dans un monolithe, il y a le risque de se retrouver dans un énorme chaos de SOLID, DRY et autres balivernes de “clean code”, où plus personne n’ose rien modifier de peur de tout casser. Cela ne veut pas dire que les principes orientés objet sont faux en apparence, mais ils sont souvent si extrêmement vagues que personne n’arrive à les appliquer correctement
Je ris toujours quand Uncle Bob balaie chaque critique en disant que “ces gens ont mal compris les principes”. Si tant de personnes se trompent, peut-être que les principes sont mauvais ? Les microservices ne protègent pas non plus d’une mauvaise gouvernance ; les problèmes se manifestent simplement sous une autre forme. Il est très facile, et à mon avis très courant, de créer plusieurs microservices sans que personne ne sache quel impact un changement aura sur les autres services
Au final, c’est un problème de gestion d’équipe et, d’expérience, c’est le domaine où notre industrie est la plus mauvaise. Les choses s’amélioreront peut-être avec l’arrivée d’une nouvelle génération d’idées comme “Team Topologies”, mais même si cela finit vraiment par se régler, cela prendra des décennies. Si l’organisation voit l’“IT” uniquement comme un centre de coûts et n’exprime pas ses besoins d’une manière intégrable à des processus de bonnes pratiques d’ingénierie logicielle, cela échappe souvent aussi aux départements de digitalisation
L’une des raisons pour lesquelles j’aime Go comme langage généraliste est qu’il est simple par conception, ce qui mène souvent à des bases de code faciles à modifier. J’ai vu plusieurs banques en ligne et plateformes de gestion locative/d’actifs passer à Go et croître parce qu’elles pouvaient réellement livrer ce dont le métier avait besoin. Pendant ce temps, leurs concurrents restaient coincés dans des bases de code Java ou C# ingérables et, avec un peu de chance, sortaient une fonctionnalité pleine de bugs tous les six mois
Ce n’est pas un problème propre à Go, Java ou C#, mais au fait que l’architecture et la conception orientées objet à l’ancienne sont trop faciles à ruiner. Dans un ancien poste, il y avait plus d’un millier d’interfaces C#, et aucune n’était consommée par plus d’une classe. Des dizaines de milliers d’interfaces étaient toutes dans le même dossier et le même namespace, et il fallait compter sur la chance pour trouver ce dont on avait besoin. On peut faire ça en Go ou dans n’importe quel langage, mais c’est moins probable si l’on ne baigne pas dans la vieille culture des langages orientés objet et du clean code. En C# en particulier, l’abstraction par défaut est tellement ancrée dans la culture qu’il est plus difficile de ne pas le faire
Personnellement, j’ai une affection secrète pour les organisations Python. Elles livrent toujours vite, et le code est horrible. C’est adorable
C’est globalement juste, mais aussi largement hors sujet.
En résumé, seules comptent les performances du logiciel, et donc les performances humaines. La gestion et l’acceptation du risque peuvent se mesurer en chiffres. Dans le logiciel, c’est bien plus simple que dans d’autres métiers, car un ingénieur logiciel ne peut accepter un risque que dans les limites opérationnelles connues ; tout le reste est reporté.
Si l’on veut aller plus vite, il faut avant tout maximiser la fréquence d’itération humaine. Si l’on ne peut pas itérer parce qu’on attend une autorisation, on est bloqué ; si l’on attend un build ou un rafraîchissement d’écran, on est ralenti. Cela aussi se mesure en chiffres.
Si A peut itérer 100 fois plus vite que B, l’exactitude devient secondaire. B étant lent, il doit maximiser l’exactitude. A dispose d’une flexibilité extrême pour apprendre, échouer et s’améliorer afin de devenir à la fois plus rapide et plus exact.
L’automatisation rapide des tests fait partie des moyens de réduire le risque tout en itérant plus vite. Si A peut exécuter plus de 90 % de couverture de tests en l’espace de 4 itérations humaines, cette automatisation des tests reste 25 fois plus rapide qu’une seule itération de B, tout en réduisant le risque de régression de plus de 90 %.
Les déploiements rapides créent des war rooms de gestion d’incident
Ce qui comptait encore bien plus que cette baisse, c’était la vitesse à laquelle on trouvait la cause quand un problème survenait. Les changements à rollbacker étaient très peu nombreux, donc revenir en arrière était aussi beaucoup plus sûr et plus simple. Personne n’a envie d’annuler 3 semaines de travail. C’est le chaos.