Gains :
- Trouvez rapidement un signal dans le bruit en utilisant l'IA pour résumer, regrouper et chronométrer les journaux.
- Capacité à séparer la corrélation et la causalité et à traiter les suggestions de causes profondes de l'intelligence artificielle comme des hypothèses qui doivent être vérifiées
- Capacité à identifier la véritable cause profonde en appliquant la méthode des « 5 Pourquoi » avec l'intelligence artificielle et en appuyant chaque étape avec des preuves réelles.
Analyse des journaux et analyse des causes profondes : trouver le signal dans le bruit avec l'IA
Lorsqu'un système tombe en panne, le premier endroit où vous regardez, ce sont les journaux. Le journal est un flux de texte qui conserve un enregistrement horodaté de « ce que j'ai fait, ce qui s'est passé, ce qui s'est cassé » d'un système ou d'une application. Mais une infrastructure moderne produit des millions de lignes de journaux par heure ; ce n'est pas une mer d'informations, mais souvent un océan de bruit. L'analyse des logs est l'art de trouver le signal important (erreur, anomalie, modèle) dans ce bruit. Le processus consistant à répondre à la question « quelle était la véritable cause » après un événement est appelé analyse des causes profondes (RCA - Root Cause Analysis). Ici, l’IA est très puissante pour résumer des milliers de lignes par seconde, extraire des modèles, établir des délais et répertorier les causes possibles. Mais attention : l’IA génère des causes possibles ; C'est vous qui vérifiez dans le système lequel est réel et prenez la décision.
Dans cette unité, vous apprendrez comment résumer en toute confiance les journaux avec l'IA, comment établir une chronologie d'un événement, comment faire la différence entre la corrélation (qui change ensemble) et la causalité (l'une provoquant l'autre) et comment exécuter une méthode RCA telle que les « 5 Pourquoi » avec l'IA.
Pourquoi la corrélation n’est-elle pas la causalité ?
C'est le concept le plus critique de cette unité. Ce n’est pas parce que deux événements se produisent en même temps que l’un provoque l’autre. Le trafic CPU et réseau d'un serveur peut augmenter en même temps ; mais l'un n'est pas le résultat de l'autre, les deux peuvent être le résultat d'un troisième événement (par exemple, le démarrage d'un travail par lots). Lorsque l’IA voit les métriques changer ensemble, elle émet l’hypothèse « probablement que X a causé Y ». Ceci est un point de départ, pas une conclusion. Pour vérifier la causalité, vous devez soit isoler la variable (déclencher X dans l'environnement de test et voir si Y se produit), soit prouver le mécanisme (montrer les moyens techniques par lesquels X produit Y).
Attention : considérez la phrase de l'IA « cela a probablement causé cela » comme une hypothèse et non comme une découverte. En RCA, une cause première incorrecte entraîne une correction incorrecte et une récurrence de l'événement. Vous avez trouvé le premier suspect, pas la cause ; Le travail commence là.
Étape par étape : analyse des journaux avec l'IA
- Réduisez la portée. Donnez la fenêtre de l'événement, pas l'intégralité du journal : "l'événement a commencé à 14h05, critique de 14h00 à 14h20". Indiquez à l'IA le créneau horaire et le service concernés.
- Masque. Les journaux contiennent l'adresse IP interne, le nom d'hôte, l'utilisateur et le jeton. Masquez-les (10.x.x.x, hôte-A, utilisateur1, SUPPRIME) puis exportez-les.
- Demande de synthèse et de regroupement. "Regroupez ce journal par gravité, comptez les erreurs récurrentes, recherchez l'horodatage de la première erreur." Demandez la structure, pas le journal brut.
- Établissez un calendrier. "Organisez ces événements dans l'ordre chronologique et montrez ce qui suit." Trouver le premier domino est le chemin vers la cause profonde.
- Demandez des hypothèses, pas des preuves. "Énumérez les causes profondes possibles par ordre de probabilité et donnez-moi une commande de vérification à exécuter sur le système pour chacune." Demandez le diagnostic, pas le résultat.
- Vérifiez dans le système. Testez chaque hypothèse avec des commandes de diagnostic en lecture seule (log grep, requête d'état, métrique). Éliminez jusqu’à ce qu’il n’y ait qu’une seule cause fondamentale confirmée.
5 Pourquoi la méthode
L'outil classique et puissant de RCA est le « 5 Pourquoi » : en commençant par un symptôme et en demandant « pourquoi ? cinq fois. En posant la question, vous accédez à la cause profonde qui se cache sous le symptôme superficiel. Exemple : "Le site est tombé en panne. Pourquoi ? L'application est morte car elle manquait de mémoire. Pourquoi ? Une requête a consommé toute la mémoire. Pourquoi ? La requête n'a pas utilisé d'index. Pourquoi ? L'index a été supprimé dans la dernière version. Pourquoi ? Cela n'a pas été remarqué lors de l'examen des modifications." La cause première n'est pas le « site en panne » mais la « faiblesse du processus d'examen des modifications ». L’IA serait un bon partenaire dans la construction de cette chaîne – mais vous devez étayer chaque étape du « pourquoi » par des preuves réelles, sinon l’IA pourrait proposer une chaîne plausible mais fausse.
trois mini-cases
Cas 1 : 40 000 lignes, 3 minutes. Un administrateur avait commencé à analyser manuellement 40 000 lignes de journaux d’applications lors d’une panne nocturne. Il a donné la partie pertinente de 20 minutes du journal masqué à l'IA et a demandé un résumé et un regroupement. L'IA a signalé le premier bug OutOfMemory à 02h14, juste après l'augmentation des bugs de délai d'attente. L'ingénieur a reçu la feuille de temps en 3 minutes ; a confirmé le diagnostic initial sur son propre panel métrique.
Cas 2 — Revenir d'une mauvaise cause profonde. Une équipe a pensé que la première hypothèse de l'IA (« les journaux remplissaient le disque ») était correcte et a effacé les journaux. Mais l'incident s'est répété le lendemain. Au deuxième tour, ils ont mis en œuvre les « 5 pourquoi » avec discipline : la vraie raison était qu'une erreur d'application écrivait des centaines de core dumps par seconde. La première hypothèse était la corrélation ; La vraie raison était différente. L'acceptation sans vérification n'avait accordé qu'un sursis d'un jour.
Cas 3 – Timeline a trouvé le coupable. Il y avait des journaux de dizaines d'appareils lors d'une panne de réseau intermittente. L'ingénieur a donné les journaux masqués à l'IA et lui a demandé de créer une chronologie unifiée. Le graphique montre que chaque panne a commencé exactement 30 secondes après un message de vérification de l'état du commutateur de redondance. Cette corrélation était un indice fort ; L'équipe a vérifié l'erreur du micrologiciel de la clé sur l'appareil et l'a remplacée.
Quatre modèles copiables
1) Résumé et regroupement des journaux :
Vous trouverez ci-dessous le journal masqué pour [service] de 14h00 à 14h20. Dites-moi : (1) regroupez et comptez les lignes par gravité (ERREUR/AVERTISSEMENT/INFO), (2) répertoriez les 5 principaux modèles d'erreurs récurrentes, (3) recherchez l'horodatage de la première ERREUR. Ne réécrivez pas le journal brut, donnez simplement un résumé structuré. Ajout d'une ligne composée.Log : [journal masqué]
2) Mise en place d'un calendrier :
Nous avons organisé les enregistrements d'événements masqués suivants dans une seule chronologie (horodatage + source + événement). Montrez ce qui suit quoi et marquez l'événement qui semble être le premier déclencheur. Notez qu’il s’agit d’une HYPOTHÈSE et que la causalité doit être vérifiée. Enregistrements : [enregistrements masqués]
3) 5 raisons pour lesquelles RCA est partenaire :
Votre rôle : facilitateur RCA. Symptôme : [symptôme].Faites les « 5 pourquoi » avec moi : un « pourquoi ? » à chaque étape. Demandez, je répondrai avec les preuves dont je dispose, vous posez la question suivante. Si mes preuves sont faibles, prévenez-moi et dites-moi quelles données je dois collecter. Ne déclarez pas une cause profonde sans preuve.
4) Hypothèse + commande de vérification :
Énumérez les causes profondes possibles de ce symptôme [symptôme] par ordre de probabilité. Pour chaque raison : (a) que pensez-vous, (b) donnez-moi une commande de vérification en LECTURE SEULEMENT à exécuter sur mon système (pas de suppression/modification). Expliquez quel résultat confirme ou infirme l’hypothèse.
Invite faible/Invite forte
Invite faible :
Quel est le problème avec ce journal ? [10 000 lignes de journal brut]
Cette invite révèle à la fois des données sensibles et laisse l’IA sans contexte. L’IA peut tomber sur une ligne aléatoire et donner une raison superficielle, voire inventée.
Invite puissante :
Votre rôle : SRE senior. Événement : le service de paiement a donné une erreur de 50 % entre 02h10 et 02h25. Vous trouverez ci-dessous le journal masqué de cette fenêtre. Donnez-moi (1) le résumé regroupé par gravité, (2) l'horodatage de la première erreur, (3) les causes profondes possibles par ordre de probabilité et une commande de vérification en lecture seule pour chacune. Marquez les allégations de causalité comme des hypothèses. Journal : [journal masqué]
étape
Objectif
Rôle de l'IA
le rôle de l'homme
Résumé/regroupement
réduire le bruit
Configuration de milliers de lignes
Déterminer la portée et le masque
chronologie
Trouver le premier domino
tri des événements
Valider les tampons
génération d'hypothèses
trier les suspects
lister les possibilités
filtrer par contexte
vérification
trouver la vraie raison
Suggérer une commande de diagnostic
Exécutez la commande et commentez-la
décision
Choisir de réparer
proposer des options
Prendre la décision et confirmer
Erreurs courantes
- Confondre corrélation et causalité. Accepter deux mesures qui changent ensemble comme « l’une a causé l’autre » produit une fausse correction.
- Coller le journal brut sans masque. Donner le journal contenant l'IP, le jeton et l'utilisateur à un outil ouvert est une violation de la sécurité.
- Déclarer la première hypothèse comme cause profonde. Accepter la première suggestion de l’IA sans la vérifier est une invitation à répéter l’événement.
- Exportation de l'intégralité du journal. Un énorme journal sans contexte branche l'IA sur une ligne aléatoire ; Réduire à la fenêtre de l'événement.
- 5 raisons sans preuves. Si vous ne sauvegardez pas chaque étape du « pourquoi » avec des données réelles, vous vous retrouverez avec une chaîne plausible mais inventée.
Astuce : avant de mettre fin à une RCA, demandez : « si cette cause première est réellement corrigée, cela ne se reproduira-t-il pas ? » Posez la question. Si la réponse est « peut-être », vous n’avez pas encore trouvé la cause profonde ; Demandez un autre « pourquoi ».
En résumé
L'analyse des logs consiste à trouver le signal dans un océan de bruit ; L’IA résume et structure cet océan en quelques secondes, établit une chronologie et génère des hypothèses. Mais la corrélation n’est pas la causalité : la cause suggérée par l’IA est un soupçon initial, et non une découverte tant qu’elle n’est pas confirmée. Réduisez le journal dans la fenêtre d'événement, masquez-le, demandez une structure, approfondissez les « 5 pourquoi » et testez chaque hypothèse sur le système avec des commandes en lecture seule. C’est vous qui trouvez la cause première et confirmez le correctif ; L'IA est votre compagnon.
Tâche de candidature
Prenez les journaux d'un événement passé (ou d'un événement test), réduisez-le dans la fenêtre d'événement et masquez toutes les zones sensibles. Demandez un résumé et un calendrier à AI avec les modèles « Résumé du journal » et « Chronologie » ci-dessus. Passez ensuite du symptôme à la cause profonde avec le modèle « 5 Reasons RCA Partner » ; Écrivez vos propres preuves pour chaque étape. Enfin, testez l'hypothèse initiale de l'IA avec une commande de vérification et notez si elle est confirmée ou infirmée. Résumez le processus en 6 éléments.
liste de contrôle
- [ ] Ai-je réduit le journal dans la fenêtre d'événement et masqué les zones sensibles ?
- [ ] Ai-je demandé à l'IA un résumé structuré et une chronologie, pas un journal brut ?
- [ ] Ai-je marqué les allégations de causalité d'IA comme des hypothèses ?
- [ ] Ai-je testé chaque hypothèse sur le système avec une commande de vérification en lecture seule ?
- [ ] Ai-je étayé chaque étape des « 5 Pourquoi » avec des preuves réelles ?
- [ ] Est-ce que je me suis demandé et pris la décision si la cause profonde empêcherait réellement l'événement ?