Avito a relié les LLM aux tests de chaos et fait passer la couverture des incidents de 22 % à 41 %

L’incident est terminé, l’équipe a rédigé son analyse, créé les tâches nécessaires — puis, un trimestre plus tard, elle subit une panne presque identique. Un scénario bien connu : les fonctionnalités produit prennent constamment le pas sur la dette technique, tandis que les enseignements des post-mortems se transforment peu à peu en archives.

Avito a tenté de combler ce fossé. Les pannes passées sont devenues une source de scénarios pour les tests de chaos, et le LLM, un filtre aidant à analyser des centaines de rapports. Le modèle a étudié 977 LSR, évalué quelles défaillances pouvaient être reproduites et proposé les anomalies appropriées. Un ingénieur vérifie ensuite si le test reproduit réellement la cause racine, au lieu de simplement produire des courbes similaires dans les graphiques.

Du rapport d’incident à la validation en production

Le pipeline enrichissait le texte du LSR avec les échanges du chat associé, puis posait six questions distinctes au modèle. Celui-ci résumait la cause et le symptôme, évaluait la possibilité d’un test de chaos, vérifiait le devenir des Action Items, attribuait au scénario une note de 0 à 10 et sélectionnait des anomalies dans une bibliothèque interne. Les résultats étaient enregistrés dans MongoDB, tandis qu’un index vectoriel était créé dans Elasticsearch afin de rechercher des incidents similaires.

Avito a ainsi obtenu 432 conclusions mises à jour automatiquement pour 408 services. Selon l’évaluation du modèle, 41 % des pannes analysées peuvent être reproduites avec des moyens existants ou planifiés. Avec LitmusChaos seul, qui agit principalement au niveau des pods, ce taux était d’environ 22 %. Kratos, l’orchestrateur métier, a presque doublé la couverture potentielle grâce à des scénarios ciblant les bases de données et le réseau.

Prenons un exemple simple : la bascule du maître Redis. Un test classique peut arrêter un processus ou supprimer un pod, mais cela ne revient pas à déclencher une véritable réélection du primary au sein d’un replica set. L’équipe a donc ajouté le scénario trigger-primary-re-election pour MongoDB et Redis. Il est utilisé dans 95,6 % des exécutions automatiques : les services sont testés face à une véritable bascule du maître, et non à une imitation approximative.

Là où le LLM se trompe

Une note élevée du modèle ne garantit pas encore l’utilité du test. Dans un cas, la panne provenait d’une mauvaise configuration de Nginx après la correction d’une vulnérabilité. Le LLM a attribué au scénario la note de 10 sur 10 et proposé d’introduire une latence réseau. Les symptômes étaient effectivement similaires : erreurs HTTP, délais d’expiration et documents indisponibles. Mais le test de chaos ne pouvait pas modifier la configuration d’un système tiers et n’aurait donc jamais reproduit la cause racine.

C’est une limite importante. Le modèle sait trier un vaste ensemble de rapports et indiquer à l’ingénieur où chercher, mais il peut confondre la cause et la conséquence. Avito ne lui confie pas la décision finale : un humain vérifie l’hypothèse, le périmètre d’impact et la sécurité du lancement. Le pipeline d’analyse lui-même est actuellement suspendu depuis la fermeture du service interne qui hébergeait l’ancien modèle, même si le jeu de données constitué et la méthodologie ont été conservés.

Ce qu’il faut en retenir

Il convient de commencer non par l’achat d’une plateforme de chaos engineering, mais par une cartographie des défaillances réelles. Répartissez-les entre ressources, réseau, processus, couche applicative, infrastructure externe et logique métier. Associez ensuite à chaque catégorie une cause racine vérifiable, une fenêtre d’exécution sûre et un critère de rétablissement mesurable.

Le LLM est ici utile comme couche de recherche au-dessus des post-mortems : il repère les causes récurrentes, regroupe les incidents et propose des candidats à l’automatisation. Mais un test ne doit être ajouté que s’il reproduit le mécanisme de défaillance. Dans le cas contraire, l’équipe n’obtiendra qu’un rapport au vert, un calendrier d’exécutions et un dangereux sentiment de sécurité.