L’intervieweur a déjà vu vingt personnes réciter ps, df, ss. Il ne recrute pas un mémento. Il veut savoir si, à 3 h du matin, vous réduisez l’espace des causes ou si vous lancez des commandes jusqu’à ce que quelque chose bouge.
La méthode tient en quatre mots : symptôme → hypothèse → preuve → geste.
On refuse le vague. « C’est lent » n’est pas un symptôme. « Les requêtes HTTPS passent de 80 ms à 8 s depuis 02:10, le load 15 min n’a pas bougé, le disque wa est à 40 % » en est un. On fixe : pour qui (un client, tous), depuis quand, quel message d’erreur, ce qui marche encore (ping, un autre service, un autre AZ). Un symptôme mal posé fait diagnostiquer le CPU d’un incident DNS.
On en pose deux ou trois, ordonnées par vraisemblance et coût de test. Exemple : timeout applicatif → (1) le process n’écoute plus, (2) le FS de /var est plein, (3) un aval (base, DNS) ne répond plus. On n’ouvre pas strace avant d’avoir écarté ss et df. L’hypothèse favorite du dernier incident est un biais : on la met sur la liste, on ne lui donne pas le premier créneau.
Chaque test doit pouvoir tuer une hypothèse. df -h tue ou confirme « plus de place ». ss -lntup tue « rien n’écoute ». journalctl -u -n 100 tue « le service n’a rien dit ». Un test qui « montre que la machine est occupée » sans lier au symptôme n’est pas une preuve, c’est du tourisme.
On note le temps : une preuve d’il y a une heure ne décrit plus un process redémarré. On reste sur la même machine que le symptôme (pas le laptop).
On change une chose, on observe. Restart du service après avoir capturé status, limites, lsof deleted. On n’enchaîne pas reboot + chmod 777 + setenforce 0. Le geste a un critère de succès : la latence redescend, l’unité reste active, df a baissé et l’écriture réussit.
« Je regarderais les logs » sans dire lesquels. « Je ferais un reboot, ça règle souvent. » Une liste d’outils sans ordre. Confondre mitigation (scale, restart) et cause. Mentir sur une commande dont on ne sait pas lire la sortie.
« Vous avez cinq minutes, un site down. »
Vous parlez à voix haute : impact (un hôte, le LB), santé du process (systemctl, ss), ressources (free, df, load interprété), dernière erreur (journalctl -u --since). Vous nommez la première hypothèse éliminée. Cinq minutes de méthode battent vingt minutes d’outils.
C’est la question qui referme un oral Linux. Les 29 précédentes sont des briques. Celle-ci vérifie que vous savez les enchaîner.