Sauver un serveur à 3 h : triage en 15 minutes

Il est 3 h du matin. Tu es à moitié réveillé, le téléphone vibre, et tu vois le genre de message qui fait grimacer avant même d’ouvrir les yeux : « site down », « API en erreur », « CPU à 100 % », « plus de place disque ». Et toi tu penses juste… ok. Calme. On va faire simple.

Le piège classique à cette heure là, c’est de partir dans tous les sens. De se connecter et de taper des commandes au hasard, de redémarrer « pour voir », de casser autre chose. Alors que souvent, ce qu’il faut, c’est un triage. Rapide. Méthodique. Qui te donne un diagnostic provisoire et une action de stabilisation.

L’objectif ici n’est pas de « résoudre définitivement » en 15 minutes. C’est de remettre le service en vie, de limiter les dégâts, et de te donner assez d’info pour faire le vrai correctif plus tard, quand tu es humain.

Dans ce billet du Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, je te partage ma routine de triage express. Celle qui m’a déjà sauvé des nuits. Et des clients.

Le principe : stabiliser, puis comprendre

À 3 h, je me répète une phrase un peu bête, mais efficace : « stabilise avant d’optimiser ». Ça veut dire :

• remettre un service minimum
• éviter la perte de données
• récupérer des indices (sans noyer le système)
• noter ce que tu fais

Et oui, noter. Même un mini bloc notes. Parce qu’à 3 h 20 tu ne te souviens déjà plus de la commande exacte que tu as lancée.

Avant de toucher à tout : deux vérifications basiques

1) Tu es où, et tu touches quoi ?

Ça paraît idiot, mais… SSH sur le mauvais serveur, ça arrive. En prod, en préprod, sur un ancien nœud, sur un clone. Donc :

bash hostnamectl whoami pwd date

Je veux voir le hostname, l’heure, et je veux être sûr d’être sur la bonne machine.

2) Tu as une voie de retour ?

Si tu dois redémarrer un service ou bidouiller un firewall, assure toi d’avoir un accès alternatif : console cloud, IPMI, écran de secours, session tmux persistante.

bash tmux new -s triage

Tu lances tmux. Ça évite la déconnexion bête qui te fait perdre 4 minutes et le fil.

Minute 0 à 3 : est-ce que c’est réseau, charge, disque, ou appli ?

Tu veux des signaux faibles, tout de suite.

Ping et HTTP rapide

Depuis ta machine, ou depuis un bastion :

bash ping -c 2 IP_DU_SERVEUR curl -I https://ton-domaine.tld --max-time 5

• si ping KO mais console OK, pense réseau ou firewall
• si ping OK mais HTTP KO, pense service applicatif, reverse proxy, ou saturation
• si curl met 5 secondes puis timeout, souvent charge ou backlog

Vue d’ensemble en 30 secondes

Sur le serveur :

bash uptime free -h df -h

Trois commandes, trois bombes potentielles :

• load average délirant
• RAM pleine et swap en feu
• disque à 100 %

Ensuite, je prends une photo mentale du CPU et des processus :

bash top

Ou mieux, si dispo :

bash htop

Minute 3 à 6 : identifier le « goulot » dominant

À ce stade, tu classes. Tu ne cherches pas encore la cause profonde, tu cherches la catégorie.

Cas A : disque plein (le tueur silencieux)

Le disque à 100 %, c’est un classique. Et souvent ça casse tout : base de données, logs, sockets, déploiements.

1. trouver le coupable :

bash du -xhd1 /var | sort -h du -xhd1 / | sort -h

2. si ce sont les logs :

bash journalctl --disk-usage ls -lh /var/log | tail

3. action de stabilisation (prudente) :

• compresser ou purger des archives évidentes
• couper un log qui tourne en boucle
• si Docker, nettoyer ce qui explose

Docker qui mange tout :

bash docker system df docker system prune -af

Attention : prune peut supprimer des images utiles. À 3 h, je le fais seulement si je sais ce que je fais, et si l’urgence est réelle.

Cas B : CPU à 100 %

Tu veux savoir qui consomme :

bash ps aux --sort=-%cpu | head

Si tu vois un processus unique qui bouffe tout, tu as trois options :

• le tuer (risqué)
• le renicer (temporaire)
• redémarrer le service (parfois le plus propre)

Renicer vite fait :

bash renice +10 -p PID

Si c’est un worker qui boucle, parfois un restart contrôlé est mieux :

bash systemctl restart ton-service

Mais avant de restart, je prends 30 secondes de logs. Toujours.

Cas C : RAM saturée, OOM, swap qui hurle

Vérifie :

bash free -h dmesg -T | tail -n 50

Si tu vois des OOM killer, tu as déjà un indice. Stabilisation :

• redémarrer le service qui fuit
• baisser temporairement le nombre de workers
• augmenter la RAM si cloud et si tu peux, mais ça c’est plus un plan B

Cas D : IO disque saturé

Quand tout « rame » mais CPU pas si haut, pense IO.

bash iostat -xz 1 3

Si pas installé :

bash apt install sysstat

Ou :

bash vmstat 1 5

Tu regardes wa (iowait). Si c’est haut, tes requêtes attendent le disque. Souvent : logs massifs, base en souffrance, backup au mauvais moment, ou disque réseau malade.

Minute 6 à 10 : les logs utiles, pas les logs infinis

À 3 h, on veut les 50 dernières lignes qui expliquent le drame, pas un roman.

systemd, le réflexe

bash systemctl --failed journalctl -p 3 -xb --no-pager | tail -n 80

• -p 3 pour erreurs
• -xb pour le boot courant

Nginx / Apache / reverse proxy

Selon ton stack :

bash tail -n 80 /var/log/nginx/error.log tail -n 80 /var/log/apache2/error.log

Tu cherches : timeout upstream, too many open files, 502/504 en cascade, handshake TLS, etc.

Application et base de données

Pour PostgreSQL :

bash tail -n 80 /var/log/postgresql/postgresql-*.log

Pour MySQL :

bash tail -n 80 /var/log/mysql/error.log

Et pour ton app, ça dépend, mais tu as souvent un logs/ ou un journalctl -u.

Exemple :

bash journalctl -u mon-api.service --since "20 minutes ago" --no-pager | tail -n 120

Minute 10 à 12 : actions de stabilisation typiques (celles qui marchent vraiment)

Là, tu as une hypothèse. Même si elle est imparfaite. Tu choisis une action qui a un bon ratio « impact positif » sur « risque ».

1) Redémarrer un service… mais pas tout le serveur

Redémarrer le serveur, c’est parfois une fuite en avant. Si tu peux isoler :

bash systemctl restart nginx systemctl restart mon-api systemctl restart postgresql

Un par un, avec vérification entre chaque.

2) Limiter l’hémorragie côté trafic

Si tu es sous DDoS léger, ou juste un pic, tu peux activer une protection rapide :

• activer un mode maintenance
• mettre un cache plus agressif
• baisser le nombre de workers
• activer un rate limit (Nginx)

Exemple Nginx (si déjà prévu dans ta conf, sinon évite d’improviser) : tu actives une map ou une zone de limit.

3) Libérer de la place disque en mode « safe »

Mes « safe deletes » habituels :

• vieux fichiers temporaires dans /tmp
• archives de build périmées
• logs compressables

bash find /tmp -type f -mtime +3 -delete

Tu fais attention à ne pas supprimer des sockets ou des fichiers utilisés. Oui, lsof peut aider :

bash lsof | grep deleted | head

4) Couper un job planifié qui détruit tout

Il y a des nuits où le coupable est un cron de backup qui s’emballe.

bash systemctl list-timers --all | head -n 30 crontab -l ls -l /etc/cron.* /

Tu désactives temporairement. Tu le notes. Tu reviendras.

Minute 12 à 15 : valider, puis laisser des traces

Valider le retour à la vie

Je teste comme un utilisateur.

bash curl -I https://ton-domaine.tld --max-time 5

Puis un endpoint un peu plus réel, si tu en as un :

bash curl -s https://ton-domaine.tld/healthz

Et côté serveur :

bash ss -lntp | head systemctl status mon-service --no-pager

Laisser une trace, sinon tu vas souffrir demain

Même si tu es solo. Surtout si tu es solo.

• un mini compte rendu dans un fichier
• ou un ticket
• ou une note sur ton espace de travail

Exemple :

bash cat >> /root/INCIDENTS.md << 'EOF' [2026-07-31 03:12] Symptômes : 502 sur /, load élevé. Cause probable : disque plein via logs nginx + conteneurs. Actions : purge /tmp, rotation logs, restart nginx + api. À faire : mettre alerte disque 80%, limiter logs, revoir retention Docker. EOF

C’est basique, mais ça sauve ton lendemain.

Mini checklist imprimable (la version « je n’ai plus de cerveau »)

1. hostnamectl + tmux
2. uptime free -h df -h
3. top puis ps aux --sort=-%cpu | head
4. systemctl --failed
5. journalctl -p 3 -xb | tail
6. logs nginx / app / DB
7. stabilisation : libérer disque, restart service ciblé, couper cron
8. curl -I + endpoint /healthz
9. note d’incident

Tu peux littéralement copier ça dans un fichier TRIAGE_3H.md sur tes serveurs.

Ce que je mettrais en place pour ne plus revivre ça (ou moins souvent)

Parce que oui, on peut réduire les réveils nocturnes. Pas à zéro, mais… quand même.

• alertes disque à 80 % et 90 %
• rotation de logs validée (logrotate, retention)
• endpoint healthz + monitoring externe
• limites sur la volumétrie Docker
• sauvegardes testées, pas seulement « configurées »
• un runbook simple, partagé

Sur https://monblog-sa-abasse.blogspot.com, j’essaie justement de publier ce genre de runbooks et routines. Pas parfaits, pas corporate. Utiles. Si tu veux, va jeter un œil aux pages « Méthodes » et « Services », ça donne une idée de ma manière de bosser, et ça peut t’éviter de réinventer la roue.

Conclusion

Sauver un serveur à 3 h, ce n’est pas une démonstration de génie. C’est surtout de la discipline. Un triage court, des commandes simples, des actions à faible risque, et une trace écrite.

Et franchement, le vrai luxe, ce n’est pas d’être rapide au clavier. C’est de dormir après. Parce que tu sais que tu as stabilisé. Et que demain, tu pourras corriger proprement.

Questions fréquemment posées

Quelle est la première étape à suivre lorsqu'on reçoit une alerte de service en pleine nuit ?

La première étape consiste à rester calme et à faire un triage rapide et méthodique. Il faut établir un diagnostic provisoire pour stabiliser le service sans chercher à résoudre définitivement le problème immédiatement.

Pourquoi est-il important de vérifier sur quel serveur on travaille avant d'agir ?

Il est crucial de s'assurer d'être connecté au bon serveur (production, préproduction, clone, etc.) pour éviter des erreurs graves. Des commandes comme 'hostnamectl', 'whoami', 'pwd' et 'date' permettent de confirmer l'environnement et l'heure.

Comment garantir un accès sécurisé et éviter la perte de session lors d'interventions à distance ?

Utiliser une session tmux persistante (commande 'tmux new -s triage') permet de maintenir la session active même en cas de déconnexion, évitant ainsi la perte du fil d'intervention.

Quelles commandes permettent d'avoir rapidement une vue d'ensemble de l'état du serveur ?

Les commandes 'uptime', 'free -h' et 'df -h' fournissent des informations sur la charge moyenne, la mémoire disponible et l'espace disque utilisé, essentielles pour diagnostiquer rapidement la situation.

Comment identifier si le problème vient du disque plein ?

On peut utiliser 'du -xhd1 /var | sort -h' ou 'du -xhd1 / | sort -h' pour trouver les dossiers qui occupent le plus d'espace, puis vérifier les logs avec 'journalctl --disk-usage' ou 'ls -lh /var/log'. Une action prudente comme compresser ou purger des archives peut stabiliser le système.

Que faire en cas de CPU à 100 % lors d'une panne nocturne ?

Il faut identifier les processus gourmands en ressources avec 'ps aux' ou des outils comme 'top' ou 'htop'. L'objectif est de comprendre rapidement quel service ou application consomme excessivement le CPU pour prendre des mesures temporaires de stabilisation.