Formation DevOps écrite
Comment favoriser l’apprentissage continu en DevOps ?
Vos projets logiciels vous ont déjà montré que, malgré les listes de contrôle, les revues par les pairs et les mécanismes de contrôle, d’audit et de conformité, des problèmes restent inévitables. Il est temps d’instaurer une culture dans laquelle votre équipe et votre organisation DevOps savent diagnostiquer leurs propres problèmes, en tirer des enseignements et s’améliorer. Cette culture accepte que des problèmes surviennent et vos équipes y sont préparées. La résolution des problèmes fait partie du travail quotidien et contribue à l’apprentissage et à l’amélioration continue. Vous multipliez les effets de vos solutions en les rendant transparentes, disponibles et faciles à consulter dans toute l’organisation.
Netflix, une organisation DevOps de premier plan, a développé en interne Chaos Monkey, un logiciel qui simule des événements catastrophiques dans ses centres de données cloud. Chaos Monkey arrête aléatoirement des serveurs en production, ce qui permet à Netflix de mieux éprouver la résilience et la stabilité de ses opérations et la continuité de la qualité de service pour ses clients. L’équipe apprend de chaque panne et utilise ces enseignements pour rendre les systèmes encore plus stables et résilients.
Comprendre l’importance d’une culture d’apprentissage
Si les incidents donnent lieu à des accusations dans votre organisation, les ingénieurs travailleront dans la crainte. L’organisation devient lente, bureaucratique et minée par les jeux de pouvoir. Au lieu d’apprendre des erreurs, de rendre les systèmes plus résistants et résilients et de travailler plus attentivement pour éviter les problèmes, chacun cherche à se protéger. Le travail, les difficultés et même leurs solutions ne sont jamais entièrement transparents.
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- Ils produisent moins de travail pour commettre moins d’erreurs.
- Ils manquent de transparence sur le travail, les problèmes et les solutions.
- Rien ne les encourage à transformer les solutions en connaissances partagées dans l’organisation.
- Le même problème ou un problème très similaire se reproduira à coup sûr, car personne ne consacre de temps ni d’énergie à apprendre, à partager et à transmettre les problèmes et leurs solutions ou à les rendre visibles.
Analysez les incidents dès qu’ils surviennent, avant que le souvenir de leurs causes s’estompe
Les objectifs d’un retour d’expérience sont simples :
- Repérer ce que vous avez bien fait pour penser à le refaire dans des situations similaires.
- Relever ce qui aurait dû être fait autrement pour affiner vos méthodes à l’avenir.
- Relever ce que vous avez mal fait et proposer d’autres méthodes ou mesures de protection à appliquer la prochaine fois que vous rencontrerez un problème similaire.
- Comprendre pourquoi il était logique de prendre ou de ne pas prendre la mesure qui a conduit à l’incident.
Examiner ce que vous avez mal fait peut être effrayant et, dans certaines organisations, dangereux. Si reconnaître une erreur vous expose à des critiques ou à des sanctions, vous serez peu enclin à la reconnaître. À terme, cette stratégie se retourne contre vous, car faute de comprendre une erreur passée, vous risquez de la répéter. Les organisations qui prennent l’amélioration au sérieux le comprennent et s’efforcent de créer un processus et une culture où l’on peut examiner les erreurs en toute sécurité.
Pour entamer un retour d’expérience, vous devez accepter quelques principes :
- Tout le monde essaie de faire de son mieux, selon sa compréhension de la situation.
- Vous prenez des décisions sous pression, avec des informations imparfaites.
- On vous demande souvent d’effectuer des tâches pour lesquelles vous n’avez pas été formé, avec les outils et ressources disponibles à ce moment-là.
- Les erreurs sont inévitables dans de telles situations.
- Le but de ce processus est d’examiner les faits et d’en tirer des enseignements, sans attribuer de faute à une personne ou à ses actions.
- Ce processus évalue nos pratiques et la façon de les améliorer, sans évaluer une personne ou un groupe.
Toutes les personnes concernées doivent impérativement adhérer pleinement à ce principe :« Nous sommes ici pour apprendre, sans chercher de coupable ». De nombreuses organisations s’efforcent de créer un environnement sûr. Par exemple, la FAA dispose d’un système de signalement pour la sécurité aérienne (Aviation Safety Reporting System). Les pilotes qui commettent des « erreurs » peuvent être exemptés de sanctions réglementaires s’ils signalent ces incidents.
Les retours d’expérience doivent toujours définir des mesures concrètes pour éviter que l’incident se reproduise. Par exemple, ajoutez des indicateurs de télémétrie ou des cas de test automatisés, déterminez quels types de changements exigent des revues de code supplémentaires, refactorisez le code ou découplez les composants complexes qui causent des problèmes fréquents.
Diffusez largement les comptes rendus des analyses d’incident et les leçons apprises. Vous transformerez ainsi les enseignements d’une unité de travail de votre flux de valeur en connaissances partagées par toute l’organisation. Vous encouragerez clairement la transparence, l’ouverture et l’apprentissage dans votre organisation DevOps.
Organisez des exercices de simulation pour améliorer vos systèmes
Un exercice de simulation de crise (game day) est bien différent de ces événements d’équipe ennuyeux où les extravertis s’amusent pendant que les introvertis consultent leur téléphone pour faire passer le temps.
Lors d’un exercice de simulation, on reproduit des pannes catastrophiques dans vos systèmes de test. Les équipes DevOps travaillent à les résoudre et à en tirer des enseignements.
Par exemple, on arrête un serveur critique pour vérifier que le basculement fonctionne sans interruption de service. L’équipe DevOps vérifie ensuite si et comment le rétablissement fonctionne à partir des sauvegardes ou de l’infrastructure en tant que code (IaC). Repérer les problèmes dans ces scénarios de panne aide l’équipe à construire des systèmes résilients et tolérants aux pannes et à en tirer des enseignements.
En résolvant le problème, l’équipe DevOps tisse des liens avec les autres services, car ils répètent ensemble la réponse aux pannes sans pression. Vous testez ainsi les pratiques de communication et de résolution des problèmes dans l’ensemble de l’organisation et pouvez voir comment les améliorer.
Vous pourrez aussi observer des signaux faibles annonçant des problèmes plus importants. Des incidents de faible priorité qui se répètent pendant les simulations ou un effet secondaire mineur qui a failli mettre en panne un autre composant critique sont des signaux importants à prendre en compte et à traiter pour améliorer vos systèmes.
CONCLUSION
Encouragez la prise de risques calculés dans votre équipe DevOps. Les organisations DevOps les plus performantes comme la vôtre commettent des erreurs plus souvent. C’est acceptable et nécessaire pour que votre organisation apprenne et s’améliore.
Par rapport aux organisations classiques, les plus performantes subissent 80 % de défaillances critiques en moins dans leurs systèmes de production. Autrement dit, elles connaissent cinq fois moins d’incidents qui touchent leurs clients. C’est pourquoi les ingénieurs de votre organisation DevOps doivent se sentir libres de se tromper et d’apprendre de leurs erreurs.
