Comment DataDome a automatisé la création de post-mortems avec l’agent d’IA DomeScribe

Rédiger des post-mortems est une tâche nécessaire mais souvent frustrante pour les ingénieurs d’astreinte. Bien que ces rapports aident les équipes à apprendre et à s’améliorer, ils peuvent être chronophages—surtout lorsque le processus ressemble davantage à de l’administratif qu’à une réelle résolution de problèmes.

Lors d’un récent hackathon interne, nous avons décidé de changer cela. Notre objectif ? Rendre la documentation des post-mortems plus rapide et plus simple, sans compromettre les analyses essentielles à l’amélioration continue. Le résultat : DomeScribe, un Slackbot et un agent d’IA qui automatisent la création des post-mortems dans Notion.

Dans cet article, nous vous expliquerons comment nous avons développé DomeScribe, comment il optimise notre gestion des incidents, les services AWS que nous avons utilisés pour le déployer et comment vous pouvez le reproduire pour automatiser votre propre processus de post-mortem.

Comment nous gérons les incidents chez DataDome

Chez DataDome, la gestion des incidents consiste à minimiser l’impact, à résoudre rapidement les problèmes pour respecter nos Service Level Agreements (SLA) et à garantir une expérience client sans interruption. Lorsqu’un incident survient, il est déclaré dans un canal Slack dédié, où la réponse est coordonnée.

Le premier objectif de toute gestion d’incident est d’en atténuer l’impact. L’équipe documente chaque action effectuée afin de créer une chronologie claire de ce qui a été fait et à quel moment, ce qui permet de maintenir une transparence tout au long du processus.

Les incidents proviennent principalement de nos systèmes de surveillance internes, mais ils peuvent également être signalés par l’équipe support ou par nos clients. La surveillance interne est essentielle pour détecter les problèmes avant qu’ils n’affectent les utilisateurs, ce qui permet une gestion proactive et réduit les risques d’impact côté client.

Notre approche des post-mortems

Chez DataDome, les post-mortems suivent une approche sans blâme, axée sur l’apprentissage et l’amélioration plutôt que sur la recherche de responsabilités. Cela favorise une culture collaborative où les membres de l’équipe se sentent en confiance pour partager leurs analyses. Les post-mortems sont un outil essentiel pour comprendre ce qui s’est mal passé et garantir que les actions correctives sont clairement définies et communiquées aux clients.

Chaque post-mortem inclut :

• résumé général & impact : un aperçu concis de l’incident et de ses conséquences ;
• chronologie de l’incident : une séquence détaillée des événements, de la détection à la résolution ;
• analyse des causes racines : identification de la cause profonde de l’incident ;
• suivi des actions : documentation des mesures correctives et préventives ;
• leçons apprises : points clés à retenir pour éviter des incidents similaires à l’avenir.

En réalisant systématiquement des post-mortems, DataDome vise à tirer des enseignements de chaque incident, à soutenir les plans d’action et à améliorer la qualité globale des réponses. Pour en savoir plus sur la culture des post-mortems chez DataDome, consultez notre article sur la façon dont les post-mortems aident l’équipe à apprendre des incidents.

Le post-mortem va au-delà de la simple documentation : il permet un suivi efficace des actions et une communication renforcée avec les clients. Cependant, sa création peut être fastidieuse, notamment pour établir une chronologie ou rassembler des liens partagés. C’est pourquoi nous avons développé DomeScribe, un agent d’IA qui automatise la première ébauche, libérant ainsi les ingénieurs des tâches administratives pour qu’ils puissent se concentrer sur l’analyse. Il fournit une base solide, que les équipes peuvent affiner et ajouter des informations efficacement.

Comment créer un agent d’IA pour la gestion des incidents

Maintenant que nous avons exploré les processus de gestion des incidents chez DataDome, il est temps d’entrer dans la technique. Dans la section suivante, vous apprendrez à créer un agent d’IA personnalisé pour gérer les incidents, étape par étape.

Anatomie et technologie de DomeScribe

Voyons comment DomeScribe est hébergé et quels services AWS alimentent la génération des post-mortems.

DomeScribe est encapsulé dans un conteneur Docker, stocké dans un AWS Elastic Container Registry (ECR) et alimenté par des images générées et poussées depuis une action GitHub. Du point de vue de l’orchestration, il s’exécute en tant que pod dans un cluster AWS Elastic Kubernetes Service (EKS).

DomeScribe ne nécessite pas de mise à l’échelle intensive, mais en l’exécutant sur EKS, nous garantissons sa haute disponibilité tout en facilitant son déploiement et sa maintenance avec ArgoCD.

Un avantage intéressant de la communication WebSocket Secure (WSS) de Slack est qu’elle élimine le besoin d’un enregistrement DNS, ce qui réduit les ressources Kubernetes nécessaires au déploiement.

Il suffit d’un déploiement, de plusieurs secrets externes et d’un compte de service pour exploiter l’IAM Role for Service Account (IRSA) et permettre la communication avec AWS Bedrock.

L’utilisation d’AWS Bedrock constitue l’épine dorsale de DomeScribe. Face au besoin croissant des entreprises de tirer parti des grands modèles de langage (LMM), Bedrock constitue un moyen d’exposer les modèles de base (MB) et une alternative à l’utilisation d’OpenAI en exposant une grande diversité de LMM. Les plus courants sont Claude d’Anthropic, Titan d’Amazon, Mistral de Mistral AI et Llama de Meta. Après plusieurs tests prenant en compte la disponibilité des modèles et leur coût, nous avons décidé de déployer Llama 3.1 (version 405B).

Enfin, parlons des coûts. DomeScribe génère des dépenses minimales grâce à :

• son pod qui nécessite très peu de ressources de calcul ;
• la tarification de Bedrock au token, où le faible volume de requêtes post-mortem—même en phase de développement—n’ajoute que quelques centimes à la facture.

Comment les différents composants interagissent

Concentrons-nous maintenant sur l’interaction entre les composants de DomeScribe. Il agit comme un intermédiaire entre Slack, Bedrock et Notion.

1.) Selection des messages pertinents : après la résolution d’un incident, l’ingénieur d’astreinte invoque DomeScribe avec la commande /unroll dans Slack. Une fois l’appel reçu, le bot demande à l’ingénieur de sélectionner la liste des fils de discussion Slack pertinents. Dans la plupart des cas, un seul fil de discussion contiendra toutes les informations liées à un incident, mais DomeScribe permet également à l’utilisateur de sélectionner plusieurs fils ou messages.

2.) Récupération et amélioration des messages du fil de discussion : DomeScribe explore ensuite chaque fil Slack pour récupérer et formater le contenu de la conversation. Parfois, ces messages bruts manquent de contexte pertinent pour la création du post-mortem. Prenons l’exemple de la fonctionnalité de mention dans Slack : @quelqu’un. Lors de la récupération des messages, Slack ne renvoie pas le nom réel de la personne, mais un identifiant interne comme <@RAND_UUID>. Cet identifiant n’apporte aucune information utile au LLM et peut, dans certains cas, entraîner des hallucinations du modèle.

3.) Envoi à AWS Bedrock : une fois les messages affinés, nous ajoutons un prompt prédéfini avant de les envoyer à AWS Bedrock. Nous détaillerons ce prompt plus tard, mais son rôle est d’assurer que le LLM génère un post-mortem structuré et conforme à notre modèle.

4.) Création de la page Notion : enfin, le résultat fourni par AWS Bedrock est formaté et utilisé pour créer une entrée dans notre base de données Notion dédiée aux post-mortems.

Personnalisation du prompt et sélection du LLM

De manière surprenante, l’un des plus grands défis de DomeScribe a été l’ajustement du prompt et le choix du bon LLM. Dans cette section, nous allons détailler le processus qui a permis d’obtenir un post-mortem bien structuré et cohérent.

Tout d’abord, nous avons collecté des messages Slack issus d’incidents passés afin de tester et valider différents LLM et prompts avec des exemples pertinents. Nous avons sélectionné des incidents de complexité variable—certains simples, d’autres nécessitant une connaissance approfondie de notre infrastructure et de notre activité pour être bien compris.

Ensuite, nous avons conçu un prompt simple demandant au LLM de créer un post-mortem avec des sections spécifiques (introduction, chronologie, analyse des causes, etc.). Nous avons affiné ce prompt pour mieux orienter le LLM. Nous avons précisé qu’il devait se comporter comme un ingénieur SRE chargé de rédiger un post-mortem. Nous lui avons indiqué qu’il recevrait une liste de messages Slack liés à un incident et qu’il devrait formater le résultat en Markdown.

Nous avons associé nos exemples d’incidents à une première version du prompt et l’avons testé sur plusieurs Foundation Models d’AWS Bedrock. Après avoir évalué les résultats, nous avons choisi Llama 3.1 405B pour sa cohérence, sa capacité à traiter des informations complexes et son coût.

Nous avons rapidement constaté que le modèle avait du mal à générer certaines sections des post-mortems. Lors des incidents, les ingénieurs adoptent souvent une communication raccourcie, sous-entendant des détails sur notre infrastructure et notre activité. Comme le LLM s’appuie uniquement sur les messages Slack, ce manque de contexte a entraîné des incompréhensions et parfois des hallucinations.

En conséquence, le prompt a été mis à jour pour lui demander explicitement de rédiger trois sections :

• un résumé de l’incident en 5 phrases maximum ;
• une section sur l’impact client, incluant uniquement les détails mentionnés dans les messages, comme le nombre de clients affectés ou la durée de l’impact ;
• une chronologie détaillant l’incident, les actions menées par l’ingénieur d’astreinte, tout en ignorant les questions ou messages non pertinents.

En orientant le LLM vers ces trois sections, il a généré des post-mortems plus pertinents et exploitables.

Bien qu’imparfait en raison de sa connaissance limitée de notre activité, il constitue un excellent point de départ, qui permet de rédiger rapidement des post-mortems et de gérer les sections les plus chronophages.

Voici un exemple d’un des post-mortems qu’il a générés pour nous.

Gagnez du temps avec votre propre agent d’IA de gestion des incidents

Construire DomeScribe a été plus rapide et plus simple que prévu. Nous avions une solution prête pour la production en moins de deux jours. Grâce à EKS, ECR et Bedrock, l’infrastructure a été mise en place rapidement, ce qui nous a permis de nous concentrer sur l’ingénierie du prompt et l’affinage du modèle avec des tests en conditions réelles.

Le gain de temps pour nos ingénieurs est difficile à quantifier, mais ils peuvent désormais se concentrer sur les sections des post-mortems où leur valeur ajoutée est la plus forte.

Mieux encore : le coût est négligeable, ce qui fait de DomeScribe une solution efficace et pratique pour optimiser la rédaction des post-mortems.