Ne vous arrêtez pas à la première panne.
La première panne que vous trouvez n'est presque jamais la seule. Notre méthode pour démêler un effondrement à causes multiples : classez les causes par contribution plutôt que par bruit, lisez les sources primaires au niveau du noyau plutôt que les tableaux de bord, retirez une panne à la fois, et traitez tout symptôme qui revient comme un diagnostic entièrement nouveau.
Dans cet article 6 sections
- Dans un effondrement à pannes multiples, plusieurs pannes portent le même symptôme en même temps. Corriger la plus bruyante ressemble à un progrès et ne change presque rien.
- La méthode : classez les causes par contribution, pas par bruit. Corrigez dans cet ordre. Mesurez à nouveau à la frontière qui a cédé après chaque changement.
- Quand une correction tient et que le symptôme revient, ne réappliquez pas la correction. Rediagnostiquez de zéro. Même symptôme ne veut pas dire même cause.
- La récupération a aussi un ordre : arrêtez d'abord le déclencheur immédiat, prouvez l'état avant toute action destructrice, gardez chaque étape réversible.
Votre site s'effondre. Quelqu'un trouve une panne plausible, la corrige et crie victoire. Le site reste à terre, ou revient et s'effondre de nouveau au déclencheur suivant. La correction s'est arrêtée à la première panne, et les pires jours il y en a quatre autres derrière. Voici la discipline qui ne s'arrête pas.
Règle un : classez par contribution, pas par bruit
Le symptôme le plus bruyant est une très mauvaise clé de tri. Exemple : le noyau hurle à la contention d'I/O disque, mais le moteur de la cascade est un resolver bloqué qui retient chaque worker, et le plus gros facteur persistant est une tempête de fichiers de session qu'aucune première théorie n'incluait. Classez les causes selon la part de l'effondrement qu'elles possèdent, et corrigez dans cet ordre.
- Contention d'I/O disque (le symptôme bruyant)
- Le job que tout le monde soupçonne
- Le resolver que personne ne soupçonne
- Le resolver : le moteur
- La tempête de sessions : le plus gros facteur
- Le job : réel, mais pas le facteur
Règle deux : lisez les sources primaires, pas les tableaux de bord
Les tableaux de bord résument. Les noyaux témoignent. Quand les couches ne sont pas d'accord, le noyau gagne. Le premier passage canonique sur n'importe quelle machine Linux bloquée est la même courte liste à chaque fois, puis une heuristique qui mérite d'être encadrée : de la marge disponible et un site à terre signifient une panne d'application ou de dépendance, pas de capacité. Un disque à une fraction de pour cent d'utilisation pendant que les workers pendent, c'est de la contention de verrous, pas de l'I/O, quoi que dise le graphique.
# the canonical first pass on a wedged Linux box
dmesg -T | tail -50 # OOM kills, hung tasks, hardware complaints
journalctl --list-boots # did this box reboot when you think it did?
last -x reboot | head # corroborate the reboot story
cat /etc/resolv.conf # who does this box think answers DNS?
iostat -x 5 3 # is the disk actually busy, or just blamed?
cat /proc/<pid>/stack # where exactly is that worker stuck?
strace -p <pid> -c -f # a few seconds: is it even making syscalls?Dix minutes de sources primaires valent mieux qu'un après-midi d'archéologie dans les tableaux de bord.
Règle trois : retirez une panne à la fois
Un changement, puis une nouvelle mesure à la frontière qui a cédé, avant de toucher la couche suivante. La discipline paraît lente et c'est la plus rapide qui existe, parce que deux changements simultanés qui interagissent ne vous apprennent rien sur aucun des deux. La vérification se fait par couche : corrigez le resolver, prouvez la résolution de noms sur la machine ; dissipez la tempête, prouvez l'état des workers ; puis remontez.
Règle quatre : méfiez-vous du moment « c'est corrigé »
Quand une correction tient et que le symptôme revient quelques heures plus tard, le réflexe est de réappliquer la correction plus fort. Mesurez à nouveau à la place. La question à poser est la plus simple : comment savez-vous que ça fait de l'I/O ? Quelques secondes de strace qui n'attrapent aucun appel système signifient que les workers sont bloqués dans le noyau sur un verrou, qu'ils ne font pas d'I/O du tout, et c'est ainsi qu'on trouve le vrai facteur au lieu de le masquer. Quand un symptôme revient après une vraie correction, c'est une autre panne qui porte les mêmes habits.
Règles cinq à sept : la récupération a aussi un ordre
Arrêtez le déclencheur immédiat avant de toucher à la cause.
Si c'est une interrogation de supervision qui fait tomber un cluster, arrêtez d'abord l'interrogation, reprenez position, retirez la cause, et seulement alors appliquez le changement prévu à un cluster sain.
Prouvez l'état avant toute action destructrice.
Un volume marqué corrompu reçoit une vérification d'intégrité en lecture seule avant que quiconque n'efface un drapeau ou ne se tourne vers une restauration. La récupération elle-même a ses pièges. Connaissez-les avant d'avancer.
Gardez chaque étape réversible.
Backup avant de toucher. Mettez de côté, ne supprimez pas. Rechargez, ne redémarrez pas, sous charge. Le geste de panique qui ne peut pas être annulé n'est jamais le bon geste.
Règle huit : fermez la brèche pour tout le monde
Chaque nouveau motif de défaillance devient une vérification préalable nommée dans la configuration de référence. La méthode n'est pas seulement la façon de démêler une mauvaise matinée. C'est la façon d'empêcher la même matinée de se répéter ailleurs.
Réponses directes
Pourquoi le problème de mon serveur revient-il après chaque correction ?+
Parce que l'incident a plus d'une cause et que chaque correction en a traité une. Quand une correction tient et que le symptôme revient, rediagnostiquez depuis les premiers principes. Même symptôme ne veut pas dire même cause.
Comment trouver la vraie cause racine d'une charge serveur élevée ?+
Les sources primaires d'abord : dmesg pour les OOM et les tâches bloquées, iostat pour vérifier si le disque est réellement occupé, une pile de processus ou quelques secondes de traçage pour voir où les workers sont coincés. Classez ce que vous trouvez par contribution à l'effondrement, pas par le bruit que cela fait.
Que signifie une charge élevée avec un disque inactif ?+
En général de la contention de verrous ou une dépendance bloquée, pas un manque de capacité. De la marge disponible pendant que le site est à terre pointe vers une panne d'application ou de dépendance, et ajouter des ressources ne change rien.
Dois-je redémarrer un service qui plante pour le réparer ?+
Pas tant que le déclencheur est encore actif. Si quelque chose le tue à répétition, un redémarrage rejoue le plantage. Arrêtez d'abord le déclencheur immédiat, puis retirez la cause, puis redémarrez dans un état sain.
Quelle est une bonne méthode de post-mortem d'incident ?+
Listez chaque panne contributrice, pas seulement la première. Classez par contribution. Notez l'indice qui a révélé chacune. Et transformez chaque brèche en vérification préalable permanente pour qu'elle ne puisse plus s'aligner. Si un post-mortem a exactement une cause pour un effondrement total, relisez-le deux fois.
Un second avis sur un incident tenace ?
S'il revient sans cesse, il a plus de causes que le dernier rapport n'en a trouvé. Apportez-nous l'historique des symptômes, nous apportons la méthode.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur