L’ère du bouton reset : la réparation la plus honnête en informatique

Pourquoi les réinitialisations semblent honnêtes (et pourquoi elles sont aussi un mensonge)

Une réinitialisation est une rupture nette dans la causalité. Vous cessez d’essayer de négocier avec un runtime corrompu et vous repartez à zéro avec des chemins d’initialisation réputés sains : boot du noyau, initialisation des pilotes, démarrage des services, chargement des configs, réchauffement des caches. Pour une vaste catégorie de pannes — fuites, interblocages, I/O bloquées, pilotes coincés — l’initialisation est le seul chemin de code qui a été testé des milliers de fois.

C’est la partie honnête. La partie malhonnête est qu’une réinitialisation détruit souvent des preuves. Elle nettoie la scène de crime, jette les traces de pile et remet à zéro des compteurs qui vous disaient exactement à quel point les choses empirent.

Alors traitez le reset comme vous traiteriez un analgésique après une blessure. Utilisez-le pour fonctionner, oui. Mais si vous continuez à en prendre sans diagnostic, vous n’êtes pas « coriace », vous êtes simplement aveugle.

Voici la vérité opérationnelle : le reset est une atténuation valide. Il achète du temps. Il réduit le rayon d’impact. Il ramène vos clients. Mais si c’est votre unique action, vous finirez par avoir un système qui « a besoin » de réinitialisations comme une usine victorienne a besoin de travail d’enfants : ça marche, mais ce n’est pas un plan.

Blague n°1 : Un reboot est les excuses les plus sincères qu’un ordinateur puisse offrir : il ne peut pas expliquer ce qui s’est passé, mais il promet d’aller mieux.

Quand un reset est le bon choix

• Violation d’un SLO en cours et vous avez une procédure de rollback ou de redémarrage connue et saine.
• L’état est déjà suspect (erreurs de système de fichiers, avertissements noyau, resets de NIC, signaux de corruption de l’allocateur).
• Vous ne pouvez pas reproduire sous observation et avez besoin d’une baseline stable pour collecter de meilleures données la prochaine fois.
• Confinement du rayon d’impact : isoler un nœud, dérouter la charge, redémarrer, le réintégrer.

Quand un reset est de la mauvaise pratique

• Vous n’avez pas capturé les éléments forensiques de base (logs, dmesg, principaux coupables) et vous êtes sur le point de les effacer.
• Un reboot déclenchera une reconstruction (RAID, ZFS resilver, récupération de base de données) qui augmente le risque.
• Le problème est clairement externe (dépendance en amont en panne, partition réseau, certificat expiré). Un reboot ne change rien.
• Vous utilisez le reboot pour éviter d’admettre que vous manquez d’observabilité.

Il y a une idée paraphrasée de Werner Vogels (CTO d’Amazon) qui devrait figurer sur le mur de chaque équipe ops : on construit pour la panne, parce que tout échoue un jour. L’ère du bouton reset, c’est ce qui arrive quand vous acceptez cette phrase littéralement et l’opérationnalisez : les pannes auront lieu ; la question est de savoir si vos réinitialisations sont contrôlées et informatives — ou chaotiques et oublieuses.

Faits et histoire : comment on en est arrivés là

Les réinitialisations ne sont pas une faute morale ; elles sont une conséquence de la complexité. Quelques points concrets qui expliquent pourquoi le redémarrage est resté pertinent pendant des décennies :

1. Les micro-ordinateurs précoces ont normalisé les resets matériels. Beaucoup de systèmes domestiques encourageaient la coupure d’alimentation comme récupération de routine parce que l’état persistant et le journal n’étaient pas la norme.
2. Le « salut à trois doigts » est devenu une mémoire musculaire culturelle. Les resets clavier sur les premiers PC ont fait du « reset » un correctif accessible à l’utilisateur, pas seulement aux ingénieurs.
3. Les timers watchdog existaient bien avant le cloud. Les systèmes embarqués utilisaient des watchdogs matériels pour redémarrer automatiquement quand le logiciel cessait de « caresser le chien ».
4. Les systèmes de fichiers avec journalisation ont réduit — mais pas éliminé — la douleur du reset. Ils ont rendu la récupération après crash plus rapide et plus sûre, ce qui paradoxalement a rendu les resets plus acceptables en production.
5. La virtualisation a rendu le reboot moins coûteux. Quand un « serveur » est une VM, le redémarrage paraît moins dramatique que de pousser un chariot physique dans une allée de datacenter.
6. Les conteneurs ont remis le redémarrage dans la norme. Un restart de pod est un événement prévu ; les orchestrateurs traitent les processus comme jetables.
7. Les systèmes modernes dépendent de caches partout. Caches DNS, page cache, pools de connexions, caches JIT, tables de routage. Les resets les vident — parfois en améliorant les choses, parfois en provoquant un thundering herd.
8. Les mises à jour firmware et microcode ont brouillé la frontière entre « correctif logiciel » et « reboot requis ». Un patch de sécurité peut nécessiter un reboot car la poignée main entre noyau et matériel a changé.
9. Les piles de stockage sont devenues multilayer. Firmware RAID/HBA, multipath, système de fichiers, gestionnaire de volumes, chiffrement, application. Un reset peut débloquer une couche ; il faut identifier laquelle.

Remarquez le schéma : les resets sont devenus plus faciles, et le fait qu’ils soient « faciles » a changé la culture. Le danger, c’est que la facilité devienne défaut, et le défaut devienne doctrine.

Ce qu’une réinitialisation change réellement : couches, caches, état et temps

1) Mémoire des processus et état de l’allocateur

La plupart des histoires « le reboot a résolu » sont en réalité des « nouvel espace d’adressage a résolu ». Fuites mémoire, fragmentation, contention d’allocateur, threads incontrôlables, fuites de descripteurs — le redémarrage nettoie tout cela, au prix de ne jamais prouver lequel était responsable.

2) État du noyau et des pilotes

Les bugs noyau sont rares jusqu’à ce qu’ils ne le soient plus. Un reboot remet à zéro les structures noyau : tables de pages, files d’attente du scheduler, état TCP, machines d’état des pilotes. Si un pilote s’est coincé — courant avec les NIC, HBA, GPU et certains périphériques virtuels — un reboot est une méthode brutale mais efficace pour forcer la réinitialisation.

3) Caches de stockage et files d’I/O

Le stockage a deux types d’état : état des données (sur disque) et état opérationnel (en vol). Un reset efface l’état opérationnel : I/O en attente, profondeurs de file, décisions multipath, contrôle de congestion. Cela peut « réparer » une spirale de latence, mais aussi déclencher une reconstruction, un rescannage ou un failover de contrôleur au pire moment.

4) Sessions réseau et affinité des load balancers

Les reboots rompent les connexions TCP, remettent à zéro les tables conntrack et forcent les clients à se reconnecter. Dans un système sain, c’est acceptable. Dans un système fragile, cela devient une tempête de reconnexions synchronisées qui ressemble à un DDoS auto-infligé.

5) Le temps : la dépendance silencieuse

Beaucoup de bugs dépendent du temps : expiration de certificats, logique de rafraîchissement de tokens, cron jobs, rotation des logs, compteurs atteignant un seuil, safepoints JVM sous pression du heap. Un reboot peut « résoudre » le symptôme en remettant à zéro horloges et compteurs en espace utilisateur, tandis que la condition d’expiration sous-jacente continue sa course vers la prochaine falaise.

Redémarrage vs reboot vs coupure d’alimentation : choisissez le plus petit marteau qui fonctionne

Redémarrage de service

À utiliser quand la panne semble confinée à un seul processus ou un petit ensemble de daemons. Exemples : fuite mémoire dans un service, pool de workers bloqué, file interne coincée, rechargement de config raté. Un restart préserve l’état noyau, évite le rescannage du stockage et est plus rapide à revenir en arrière.

Reboot du nœud

À utiliser quand le noyau ou les couches matérielles semblent suspectes : resets récurrents de pilotes, processus inkillable en état D, blocages I/O de système de fichiers, NIC instables, dérive d’horloge sévère, ou besoin d’appliquer une mise à jour du noyau.

Coupure d’alimentation (hard reset)

À utiliser quand le système ne répond pas à un reboot propre, ou que le management plane montre du matériel bloqué (événements BMC, problèmes PCIe, HBA verrouillé). C’est l’option « il faut arrêter et redémarrer les électrons ». Parfois nécessaire. Jamais douce.

Blague n°2 : La coupure d’alimentation, c’est comme éteindre et rallumer votre collègue — efficace, mais les RH voudraient un post-mortem.

Une règle de décision qui fonctionne sous pression

Commencez en haut de la pile et descendez seulement si les preuves vous y poussent :

• Si un service se comporte mal : redémarrez le service.
• Si beaucoup de services se comportent mal sur un nœud : redémarrez le nœud (après évacuation si possible).
• Si le nœud ne peut pas redémarrer ou que le matériel est bloqué : power-cycle.

Et quel que soit votre choix : capturez suffisamment de preuves pour rendre le prochain incident plus court.

Plan de diagnostic rapide : trouvez le goulot d’étranglement avant de « réparer »

Voici l’ordre de triage qui fonctionne quand le pager hurle et que vous avez cinq minutes pour être utile. Le but n’est pas d’être brillant. Le but est d’arrêter de deviner.

Première étape : un seul hôte, un service ou toute la flotte ?

• Vérifiez si le symptôme se corrèle avec un nœud, une zone de disponibilité/rack, un déploiement ou une dépendance.
• Si plusieurs nœuds présentent des symptômes identiques simultanément, les reboots sont souvent du bruit. Cherchez des dépendances partagées (DNS, auth, backend de stockage, réseau).

Deuxième étape : CPU, mémoire, I/O ou réseau ?

• Limitation CPU : charge élevée, file d’exécution élevée, faible iowait, top montre threads brûlants.
• Pression mémoire : activité swap, stalls de reclaim, OOM kills, RSS en croissance.
• Limitation I/O : iowait élevé, latence disque en hausse, tâches bloquées, avertissements système de fichiers.
• Limitation réseau : retransmissions, pertes, saturation conntrack, timeouts DNS.

Troisième étape : signaux noyau et matériel

• dmesg/journal montre resets de périphérique, lien down/up, erreurs de système de fichiers, tâches hung.
• Erreurs SMART, dégradation de pool ZFS, multipath qui fluctue.

Quatrième étape : choisissez la plus petite atténuation qui restaure le service

• Redémarrez un service si le nœud semble sain.
• Évacuez et redémarrez si l’état au niveau nœud est suspect.
• Basculez si le chemin stockage/réseau est instable.

Cinquième étape : après stabilisation, transformez l’atténuation en diagnostic

• Notez ce qui a changé après le reset : latence, taux d’erreurs, compteurs noyau, ratios de hit cache.
• Formulez une hypothèse que vous pourrez tester avant le prochain incident.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les commandes « avant le reboot » et « juste après le reboot » que je veux réellement voir dans une checklist d’incident. Chaque item inclut ce que la sortie signifie et la décision que vous en tirez.

1) Uptime et charge : sommes-nous dans une lente agonie ou une panne soudaine ?

cr0x@server:~$ uptime
 14:22:10 up 87 days,  3:41,  2 users,  load average: 18.44, 17.90, 16.72

Signification : 87 jours d’uptime ; les moyennes de charge sont élevées et persistantes (pas un pic court).

Décision : Si c’est un seul nœud et que la charge est anormale, séparez CPU vs I/O. Ne redémarrez pas encore ; collectez pourquoi la charge est élevée.

2) Snapshot de top : CPU vs iowait vs process runaway

cr0x@server:~$ top -b -n 1 | head -n 20
top - 14:22:25 up 87 days,  3:41,  2 users,  load average: 18.44, 17.90, 16.72
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.3 us,  2.1 sy,  0.0 ni, 21.7 id, 67.6 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  64049.2 total,   1800.5 free,  51221.4 used,  11027.3 buff/cache
MiB Swap:   8192.0 total,   8120.0 free,     72.0 used.  10341.8 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
18342 postgres  20   0 12.1g  9.2g  9120 S  120.0  14.7  36:12.44 postgres

Signification : l’iowait est énorme (67.6% wa). Le CPU attend surtout le disque, il ne fait pas de travail utile.

Décision : Ne redémarrez pas une base de données parce qu’elle attend le disque ; trouvez d’abord le goulot de stockage. Un reboot peut aggraver le temps de récupération et provoquer des tempêtes I/O.

3) Identifier les tâches bloquées (le piège classique « reboot règle ça »)

cr0x@server:~$ ps -eo pid,state,comm,wchan:32 | awk '$2 ~ /^D/ {print}'
21991 D kworker/u96:2      nvme_poll
18342 D postgres           io_schedule

Signification : Processus en sommeil non interruptible (état D), en attente de chemins I/O.

Décision : Le restart d’un service ne suffira pas. Investiguer le stockage/NVMe/HBA/multipath. Si le chemin I/O est bloqué et que vous pouvez basculer, faites-le ; sinon planifiez un reboot après avoir capturé des preuves.

4) Messages noyau pour stockage ou resets de pilotes

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Jan 21 13:58:12 2026] nvme nvme0: I/O 47 QID 4 timeout, aborting
[Mon Jan 21 13:58:12 2026] nvme nvme0: Abort status: 0x371
[Mon Jan 21 13:58:13 2026] nvme nvme0: resetting controller
[Mon Jan 21 13:58:18 2026] nvme nvme0: failed to set APST feature (-19)

Signification : Timeouts NVMe et resets de contrôleur ; le noyau indique que le périphérique est peu fiable.

Décision : Un reboot peut récupérer temporairement le périphérique, mais traitez cela comme un travail matériel/firmware/pilote. Planifiez remplacement ou mise à jour firmware ; ne normalisez pas des « siestes NVMe » hebdomadaires.

5) Latence disque et saturation avec iostat

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0-21-generic (server) 	01/21/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          7.89    0.00    2.34   66.85    0.00   22.92

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         12.0   420.0   512.0  8752.0     43.1    198.4   451.2     9.8   462.5    2.1  99.7

Signification : %util ~99.7 et await ~451ms : le périphérique est saturé et la latence est catastrophique.

Décision : Cessez d’incriminer l’application. Réduisez la charge d’écriture, déplacez les données chaudes, ou ajoutez de la capacité IOPS. Le reboot ne changera pas la physique.

6) Trouver quels systèmes de fichiers sont pleins (le mythe ancien « reboot règle ça »)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  220G  219G  1.2G 100% /
tmpfs            32G  1.2G   31G   4% /run

Signification : Le système de fichiers racine est pratiquement plein. Beaucoup de services échouent de façon étrange quand ils ne peuvent pas écrire des logs ou des fichiers temporaires.

Décision : Libérez de l’espace immédiatement (logs, core dumps, anciens artefacts). Un reboot ne créera pas d’espace disque ; il peut simplement retarder les écritures jusqu’à ce que ça empire.

7) Identifier rapidement les gros répertoires

cr0x@server:~$ sudo du -xhd1 /var | sort -h | tail -n 10
1.1G	/var/cache
2.9G	/var/lib
4.8G	/var/crash
58G	/var/log

Signification : /var/log est massif ; /var/crash indique des crashes répétés ou des core dumps.

Décision : Faites une rotation / compression des logs, externalisez-les, corrigez la boucle de crash. Envisagez de limiter les core dumps. Ne redémarrez pas tant que la croissance n’est pas arrêtée.

8) Vérification de la pression mémoire : le noyau se recycle-t-il jusqu’à la mort ?

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           64049       59721         811         922        3516        1920
Swap:           8192        6130        2062

Signification : Peu de mémoire disponible et utilisation significative du swap. La machine est probablement en thrash.

Décision : Si un service particulier a gonflé, redémarrez ce service. Si c’est systémique (beaucoup de processus, caches noyau qui ne se recyclent pas, fragmentation), planifiez un reboot mais capturez d’abord les processus coupables.

9) Qui consomme la mémoire en ce moment ?

cr0x@server:~$ ps -eo pid,comm,rss --sort=-rss | head -n 10
  PID COMMAND           RSS
18342 postgres      9654320
22107 java          8421000
 9821 node          1320040

Signification : Quelques processus dominent la mémoire. C’est une bonne nouvelle : un redémarrage ciblé peut suffire sans reboot.

Décision : Redémarrez ou recyclez le principal coupable après avoir confirmé qu’il peut être redémarré en toute sécurité (HA, redémarrage progressif, évacuation).

10) Santé des services systemd et échecs récents

cr0x@server:~$ systemctl --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● app-worker.service   loaded failed failed Background worker
● nginx.service        loaded failed failed A high performance web server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Signification : Des services spécifiques sont en échec ; ce n’est pas nécessairement une panne du nœud.

Décision : Essayez de redémarrer le service et inspectez les logs. Si les échecs sont dus à disque plein, DNS ou config, le reboot est hors sujet.

11) Logs journal autour de la fenêtre de panne

cr0x@server:~$ sudo journalctl -u nginx.service -S "10 minutes ago" --no-pager | tail -n 20
Jan 21 14:13:41 server nginx[29110]: nginx: [emerg] open() "/var/log/nginx/access.log" failed (28: No space left on device)
Jan 21 14:13:41 server systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE

Signification : Échec explicite : plus d’espace disque disponible.

Décision : Libérez de l’espace disque, puis redémarrez nginx. Rebooter serait une perte de temps et échouerait probablement à nouveau.

12) Pertes et erreurs réseau (compteurs d’interface)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  12345678  0       48219    0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  11223344  0       0        0       0

Signification : Les drops en RX sont élevés. Cela peut indiquer des problèmes de pilote, des limites de ring buffer ou une congestion en amont.

Décision : Inspectez les réglages d’offload NIC, la taille des buffers, la contention CPU de l’hôte ou la congestion sur le switch en amont. Le reboot peut remettre à zéro des compteurs et « réparer » temporairement un pilote bloqué, mais vous avez besoin de causalité.

13) Sanity check DNS (vérification rapide pour « tout est cassé »)

cr0x@server:~$ resolvectl query api.internal
api.internal: resolve call failed: Timeout was reached

Signification : Timeouts DNS. Cela se déguise souvent en panne applicative à large échelle.

Décision : Ne redémarrez pas le monde. Corrigez le DNS ou le chemin du resolver. Envisagez un resolver local en cache ou des resolvers de secours.

14) Santé du système de fichiers : erreurs ext4 visibles dans les logs

cr0x@server:~$ sudo dmesg -T | grep -E "EXT4-fs error|I/O error|Buffer I/O" | tail -n 5
[Mon Jan 21 14:01:12 2026] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1587: inode #131081: comm nginx: reading directory lblock 0
[Mon Jan 21 14:01:12 2026] Buffer I/O error on dev nvme0n1p2, logical block 9123456, lost async page write

Signification : Erreurs réelles de système de fichiers et I/O. Ce n’est pas un bug applicatif.

Décision : Traitez comme un incident de stockage. Réduisez les écritures, basculez, planifiez une maintenance. Un reboot peut aggraver le risque de corruption si le matériel est défaillant.

15) État du pool ZFS (si vous utilisez ZFS, vous devez regarder)

cr0x@server:~$ sudo zpool status -x
pool 'tank' is degraded
One or more devices could not be used because the label is missing or invalid.

Signification : Pool dégradé ; la redondance est réduite.

Décision : Ne redémarrez pas à la légère. Un reboot peut déclencher un resilvering et des pics I/O. Remplacez/réparez le périphérique manquant d’abord, ou planifiez une fenêtre de maintenance contrôlée avec limites I/O claires.

16) Multipath qui fluctue (les environnements SAN aiment « guérir » après un reboot)

cr0x@server:~$ sudo multipath -ll | head -n 25
mpatha (3600508b400105e210000900000490000) dm-2 DELL,MD36xxi
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Signification : Des chemins existent avec différentes priorités (ALUA). Si vous voyez « failed faulty running » ou des chemins qui basculent, vous avez un problème de fabric/contrôleur.

Décision : Engagez l’équipe stockage/réseau ; ne masquez pas avec des reboots. Si queue_if_no_path est actif, vous pouvez accumuler latence jusqu’à ce que tout expire.

17) Avant le reboot : capturez un bundle d’incident léger

cr0x@server:~$ sudo sh -c 'date; uname -a; uptime; free -m; df -h; dmesg -T | tail -n 200' > /var/tmp/pre-reboot-triage.txt

Signification : Vous avez préservé l’état de base que le reboot effacera (surtout la queue dmesg et les snapshots de ressources).

Décision : Si vous devez redémarrer, faites-le après avoir sauvegardé ce fichier quelque part durable (logs centraux, pièce jointe du ticket, scp vers une bastion).

Trois mini-récits d’entreprise de l’ère du bouton reset

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’équipe avait un cluster de serveurs applicatifs derrière un load balancer. Chaque nœud disposait d’un NVMe local pour cache éphémère, et le système de référence réel était une base de données distante. Le modèle mental était : « le disque local n’est qu’un cache ; s’il meurt, on le redémarre et il revient. »

Un après-midi, le taux d’erreur a augmenté en ligne diagonale propre. La latence augmentait, mais seulement pour un sous-ensemble de requêtes. L’on-call a redémarré le service applicatif. Aucun changement. Ils ont rebooté un nœud. Ce nœud est revenu rapidement et a semblé sain pendant cinq minutes, puis s’est de nouveau dégradé. Ils ont rebooté deux autres nœuds. Même histoire, mais avec plus de thrash visible par les clients.

L’hypothèse erronée était subtile : le NVMe local n’était pas simplement un cache. Il contenait une spool en write-ahead pour événements sortants, conçue pour survivre aux redémarrages de processus et aux courts problèmes réseau. Le reboot a effacé la spool parce qu’elle était sur un mount tmpfs « temporaire par conception ». En pratique, c’était temporaire par accident.

Quand le collecteur d’événements en amont a ralenti, la spool s’est remplie et l’application a appliqué de la backpressure. C’était le comportement correct. Mais le reboot a effacé la spool et créé l’illusion d’une récupération — jusqu’à ce que le chemin lent amont la remplisse à nouveau. Entre-temps, la spool effacée signifiait des événements perdus, ce qui a déclenché des retries compensatoires plus tard et allongé la queue de l’incident.

Ils ont corrigé cela en déplaçant la spool sur un stockage persistant (avec politiques de cycle de vie explicites), en ajoutant des alertes sur la profondeur de spool et en modifiant les runbooks : « ne jamais redémarrer pour vider la backpressure sauf si vous acceptez la perte de données. » Le bouton reset n’a pas causé le goulot. Il a juste rendu le goulot malhonnête.

Mini-récit 2 : L’optimisation qui a mal tourné

Un groupe plateforme a décidé de réduire le temps de reboot d’une flotte de nœuds. Des reboots plus rapides signifiaient des patchs plus rapides, des évacuations plus rapides et moins de risque d’indisponibilité. Ils ont donc optimisé le boot : parallélisé le démarrage, réduit la journalisation, allégé les « checks lents » et désactivé un scan de stockage qui « ne trouvait jamais rien ».

Pendant des semaines, cela a semblé être un gain. Les reboots sont passés de minutes à moins d’une minute. Les fenêtres de changement se sont raccourcies. Les gens ont moins redouté les upgrades du noyau. Le bouton reset est devenu plus sûr, donc il a été utilisé davantage.

Puis un nœud a redémarré pendant un patch routinier et est revenu avec un miroir de stockage dégradé. Personne ne l’a remarqué parce que le scan qui aurait alerté était désactivé. Le nœud a rejoint le pool et a repris la charge. Sous charge, le disque restant a commencé à produire des erreurs intermittentes. La couche applicative a vu des timeouts et a relancé. Les relances ont créé plus de charge. Boucle de rétroaction positive classique.

Au moment où quelqu’un a vérifié la santé du stockage, le nœud était dans une spirale d’échec : la gestion d’erreur générait plus d’I/O que le succès. Ils l’ont retiré de la rotation et enfin examiné l’historique matériel. Le scan « lent » détectait des signes précoces de défaillance de disque. Ils avaient troqué la fiabilité contre un meilleur temps au chronomètre.

La correction n’était pas d’abandonner l’optimisation ; c’était de comprendre ce qu’ils avaient retiré. Ils ont rétabli les checks de santé, les ont rendus asynchrones quand possible, et ont conditionné l’admission d’un nœud au cluster à leur réussite. Un reboot rapide est bien. Un reboot rapide vers un stockage cassé est juste une façon plus rapide de se blesser.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre entreprise, une culture différente. L’équipe plateforme avait un rituel qu’ils appelaient « snapshots pré-mortem ». Ce n’était pas sophistiqué : avant toute atténuation disruptive (reboot, failover, restart en rolling), ils exécutaient un petit ensemble de commandes et joignaient la sortie au ticket d’incident.

Pendant un incident, un nœud a commencé à rejeter des requêtes sans motif évident. Le CPU était correct. La mémoire était correcte. Les logs du service n’étaient pas utiles. Tout le monde voulait redémarrer parce que c’était le moyen le plus rapide d’arrêter la douleur.

L’on-call a suivi la pratique ennuyeuse quand même. Il a capturé la queue dmesg, iostat et les compteurs d’interface. dmesg montrait des resets occasionnels de NIC. Les compteurs d’interface montraient des drops RX en hausse. iostat était propre. Ces preuves ont changé la décision : au lieu de reboot répétés, ils ont drainé le nœud et remplacé la configuration de la NIC (fonction virtuelle dans ce cas). Ils ont aussi ajusté l’affinité des interruptions sur l’hôte.

Le nœud est revenu en service sans un seul reboot. Plus important encore, l’équipe n’a pas perdu des heures à « réparer » un problème réseau avec des resets qui auraient temporairement vidé des compteurs et remis à zéro l’état du pilote. L’habitude des snapshots ennuyeux n’a pas seulement sauvé la situation ; elle a sauvé le récit. Le postmortem contenait des preuves, pas du folklore.

Erreurs courantes : symptôme → cause racine → correction

1) « Reboot a résolu » devient le titre du ticket

Symptôme : L’incident se résout après reboot ; aucune action complémentaire n’est entreprise.

Cause racine : Preuves détruites ; amnésie organisationnelle. Le système reste fragile.

Correction : Exiger un bundle minimal de capture avant reboot et une hypothèse post-incident. Si vous ne pouvez pas faire les deux, admettez que vous choisissez la disponibilité plutôt que l’apprentissage — et planifiez l’apprentissage plus tard.

2) Boucle infinie de restarts de service

Symptôme : systemd montre un service qui clapote ; il redémarre toutes les quelques secondes.

Cause racine : Dépendance externe en panne (DNS, DB, disque plein), mauvaise config ou erreur de permission.

Correction : Utilisez journalctl -u pour trouver la première erreur ; corrigez la dépendance. Les redémarrages ne sont pas une récupération si la cause est déterministe.

3) « C’est le CPU » parce que la moyenne de charge est élevée

Symptôme : La charge moyenne grimpe ; les ingénieurs supposent une saturation CPU.

Cause racine : La charge inclut les tâches exécutables et non interruptibles. Les waits I/O peuvent gonfler la charge avec une faible utilisation CPU.

Correction : Vérifiez l’iowait dans top/iostat et recherchez des processus en état D. Si l’iowait est élevé, traitez-le comme un problème de stockage/chemin.

4) Rebooter la base de données pendant un incident I/O

Symptôme : La latence DB explose ; le reboot « aide » brièvement ; puis c’est pire.

Cause racine : Saturation de stockage ou erreurs de périphérique ; le reboot déclenche la récupération, rejoue WAL, réchauffe le cache à partir du froid et augmente l’I/O.

Correction : Réduisez l’amplification d’écriture, stoppez les jobs lourds, déplacez les données chaudes, throttlez compactions/checkpoints et corrigez le stockage. Rebootez seulement après confinement.

5) Power-cycling qui masque un disque défaillant

Symptôme : Bloquages I/O occasionnels ; un power-cycle restaure le service pendant des jours.

Cause racine : Bug firmware du disque ou média qui se dégrade ; les resets effacent temporairement les états d’erreur.

Correction : Corrélez les erreurs dmesg avec les stats SMART ou la dégradation du pool ; remplacez le matériel, mettez à jour le firmware, validez câblage/backplane.

6) Le vidage de cache « règle » la performance

Symptôme : Après reboot, la latence s’améliore drastiquement, puis se détériore lentement.

Cause racine : Pollution du cache, fragmentation, fuite mémoire ou cardinalité non bornée (par exemple caches par locataire).

Correction : Mesurez le hit ratio du cache et le comportement d’éviction ; implémentez des caps de cache, TTL et métriques. Ne traitez pas le reboot comme de la gestion de cache.

7) Les reboots de nœuds Kubernetes provoquent des reschedulings en cascade

Symptôme : Rebooter un nœud déclenche un pic de latence à l’échelle du cluster.

Cause racine : Absence de pod disruption budgets, capacité spare trop faible, autoscaling agressif ou workloads stateful trop lourds reschedulés en même temps.

Correction : Drainer correctement, appliquer des PDBs, garder de la marge, et limiter le taux des rollouts. Le reboot est acceptable ; les bousculades ne le sont pas.

8) Considérer les timeouts réseau comme des bugs applicatifs

Symptôme : Timeouts aléatoires entre services ; redémarrer certains nœuds « aide ».

Cause racine : Problèmes de resolver DNS, drops de paquets, épuisement de conntrack ou mismatch MTU.

Correction : Vérifiez le resolver, les drops d’interface et conntrack ; corrigez la condition réseau. Les reboots peuvent réinitialiser conntrack et sembler aider, d’où la répétition de la pratique.

Checklists / plan étape par étape

Checklist A : Avant d’appuyer sur reset (production)

1. Confirmer l’étendue : un nœud vs flotte vs dépendance.
2. Capturer le bundle forensique minimal : uptime, snapshot top, iostat, df -h, tail dmesg, échecs de service.
3. Vérifier la santé du stockage : erreurs dans dmesg, état pool/RAID, saturation des périphériques.
4. Vérifier le réseau de base : drops d’interface, résolution DNS, sanity de la table de routage si pertinent.
5. Choisir la plus petite atténuation : restart service → reboot nœud → power-cycle.
6. Planifier l’impact client : drainer le trafic, cordonner le nœud, basculer si possible.
7. Communiquer : « Mitigation : reboot ; objectif : rétablir. Preuves capturées. Étape suivante : cause racine. »

Checklist B : Reboot contrôlé dans un cluster (la manière sûre)

1. Cordonner/vider le nœud (ou le retirer du load balancer).
2. Confirmer que les workloads stateful sont sûrs (réplication saine, pas de reconstruction en cours).
3. Rebooter une seule fois. Si ça n’a pas aidé, ne le refaites pas sans raison.
4. Au retour, valider les health checks et métriques clés avant de réintroduire le trafic.
5. Surveiller les effets de réchauffement de cache et les thundering herds.

Checklist C : Après le reset (transformer en apprentissage)

1. Comparer les métriques clés : latence, taux d’erreurs, iowait, drops, usage mémoire pré/post.
2. Formuler une hypothèse : « Le reboot a aidé parce que le reset du pilote a nettoyé X » est un point de départ, pas une fin.
3. Faire un durcissement : alerte, limitation, test ou upgrade. Un changement par incident suffit pour accumuler des gains.
4. Mettre à jour le runbook : inclure les commandes exactes et la règle de décision qui s’est avérée correcte.

FAQ

1) Rebooter un serveur en production est-il toujours mauvais ?

Non. Les reboots non contrôlés sont mauvais. Un reboot contrôlé — après évacuation du trafic et capture des preuves — est une atténuation légitime, surtout pour l’état noyau/pilote.

2) Pourquoi le reboot « règle » des problèmes qu’on ne peut pas reproduire ?

Parce que beaucoup de défaillances sont des états émergents : fuites, fragmentation, accumulation de files, périphériques bloqués. Le reboot remet à zéro cet état. Il ne l’explique pas.

3) Dois-je redémarrer le service ou rebooter le nœud ?

Redémarrez le service si le nœud a l’air sain (pas de tempête iowait, pas d’empilement d’états D, pas d’erreurs noyau). Rebootez le nœud quand vous suspectez des problèmes du noyau/pilote/chemin I/O.

4) Quelle est la chose la plus importante à faire avant un reboot ?

Capturer des preuves noyau et ressources : tail dmesg, iostat, top, df -h et logs pertinents du service. Si vous redémarrez sans cela, vous choisissez l’ignorance.

5) Comment savoir si le goulot est le disque ?

Cherchez un iowait élevé dans top, un await élevé et un %util élevé dans iostat -x, et des processus en état D attendant l’I/O.

6) Un reboot peut-il aggraver un incident de stockage ?

Oui. Les reboots peuvent déclencher des rebuilds/resilvers, l’amplification du cache froid, des replays de journal et des tempêtes de reconnexion vers le stockage partagé. Stabilisez d’abord, puis rebootez avec intention.

7) Dans Kubernetes, rebooter un nœud est-il acceptable ?

Oui, si vous cordonnez et videz correctement, respectez les pod disruption budgets et gardez de la marge dans le cluster. Traitez le reboot d’un nœud comme une mise à jour rolling, pas une surprise.

8) Pourquoi voit-on « ça marche après reboot » pour des problèmes réseau ?

Parce que le reboot remet à zéro les tables conntrack, nettoie des états transitoires de pilote et force la résolution DNS et les sessions TCP fraîches. C’est aussi pourquoi cela masque le vrai défaut réseau.

9) Comment réduire notre dépendance aux resets ?

Ajoutez des limites (mémoire, disque, profondeur de queue), augmentez l’observabilité (découpage de latence par couche) et rendez les modes d’échec connus auto-réparables (health checks qui redémarrent le bon composant, pas tout le nœud).

10) Devrait-on automatiser les reboots avec des watchdogs ?

Parfois. Pour des appliances monofonction et des nœuds en edge, les watchdogs peuvent être appropriés. Pour des systèmes stateful complexes, un reboot automatique sans capture de preuves et sans limites de cadence efface souvent les seuls indices dont vous disposiez.

Conclusion : prochaines étapes pour réduire le « reboot comme mode de vie »

L’ère du bouton reset n’est pas une question de honte. C’est une question de clarté. Les resets sont honnêtes parce qu’ils admettent qu’un système a accumulé un état que vous ne pouvez pas raisonner sous pression. Ils sont malhonnêtes parce qu’ils effacent la piste à moins que vous ne la préserviez délibérément.

Si vous gérez des systèmes de production, faites trois choses dès cette semaine :

1. Standardisez le bundle pré-reboot (cinq commandes, un fichier, toujours attaché à l’incident).
2. Adoptez la règle du plus petit marteau (redémarrer le service avant de rebooter ; rebooter avant de power-cycle ; basculer avant de reconstruire).
3. Transformez chaque reset réussi en hypothèse que vous pouvez tester : stockage, réseau, mémoire, noyau ou dépendance. Puis durcissez un point faible.

Rebooter n’est pas un échec. Rebooter sans apprendre l’est.