Modèles de prompts pour déboguer des problèmes en production

Utilisez l’IA pour le débogage en production comme un flux de travail allant des preuves à la validation : collectez les faits, formulez des hypothèses, vérifiez-les, appliquez le plus petit correctif étayé et validez en toute sécurité. Ne demandez pas à un assistant de corriger un problème en direct à partir d’un symptôme vague et n’appliquez pas aveuglément le résultat.

Les modèles ci-dessous maintiennent l’enquête ancrée dans les faits. Retirez les secrets, jetons d’accès, données personnelles et identifiants de clients avant de partager des journaux ou des traces.

La séquence de débogage en production

preuves -> hypothèses -> vérification -> plus petit correctif -> validation

Chaque prompt doit inclure le comportement attendu, le comportement observé, l’environnement, les informations de reproduction, les modifications récentes pertinentes et la limite sûre du travail demandé.

Modèle : triage initial d’un incident

Nous devons enquêter sur un problème en production. Ne propose pas encore de
modification du code.

Symptômes : [Ce que montrent les utilisateurs ou la supervision.]
Comportement attendu : [Ce qui devrait se produire.]
Comportement observé : [Ce qui se produit réellement.]
Impact : [Personnes touchées, fréquence, gravité et solution de repli sûre si connue.]
Environnement : [Version, déploiement, navigateur/OS, région, flags de
fonctionnalité ou détails d’exécution.]
Modifications récentes : [Déploiements, migrations, configuration ou dépendances pertinents.]
Preuves : [Journaux nettoyés, erreurs, métriques, ID de trace, captures d’écran, commandes.]
Reproduction : [Étapes fiables, ou indique qu’elle est intermittente.]

Retourne :
1. une chronologie concise des faits confirmés ;
2. les principales hypothèses, classées par vraisemblance et impact ;
3. la prochaine observation ou étape de reproduction sûre pour chaque hypothèse ;
4. toute information manquante qui bloque matériellement le diagnostic.

Cela donne à un assistant assez d’éléments pour raisonner sans prétendre qu’il a accès à vos systèmes de production.

Modèle : reproduire avant de corriger

Tente de reproduire ce problème localement ou dans l’environnement hors
production approuvé.

Attendu : [Résultat attendu.]
Observé : [Résultat réel.]
Configuration : [Fixture, état du compte, commande, configuration ou données de test.]
Modification récente à examiner : [Commit, version ou changement de comportement.]

Ne modifie pas le code de production tant que l’échec n’est pas reproduit ou que
nous ne disposons pas d’une explication fondée sur des preuves expliquant pourquoi
la reproduction est impossible. Capture le plus petit test défaillant, la séquence
de journaux ou la sortie de commande qui distingue les hypothèses principales.

Si la reproduction est impossible, indiquez l’incertitude et recommandez une instrumentation sûre ou une décision de retour arrière, pas un correctif de code spéculatif.

Modèle : analyser des journaux nettoyés

Analyse ces journaux nettoyés pour un échec en production.

Contexte : [Service/fonctionnalité et flux de requête attendu.]
Fenêtre temporelle : [Début/fin et fuseau horaire.]
Comportement attendu : [Chemin de réussite attendu.]
Comportement observé : [Erreur ou comportement dégradé.]
Modifications récentes : [Modifications de déploiement/configuration/dépendances.]
Journaux : [Entrées nettoyées dans l’ordre chronologique.]

Sépare les faits des inférences. Corrèle les événements uniquement lorsque des
ID, horodatages ou preuves causales l’étayent. Liste les hypothèses plausibles,
le journal ou la métrique qui confirmerait chacune et la prochaine observation
présentant le risque le plus faible.

Ne laissez pas un assistant traiter des horodatages voisins comme une preuve de causalité.

Modèle : enquêter sur l’échec d’une commande ou d’un script

Enquête sur la raison de l’échec de cette commande de maintenance en production.

Commande : [Commande exacte dont les secrets ont été retirés.]
Sortie attendue : [Signal de réussite attendu.]
Sortie observée : [stderr/stdout nettoyés exacts et code de sortie.]
Environnement : [Shell, répertoire de travail, version de l’OS/de l’exécution, fichiers pertinents.]
Modifications récentes : [Modifications du script ou du déploiement.]

Explique d’abord ce que la commande fait réellement et identifie l’étape qui
échoue le plus tôt. Propose des commandes de diagnostic sûres qui ne modifient
pas les données. Ce n’est qu’après avoir compris l’échec que tu peux proposer le
plus petit correctif et la manière de le valider dans un environnement hors production.

Pour les échecs de terminal, l’entrée et la sortie exactes ont souvent plus de valeur qu’un résumé en prose.

Modèle : enquêter sur une régression de déploiement

Évalue si cette régression est liée au déploiement récent.

Référence : [Comportement/version avant le déploiement.]
Modification : [Version, flag, migration ou différence de configuration.]
Régression observée : [Personnes touchées et manière dont elles le sont.]
Preuves : [Métriques, journaux, traces, captures d’écran ou reproduction.]
Contraintes : ne modifie pas le déploiement et ne migre pas les données tant que
les preuves ne justifient pas une décision. Préserve le chemin de retour arrière.

Compare les chemins de référence et modifié. Identifie la plus petite expérience,
vérification de flag de fonctionnalité ou test hors production qui pourrait
confirmer la causalité. Recommande un retour arrière, une atténuation ou une
enquête sur le code avec le niveau de confiance et les compromis de chaque option.

La bonne réponse peut être un retour arrière ou un ajustement de flag de fonctionnalité, et non une modification du code.

Modèle : demander un correctif sûr

N’utilisez ce modèle qu’une fois qu’une cause est étayée par les preuves :

Cause confirmée : [Cause racine étayée par les preuves.]
Périmètre : [Fichiers, module ou configuration à modifier.]
Comportement à préserver : [Chemin de réussite existant, contrat public,
autorisations, données, locale, performances ou comportement de retour arrière.]

Propose le plus petit correctif. Inclus :
- pourquoi il traite la cause confirmée ;
- le test de régression ou la vérification reproductible ;
- la validation dans un environnement hors production approuvé ;
- les considérations de déploiement, de supervision et de retour arrière ;
- le comportement qui reste incertain.

N’inclus aucune refactorisation sans rapport dans cette modification.

Le prompt empêche qu’un incident réel devienne l’occasion d’une réécriture impossible à examiner.

Modèle : valider après le correctif

Valide le correctif par rapport à l’incident d’origine.

Vérifie :
1. la reproduction d’origine ou le test défaillant passe maintenant ;
2. le chemin de réussite normal reste inchangé ;
3. les chemins d’erreur et les cas limites pertinents continuent de se comporter
   en toute sécurité ;
4. les signaux de déploiement ou de supervision indiquent le rétablissement attendu ;
5. la condition de retour arrière reste disponible.

Signale les preuves de chaque vérification et nomme explicitement tout élément
non vérifié.

La validation doit répondre à la question initiale de l’incident, pas simplement confirmer qu’un nouveau chemin de code s’est exécuté.

Utilisez l’IA comme enquêteur rigoureux

L’IA peut aider à organiser les preuves, générer des hypothèses, expliquer du code inconnu et suggérer des tests. Elle ne peut pas remplacer le contrôle d’accès, la responsabilité de l’incident, les protections de production ni la revue humaine.

Commencez par comment écrire de meilleurs prompts d’IA pour la structure générale. Utilisez les erreurs des assistants de programmation IA et comment les éviter pour reconnaître les raccourcis dangereux et utilisez les modèles de prompts pour refactoriser du code seulement une fois l’incident compris.

Si les preuves comprennent des commandes shell, reproduisez le flux de travail en toute sécurité avant de le modifier. Exercez-vous à des scénarios de ligne de commande dans le navigateur afin de prendre l’habitude de vérifier les signaux d’entrée, de sortie et d’échec.