Ingénierie du Chaos — Comment Commencer? — Partie 3 : Expliquer et faire partager la démarche
La communication est un élément clé dans la mise en place d’une démarche de Chaos Engineering. Il est impératif que tous les intervenants concernés sachent précisément de quoi il en retourne :
- Exploitants, car il devront potentiellement gérer les effets de bord et les incidents.
- Développeurs, car ce sont eux qui décideront de mettre à l’épreuve leurs applications.
- Managers et métier, car ils assumeront la responsabilité d’un éventuel impact sur le volume d’affaire.
- CODIR, car ils ont le pouvoir de nourrir ou enrayer une démarche.
Savoir présenter
Préparer un argumentaire bien ficelé est impératif avant de se lancer dans la course aux présentations. Une fois lancé, si vous avez pris le mauvais angle, il sera très difficile de corriger le tir.
On ne peut pas faire deux fois une bonne première impression.
Nous sortons un peu du sujet du Chaos Engineering mais il est primordial de réussir sa communication.
Death by powerpoint est un slideshare amusant qui dresse un tableau assez peu flatteur des présentations en entreprise. Inspirez-vous en pour ne pas faire de fail sur votre approche.
Vous pouvez avoir l’impression de perdre du temps à préparer une présentation digne de ce nom. Sachez qu’une présentation efficace vous ouvrira des portes inattendues sans compter que vous pourrez être amenés à la faire plusieurs fois. Vous pourriez même être surpris de voir qu’on vous demandera régulièrement de la refaire… :)
L’argumentaire
Pourquoi fait-on du Chaos Engineering, pourquoi la résilience est importante, quel piste évoquer si votre société n’est pas encore mature, qu’est-ce réellement que le chaos engineering, lutter contre les idées reçues…oui, ce n’est pas évident de savoir quels points aborder. Ce qui suit n’est pas un exemple absolu mais c’est celui qui a fonctionné pour moi.
La résilience : redonner la définition en l’agrémentant d’arguments liés à l’entreprise. Ne pas hésiter à donner un exemple potentiellement catastrophique en partant d’une lacune de votre SI que tout le monde connait. Attention cependant à ne pas froisser une équipe ou une direction. L’objectif n’est pas ici de pointer du doigt mais plus d’illustrer avec du concret que tout le monde comprendra. L’amélioration de la résilience de l’entreprise (SI, applications, organisation) est le but du Chaos engineering.
Le chaos monkey, mythes et réalité : Souvent quand on pense Chaos Monkey, on imagine “casser la prod pour le fun”. Concrètement ce n’est pas ça, il faut le dire et rassurer sur la mise en œuvre. Cet argument est particulièrement important pour un CODIR. Proposez un POC hors production et un POC en production sur un périmètre sûr, restreint et maitrisé dans le temps : pas question de faire de l’exécution “au hasard” au début car se serait contre-productif.
Le Chaos Engineering : Définition et utilité de mise en œuvre. Vous ne devriez pas avoir trop de problèmes pour ce point en vous basant sur l’article de Christophe Rochefolle.
La gamification : Mobiliser ou re-mobiliser les équipes sur des sujets peu avenant comme le suivi de production ou l’importance du monitoring applicatif et technique. Le jeu est un vecteur puissant permettant de créer une dynamique d’entreprise. Il permet aussi de créer ou de recréer du lien transverse (en particulier en mode DevOps). Voici une définition plus complète de la gamification. Les Days of Chaos sont un bon exemple d’événement implémentant ce concept. Si cette pratique n’est pas spécifique au Chaos Engineering, la plupart des exemples en informatique tournent pourtant autour de ce sujet comme par exemple pour AWS.
La transparence : N’oubliez pas que nous parlons d’expérimentations sur la production. Même si celles-ci sont maîtrisées dans le périmètre, le temps et l’importance de la panne il faut communiquer en amont...et en aval! En amont pour que personne ne le subisse de force ou ne soit opposé à la démarche, en aval pour mettre en avant les analyses et les apprentissages suite aux expérimentations. Ce qui compte, c’est ce qu’on aura appris et les actions qu’on prendra (ou pas).
Les gains : Je n’aborde ce point qu’à la fin mais c’est pourtant essentiel! Qu’a-t-on à y gagner? Il me parait impossible de pouvoir calculer un ROI direct (return on investment). Il est plus simple de partir sur l’évaluation du ROI en estimant le coût d’une interruption de vos services. Combien d’argent vous couterait une panne générale de 5 minutes? 5 minutes paraissent peu dans l’absolu mais c’est pourtant un bon marqueur de l’impact d’une panne. En l’occurrence, plus ce chiffre est élevé plus il vous sera facile d’argumenter sur ce point. Bien entendu, en améliorant la résilience vous baisserez ce cout et le ROI indirect pourrait être mesuré et comparé dans le temps.
Partager la démarche
N’oubliez pas que cette démarche n’est pas la votre mais celle de votre entreprise (et ce même si les gains personnels pour votre carrière peuvent paraître intéressants!).
Se réunir est un début ; rester ensemble est un progrès ; travailler ensemble est la réussite. — Henri Ford
N’imposez pas aux autres de participer. Ils vivront le Chaos Engineering comme une contrainte avec toutes les inconvénients que cela implique :
- Refus de participer, ou à reculons.
- Contre-arguments sur les risques “qui seraient plus important” en opposition par rapport aux gains “potentiels”.
- Votre propre épuisement à vouloir aller à contre courant.
Les gains d’une démarche adoptée par tous est qu’il vous sera plus facile de proposer des expérimentations, d’obtenir du budget et surtout que les équipes participent et souhaitent faire elles même faire les expérimentations. Une équipe volontaire et de votre côté sera aussi un argument supplémentaire pour convaincre le métier qui sera très certainement votre plus grand opposant.
Aussi, de la même manière qu’il est important d’avoir un argumentaire et une présentation adéquate, il faut préparer à l’avance les oppositions et la manière de les désamorcer. Ceci sera l’objet de la prochaine partie.
