Téléchargé parChristophe Rochefolle
#DevOps - Et si on déployait le vendredi
Le texte plaide en faveur des déploiements de logiciels le vendredi, en soulignant que cela réduit le stress et les incidents en évitant les retards de fin de semaine. Il insiste sur la culture de la confiance et la responsabilisation des équipes pour mieux gérer les risques et encourager l'observabilité. En promouvant des méthodes telles que le chaos engineering, l'objectif est de renforcer la résilience des systèmes tout en conservant une réactivité face aux demandes des utilisateurs.
#DevOps - Et si on déployait le vendredi
- 1. ET SI ONDÉPLOYAIT AUSSI LE VENDREDI ? Christophe Rochefolle, CTO SNCF Connect 17 Novembre 2022 1 @crochefolle @crochefolle@fosstodon.org
- 2.
- 3.
- 4.
- 5.
- 6. 6 RAISON #1 :La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin.
- 7. 7 RAISON #1 :La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin. Principes DevOps : une MEP doit être un non événement technique par la mise en place : • d’une pipeline industrialisée, • des tests automatisés qui génèrent un niveau de confiance élevée pour envoyer en prod, • de l’observabilité qui permet de détecter les incidents, • voire aussi du "blue green" qui permet de revenir en arrière instantanément, • Etc.
- 8. 8 RAISON #1 :La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin. Principes DevOps : il faut déployer le plus fréquemment possible pour réduire la taille de l’incrément. Moins on déploie souvent, plus le contenu à déployer est important donc plus le risque est élevé. QUALITÉ
- 9. 9 RAISON #1 :La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin. Principes DevOps : You Build it, You Run it Les équipes – personnes – qui conçoivent les applications ou services sont ceux qui les opèrent. Cela implique notamment que les membres de l’équipe qui font un changement soient d’astreintes, gèrent et assument le problème qu’elles pourraient éventuellement générer. Ainsi elles mettront tout en œuvre, notamment les pratiques de sûreté de fonctionnement pour éviter de perdre ses nuits et week-ends.
- 10. 10 RAISON #2 :Les incidents se produisent souvent quelques temps après la MEP et que les équipes soient parties.
- 11. 11 RAISON #2 :Les incidents se produisent souvent quelques temps après la MEP et que les équipes soient parties. Pratique DevOps : Observabilité Les incidents ne se produisent pas quelques temps après (sauf cas vraiment particuliers), c’est surtout qu’avec le temps ils prennent une ampleur qui les rend visibles. L’instrumentation de la plateforme pour la rendre observable favorise la sûreté de fonctionnement des services.
- 12. 12 RAISON #2 :Les incidents se produisent souvent quelques temps après la MEP et que les équipes soient parties. Principes DevOps : You Build it, You Run it Cela implique notamment que l’équipe ne déploie pas le vendredi à 17h et parte en week- end ou prendre un verre à peine après avoir appuyé sur le bouton. Responsabiliser une équipe, lui faire confiance, c’est lui définir un cadre où elle peut prendre les décisions de déployer quand elle veut plutôt que quand elle peut.
- 13. 13 RAISON #3 :il y a toujours un risque inconnu dans un changement. Charity Majors : Chaos Engineering et Observabilité
- 14. 14 RAISON #3 :il y a toujours un risque inconnu dans un changement. Pratiques DevOps : Chaos Engineering Par définition, on ne peut prévoir l’inconnu, par contre on peut entraîner notre système sociotechnique à réagir efficacement face à l’inconnu, notamment par des pratiques de Chaos Engineering.
- 15. 15 RAISON #1 :La MEP qui se passe mal et qui vous fait rester tard le vendredi soir, voire le samedi matin. Interdire le vendredi, c’est mettre l’emphase sur la peur du déploiement, augmenter le risque en augmentant le contenu de ce que l’on déploie et déresponsabiliser les équipes. C’est un antipattern de déploiement d’une démarche DevOps. RAISON #2 : Les incidents se produisent souvent quelques temps après la MEP et que les équipes soient parties. RAISON #3 : il y a toujours un risque inconnu dans un changement.
- 16. 16 PASSER DE LACULTURE DE LA PEUR À CELLE DE LA CONFIANCE
- 17. EN RÉSUMÉ 17 Nous sommesau service d’une société durable et solidaire, et favorisons des comportements, des mobilités et des usages responsables. CITOYENNETÉ Oser déployer même le vendredi… nous sommes persuadés que c’est en se basant sur la responsabilisation de nos équipes que nous pouvons garder un temps d’avance. AUDACE Pourvoir déployer quand on veut plutôt que quand on peut nous permet d’être plus réactif et de répondre aux attentes de nos utilisateurs finaux plus rapidement. PERFORMANCE Nos yeux sont grands ouverts sur notre production à l’aide d’une démarche d’observabilité qui s’améliore à chaque évènement, tout en nous ouvrant sur de nouvelles pratiques comme les Chaos Engineering pour mieux nous préparer. OUVERTURE Nous croyons en une culture de la confiance comme un incontournable de la réussite d’une démarche DevOps. CONFIANCE https://jobs.connect-tech.sncf/ REJOIGNEZ-NOUS Une démarche qui s’incarne dans nos valeurs
Notes de l'éditeur
- #3 Introduction du sujet à l’aide de CommitStrip qui fait reference en manière de comics dans la Tech et qui illustre parfaitement le sujet #merciFrançois
- #4 Illustration sur les réseaux sociaux que c’est une phénomène et une pratique mondiale
- #5 On reste sur les reseaux sociaux en donnant l’origine de mon article et de ce talk lors d’un échange avec Charity Majors, CTO HoneyComb, rencontrée lors de la Chaos Conf en 2018 à San Francisco https://twitter.com/mipsytipsy/status/1180327118720233472?s=20&t=cFVBETOPvLuA1LMzLjQb8A
- #6 Pourquoi se priver de 20% de temps où l’on peut apporter cette valeur à nos utilisateurs ? Souvent on s’interdit également le jeudi après-midi, les veilles de jours fériés, on dépasse ainsi les 30% / an La licorne qui se pose des questions sera réutilisée tout au long de la présentation pour reprendre les tweets majeurs de la discussion avec Charity
- #7 On se concentre sur les arguments principaux à l’origine de cette “rêgle” pour mieux la déconstruire
- #11 2nde raison à déconstruire
- #13 Plutôt qu’une règle “immuable” pas de déploiement le vendredi, on définit un cadre de pratiques et de responsabilité, comme suivre activement minimum 1h ce qui se passe en production après une MEP.
- #14 3eme raison à déconstruire
- #15 2nde raison à déconstruire
- #16 Après avoir déconstruit les raisons pour lesquelles on ne déploie pas le vendredi, on démontre à quel point c’est antynomique à un déploiement d’une démarche DevOps réussie.
- #17 En résumé, on revient à l’essentiel : les valeurs nécessaires à une démarche DevOps (et on fait le lien avec les valeurs de SNCF Connect page suivante)
- #18 On garde Citoyenneté pour la fin car pas évident à lier au sujet du jour, ET permet de revenir sur SNCF Connect en invitant à nous rejoindre.