Enquête d'alerte

Tu enquêtes sur une alerte spécifique déclenchée. Les alertes arrivent avec un contexte structuré — un ID d'alerte, un nom, un seuil, une valeur qui l'a dépassé et un intervalle de temps. Ton travail consiste à expliquer pourquoi elle s'est déclenchée, à évaluer l'impact, et à recommander une action.

Prérequis

Cette compétence utilise les outils MCP d'observabilité LaunchDarkly suivants :

query-logs — interroger les enregistrements de journal
query-traces — interroger les traces distribuées
query-error-groups — interroger les groupes d'erreurs
query-sessions — interroger les sessions
query-aggregations — interroger les métriques agrégées/regroupées par intervalle de temps
get-keys — découvrir les clés d'attributs disponibles avant de filtrer

Flux de travail

Analyser le contexte d'alerte. Le premier tour de la conversation porte les variables d'alerte : alertID, alertName, alertValue, group, groupValue, query, thresholdWindow, timeRange, plus un lien spécifique au produit. Utilise-les, ne les re-dérive pas.
Charger le compagnon spécifique au produit. En fonction du type de produit de l'alerte, charge le compagnon correspondant : logs.md, traces.md, errors.md, sessions.md, ou metrics.md. Chacun capture la forme d'enquête spécifique au produit.
Mener l'enquête en utilisant la méthodologie de la compétence investigate (croiser journaux/traces/erreurs/sessions/métriques ; citer les identifiants ; agréger avant de paginer). Restreinte à l'intervalle de temps et au filtre de l'alerte.
Produire un diagnostic structuré. Voir le modèle de sortie ci-dessous.

Modèle de sortie

Les enquêtes d'alerte ont une structure cohérente pour que les consommateurs (canaux de notification, tableaux de bord) puissent les analyser.

## Ce qui s'est déclenché

<1-2 phrases nommant l'alerte, le seuil et la valeur qui l'a dépassé.>

## Cause probable

<Récit de cause racine citant des preuves spécifiques : IDs de trace, timestamps de journal, IDs de groupe d'erreurs, clés de flag, timing du déploiement.>

## Impact

<Qui ou quoi est affecté. Nombre d'utilisateurs, de services, de sessions, de groupes d'erreurs. Fenêtre de temps de l'impact.>

## Étapes suivantes

<1-3 actions concrètes que l'on-call ou le propriétaire devrait prendre. Préférer les spécificités : « annuler le flag X dans l'env Y », « redémarrer le service Z », « enquêter sur la trace <id> pour la défaillance en aval ». Éviter « enquêter davantage » — si tu n'as pas de cause racine, dis précisément ce qui doit être enquêté et comment.>

Quand charger quel compagnon

logs.md — alerte de journal, alerte de motif de journal
traces.md — alerte de latence, alerte de taux d'erreur de trace, alerte spécifique à un span
errors.md — alerte de taux d'erreur, alerte de nouveau groupe d'erreurs, alerte de taux de crash
sessions.md — alerte de santé de session, alerte de taux d'erreur pour l'utilisateur
metrics.md — seuil de métrique personnalisée, alerte de métrique agrégée, alerte composite

Si l'alerte traverse les frontières des produits (par ex. une alerte de métrique pilotée par des données d'erreur), charge les deux compagnons.

Directives

Reste concis. Les enquêtes d'alerte alimentent les notifications — garde la sortie structurée et facile à parcourir. Pas de préambule (« Voici mon analyse... »), pas de cadrage répété.
Cite les identifiants. Chaque affirmation du diagnostic doit référencer un ID de trace spécifique, un ID de groupe d'erreurs, un ID de session, ou un timestamp de journal.
Si l'alerte semble être du bruit, dis-le explicitement — « Cette alerte s'est déclenchée à cause de <X>, mais le comportement sous-jacent est dans la variance normale car <Y> ». Le bruit est un résultat légitime ; n'invente pas de causes racines.
Ne refais pas l'enquête que tu viens de faire. La sortie du diagnostic doit permettre à l'on-call d'agir sans refaire de requête.

alert-investigation