Déboguer à 2h du mat : ce qui aide vraiment
Quand la prod est down et que ton cerveau tourne au ralenti, voici les outils et les habitudes qui te sauvent.
Il est 2h du mat. Ton téléphone vient de vibrer avec une alerte PagerDuty. Quelque chose est cassé en production. Ton cerveau tourne peut-être à 40% de sa capacité.
Ce n'est pas le moment pour du débogage malin. C'est le moment pour des techniques systématiques, ennuyeuses et fiables qui marchent même quand tu es à moitié endormi.
Voici ce que j'ai appris à force d'incidents nocturnes.
Étape 1 : Qu'est-ce qui a changé ?
90% des bugs en production sont causés par quelque chose qui a changé récemment. Un déploiement. Une mise à jour de config. Une migration de base de données. Un certificat expiré.
Avant de te plonger dans le code, trouve ce qui est différent par rapport à la dernière fois que ça marchait.
Compare la config actuelle avec la dernière version connue qui fonctionnait. Un outil de diff texte transforme ça en une opération de 10 secondes au lieu de loucher sur deux fichiers côte à côte.
Sérieusement. J'ai passé 45 minutes une fois à déboguer un échec d'API « mystérieux » qui s'est avéré être une virgule mal placée dans un fichier JSON de config. Un diff l'aurait repéré en quelques secondes.
Étape 2 : Lis l'erreur pour de vrai
Ça a l'air évident. Ça ne l'est pas.
Quand tu es fatigué, tu vois un message d'erreur et tu commences immédiatement à formuler des hypothèses. « Oh c'est sûrement la connexion à la base de données. » Tu passes 20 minutes à vérifier la base. Le message d'erreur disait TypeError: Cannot read property 'name' of undefined. Rien à voir avec la base de données.
Lis l'erreur. Relis-la. Lis la stack trace. Suis-la jusqu'à la ligne de code exacte.
Étape 3 : Rends l'erreur lisible
Les logs de production sont un bazar. Tout est sur une seule ligne, les objets JSON ne sont pas formatés, les timestamps sont en format epoch Unix.
Copie ce blob de JSON, colle-le dans un formateur JSON, et d'un coup tu peux vraiment lire la réponse d'erreur.
Je garde un onglet formateur ouvert en permanence. Pendant les incidents, je l'utilise toutes les quelques minutes pour décrypter les réponses d'API, les entrées de logs et les fichiers de config.
Étape 4 : Isole, ne devine pas
Les cerveaux fatigués adorent deviner. « Peut-être que c'est ça. Et si j'essayais de changer ça. »
Résiste. Chaque changement aléatoire que tu fais ajoute de l'incertitude. Maintenant tu ne sais plus si le problème initial est résolu ou si ton correctif a introduit un nouveau problème.
À la place : reproduis l'erreur avec la plus petite entrée possible. Élimine tout ce qui n'est pas nécessaire. Trouve la variable qui compte.
Étape 5 : Vérifie les trucs basiques
Avant de plonger dans le code, vérifie :
- DNS : est-ce que ça résout correctement ?
- Certificats : est-ce qu'un a expiré ?
- Espace disque : est-ce que le serveur est plein ?
- Mémoire : est-ce que quelque chose fuit ?
- Dépendances : est-ce qu'une API externe est down ?
J'ai un post-it sur mon écran avec ces cinq points. Pendant un incident, je les vérifie en premier. Ils ont été la cause racine plus souvent que de vrais bugs dans le code.
La boîte à outils du débogage à 2h du mat
Ce sont les onglets de navigateur que j'ouvre quand une alerte me réveille :
- Diff texte — pour comparer les configs, les variables d'environnement, les fichiers de déploiement
- Formateur JSON — pour lire les réponses d'API et les entrées de logs
- Testeur regex — pour chercher dans les logs avec des patterns
- Un éditeur de texte simple — pour noter ce que j'ai essayé
Ce dernier point compte plus que tu ne le penses. À 2h du mat, ta mémoire à court terme est nulle. Note ce que tu as essayé et ce qui s'est passé. Le toi du futur remerciera le toi du passé.
Après l'incident
Une fois que le feu est éteint, ne te rendors pas directement. Passe cinq minutes à noter :
- Ce qui a cassé
- Pourquoi ça a cassé
- Ce qui l'a réparé
- Comment l'éviter la prochaine fois
Tu ne t'en souviendras pas demain. Note-le maintenant.
Le meilleur débogage à 2h du mat n'est pas une question d'intelligence. C'est une question de méthode. Compare la config. Lis l'erreur. Formate les logs. Vérifie les trucs basiques. Note tout. C'est tout le playbook.