Vous connaissez le moment : le serveur démarre, SSH fonctionne, l’application est déployée, et tout le monde se félicite. Puis, deux semaines plus tard, c’est « mystérieusement lent », les sauvegardes « arrivent bientôt », l’heure est incorrecte et le système racine est rempli à 97 % parce que les logs se sont mis à pousser comme des champignons.
Voici la checklist qui évite ces réunions. Ce n’est pas romantique. Ce n’est pas « cloud native ». C’est l’ensemble ingrat de vérifications qui vous permet de dormir, migrer et déboguer sans pratiquer l’archéologie médico-légale sur votre propre installation.
L’état d’esprit : établir une base, puis construire
Une installation neuve est le seul moment dans la vie d’un système où tout est propre, déterministe et encore obéissant. Une fois le trafic de production arrivé, l’entropie suit : les paquets dérivent, les fichiers de configuration sont modifiés « temporairement », et la seule personne qui se souvient pourquoi un paramètre du noyau a été changé est en vacances pour toujours.
Votre objectif pendant les 20 premières minutes n’est pas de « finir la configuration ». Votre objectif est de capturer une base et d’installer des garde-fous :
- Base : Identifier le matériel et l’environnement virtuel que vous avez réellement reçus (pas ce que les achats ont promis).
- Confirmer les invariants : Heure, DNS, routage, disposition des disques et canaux de mise à jour.
- Rendre le futur bon marché : Instantanés, sauvegardes, un endroit pour les logs et un moyen de déboguer sans deviner.
Une citation à coller sur votre écran. C’est une idée paraphrasée de John Allspaw (opérations et fiabilité) : idée paraphrasée : Les systèmes échouent de manière surprenante ; votre travail est de rendre sûr l’apprentissage et la récupération rapides.
Faites les vérifications ennuyeuses maintenant. Ou faites-les à 02:00 pendant que quelqu’un demande si le problème vient « de la base de données ».
Faits et contexte intéressants (pourquoi cela arrive encore)
- Les cicatrices de la mesure du temps Unix sont anciennes. Les ancêtres de NTP datent de plusieurs décennies ; les bugs de synchronisation temporelle provoquent encore des échecs d’authentification, des erreurs TLS et des chronologies de logs « impossibles ».
- Les systèmes de fichiers ont une histoire, et ça se voit. ext4 est conservateur parce qu’il a hérité d’une lignée qui a tiré des leçons difficiles des pertes de courant et des disques défaillants.
- Le journalisation a été une révolution. Avant l’avènement des systèmes de fichiers journalisés, un crash pouvait transformer un redémarrage en plusieurs heures de fsck. Beaucoup de « mauvais » paramètres par défaut existent encore pour éviter le retour à cette époque.
- RAID n’a jamais été une sauvegarde. L’expression est plus vieille que la plupart des rotations d’astreinte et est encore ignorée chaque semaine ; RAID protège de certaines pannes de disque, pas des suppressions ou corruptions.
- Les pannes DNS sont un vilain récurrent. Internet a connu plusieurs pannes de grande ampleur causées par des erreurs DNS ; en interne, le même schéma se répète avec le split-horizon et des résolveurs obsolètes.
- Les valeurs par défaut d’OpenSSH ont évolué pour une raison. L’abandon d’algorithmes faibles et la promotion de l’authentification par clé n’étaient pas une mode ; c’était le résultat d’incidents accumulés.
- cgroups et systemd ont changé l’exploitation Linux. Ils ont amélioré le contrôle des ressources et la supervision des services, mais ont aussi introduit des modes de défaillance que l’on ne voit que si l’on consulte les bons statuts.
- « Ça marche sur ma machine » s’est aggravé avec la virtualisation. Dérive d’horloge, voisins bruyants, I/O sursouscrites et flags CPU incompatibles peuvent faire que deux VM « identiques » se comportent comme deux espèces différentes.
Ce ne sont pas des anecdotes. Ce sont les raisons pour lesquelles une checklist d’installation neuve n’est pas de la paranoïa. C’est de l’intérêt composé.
Checklists / plan étape par étape (la routine de 20 minutes)
Minute 0–3 : Identité et accès (avant de toucher à quoi que ce soit)
- Confirmer le nom d’hôte, la version de l’OS, le noyau et le contexte de virtualisation.
- Confirmer que vous pouvez accéder en toute sécurité : clés SSH, sudo, et un second chemin (console, hors-bande ou port série VM).
- Enregistrer l’état initial : sources de paquets, kernel cmdline, disposition des disques.
Minute 3–8 : Disposition du stockage que vous n’allez pas détester plus tard
- Vérifier quels disques vous avez, comment ils sont nommés et si vous êtes sur NVMe, SATA ou stockage en réseau.
- Confirmer le partitionnement et les points de montage. Assurez-vous que les logs et les données ne partagent pas accidentellement une racine minuscule.
- Confirmer le comportement TRIM/discard pour les SSD lorsque c’est pertinent.
Minute 8–12 : Vérification de la réalité réseau
- Vérifier les IP, les routes et les résolveurs DNS.
- Vérifier le MTU et la latence basique. Chercher tôt les trous PMTU.
- Vérifier la connectivité sortante vers vos miroirs de paquets et les endpoints de monitoring.
Minute 12–16 : Temps, mises à jour et superviseur de services
- Confirmer la synchronisation du temps et le fuseau horaire (et que ça reste synchronisé).
- Confirmer la politique de mises à jour automatiques (ou votre processus de patch). « On le fera plus tard » est un mensonge que l’on se raconte.
- Confirmer la santé de systemd et la persistance des logs.
Minute 16–20 : Observabilité + sauvegardes (prouver que ça fonctionne)
- Installer un agent minimal d’envoi de métriques/logs ou au moins activer les logs persistants.
- Créer un premier snapshot (VM ou niveau système de fichiers) une fois que le système est « connu bon ».
- Lancer un job de sauvegarde, puis tenter une petite restauration. Oui, immédiatement.
Blague courte #1 : Les sauvegardes sont comme les parachutes : si vous découvrez qu’elles ne fonctionnent qu’au moment du saut, votre post-mortem sera bref.
Tâches pratiques avec commandes, sorties et décisions
Le but des commandes n’est pas de collecter des anecdotes. Chaque commande doit répondre : « Qu’est-ce qui est vrai ? » et « Que fais-je ensuite ? » Ci‑dessous des tâches pratiques que vous pouvez exécuter sur la plupart des distributions Linux modernes. Ajustez les chemins et outils selon vos besoins, mais conservez l’intention.
Task 1: Confirm OS, kernel, and architecture
cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04 LTS (Noble Numbat)"
ID=ubuntu
cr0x@server:~$ uname -r
6.8.0-31-generic
cr0x@server:~$ uname -m
x86_64
Ce que signifie la sortie : Vous avez la version exacte de la distribution, la branche du noyau et l’architecture CPU. Cela affecte la disponibilité des paquets, les valeurs par défaut du noyau (ordonnanceurs I/O, cgroups) et le comportement des pilotes.
Décision : Confirmez que cela correspond à votre politique de support. Si vous avez besoin d’un noyau spécifique ou d’un patch LTS pour des pilotes (HBA/NIC), décidez maintenant — avant que des données de production existent.
Task 2: Confirm virtualization / cloud environment
cr0x@server:~$ systemd-detect-virt
kvm
cr0x@server:~$ cat /sys/class/dmi/id/product_name
KVM
Ce que cela signifie : Vous êtes dans KVM. La dénomination des disques, le comportement de l’horloge et les plafonds I/O peuvent différer du bare metal.
Décision : Si vous attendiez du bare metal, arrêtez-vous et escaladez. Si vous attendiez une VM, vérifiez vos hypothèses de performance de stockage (les blocs réseau peuvent être « corrects » jusqu’à ce qu’ils ne le soient plus).
Task 3: Record CPU and memory basics (catch underprovisioning)
cr0x@server:~$ lscpu | sed -n '1,12p'
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R)
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
Virtualization: VT-x
L1d cache: 64 KiB
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 7.7Gi 420Mi 6.6Gi 4.0Mi 720Mi 7.1Gi
Swap: 0B 0B 0B
Ce que cela signifie : Vous avez 4 vCPU, ~8 GiB de RAM et aucun swap configuré.
Décision : Décidez explicitement du swap. Pour de nombreuses charges serveur, un petit swap peut prévenir le chaos de l’OOM-killer ; pour des charges sensibles à la latence, vous pouvez préférer l’absence de swap et des limites mémoire strictes. Ne laissez pas la valeur par défaut s’installer par accident.
Task 4: Confirm disks, models, and transport
cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,TRAN,ROTA,MOUNTPOINTS
NAME TYPE SIZE MODEL TRAN ROTA MOUNTPOINTS
vda disk 120G Virtio Block Dev virtio 1
├─vda1 part 1G 1 /boot
└─vda2 part 119G 1 /
Ce que cela signifie : Un disque virtio, rotational=1 (souvent sans sens en VM mais indice quand même). La racine et /boot partagent le même disque.
Décision : Si cela doit héberger des bases de données, des queues ou des logs intensifs, planifiez des volumes ou points de montage séparés maintenant (ou migrez vers LVM/ZFS). Une racine unique sur un seul disque est la voie royale vers des pannes « disque plein » provoquées par des logs bavards.
Task 5: Verify filesystem type and mount options
cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/vda2 ext4 rw,relatime,errors=remount-ro
cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /boot
/boot /dev/vda1 ext4 rw,relatime
Ce que cela signifie : ext4 avec des valeurs par défaut plutôt sûres. errors=remount-ro peut vous sauver d’une corruption silencieuse au prix de transformer les erreurs en douleur immédiate. C’est un bon compromis.
Décision : Conservez des valeurs raisonnables sauf raison mesurée. Si vous utilisez des SSD et vous souciez de l’usure d’écriture, examinez noatime vs relatime et vos besoins de monitoring.
Task 6: Check free space and inode headroom
cr0x@server:~$ df -hT /
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda2 ext4 117G 6.1G 105G 6% /
cr0x@server:~$ df -ihT /
Filesystem Type Inodes IUsed IFree IUse% Mounted on
/dev/vda2 ext4 7.5M 132K 7.4M 2% /
Ce que cela signifie : Espace et inodes sains. L’épuisement des inodes est un piège classique « disque plein mais pas vraiment » avec de nombreux petits fichiers (caches, queues mail, couches de conteneurs).
Décision : Si vous prévoyez beaucoup de petits fichiers, envisagez des systèmes de fichiers séparés avec des ratios d’inodes adaptés, ou déplacez ces charges vers du stockage objet ou une base de données conçue pour cela.
Task 7: Establish a quick I/O baseline (latency matters more than MB/s)
cr0x@server:~$ sudo apt-get update -y
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 1s (160 kB/s)
Reading package lists... Done
cr0x@server:~$ sudo apt-get install -y fio
Setting up fio (3.36-1) ...
cr0x@server:~$ fio --name=randread --filename=/tmp/fio.test --size=1G --rw=randread --bs=4k --iodepth=32 --numjobs=1 --direct=1 --runtime=20 --time_based --group_reporting
randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=32
fio-3.36
randread: (groupid=0, jobs=1): err= 0: pid=2176: Thu Feb 5 10:11:02 2026
read: IOPS=18.4k, BW=71.9MiB/s (75.4MB/s)(1.40GiB/20001msec)
slat (usec): min=3, max=140, avg=9.12, stdev=2.88
clat (usec): min=179, max=4112, avg=1726.44, stdev=312.20
lat (usec): min=188, max=4124, avg=1735.81, stdev=312.34
Ce que cela signifie : IOPS en lecture aléatoire et, plus important, la distribution des latences. Une moyenne ~1,7 ms peut convenir pour des charges générales ; elle peut être mortelle pour une base de données sensible à la latence de queue.
Décision : Si la latence est plus élevée que prévu, investiguez le backend de stockage (virtio sur bloc réseau, cache hôte, overhead du chiffrement). N’« optimisez » pas l’application avant d’avoir vérifié que le disque n’est pas silencieusement en feu.
Task 8: Check network interfaces, addresses, and link state
cr0x@server:~$ ip -br addr
lo UNKNOWN 127.0.0.1/8 ::1/128
ens3 UP 10.20.14.37/24 fe80::5054:ff:fe2a:1b2c/64
cr0x@server:~$ ip route
default via 10.20.14.1 dev ens3 proto dhcp src 10.20.14.37 metric 100
10.20.14.0/24 dev ens3 proto kernel scope link src 10.20.14.37
Ce que cela signifie : L’interface est UP, a une IP et une route par défaut.
Décision : Si c’est de la production, décidez si le DHCP est acceptable. Pour les serveurs, l’adressage statique (ou réservations DHCP avec inventaire strict) vaut souvent le coup.
Task 9: Verify DNS resolution and resolver configuration
cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
DNS Servers: 10.20.0.53 10.20.0.54
cr0x@server:~$ getent hosts archive.ubuntu.com
2620:2d:4000:1::19 archive.ubuntu.com
91.189.91.83 archive.ubuntu.com
Ce que cela signifie : Vous savez quels résolveurs vous utilisez, et la résolution de noms fonctionne.
Décision : Si des résolveurs sont des « IP mystère », corrigez cela maintenant. Décidez aussi si vous avez besoin de DNS split, de domaines de recherche ou de validation DNSSEC (rare en interne, mais sachez quel choix vous faites).
Task 10: Check MTU and basic path health
cr0x@server:~$ ip link show ens3 | sed -n '1,2p'
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:2a:1b:2c brd ff:ff:ff:ff:ff:ff
cr0x@server:~$ ping -c 3 10.20.14.1
PING 10.20.14.1 (10.20.14.1) 56(84) bytes of data.
64 bytes from 10.20.14.1: icmp_seq=1 ttl=64 time=0.335 ms
64 bytes from 10.20.14.1: icmp_seq=2 ttl=64 time=0.284 ms
64 bytes from 10.20.14.1: icmp_seq=3 ttl=64 time=0.290 ms
cr0x@server:~$ ping -M do -s 1472 -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1472 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=2.31 ms
1472 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=2.28 ms
Ce que cela signifie : Le MTU est 1500 et vous pouvez passer un paquet pleine taille sans fragmentation.
Décision : Si des jumbo frames sont attendues (MTU 9000), confirmez le bout en bout. Des MTU mixtes créent des tickets « tout marche sauf la chose importante ».
Task 11: Confirm time sync and clock health
cr0x@server:~$ timedatectl
Local time: Thu 2026-02-05 10:14:21 UTC
Universal time: Thu 2026-02-05 10:14:21 UTC
RTC time: Thu 2026-02-05 10:14:22
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
cr0x@server:~$ chronyc tracking
Reference ID : 0A140035 (10.20.0.53)
Stratum : 3
Last offset : -0.000021 seconds
RMS offset : 0.000110 seconds
Frequency : 11.432 ppm fast
Skew : 0.221 ppm
Root delay : 0.001234 seconds
Root dispersion : 0.000532 seconds
Update interval : 64.2 seconds
Leap status : Normal
Ce que cela signifie : La synchronisation temporelle est active et stable. L’offset est minuscule. Bien.
Décision : Si le temps n’est pas synchronisé, corrigez-le avant de déployer quoi que ce soit utilisant TLS, Kerberos, JWTs ou la corrélation de logs. En d’autres termes : tout.
Task 12: Check systemd for failed units (catch quiet breakage)
cr0x@server:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
Ce que cela signifie : Aucune unité échouée. C’est la base que vous voulez préserver.
Décision : Si quelque chose a échoué, lisez les logs maintenant, pas pendant une panne. Une unité « failed » peut être votre agent de monitoring, votre timer de sauvegarde ou le réseau.
Task 13: Confirm logging persistence and disk usage controls
cr0x@server:~$ sudo grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)=' /etc/systemd/journald.conf | grep -v '^#' || true
cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 64.0M in the file system.
Ce que cela signifie : journald utilise les valeurs par défaut ; la persistance peut être en mémoire selon la distribution et la présence des répertoires.
Décision : Décidez si les logs doivent survivre au reboot. Pour le débogage en production, rendez-les persistants et limitez leur usage pour éviter que les logs ne dévorent la racine.
Task 14: Confirm firewall state (and don’t pretend “security group” is enough)
cr0x@server:~$ sudo nft list ruleset
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
}
chain forward {
type filter hook forward priority filter; policy accept;
}
chain output {
type filter hook output priority filter; policy accept;
}
}
Ce que cela signifie : La politique du pare-feu est grande ouverte.
Décision : Si cet hôte est accessible au-delà d’un réseau strictement contrôlé, verrouillez-le. Même dans des réseaux « privés », le mouvement latéral existe. Mettez la politique par défaut en deny inbound, autorisez ce dont vous avez besoin et journalisez les drops à un rythme raisonnable.
Task 15: Confirm SSH configuration and key-only access
cr0x@server:~$ sudo sshd -T | egrep '^(port|passwordauthentication|permitrootlogin|pubkeyauthentication|kexalgorithms|macs|ciphers)'
port 22
passwordauthentication no
permitrootlogin prohibit-password
pubkeyauthentication yes
kexalgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
Ce que cela signifie : L’authentification par mot de passe est désactivée, la connexion root est restreinte et la cryptographie moderne est activée.
Décision : Si l’authentification par mot de passe est activée, désactivez-la une fois les clés et l’accès de secours confirmés. Si la connexion root est autorisée, corrigez cela sauf exception strictement gérée.
Task 16: Confirm updates policy (security patches are not optional)
cr0x@server:~$ apt-cache policy | sed -n '1,20p'
Package files:
100 /var/lib/dpkg/status
release a=now
Pinned packages:
cr0x@server:~$ systemctl status unattended-upgrades --no-pager
● unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled)
Active: inactive (dead)
Ce que cela signifie : Unattended upgrades est installé/activé (commun sur Ubuntu). L’unité peut apparaître inactive parce qu’elle s’exécute périodiquement via des timers.
Décision : Choisissez : mises à jour automatiques de sécurité, ou fenêtre de patch planifiée avec monitoring et enforcement. Ce que vous ne choisissez pas, c’est « espérer ».
Task 17: Confirm kernel command line (catch accidental flags)
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=/dev/vda2 ro quiet splash
Ce que cela signifie : Rien d’exotique. Bien.
Décision : Si vous voyez des flags de tuning que vous n’avez pas posés (désactivation des mitigations, changement d’IOMMU, forçage de nommage legacy), documentez pourquoi. Les flags noyau inconnus sont la manière dont vous héritez du risque.
Task 18: Confirm top talkers quickly (CPU, memory, I/O) after deploying anything
cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 10:17:02 up 1:21, 1 user, load average: 0.08, 0.04, 0.01
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.2 us, 0.8 sy, 0.0 ni, 97.8 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 7872.4 total, 6760.8 free, 430.7 used, 680.9 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 7441.7 avail Mem
Ce que cela signifie : La charge est faible, le CPU est majoritairement idle, iowait est nul. C’est une base « calme ».
Décision : Capturez cette sortie une fois. Plus tard, quand quelqu’un dira « c’est lent », vous aurez un ancrage avant/après.
Stockage : partitionnement, systèmes de fichiers et le « vous futur »
La plupart des incidents que j’ai vus commençant par « l’app est lente » se terminent par « le disque est plein », « le disque ment » ou « nous avons construit le stockage sur une hypothèse ». Le stockage est silencieux jusqu’à ce qu’il ne le soit plus. Et quand il ne l’est pas, il entraîne tout avec lui.
Partitionnement : choisissez les domaines de panne volontairement
Les partitions racine uniques conviennent aux VM éphémères et aux services sans état. Elles sont un piège pour tout ce qui émet des logs, stocke des fichiers de queue, caches, couches de conteneurs ou données de base.
Que faire :
- Séparez
/var(ou au moins/var/log) si vous attendez des logs bruyants ou des changements de paquets fréquents. - Séparez les données applicatives (par ex.
/srvou/var/lib/<service>) de l’OS. - Si vous devez garder un seul système de fichiers, appliquez des politiques de rétention des logs et mettez en place quotas/limites quand c’est possible.
Choix du système de fichiers : l’ennuyeux est une fonctionnalité
ext4 et XFS sont « ennuyeux » dans le meilleur sens : modes de défaillance compris, outils prévisibles et chemins de récupération mûrs.
ZFS est fantastique quand vous avez besoin de snapshots, checksums, réplication et intégrité des données avec une histoire d’administration cohérente. Mais ZFS exige que vous respectiez la RAM, recordsize, ashift, et le fait que c’est une plateforme de stockage, pas une option de montage.
Comportement des SSD : TRIM et le mythe des IOPS infinies
Pour le stockage SSD, assurez-vous que TRIM/discard est approprié. Le discard continu peut être utile ou nuisible selon le backend ; un TRIM programmé (fstrim timer) est un compromis courant.
Aussi : les SSD sont rapides sur beaucoup de points et étonnamment mauvais sur quelques-uns. La latence d’écriture aléatoire sous charge soutenue peut passer de « agréable » à « pourquoi nous paginons le PDG » si le périphérique ou le backend est saturé.
Chiffrement : décidez, mesurez, puis standardisez
Le chiffrement disque (LUKS) est souvent requis, parfois optionnel, et toujours quelque chose à benchmarker. L’accélération matérielle le rend généralement peu coûteux. De mauvais flags CPU ou une accélération manquante le rendent moins bon marché.
Rendez la décision explicite : chiffrer le disque OS ? chiffrer les disques de données ? qui détient les clés ? comment gérer les démarrages non supervisés en VM ? Si vous ne pouvez pas répondre clairement, vous n’avez pas fini.
Réseau : vérifier la réalité, pas les diagrammes
Les réseaux sont des systèmes politiques avec des paquets. Votre checklist d’installation doit confirmer ce qui est vrai : routes, résolveurs, MTU et quelle frontière de sécurité applique réellement la politique.
DNS : la dépendance de votre dépendance
Vérifiez les résolveurs et confirmez qu’ils sont les bons pour votre environnement. Les erreurs DNS les plus courantes après une installation :
- Utiliser un résolveur par défaut qui ne peut pas résoudre les zones internes.
- Domaines de recherche qui provoquent des recherches lentes et des collisions de noms étranges.
- Deux résolveurs listés, l’un mort ; la moitié de vos requêtes se bloquent en timeout.
MTU : petit réglage, vaste rayon d’impact
Quand les MTU sont en désaccord, certains trafics fonctionnent. Puis votre VPN casse, la réplication de la base de données stagne, ou votre overlay de conteneurs commence à laisser tomber les gros paquets. Vérifiez tôt avec des ping « do not fragment » vers des destinations représentatives.
Egress compte
Un serveur qui ne peut pas atteindre les dépôts de paquets, serveurs temporels, endpoints de certificats ou votre intake de monitoring est un serveur qui va pourrir silencieusement. Confirmez l’egress maintenant. Si vous êtes dans un environnement verrouillé, documentez les destinations et ports exacts requis afin que les modifications de pare-feu ne deviennent pas du folklore.
Sécurité : durcir sans casser l’exploitation
Le renforcement de la sécurité échoue de deux façons : vous ne faites rien et vous vous faites compromettre, ou vous faites « tout » et vous lockez les personnes qui doivent réparer la production.
SSH : clés, exposition minimale, accès prévisible
- Utilisez l’authentification par clé. Désactivez le mot de passe après avoir vérifié que vous avez des clés fonctionnelles.
- N’autorisez pas la connexion directe de root. Utilisez sudo avec audit.
- Restreignez SSH aux réseaux de gestion quand c’est possible.
Pare-feu : refuser par défaut l’inbound, autoriser explicitement
Si votre environnement utilise déjà des contrôles réseau, tant mieux. Mettez néanmoins un pare-feu hôte sauf raison stricte contraire (certains appliances, load balancers, hôtes routage spécialisés). La défense en profondeur n’est pas un slogan ; c’est comment vous survivez à une règle mal appliquée en amont.
Moindre privilège : utilisateurs et services
Créez des comptes de service. Évitez d’exécuter des processus applicatifs en root. Si vous avez besoin de ports privilégiés ou d’accès noyau, soyez explicite avec les capabilities, le hardening des unités systemd et la documentation.
Blague courte #2 : L’exception pare-feu « temporaire » est l’employé le plus permanent dans la plupart des entreprises.
Observabilité : logs, métriques et temps
Les installations neuves sont le moment où vous décidez si le débogage sera de l’ingénierie ou une séance de spiritisme.
La synchronisation du temps est le squelette de l’observabilité
Si les horodatages dérivent, la chronologie d’incident devient de la fiction. Gardez les systèmes en UTC sauf raison forte contraire. Configurez NTP/chrony, confirmez la synchro et monitorisez-la.
Logs : rendez-les persistants, bornés et recherchables
Au minimum :
- Assurer la persistance de journald (
/var/log/journal) ou configurer rsyslog pour stocker sur disque. - Limiter l’espace dédié aux logs pour qu’ils ne consument pas la racine.
- Expédier les logs centralement si vous exécutez plus d’un serveur. « SSH et grep » ne scale pas après le premier incident stressant.
Métriques : capturez les éléments ennuyeux
CPU, mémoire, latence disque, utilisation du système de fichiers, erreurs réseau et compte de processus ne sont pas de l’observabilité avancée. Ce sont le minimum. Capturez-les dès le jour un pour pouvoir répondre : « C’est nouveau ou normal ? »
Core dumps : définissez la politique avant d’en avoir besoin
Les core dumps peuvent faire gagner des jours lors du débogage d’un crash. Ils peuvent aussi fuir des secrets et bouffer du disque. Décidez :
- Activer les core dumps pour des services spécifiques dans des emplacements contrôlés.
- Désactiver ou les limiter sur des systèmes sensibles où la politique l’interdit.
- Toujours caper la taille et l’emplacement, et traiter les dumps comme des artefacts sensibles.
Sauvegardes : prouver la restauration, pas l’intention
Les sauvegardes échouent de manières prévisibles : elles ne s’exécutent pas, elles s’exécutent mais stockent des données vides, elles stockent des données que vous ne pouvez pas déchiffrer, ou elles stockent des données que vous ne pouvez pas restaurer assez vite pour que cela ait de l’importance.
Conception de sauvegarde minimale viable
- Définir le périmètre : l’OS est-il reconstruisible ? Si oui, ne perdez pas de temps à le sauvegarder ; sauvegardez la config et les données.
- Définir RPO/RTO : combien de perte de données est acceptable et à quelle vitesse vous devez récupérer.
- Faire de la restauration un test prioritaire : chaque nouvel hôte doit subir un exercice de restauration.
Que faire immédiatement après l’installation
- Créer un instantané initial (niveau VM ou système de fichiers) une fois les vérifications de base passées.
- Lancer un job de sauvegarde et restaurer un petit fichier ou répertoire vers un chemin différent. Vérifier le contenu.
- Vérifier que les identifiants et clés de chiffrement sont stockés dans votre gestionnaire de secrets et accessibles via les procédures de break-glass.
Si votre solution de sauvegarde est « nous avons du RAID », arrêtez. Relisez cette phrase, puis corrigez votre vie.
Guide de diagnostic rapide : trouver rapidement le goulot d’étranglement
Quand une installation neuve « semble lente », ne commencez pas par l’optimisation applicative. Commencez par les chemins critiques du système. Ce playbook est ordonné : les premières vérifications captent les modes de défaillance les plus courants et à fort impact.
Première étape : la machine est-elle affamée ou malade ?
- Vérifier la charge et la saturation : CPU, iowait, pression mémoire.
- Vérifier les services échoués : réseau, sync temps, montages de stockage, échecs d’agents.
- Vérifier disque plein / inodes : c’est le classique parce que ça marche.
cr0x@server:~$ uptime
10:20:11 up 1:24, 1 user, load average: 0.12, 0.06, 0.02
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 6758208 88240 650240 0 0 1 4 75 98 1 1 98 0 0
0 0 0 6758120 88240 650240 0 0 0 0 70 90 0 0 100 0 0
1 0 0 6758020 88240 650240 0 0 0 12 88 120 2 1 97 0 0
0 0 0 6757908 88240 650240 0 0 0 0 66 85 0 0 100 0 0
0 0 0 6757800 88240 650240 0 0 0 0 69 89 0 0 100 0 0
Interprétation : Un wa élevé signifie iowait ; un r en hausse signifie des processus runnable s’accumulant ; des si/so non nuls signifient du swap. Décidez si vous êtes CPU-bound, I/O-bound ou mémoire-bound.
Deuxième étape : le stockage est-il le facteur limitant ?
- Vérifier la latence et l’utilisation des périphériques.
- Vérifier les erreurs système de fichiers et l’état des montages.
- Vérifier les coupables d’amplification d’écriture (logs, journalisation, services bavards).
cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-31-generic (server) 02/05/2026 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.21 0.00 0.62 0.05 0.00 98.12
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %util await r_await w_await
vda 5.00 8.00 80.0 120.0 0.00 0.50 2.10 1.10 0.90 1.25
Interprétation : await qui augmente et %util proche de 100 indiquent une saturation. Si la latence est élevée avant d’avoir une charge réelle, votre backend est contraint.
Troisième étape : le réseau est‑il le goulot ?
- Vérifier la perte de paquets et le RTT vers les dépendances clés.
- Vérifier la latence DNS et les échecs.
- Vérifier les retransmissions et erreurs d’interface.
cr0x@server:~$ ip -s link show ens3 | sed -n '1,12p'
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:2a:1b:2c brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
1283942 9321 0 0 0 0
TX: bytes packets errors dropped carrier collsns
902211 8010 0 0 0 0
cr0x@server:~$ dig +stats +time=2 +tries=1 archive.ubuntu.com A | tail -n 5
;; Query time: 21 msec
;; SERVER: 10.20.0.53#53(10.20.0.53)
;; WHEN: Thu Feb 05 10:22:01 UTC 2026
;; MSG SIZE rcvd: 79
Interprétation : L’interface n’a pas d’erreurs/drops ; le DNS est rapide. Si le temps de requête est de centaines/milliers de ms, le DNS est votre générateur de latence aléatoire.
Quatrième étape : validez les dépendances de l’app, pas juste l’app
Bases de données, brokers de messages, stockage objet, fournisseurs d’auth et serveurs de licence peuvent tous être le goulot. Un diagnostic rapide consiste à identifier quelle dépendance est lente, puis quelle couche (réseau vs stockage vs CPU) en est la cause.
Erreurs courantes : symptômes → cause racine → correctif
1) Symptom: disk fills up overnight
Cause racine : Logs par défaut trop verbeux, journald non borné, ou une app écrit des logs debug dans /var/log sans rotation.
Correctif : Caper journald, configurer logrotate et séparer /var ou /var/log si l’hôte est log-heavy. Vérifier avec journalctl --disk-usage et df -h.
2) Symptom: SSH works, but package installs randomly hang
Cause racine : Résolveur DNS partiellement cassé ; un résolveur timeout, provoquant des délais intermittents.
Correctif : Utiliser resolvectl status pour identifier les serveurs, retirer les résolveurs morts et confirmer les temps de requête avec dig +stats. Si vous utilisez systemd-resolved en mode stub, assurez-vous que les upstreams sont corrects.
3) Symptom: TLS errors, “certificate not yet valid,” weird auth failures
Cause racine : Le temps n’est pas synchronisé ; chrony/NTP est désactivé ou bloqué.
Correctif : Activer la synchro temporelle, autoriser UDP 123 vers les sources NTP (ou ce que votre environnement utilise), vérifier avec timedatectl et chronyc tracking.
4) Symptom: “server is slow” only during backups
Cause racine : Le job de sauvegarde sature l’I/O disque ou réseau ; pas de limitation de bande passante ; les snapshots provoquent une amplification copy-on-write sur certains systèmes de fichiers.
Correctif : Mesurer avec iostat -xz pendant la sauvegarde, fixer des limites de débit, planifier hors-peak et envisager des dispositions snapshot-friendly. Tester aussi la vitesse de restauration, pas seulement celle de la sauvegarde.
5) Symptom: reboot takes forever, then services are missing data
Cause racine : Checks système de fichiers ou montages qui échouent ; volume de données non monté ; le système continue avec des répertoires vides.
Correctif : Utiliser systemctl --failed, journalctl -b et findmnt. Ajouter x-systemd.automount ou dépendances si approprié, mais ne masquez pas la défaillance. Assurez-vous que les points de montage ne sont pas créés silencieusement sur la racine.
6) Symptom: performance regressions after “tuning”
Cause racine : Changer des paramètres noyau/sysctl sans mesures de base ; suivre un guide de tuning écrit pour d’autres noyaux ou stockages.
Correctif : Capturer une baseline (fio, iostat, vmstat) avant tuning. Changer une variable à la fois, enregistrer les résultats et être prêt à revenir en arrière. La production n’est pas votre labo.
7) Symptom: intermittent connection resets under load
Cause racine : MTU mismatch ou PMTU discovery bloqué ; parfois seuls les gros paquets échouent.
Correctif : Valider avec ping -M do et tester entre nœuds clés. Corriger le MTU de façon cohérente sur le chemin, ou autoriser la fragmentation/ICMP selon la politique.
8) Symptom: can’t log in during incident; only one admin has access
Cause racine : Pas de chemin de secours, pas de clé admin secondaire, pas d’accès console documenté.
Correctif : Ajouter au moins deux clés admin, confirmer que sudo fonctionne, documenter l’accès console/hors-bande et le tester. « Je crois que ça marche » n’est pas un contrôle.
Trois micro-histoires d’entreprise issues du terrain
Mini-histoire #1 : L’incident causé par une mauvaise hypothèse
La société A a déployé un nouveau lot de serveurs applicatifs. Le build était « standard », et l’équipe était fière : provisioning automatisé, paquets cohérents, types d’instances identiques. Ils avaient même une checklist, mais elle ressemblait surtout à une liste d’achats : installer l’agent, installer l’app, fini.
Deux semaines plus tard, ils ont subi une série d’erreurs intermittentes : timeouts de base de données, puis vagues de récupération. Les graphes CPU semblaient corrects. La mémoire aussi. L’équipe base de données insistait sur le fait que ce n’était pas de leur faute, ce qui était techniquement vrai et culturellement suspect.
Le coupable était une mauvaise hypothèse : que le stockage supportant les disques VM était un SSD local. Ce n’était pas le cas. Un changement dans le cluster de virtualisation avait déplacé ces VM vers une classe de stockage en bloc réseau avec un caching agressif et une latence tail imprévisible. En charge normale, c’était correct. Sous rafales, la latence d’écriture aléatoire montait en flèche, la queue locale de l’app s’accumulait et tout le reste semblait coupable.
La correction fut anodine : ils ajoutèrent un check fio de baseline dans la pipeline de provisioning, enregistrèrent les percentiles de latence et firent échouer les builds qui atterrissaient sur la mauvaise classe de stockage. Ils séparèrent aussi le répertoire de queue sur un volume dédié avec une performance prévisible. L’incident ne leur a pas appris à « optimiser ». Il leur a appris à vérifier ce pour quoi ils payent.
Mini-histoire #2 : L’optimisation qui a fait rebondir
La société B avait un problème qui ressemblait à un problème de stockage : volume élevé de logs d’un service bavard. Quelqu’un proposa un « gain rapide » : monter le système de fichiers des logs avec des options plus agressives pour réduire les écritures. Ils changèrent les options de montage et bidouillèrent quelques sysctls trouvés sur un billet de blog. La machine semblait correcte la première heure. Tout le monde rentra satisfait.
Puis le retour de bâton. Après un reboot non propre (maintenance hôte, rien d’exotique), le système de fichiers exigea une récupération. Le temps de démarrage explosa. Pire, le service reprit avec des pertes de données subtiles dans son répertoire d’état local parce qu’il supposait certains sémantiques fsync qui avaient été affaiblies par l’« optimisation ». L’app n’était pas conçue pour ça. La plupart ne le sont pas.
Ce qui l’a rendu douloureux n’était pas seulement la régression. C’était l’absence de mesure. Pas de chiffres I/O de base. Aucune note indiquant exactement ce qui avait changé. Aucun plan de rollback rapide. L’équipe passa plus de temps à prouver la causalité qu’à réparer.
Ils revinrent finalement aux valeurs sûres, déplacèrent les logs sur un volume séparé avec rotation stricte et réduisirent la verbosité des logs à la source. La leçon à long terme : si vous ne pouvez pas expliquer le tunning en une phrase et le valider par une mesure avant/après, ce n’est pas du tuning. C’est du cargo cult.
Mini-histoire #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
La société C gérait une flotte de services internes peu glamour : schedulers, API glue, petites bases. Rien qui mérite des talks en conférence. L’équipe avait une habitude qu’ils trouvaient trop prudente : après chaque installation neuve, ils exécutaient un test de restauration.
Pas un drill annuel. Pas un « nous avons validé le système de sauvegarde ». Une restauration littérale d’un petit sous-ensemble de données depuis la cible de sauvegarde vers un répertoire alternatif sur le nouvel hôte. À chaque fois. Le rituel devint si constant qu’il entra dans la définition de done du provisioning.
Un jour, ils ont fait tourner les identifiants de la cible de sauvegarde. Les nouvelles identifiants furent déployés sur la plupart des hôtes, mais pas tous. Le monitoring indiquait des sauvegardes « en cours », mais un sous-ensemble échouait avec des erreurs d’auth. Les échecs étaient masqués par une boucle de retry qui loguait des warnings que personne ne lisait parce que, bien sûr, les logs étaient bruyants.
Le test de restauration le détecta immédiatement sur les nouveaux hôtes. L’équipe corrigea le déploiement des identifiants avant que le trou ne devienne un désastre. Pas d’héroïsme, pas de war room, pas de reconstruction le week-end. Juste une pratique ennuyeuse avec un fort rapport signal/bruit.
FAQ
1) À quel point cette checklist doit-elle être stricte pour les environnements dev ?
Plus stricte que vous ne le pensez. Les systèmes dev sont le lieu où naissent de mauvais défauts, puis sont promus en production via « ça marchait en staging ». Vous pouvez sauter certains durcissements, mais ne sautez pas les baselines, la synchronisation temps et la sanity de la disposition des disques.
2) Dois-je utiliser ext4, XFS ou ZFS ?
Utilisez ext4 ou XFS si vous voulez des opérations prévisibles et bien comprises et que vous n’avez pas besoin de snapshots/réplication avancés. Utilisez ZFS si vous allez réellement utiliser ses forces (checksums, snapshots, réplication) et pouvez l’exploiter avec discipline.
3) Le swap est-il encore pertinent sur les serveurs ?
Oui. La bonne réponse dépend de la charge et de la tolérance aux pannes. Un petit swap peut adoucir les pics et prévenir les OOM kills. Mais un swap incontrôlé peut détruire la latence. Décidez explicitement, mettez du monitoring et testez sous charge.
4) Ai-je vraiment besoin d’un pare-feu hôte si mon réseau a des security groups ?
Généralement oui. Les security groups sont mal appliqués, dupliqués ou temporairement ouverts. Un pare-feu hôte est un second verrou. Il documente aussi l’intention directement sur la machine.
5) Quelle est l’observabilité minimale pour un seul serveur ?
Logs persistants avec rotation/caps, métriques CPU/mémoire/latence disque/réseau et monitoring de la synchronisation temps. Si vous ne pouvez pas répondre à « qu’est-ce qui a changé ? » après un incident, vous êtes sous-instrumenté.
6) Comment éviter les incidents « disque plein » sans sur-ingénierie du stockage ?
Séparez /var ou au moins /var/log quand c’est possible, capez l’usage de journald, configurez logrotate et monitorisez l’utilisation des systèmes de fichiers avec des alertes qui se déclenchent avant 95 %.
7) Quand dois-je benchmarker le disque avec fio ?
Une fois sur un système propre pour établir la baseline, et de nouveau après tout changement de backend de stockage (nouvel hôte VM, nouveau type de volume, changement de chiffrement). Gardez les tests petits et contrôlés — ne torchez pas les disques de production.
8) Quelle est la première chose à vérifier lorsque « l’app est lente » sur un hôte neuf ?
La latence disque (iostat), la pression mémoire (vmstat) et la latence DNS (dig +stats). Ces trois éléments se déguisent constamment en problèmes applicatifs.
9) Comment m’assurer que les montages ne tombent pas silencieusement ?
Utilisez findmnt dans les checks de santé, assurez-vous que les unités systemd dépendent des montages quand nécessaire, et surveillez les logs de démarrage. Évitez les designs où l’absence d’un montage amène l’app à écrire dans la racine sans s’en apercevoir.
10) Que dois-je documenter d’une installation neuve ?
Versions OS/noyau, disposition disque et types de systèmes de fichiers, config réseau (IPs/routes/DNS), sources de synchronisation temporelle, politique pare-feu, politique de mise à jour et résultats de vérification sauvegarde/restauration. Si ce n’est pas écrit, ça n’est pas arrivé.
Conclusion : prochaines étapes qui tiennent
Une checklist d’installation neuve n’est pas de la bureaucratie. C’est une réduction de latence pour vos incidents futurs. Les minutes que vous passez maintenant vous achètent de la vitesse plus tard : diagnostic plus rapide, changements plus sûrs, moins de surprises « comment en sommes-nous arrivés là ? ».
Faites ceci ensuite :
- Transformez ceci en runbook que votre équipe peut exécuter sans vous. Stockez-le avec votre code d’infrastructure.
- Automatisez les vérifications qui peuvent l’être : unités failed, utilisation disque, sync temps, test fio baseline (là où c’est sûr) et contrôles pare-feu/SSH.
- Exigez une preuve pour les sauvegardes : un test de restauration par nouvel hôte, consigné comme artefact.
- Capturez des baselines (CPU/mémoire/disque/réseau) et conservez-les. Sans baselines, vous n’avez que des opinions.
Si vous ne faites rien d’autre, retenez la thèse : vous n’installez pas un serveur. Vous installez un futur processus de réponse aux incidents. Rendez-le aimable pour vous.