Une soirée. Quatre heures chrono. C’est le temps qu’il m’a fallu pour réaliser que j’administrais mes serveurs Linux comme un conducteur qui ignorerait l’existence du rétroviseur. Je gérais mes VPS depuis deux ans, je me débrouillais, les services tournaient… mais je naviguais à l’aveugle sur des machines dont je ne comprenais pas vraiment ce qui se passait sous le capot. Puis quelqu’un m’a partagé une poignée de commandes que je n’utilisais pas, et ma façon de travailler a basculé du tout au tout.
À retenir
- Quelles sont ces commandes mystérieuses qui ont changé tout le jeu en une seule soirée ?
- Pourquoi redémarrer un serveur n’est jamais la bonne première solution
- Le réflexe de diagnostic que tout administrateur devrait acquérir immédiatement
Le faux sentiment de maîtrise
Le problème avec l’administration système quand on est autodidacte, c’est qu’on apprend juste ce qu’il faut pour que ça marche. ssh user@ip, apt update && apt upgrade, systemctl restart nginx. Le kit de survie. Et pendant longtemps, ce kit suffit. Jusqu’au jour où un service plante à 2h du matin, où le disque se remplit mystérieusement, ou où les performances chutent sans raison apparente, et là tu réalises que tu n’as aucun outil pour diagnostiquer quoi que ce soit.
Mon déclic est venu d’un simple problème : un serveur web qui répondait de plus en plus lentement sur une période de plusieurs jours. Je savais qu’il se passait quelque chose, mais je n’avais aucune idée de Comment regarder à l’intérieur de la machine en temps réel. J’ai fini par redémarrer le serveur entier parce que c’était ma seule solution. C’est à ce moment-là que j’ai compris qu’il y avait un trou béant dans mes compétences.
Les commandes qui changent réellement la donne
La première révélation a été htop. Pas top, son ancêtre austère que tout le monde connaît vaguement, mais htop, sa version colorée et interactive qui affiche en temps réel chaque processus, sa consommation CPU et mémoire, avec la possibilité de les trier, les filtrer, les tuer directement depuis l’interface. Ce n’est pas une commande secrète, mais la différence entre l’utiliser vraiment et se contenter de ps aux | grep quelquechose est la même qu’entre lire une carte routière et avoir un GPS.
Ensuite il y a iotop, qui fait la même chose mais pour les accès disque. C’est cette commande qui m’a permis de comprendre, ce fameux soir, pourquoi mon serveur ramait : un script de sauvegarde mal configuré tournait en boucle et saturait les I/O. Sans iotop, j’aurais cherché pendant des heures du côté du CPU ou de la RAM.
ss est une autre pépite. La plupart des gens utilisent encore netstat par habitude, mais ss est son remplaçant moderne, bien plus rapide sur les machines avec beaucoup de connexions. La commande ss -tulpn affiche immédiatement tous les ports en écoute avec le processus associé. En une ligne, tu sais exactement ce qui tourne et sur quel port. C’est le genre d’information qui t’évite de chercher pendant vingt minutes pourquoi ton application ne démarre pas parce qu’un port est déjà occupé.
Mais celle qui m’a le plus surpris par son utilité discrète, c’est journalctl. Je savais qu’elle existait pour lire les logs systemd, je l’avais utilisée de temps en temps avec -u nginx pour regarder les logs d’un service. Ce que je ne faisais pas, c’est l’utiliser avec -f pour suivre les logs en temps réel, ou avec --since "1 hour ago" pour cibler une fenêtre temporelle précise. La combinaison journalctl -u mon-service -f --no-pager devient un outil de débogage redoutable quand tu essaies de comprendre pourquoi un service crashe au démarrage.
La triade du diagnostic réseau
Le réseau reste le domaine où les administrateurs débutants tâtonnent le plus longtemps. On sait faire un ping, parfois un traceroute, et c’est à peu près tout. Ce qui manque souvent, c’est curl utilisé correctement. Pas juste curl http://monsite.com, mais curl -I pour récupérer uniquement les headers HTTP, ou curl -v pour voir l’intégralité de la négociation TLS et de la requête. Quand tu débogues un problème de certificat SSL ou de redirection, c’est incomparablement plus utile que d’ouvrir un navigateur.
tcpdump est dans une autre catégorie de complexité, mais même une utilisation basique ouvre des portes. Voir les paquets qui arrivent sur une interface en temps réel, filtrer par port ou par adresse IP, c’est le genre de chose qui transforme un problème réseau opaque en quelque chose d’observable. La courbe d’apprentissage existe, mais les premières commandes suffisent déjà à débloquer beaucoup de situations.
Et puis df -h et du -sh /chemin/*. Basiques, oui. Mais la quantité de gens qui redémarrent des services ou se grattent la tête pendant des heures sans avoir simplement vérifié que le disque n’est pas plein est édifiante. du -sh /* 2>/dev/null | sort -rh | head -10 te dit en quelques secondes quels répertoires engloutissent ton espace. Trente secondes de diagnostic qui auraient pu m’éviter quelques situations embarrassantes dans le passé.
Ce que cette soirée a vraiment changé
La vraie leçon n’est pas une liste de commandes à mémoriser. C’est la posture mentale qui va avec : avant de redémarrer quoi que ce soit, avant de modifier une config, observer. Lire ce que la machine te dit. Les outils de diagnostic ne servent à rien si on ne développe pas le réflexe de les utiliser en premier.
Depuis cette soirée, j’ai ajouté htop, iotop et ncdu (la version interactive de du, vraiment excellente) comme premières installations sur tout nouveau serveur. Pas parce que c’est obligatoire, mais parce que naviguer à l’aveugle sur une machine de production, j’ai donné.
La question qui me reste : combien d’heures j’ai perdues à redémarrer des services ou à fouiller des configs dans le vide, alors que la réponse était visible en deux commandes depuis le début ? Je préfère ne pas calculer.