Debugging Production Issues at 2 AM: A Survival Guide [Français]

# Déboguer des problèmes de production à 2 heures du matin : un guide de survie 2:17 AM. PagerDuty. L'alerte dit 95 % de taux d'erreur sur le service de paiement. 847 transactions affectées. Votre estomac se noue. Vous êtes instantanément éveillé—ce type particulier d'adrénaline que seuls les incidents de production peuvent provoquer. Votre téléphone est déjà déverrouillé, l'ordinateur portable démarre, la machine à café commence à gargouiller par simple mémoire musculaire. C'est la page numéro 847 de votre carrière. Oui, vous faites le suivi. Vous avez commencé à compter après la page 200 lorsque vous vous êtes rendu compte que c'était une partie déterminante de votre vie professionnelle, et si vous alliez être réveillé à des heures indécentes, autant avoir des données à ce sujet. Le service de paiement. Bien sûr, c'est le service de paiement. C'est toujours le service de paiement, ou la couche d'authentification, ou ce microservice dont quelqu'un avait juré qu'il était "juste un simple wrapper" il y a trois ans et qui s'est depuis métastasé en une dépendance critique pour la moitié de votre infrastructure. Vous avez peut-être 90 secondes avant que la deuxième alerte ne soit envoyée à votre responsable. Peut-être trois minutes avant que les clients ne commencent à inonder les canaux de support. Peut-être cinq minutes avant que quelqu'un de la direction ne se réveille et commence à poser des questions sur Slack. Le temps passe, vos mains bougent, et votre cerveau parcourt déjà la liste de contrôle mentale que vous avez établie au fil de centaines de ces incidents. Ce n'est pas votre premier rodéo. Mais voici ce que personne ne vous dit sur le débogage en production à 2 heures du matin : cela ne devient jamais plus facile. Vous devenez juste plus rapide. Vous construisez de meilleurs outils. Vous commettez moins d'erreurs stupides. Vous apprenez à faire confiance à votre instinct tout en remettant tout en question. Vous développez un sixième sens pour ce qui est réellement cassé par rapport à ce qui semble juste être cassé. Et surtout, vous apprenez que la différence entre un incident de 10 minutes et un incident de 4 heures se joue souvent dans les 60 premières secondes de votre réponse. Ce guide est tout ce que j'aurais aimé que quelqu'un me dise avant la page numéro 1.

Les 60 premières secondes : triage comme si votre travail en dépendait

La première minute de tout incident de production est une gestion du chaos pur. Votre cerveau est encore en train de démarrer, vous ne portez probablement pas de pantalon, et vous devez prendre des décisions critiques qui détermineront si cet incident se résout en minutes ou en heures. Voici ce que je fais, dans l'ordre, à chaque fois : Accuser réception de l'alerte immédiatement. N'attendez pas pour "enquêter d'abord." Accusez réception. Cela arrête la chaîne d'escalade et signale à votre équipe que quelqu'un s'en occupe. J'ai vu trop d'incidents où plusieurs personnes ont été alertées parce que le premier répondant voulait "juste jeter un coup d'œil rapide" avant d'accuser réception. Ces 30 secondes d'enquête vous coûtent des répondants de secours qui auraient pu dormir. Ouvrez votre tableau de bord de réponse aux incidents. Pas l'application. Pas les journaux. Votre tableau de bord. Celui qui vous montre l'état du système en un coup d'œil. Pour moi, c'est un tableau Grafana personnalisé qui montre les taux d'erreur, les percentiles de latence, les pools de connexions de base de données, les profondeurs de queue et le CPU/mémoire à travers tous les services critiques. Je peux voir le rayon d'explosion en moins de 5 secondes. Vérifiez si cela se produit toujours. Cela semble évident, mais j'ai été alerté pour des problèmes qui se résolvaient 30 secondes avant que l'alerte ne se déclenche. Les systèmes de surveillance ont un délai. Les seuils d'alerte ont des fenêtres d'évaluation. Parfois, le problème est déjà résolu, et vous devez le savoir avant de commencer à annuler des déploiements ou à redémarrer des services. Évaluez l'impact sur les clients. Pas d'impact théorique—impact réel. Combien d'utilisateurs sont affectés en ce moment ? Est-ce 100 % du trafic ou 5 % ? Est-ce isolé à une région, un segment de clientèle, une fonctionnalité ? Cela détermine votre urgence de réponse et si vous devez réveiller plus de personnes. Dans cet incident particulier—le service de paiement à 2:17 AM—mon tableau de bord m'a dit tout ce que j'avais besoin de savoir en 8 secondes. Taux d'erreur : 94,7 %. Requêtes affectées : 847 au cours des 5 dernières minutes. Distribution géographique : mondiale. Segment de clientèle : tous. Latence API du fournisseur de paiement : normale. Connexions à la base de données : normales. Le problème n'était ni en amont ni en aval. C'était nous. C'est alors que j'ai su que la nuit serait longue.

La méthodologie de débogage qui fonctionne vraiment sous pression

Tout le monde a une méthodologie de débogage quand il est calme, caféiné, et en train de travailler sur un environnement de développement à 14 heures. Très peu de gens ont une méthodologie qui tient le coup quand vous êtes à moitié endormi, que le PDG est dans le canal d'incidents, et que chaque seconde d'indisponibilité coûte de l'argent réel. J'utilise ce que j'appelle l'approche "Rayon d'explosion à la cause profonde". Ce n'est pas sophistiqué, mais cela fonctionne quand votre cerveau tourne à 60 % de sa capacité. Commencez par le rayon d'explosion, pas la cause profonde. C'est contre-intuitif. Chaque instinct vous dit de trouver la cause profonde immédiatement. Résistez à cet instinct. D'abord, comprenez exactement ce qui est cassé et ce qui ne l'est pas. Tracez les limites de l'échec. Cela sert deux objectifs : cela vous évite de poursuivre de fausses pistes dans des systèmes sains, et cela pointe souvent directement vers la cause profonde grâce à un processus d'élimination. Pour l'incident du service de paiement, j'ai passé 90 secondes à cartographier le rayon d'explosion : - Initiation de paiement : échoue - Vérifications de statut de paiement : échouent - Webhooks de paiement : échouent - Traitement des remboursements : fonctionne bien - Requêtes administratives de paiement : fonctionnent bien Ce schéma m'a indiqué quelque chose d'important : les opérations de lecture allaient bien, les opérations d'écriture échouaient. C'est un problème de base de données, un problème de file d'attente, ou un problème d'autorisations. Trois possibilités au lieu de trente. Suivez le flux de données, pas le flux de code. Quand vous déboguez à 2 heures du matin, vous n'avez pas le temps de tracer à travers le code. Suivez les données. Où une demande de paiement entre-t-elle dans le système ? Où va-t-elle ensuite ? Où échoue-t-elle ? J'ai ouvert notre traçage distribué (merci d'avoir cela) et j'ai regardé une seule demande circuler dans le système. Elle est passée par l'authentification, la limitation des débits, la validation, et est morte au moment où elle a essayé d'écrire dans la base de données. Base de données. Voilà. Vérifiez d'abord les choses ennuyeuses. Espace disque. Mémoire. Pools de connexions. Descripteurs de fichiers. Expiration des certificats. DNS. Les choses ennuyeuses tuent plus de systèmes de production que des bugs astucieux ne le feront jamais. J'ai été alerté à 2 heures du matin parce que le cron d'une personne avait rempli le disque. J'ai été alerté parce qu'un certificat avait expiré. J'ai été alerté parce que quelqu'un a changé un TTL DNS et n'a pas attendu la propagation. Dans ce cas, le pool de connexions à la base de données était à 100 %. Chaque connexion était en cours d'utilisation. Mais pourquoi ? Le trafic n'avait pas augmenté. Les schémas de requêtes n'avaient pas changé. Quelque chose maintenait les connexions ouvertes. Faites confiance à votre surveillance, mais vérifiez tout. Les systèmes de surveillance mentent. Pas malicieusement—ce sont juste des logiciels, et les logiciels ont des bugs. J'ai vu des systèmes de surveillance signaler des services sains qui étaient complètement hors service. J'ai vu qu'ils signalaient des erreurs qui n'existaient pas. Vérifiez toujours manuellement le chemin critique. Pour les systèmes de paiement, je garde une carte de crédit de test et une commande curl prêtes à l'emploi. Je peux valider l'ensemble du flux de paiement en 10 secondes. J'ai exécuté mon paiement de test. Cela s'est bloqué pendant 30 secondes et a expiré. La surveillance ne mentait pas. Nous étions vraiment hors service.

L'incident qui m'a tout appris sur les connexions à la base de données

Laissez-moi vous parler de la page numéro 312. Il était 3:47 AM un mardi de mars, et cela a changé ma façon de penser à la gestion des connexions à la base de données pour toujours. Nous organisions une vente flash. Le trafic était élevé mais pas sans précédent—nous avions géré des pics plus importants. Puis soudainement, chaque service qui touchait la base de données a commencé à expirer. Pool de connexions épuisé. Symptômes classiques. La réponse évidente : augmenter la taille du pool de connexions. Alors nous l'avons fait. Nous l'avons doublé. Puis nous l'avons triplé. Le problème s'est aggravé. C'est alors que j'ai appris que parfois la solution aggrave le problème. Chaque connexion que nous avons ajoutée au pool était une autre connexion essayant d'exécuter une requête sur une base de données déjà surchargée. Nous étions en train de DDOS nos propres serveurs. Le véritable problème ? Un développeur avait ajouté une nouvelle fonctionnalité qui effectuait une analyse complète de la table sur une table de 50 millions de lignes. Aucun index. La requête a pris 45 secondes à terminer. Chaque requête qui touchait ce chemin de code maintenait une connexion à la base de données pendant 45 secondes. Avec suffisamment de trafic, nous avons épuisé le pool de connexions non pas parce que nous n'avions pas assez de connexions, mais parce que chaque connexion était bloquée en attente que cette terrible requête se termine. La solution n'était pas plus de connexions. C'était d'arrêter cette requête, d'ajouter un index, et de mettre en œuvre des délais d'attente pour les requêtes au niveau de l'application. Cet incident m'a appris trois choses : L'épuisement du pool de connexions est un symptôme, pas une maladie. Lorsque vous le voyez, ne réduisez pas immédiatement le pool. Demandez pourquoi les connexions ne sont pas libérées. Les requêtes sont-elles lentes ? Y a-t-il des blocages ? Quelque chose maintient-il les transactions ouvertes ? Le pool de connexions vous dit qu'il y a un problème ailleurs. Les délais d'attente des requêtes devraient être partout. Chaque requête de base de données devrait avoir un délai d'attente. Chaque requête HTTP devrait avoir un délai d'attente. Chaque opération de file d'attente devrait avoir un délai d'attente. Les délais d'attente ne sont pas optionnels. Ils font la différence entre un service dégradé et un service complètement hors service. Lorsque quelque chose ne va pas, les délais d'attente vous permettent d'échouer rapidement au lieu d'accumuler des connexions bloquées jusqu'à ce que l'ensemble du système s'effondre. Surveiller l'utilisation du pool de connexions n'est pas suffisant. Vous devez surveiller la durée de vie des connexions. Combien de temps la connexion moyenne est-elle maintenue ? Quel est le P99 ? Si la durée de vie de votre connexion moyenne passe soudainement de 50 ms à 5 secondes, vous avez un problème même si votre pool n'est pas encore épuisé. C'est votre système d'alerte précoce. Retour à l'incident du service de paiement à 2:17 AM. J'ai vérifié la durée de vie des connexions. Moyenne : 8 secondes. P99 :