Introduction au Chaos Engineering avec Christophe Rochefolle

Introduction au chaos engineering avec Christophe Rochefolle

Christophe et moi nous sommes rencontrés pour la première fois en octobre 2017. Il avait organisé une rencontre autour du chaos engineering, rencontre auquel il a eu la gentillesse de m’inviter. Il m’avait découvert en lisant mon livre Chaos, mode d’emploi.

Ingénieur de formation, comme beaucoup de consultants et de managers, Christophe Rochefolle est aussi un réel pratiquant de ce qu’on pourrait appeler l’art de tirer parti du chaos. Il s’efforce d’utiliser le désordre et l’imprévu comme des moteurs d’amélioration et de contrôle qualité (QA).

Regarder l’interview

Comment devient-on un « ingénieur du chaos » ?

C’est peut-être par déformation professionnelle que Christophe Rochefolle parle peu de son parcours. Il vit davantage dans le présent, l’ici et maintenant, que dans le storytelling. Après tout, un authentique chaote ne saurait se laisser aller à vivre dans un narratif, comme disent les anglophones. La vie est plus complexe, plus changeante et, admettons-le, plus bordélique qu’aucun récit ne voudra jamais l’admettre.

Malgré cela, Christophe mentionne deux facteurs importants dans son évolution. D’abord, un intérêt constant pour des objets ou des problèmes trans-disciplinaires : chaque discipline bien délimitée lui a toujours semblé trop petite et l’a conduite à chercher des liens, des ponts, plutôt qu’à prendre pour acquises des limites apparemment définitives. Ensuite, au cours de sa carrière, il s’est concentré sur les améliorations incrémentales. Non via le micromanagement, le « je viens avec ma casquette et je te dis, ça, ça va, ça ça ne va pas », mais plutôt par le changement continu et l’ajout de modifications fréquentes.

Après plusieurs années à assumer le rôle de responsable de l’assurance qualité (QA manager) pour plusieurs entreprises, Christophe a entendu parler assez tôt de la méthode Agile et à en deviner le potentiel. En juin 2009, il a convaincu un site pas encore très connu, vente-privee.com, que cela les aiderait à se développer.

Vous connaissez certainement vente-privee.com. Peut-être y avez-vous déjà dégotté un beau polo ou des places pour un voyage au bout du monde. Créé en 2001, ce déstockeur en ligne a su développer un concept original mais adapté, et ses ventes de court terme à des prix réellement cassés (parfois tout juste le tiers du prix original) ont bien convenu à une atmosphère économique de crise perpétuelle. Aujourd’hui, vente-privee.com fait partie des 3 plus gros sites de vente en ligne de tout le pays. Avant d’en arriver là, le site a dû s’adapter, passer d’une version à l’autre, assumer de larges flux de visites quotidiennes… un chantier perpétuel que mon interviewé a fortement contribuer à garder en état.

Plus tard, en 2016, Christophe Rochefolle a été embauché par la SNCF pour veiller sur la nouvelle mouture de leur site, oui.sncf. Qui est désormais le premier site français de vente en ligne.

« Avant, le développement software se passait différemment. On avait un développeur, ou un responsable développement, qui passait un an et demi à coder. Il avait un cahier des charges avec 180 pages de spécifications, il le suivait à la lettre, et voilà. » Dans les années 1980 et 90, l’informatique avançait d’un pas relativement tranquille et ce délai n’était pas un problème. Ni pour le client ou le marché, ni au point de vue des langages de programmation utilisés. Puis, au fil des années 2000, ce mode de développement a commencé à montrer ses limites. En un an, « le marché évolue, les normes de programmation évoluent, tout est mis à jour » et un produit basé sur un design vieux d’un an ne sera plus satisfaisant.

Le développement Agile a fourni une réponse au problème. Les programmeurs ne travaillent plus dans une bulle, mais font des sprints d’une ou deux semaines, rencontrent collègues et clients, font le point, s’accordent à changer tel ou tel élément. Résultat : les produits sont finis plus vite, le risque de décevoir le client et/ou les attentes en bout de course diminue largement et toutes les parties prenantes peuvent influer sur l’évolution du produit.

Christophe est aussi un aficionado du DevOps depuis longtemps. En ingénierie informatique, le DevOps consiste à rapprocher ou même à fusionner le développement software (dev) avec l’administration système ou « les opérations » (ops). Chez vente-privee.com, l’esprit DevOps a conduit Christophe à vouloir resserrer le triangle formé par les idées, la proposition de valeur et le(s) retour(s), afin que ces derniers mènent plus vite à des modifications et, bien sûr, pour réduire tant les coûts que les frictions. «_Comment rendre toute la chaîne d’approvisionnement Agile ou même Lean ? »

Pourquoi la science-fiction a quasiment disparu

Dans ce domaine, l’accélération de l’histoire n’est pas un propos académique. En 2012, voyages-sncf.com, dont vous vous rappelez encore certainement, avait « quatre mises à jour par an ». En 2018, oui.sncf a eu « une ou deux updates par jour » pour un total de 446 mises à jour en un an. Derrière le site actuel se trouvent environ 17 équipes, chacune dédiée à une fonctionnalité ou feature, ce qui signifie un fort taux d’instabilité, beaucoup de bugs potentiels et beaucoup de défis. Coordonner tout cela n’est certainement pas une tâche facile.

Le dispositif Internet de oui.sncf est surtout fait de webservices et de microservices. Plutôt que des «_blocs », qui sont en fait fragiles, ces petits services peuvent être reconfigurés, arrêtés ou démarrés à la demande, replacés ailleurs ou même supprimés sans (trop) toucher au reste. Exactement comme des pièces de rechange dans l’industrie physique, à ceci près que chaque fonctionnalité s’appuie sur plusieurs centaines de microservices. Et ce n’est pas tout : certains processus-clé, comme le système de paiement, sont externalisés et en partie opaques vus de l’intérieur du site.

Le niveau de complexité existant aujourd’hui en ingénierie informatique est absolument sans précédent. Même il y a dix ans, les choses n’ont jamais été aussi compliquées. Christophe mentionne d’ailleurs un autre facteur de complexité, l’intelligence artificielle. Apprenant eux-mêmes par le machine learning, les programmes dotés d’IA interprètent le langage naturel, y répondent et développent leur propre comportement. Qui peut parfois poser question. « Avec l’IA, nous sommes encore des apprentis », avoue Christophe.

Comment peut-on réussir dans un tel environnement ? Plus précisément, comment toute cette complexité peut-elle laisser des améliorations émerger ou simplement rester viable et non s’effondrer sous son propre poids ?

Le monde actuel est imprévisible. C’est pour cela que la science-fiction, un genre florissant autrefois, est aujourd’hui presque passée de mode. Autrefois, on pouvait projeter sur le futur une vision relativement linéaire, où telle et telle technologie attendue allaient chacune marquer l’époque de son empreinte et provoquer des problèmes bien définis. Les nouvelles d’Isaac Asimov autour de la roboticienne Susan Calvin sont autant de prétextes pour imaginer des problèmes découlant du concept de robot tel qu’Asimov l’avait imaginé, ce qui laisse supposer des robots certes « futuristes » mais relativement peu fluides. Aujourd’hui, les innovations sont constantes et ne cessent de se mélanger, ou de se heurter, à des échelles multiples. On ne peut avoir au mieux que des scénarios portant sur un futur proche.

Un ami trader m’a dit une fois que, jusqu’à la fin des années 2000, on pouvait anticiper des conséquences plutôt bien définies à divers événements : si le président de la Réserve fédérale américaine annonçait tels chiffres, le dollar devrait monter ou baisser, et ainsi de suite. Aujourd’hui, « on ne peut rien connecter », la plupart des événements ne sont plus suffisants à déterminer le futur de façon certaine. Et ce qui est vrai dans le trading l’est aussi en ingénierie informatique, comme on peut s’y attendre dans un monde fractal et donc auto-récursif.

Dès lors, à défaut de pouvoir anticiper, on doit pouvoir diagnostiquer et réagir (très) vite. Pour Christophe, cela revient à chercher des faiblesses. Les vulnérabilités cachées sont à la base des exploits zero day dont hackers et agences de renseignement sont friands, et, parfois, de malfonctions coûteuses. Mieux vaut, donc, les trouver et éventuellement y remédier avant que quelque chose de grave n’arrive. Ces faiblesses peuvent être découvertes par leurs effets, mais aussi plus ou moins devinées ou soupçonnées avant d’être réellement trouvées.

Un système petit et peu complexe peut être maintenu de façon relativement simple. Votre ordinateur, par exemple, est sorti de l’usine avec plusieurs capteurs, qui permettent de surveiller constamment certaines variables. Le système sait à quel point le cœur chauffe, quel pourcentage de mémoire vive est utilisé, quelle quantité d’électricité est consommée et ainsi de suite. Dans chaque cas, si l’ordinateur excède une valeur-limite, une alarme devrait sonner, ou alors le système devrait réagir avec un mécanisme de sûreté pré-implémenté. Si votre ordinateur chauffe trop, il devrait finir par s’éteindre automatiquement afin que l’électronique ne souffre pas (trop).

En version software, on obtient des messages d’erreur. Quand vous vous retrouvez avec un bel écran bleu et un numéro d’erreur comme « 0xc000021a », cela signifie que le problème a déjà été pensé et que l’ordinateur a réagi comme prévu.

Quand le système est beaucoup plus complexe, la surveillance ciblée (monitoring) laisse place à l’observabilité. Au lieu de surveiller telle et telle variable uniquement, on observe et on enregistre tout. Cela donne du big data interne, qui entraîne un surcoût, mais l’amélioration en termes de connaissance amortit largement la dépense. En effet, si quelque chose a besoin d’être analysé ou mieux connu, on peut revenir sur n’importe quelle séquence d’événements et la suivre avec une relative transparence.

En d’autres termes, c’est une version informatique de la traçabilité.

Les « days of chaos »

Jesse Robins, l’un des pionniers du chaos engineering, était « maître des désastres » chez Amazon. Cet intitulé étrange résumait adéquatement les méthodes avec lesquelles il rendait le leader de la vente en ligne plus sûr. Avant sa carrière dans l’IT, Robins avait été pompier volontaire et en a tiré une expérience pratique de la gestion des urgences. Il a lancé un vaste programme d’entraînement, le Game Day, où l’entreprise simule une panne majeure et où les joueurs et/ou responsables doivent trouver, puis résoudre le problème, sous l’œil vigilant d’examinateurs. De quoi rendre jaloux les départements de ressources humaines, le jeu s’intéressant plutôt au comportement humain qu’au fonctionnement software.

Quand Christophe Rochefolle a rejoint oui.sncf, il a repris la recette de Jesse Robins et créé ses propres exercices. Les « days of chaos », qu’il a mis sur pied avec quelques collègues, consistent en un jeu compétitif pratiqué par des équipes de volontaires. Pendant une demi-journée, les joueurs passent par des sessions d’une demi-heure, où l’on simule une panne ou un problème différent. Les équipes n’ont que ce laps de temps pour trouver le problème et ébaucher une solution. Si, après trente minutes, personne n’a identifié le problème, les organisateurs prennent le temps de l’expliquer.

Christophe insiste au passage sur l’importance du marketing interne de ce type de jeu. « Si j’avais appelé ça un entraînement à la détection des pannes, ça n’aurait pas intéressé grand monde. ‘Chaos’, par contre, ça frappe. » Le mot résonne instictivement dans la psyché et rend chacun vigilant. Parfois, les pannes seront plutôt simples, par exemple si un serveur cesse de fonctionner, parfois elles seront beaucoup plus complexes. Dans ce cas, le dénouement devient un véritable défi, et si le problème est relativement peu courant, sa résolution prend une valeur expérimentale.

Le premier « day of chaos » a eu lieu le vendredi 13 janvier 2017. Un choix pour qui ne craint pas de tenter le diable… 113 informaticiens se sont inscrits. Plus tard, ils étaient près de 180.

Le jeu n’est pas nécessairement (qu’)un divertissement. C’est aussi une forme d’apprentissage. On se souvient toujours mieux de ce qu’on a appris en étant engagé, dans le moment, et plus encore quand on se faisait plaisir, que de ce qu’un prof a pu dire lors d’un cours auquel on assistait passivement. À la fin du day of chaos, les meilleurs participants reçoivent des prix et les équipes sont hiérarchisées selon leur performance. Outre les sessions de Jesse Robins, Christophe mentionne le livre La stratégie Ender, un roman de science-fiction où un enfant surdoué devient un stratège hors pair grâce à un entraînement assidu sur des jeux vidéos.

« On a fait une vidéo avec des images de train, de métro, même des membres du conseil d’administration qui voyaient le réseau oui.sncf dysfonctionner et arrivaient au bord de la panique », se souvient Christophe. « On a fait un gros effort sur le marketing. » La semaine d’avant le premier jeu, les ordinateurs internes de oui.sncf se sont mis à montrer des fonds d’écran sur mesure avec un message d’avertissement : chaos is coming…

« On peut toujours venir avec des stratégies, mais la stratégie se fait bouffer par la situation. » Aucune stratégie faite d’avance ne vient sans ses points faibles et ses angles morts. L’entraînement vise à affûter quelque chose de plus primal. À savoir, la capacité à sonder une situation, à l’intuitionner, et à composer avec l’état du dispositif informatique que l’on doit toujours maintenir opérationnel.

« Chaque équipe a un tableau de bord. Son progrès dans le jeu, son esprit d’équipe, tout ce qui est important est mesuré et montré ici. Parmi les indicateurs, il y en a aussi qui touchent à la production et au business. » Si ceux-là ne sont pas exclusifs au jeu, « ils y sont très importants. Pendant deux ans, on a dit aux employés de les vérifier régulièrement, ils ne le faisaient jamais, et puis dès le deuxième ‘day of chaos’ ils les regardaient tous. » Un petit changement qui peut causer des gains pas si réduits. Une fois encore, l’amélioration a eu lieu par la pratique et non par le micromanagement.

Attention, ils arrivent !

Puis, après les days of chaos, les équipes du site ont vu arriver les chaos monkey (littéralement, singes du chaos). La même idée est poussée un cran plus loin. Cette fois, au lieu de donner une version simulée du système et d’appuyer le jeu dessus, on provoque de véritables problèmes dans le véritable système. Et au lieu de laisser des organisateurs tout-puissants décider du problème, on laisse un petit programme créer un problème au hasard.

Imaginez un singe qui rentrerait dans un data center, un de ces centres qui rassemble des centaines ou des milliers de serveurs et qui héberge toutes les fonctions critiques des services dont on se sert au quotidien. Le singe s’amuserait à débrancher des câbles au hasard et à jeter des périphériques par terre. Pour les informaticiens, le but est de maintenir le système en état de fonctionnement malgré la présence du singe, dont personne ne sait quand il arrivera pour la prochaine fois et à quelles ressources il s’en prendra. (Source)

Les chaos monkeys peuvent devenir un élément permanent du dispositif informatique. Ils obligent les informaticiens à adopter une attitude proactive. Tous les X jours, semaines, ou au hasard, le programme créée un problème. On ne peut plus espérer passivement que les problèmes n’arriveront pas : « ça va arriver, vous n’aurez pas la chance d’éviter les soucis, alors autant vous y préparer et être prêt ». Résultat, les informaticiens et leur domaine deviennent plus résilients, et lorsqu’une panne ou un problème surviennent réellement par hasard, la difficulté est largement moindre qu’elle ne l’aurait été sans préparation.

Tu sais comment on appelle la résilience au travail ? On l’appelle « même pas mal » !

Au-delà d’une certaine échelle, le dispositif informatique d’une entreprise a cent pour cent de chances d’avoir des problèmes. Ceux-ci ne seront pas forcément de grande ampleur. La plupart des problèmes sont petits, cela peut être un câble mal branché, une fonction qui n’est plus valide, un élément de mémoire qui ne répond plus, mais dans un système complexe, ce genre de petit problème peut avoir des conséquences beaucoup plus vastes. (C’est un exemple de l’effet papillon.)

Pas étonnant qu’Amazon ait eu un si grand intérêt dans la stabilité informatique : lorsqu’on gère des dizaines de centres de données tout autour du monde, avec des milliers de serveurs à la clé, on peut être absolument sûr que des dysfonctionnements apparaîtront. Cela va arriver, cela arrive tous les jours et on ne peut tout simplement pas l’éviter. Cependant, on peut fortement mitiger l’impact de ces soucis et maintenir l’entropie à un niveau marginal du côté de l’utilisateur (front-end).

Le chaos engineering est-il bankable ?

À ce stade de l’interview, je ne puis m’empêcher de me ressouvenir d’un propos important de Luc Taesch, spécialiste de la transition vers l’entreprise Agile que j’avais eu le plaisir de rencontrer il y a quelques mois et qui a travaillé avec Christophe. L’agilité, me disait-il, a émergé par les codeurs, les entrepreneurs et les start-up. Elle n’a pas émergé du management (ou du moins pas du management de grandes entreprises).

Les managers ont plutôt tendance à se méfier de l’agilité, car elle est, par définition, rebelle aux estimations trop précises. Or, si c’est le cas avec l’agilité, cela devrait être encore plus vrai ici : comment peut-on vendre le chaos engineering aux membres d’un conseil d’administration ? Qui irait voir des décideurs, a fortiori des non-informaticiens, pour leur dire je vais foutre la m… dans le système informatique de l’entreprise et vous allez me payer pour ça ?

Certes, admet Christophe, l’idée est plutôt contre-intuitive. Mais elle peut convaincre même ceux qui seraient en peine de citer une seule balise HTML. D’abord, des managers savent à quel point le rythme s’est accéléré et le monde devenu instable. Ils savent d’expérience que la résilience n’est pas un vain mot, et beaucoup s’entraînent déjà en pratiquant un sport, alors pourquoi ne pas admettre que la même chose puisse fonctionner en informatique ?

Comme le remarque mon invité, la question classique « comment faire pour que ce problème n’arrive plus jamais ? » est devenue caduque. Même si tel problème précis pouvait être rayé de la carte, la complexité systémique rend possible un nombre infini de problèmes, qui sont donc infiniment variés.

Ensuite, et je veux bien parier avec Christophe que l’argument convaincra à coup sûr, le chaos engineering permet de faire des économies en limitant les pertes.

Selon un rapport de la CIRCA (Administrateur de centre de ressources de communication et d’information, un organisme membre de la Commission Européenne), les plus grandes entreprises de l’UE ont en moyenne trois gros problèmes par mois. Chacun coûte environ 115 000 euros. Et, en plus de ces pertes directes, les entreprises en question sont bien connues, ce qui signifie que leurs dysfonctionnements peuvent ternir leur réputation.

Nombre de managers se sont mis à la page. Depuis 2016, la majorité d’entre eux mettent la disponibilité au-dessus de la sécurité. Un bon marketing peut faire des merveilles. Si vous expliquez à un directeur que l’entreprise n’a plus répondu pendant cinq minutes, il haussera les épaules, mais si vous ajoutez qu’en ne répondant pas l’entreprise a perdu un contrat à six chiffres, vous n’aurez plus besoin de lui expliquer quoi que ce soit d’autre. L’argent est ici un dénominateur universel et par conséquent un bon argument quand ingénierie rime avec économie.

Une fois le taux d’indisponibilité passé au-dessous d’une certaine limite, l’entreprise devrait être relativement préservée des pertes financières ou de réputation dues à des non-réponses.

« Dans les années 1990 », se souvient Christophe, « s’il y avait un incident, ça n’était su que d’un très petit nombre de personnes. En 2008, voyages-sncf.com est passé au journal de 20 heures suite à une grosse indisponibilité. » Depuis, ce genre d’exposition négative n’a plus jamais eu lieu, en dépit de conditions plus turbulentes. « Aujourd’hui, si on a un problème, les gens commencent à en parler sur Twitter dans la minute. »

Si les risques sur la réputation paraissent plus importants, oui.sncf tire aussi avantage de cette conjecture : des spécialistes y surveillent les réseaux sociaux pour se rendre compte rapidement si des utilisateurs se plaignent de quoi que ce soit. Autrement dit, l’établissement se sert d’éventuels utilisateurs insatisfaits comme de sondes inconscientes !

Affiner le chaos

Il n’est pas toujours facile de distinguer entre chaos et entropie. Si vous laissez un système devenir trop volatile, il risque de complètement s’effondrer. Adieu, alors, tout le potentiel, et avec lui toutes les ambiguités du chaos : les tas de ruines demeurent muets. Comment s’assurer que le désordre ne reste présent qu’à un degré tolérable, celui où il rend le système tant humain que technique plus résilient, sans aller (trop) au-delà ?

« Tu dois instaurer un périmètre », me dit Christophe. « Le but, c’est d’expérimenter, de tester. Pas de casser. » C’est d’autant plus important que la pratique en elle-même demeure ambigue et nourrie de risque, c’est-à-dire d’un élément qui, en soi, ne demande qu’à sortir des limites où on voudrait bien le cantonner. Dans l’idéal, les problèmes suscités par les singes du chaos devraient avoir un impact relativement restreint, mais aussi être a minima originaux afin qu’on tire des leçons de leur résolution.

Si une faiblesse est trouvée, elle devrait être testée et son domaine amélioré, encore et encore, jusqu’à ce qu’aucun maillon faible n’apparaisse. C’est alors que le chaos engineer peut passer à un autre périmètre (à défaut de domaines ou d’éléments déjà très bornés) ou élargir celui qu’il a déjà pour en savoir plus. « En 2017, on s’est concentrés sur les processus opérationnels, en 2018 on s’est plutôt concentrés sur les applications. »

Au-delà des days of chaos et du chaos monkey vient encore un autre niveau : Chaos Kong. Il s’agit ici de simuler l’arrêt de tout un centre de données (data center). Un événement d’une ampleur dramatique, l’équipement Internet du site oui.sncf tout entier reposant sur deux centres de données. « On l’a fait deux fois et on voudrait le refaire à nouveau. » Malgré les risques, le jeu s’appuie ici aussi sur un élément de réalité : certains flux réseau sont réellement interrompus et le dysfonctionnement simulé pourrait contaminer les fonctionnements réels des applications.

Le premier Chaos Kong n’a eu aucun impact utilisateur. Le public n’a rien vu. Par contre, les équipes participantes n’ont pas trouvé l’origine du problème. Ils ont été bons pour minimiser l’impact et maintenir le système opérationnel avec la moitié seulement de sa base hardware habituelle, mais niveau diagnostic, ils ont un peu déçu.

Pour rendre le jeu plus réaliste, la prochaine édition du Chaos Kong sera un exercice surprise.

Un pilier de la culture d’entreprise

Comme dit plus haut, le chaos engineering doit devenir une pratique courante de l’entreprise pour donner sa pleine mesure. La création plus ou moins volontaire et contrôlée de problèmes ne devrait pas être perçue comme un événement exceptionnel ou ponctuel, mais comme un processus continu. Les entraînements améliorent la cohésion des équipes et cultivent l’aptitude à bien réagir. Ce faisant, ils aident les informaticiens à s’auto-organiser et à fonctionner davantage comme une véritable unité vivante.

Une fois, se souvient Christophe, le site international lié à oui.sncf a eu une mise à jour de grande ampleur. La transformation était si grande que beaucoup d’employés, informaticiens ou non, se sont mis à craindre de gros bugs et certains managers des pertes financières conséquentes. Sachant à quel point ce genre de peur peut saper le moral des équipes et s’avérer auto-réalisatrice, Christophe y a répondu comme l’aurait fait Mithridate. Avec quelques collègues, ils ont organisé un mois entier dit du chaos.

Pendant trente jours, la version rénovée du site international a été utilisée en interne, en version beta. Chaque jour, un problème a été volontairement implémenté ici ou là. Les équipes IT avaient pour mission de trouver le ou les problèmes, de les diagnostiquer précisément et d’y remédier. À force, elles sont devenus beaucoup plus confiantes vis-à-vis de la nouvelle version, et celle-ci a acquis à son tour une résilience beaucoup plus forte.

On a là un cas d’école de comment mettre le chaos de son côté. Au lieu d’être craint passivement, l’inévitable chaos est volontairement amené, dans un cadre contrôlé, et on en fait un moyen de détecter les points de fragilité.

Un autre exemple. Les centres de données oui.sncf sont équipés de modules « shift » dont la fonction est de faire passer le traitement des données sur les autres data centers si l’un d’entre eux ne répond plus. Ainsi, si une part du système tombe en panne, le tout continue à fonctionner et les utilisateurs ne sont pas dérangés. À l’occasion d’un chaos training, on a simulé la panne d’un centre de données, les équipes y ont répondu adéquatement et le jeu s’est bien déroulé.

Un mois plus tard, le scénario simulé a réellement eu lieu en vrai ! Quelqu’un a enclenché accidentellement l’arrêt d’urgence dans l’un des data centers. Le module « shift » a bien fonctionné pour le site web, qui est resté accessible et fluide, en revanche l’application mobile s’est aussitôt mise à planter.

Pourquoi ce bug ? On a vite trouvé la cause : une route du data center concerné ne réagissait pas correctement au shift. Elle empêchait les données de bien passer sur les autres centres de traitement et faisait bugger toute l’application. C’était une petite route, loin d’être parmi les plus importantes tant en terme de fonctions assumées que de volume de données traitées. Elle avait fait l’objet d’une vigilance moindre lors des tests contrôlés. Et pourtant, en tant que maillon faible, ses effets étaient tout à fait visibles. Si elle n’avait pas été très remarquée lors de la simulation, cette dernière a pourtant bien aidé à l’identifier rapidement.

Et hors informatique ?

L’informatique est à l’avant-garde du monde de l’entreprise. Les problèmes de complexité, de rythme accéléré, d’imprévisibilité ont tendance à survenir d’abord en informatique et à ne toucher les autres domaines que plus tard. Du coup, les solutions sont souvent ébauchées par des informaticiens avant de susciter de l’intérêt ailleurs.

Regardons un instant la méthode Agile. Créée pour le développement software, elle est aujourd’hui utilisée en architecture (BTP). Un chantier fait intervenir des dizaines de spécialités différentes, avec autant de missions, de priorités et de points de vue différents. La complexité rend difficile les estimations précises. Aucun architecte ne peut savoir tout ce qui se passe sur le chantier et encore moins fournir des estimations correctes seul.

Du coup, sur un chantier agilisé, les parties prenantes se rencontrent toutes les deux semaines et échangent leurs diagnostics autour de questions précises, ce qui permet à tous de savoir où on en est, quels aspects peuvent poser problème, et à quel genre de retards ou de surcoûts on peut s’attendre.

Les avantages de l’agilité sont plutôt évidents. Les clients sont plus engagés, leurs attentes mieux connues, et les développeurs ou constructeurs forment des équipes plus productives et plus soudées. Dans le cas du chaos engineering, comment porter la méthode ou au moins l’état d’esprit hors informatique ?

Les choses vont peut-être dans l’autre sens. Avant que le chaos ne devienne une réalité inévitable pour les ingénieurs, dont la profession s’appuie plutôt, à la base, sur des régularités et des lois physiques immuables, il l’était pour nombre de travailleurs plus manuels. Les pompiers combattent un élément intrinsèquement instable et doivent s’y adapter pour sauver des vies. Même chose pour les militaires : un conflit armé a toujours sa part d’événements imprévus et imprévisibles auxquels on doit se confronter immédiatemment.

Les armées se sont d’ailleurs elles aussi mises à la page. L’US Army donne de plus en plus de pouvoir à des petites équipes et à des chefs de terrain plutôt qu’à de lointains galonnés, agilisant ainsi ses processus.

Si vous avez des enfants, vous pouvez faire de la préparation au chaos un véritable jeu. En cas de problème, vos enfants devraient pouvoir se débrouiller pour aller de l’école à la maison des grands-parents, ou chez quelqu’un de confiance, ou à rester en permanence jusque plus tard que prévu, selon les situations. Vous pouvez alors utiliser n’importe quelle opportunité pour habituer vos têtes blondes à l’imprévu. Les perturbations deviennent quelque chose de drôle, et si une vraie situation chaotique arrive, le savoir-réagir acquis peut faire toute la différence.

L’entreprise fractale

Si vous avez regardé la vidéo, vous aurez peut-être remarqué que Christophe a évoqué « l’entreprise fractale » au début mais n’en a toujours pas reparlé après 40 minutes. À ce moment-là, je regarde le chronomètre et, même si tout ce qui a été dit jusqu’ici me semble diablement intéressant, il me semble qu’on oublie l’inoubliable. Si les fractales tiennent une telle place dans ma vision, ce n’est pas pour rien ! Que signifie cette notion pour mon invité ? Pas pour moi, pas dans Chaos, mode d’emploi, mais pour celui qui a su vendre le chaos engineering à l’une des premières entreprises de France ?

Christophe définit l’entreprise fractale en trois points :

1. Intégration continue. Dans la nature, beaucoup d’objets fractals comme les nuages ou les flocons de neige ont tendance à se former très vite. Leur forme fractale n’est pas fixée mais émerge lors d’un flux ou d’un mouvement continu. Pour les développeurs et les managers, l’entreprise fractale est synonyme de changement continu : au lieu de faire des réorganisations coûteuses et compliquées tous les X mois, on admet des changements petits ou grands à chaque fois que c’est nécessaire. La pratique DevOps applique l’idée dans l’ingénierie software en faisant du développement non plus une simple étape, mais un élément permanent.

2. Auto-similarité ou scalabilité. À l’aide du changement ou de l’intégration continue, le système est désormais plus flexible. Il peut grandir, diviser ses unités ou les faire fusionner selon les besoins. Toutefois, quelle que soit l’ampleur des changements, les différentes parties du système restent toujours à peu près similaires les unes aux autres.

C’est le cas dans une entreprise agile. L’agilité repose sur trois principes : le produit, ou le but, le système qui porte sur l’équipe et sur son bien-être, et le technique avec ses méthodes, règles, cahier des charges. Chacun de ces principes doit être incarné par un responsable spécifique. Les équipes agiles fonctionnent déjà ainsi, mais c’est aussi faisable à des échelles plus élevées. Ainsi, chez oui.sncf, si un changement touche à plusieurs features et relève donc de la responsabilité de plusieurs équipes, celles-ci forment une « tribu », où de nouveaux responsables vont incarner ces mêmes rôles à l’échelle supérieure.

3. Un modèle vivant. Les équipes sont organisées comme des cellules, et les tribus sont des ensembles de cellules. Une cellule n’est pas un silo ou une tour d’ivoire : elle est délimitée par une membrane, soit un lieu d’échange en même temps qu’une frontière. « Une cellule qui n’échange pas avec ses voisines meurt, mais une cellule qui laisse tout rentrer finit par mourir aussi. » Une cellule peut aussi changer de place, de même que ses composants peuvent aussi passer d’une cellule à l’autre sans déformer les cellules ni leur ensemble. Comme toujours, la nature reste un modèle plus pérenne que des fruits de la science qui sont parfois à courte durée.

Plus l’histoire accélère, plus la normalité se rapproche de l’avant-garde. Le passage du nec plus ultra à l’habituel pouvait prendre dix ans il y a longtemps, aujourd’hui c’est l’affaire de quelques mois. Plus que jamais, discuter avec ceux qui se trouvent à l’avant des tendances aide à anticiper (ou à réagir !) sur ce qui vient. Alors vos Chaos Monkey à vous, c’est quoi ?

Pour en savoir plus, vous pouvez visiter le site days-of-chaos.com (en français) et le profil LinkedIn de Christophe Rochefolle.