Mise à niveau vs installation propre : laquelle est plus rapide et moins sujette aux bugs ?

Voici le contexte : vous avez besoin d’un OS plus récent, d’un noyau plus récent, d’un hyperviseur mis à jour, ou simplement d’une baseline de sécurité qui empêche les auditeurs de souffler dans un sac en papier. Il vous faut aussi que la machine continue à servir le trafic, que ses données restent intactes et que votre semaine ne se transforme pas en feuille de calcul de la honte.

La question paraît simple — mettre à niveau sur place ou faire une installation propre ? — mais la réponse dépend surtout de comment votre système a échoué la dernière fois, pas de ce que la page marketing du fournisseur promet.

Le vrai compromis : le temps calendrier vs le temps dans le canal d’incidents

« Plus rapide » n’est pas le temps CPU. C’est le temps calendrier : combien de temps avant que le système soit de nouveau en service en toute sécurité et avec un comportement prévisible. « Moins bogué » n’est pas moins de bugs en amont ; c’est moins de surprises causées par votre propre environnement : anciennes config, dérive, paquets orphelins, pilotes obsolètes, et cette règle udev écrite en 2019 et laissée à fossiliser.

Les mises à niveau et les installations propres échouent de manières différentes :

• Mises à niveau conservent l’état. C’est à la fois l’avantage et le piège. Elles échouent souvent sur des bords de compatibilité : changements de format de config, conflits de dépendances, incompatibilités ABI, modules noyau tiers, ou « ça boot, mais la moitié des services est silencieusement cassée ».
• Installations propres réinitialisent l’état. Elles échouent souvent par état manquant : config oubliée, certificats manquants, permissions erronées, points de montage absents, ou « ça marche mais ce n’est pas votre système ».

En tant que SRE, je le dis sans détour : si vous ne pouvez pas décrire votre système comme du code (ou au moins comme un runbook reproductible), alors les mises à niveau in-place sont essentiellement de l’archéologie. Si vous pouvez le décrire, les installations propres deviennent ennuyeuses, ce qui est le plus grand compliment en exploitation.

Une citation, parce que c’est toujours le bon modèle mental : L’espoir n’est pas une stratégie. (idée paraphrasée, souvent attribuée aux équipes d’ingénierie opérationnelle)

Lequel est vraiment plus rapide (et quand) ?

Quand les mises à niveau sont plus rapides

Les mises à niveau sont généralement plus rapides quand :

• La machine est stateful et vous ne pouvez pas déplacer facilement les données (jeux de données locaux volumineux, stockage direct sans réplication, contrôleurs matériels spéciaux).
• Vous suivez un chemin mineur→mineur ou LTS→LTS suivant que le fournisseur supporte réellement. Les chemins d’upgrade supportés sont des routes pavées ; les chemins non supportés sont des pistes forestières.
• Votre surface de configuration est énorme et mal documentée. La mise à niveau conserve votre bazar, ce qui est parfois la moins mauvaise option sous contrainte.
• Les fenêtres d’indisponibilité sont courtes et vous pouvez accepter un rollback vers un snapshot/image plutôt qu’une reprovision complète.

Mais la partie « rapide » est trompeuse. Une mise à niveau in-place est rapide jusqu’à ce qu’elle ne le soit plus, et alors vous déboguez dans le pire environnement possible : un système à moitié modifié où les logs et les services ne sont pas d’accord sur le siècle.

Quand les installations propres sont plus rapides

Les installations propres sont souvent plus rapides quand :

• Le service est sans état ou peut être rendu effectivement sans état (données externalisées vers une base gérée, stockage répliqué, objet store, ou un volume séparé).
• Vous disposez d’automatisation (PXE/Kickstart/Preseed, cloud-init, Terraform + gestion de configuration, images golden).
• Vous sautez plusieurs versions majeures où les configs et les valeurs par défaut ont changé substantiellement.
• Vous avez accumulé de la dérive—et vous avez des raisons de le croire, ce qui vaut pour la plupart des environnements âgés de plus d’un an.

La vitesse de l’installation propre vient du parallélisme : vous pouvez construire un nouveau nœud pendant que l’ancien sert encore le trafic, le valider, puis basculer. Les mises à niveau sont généralement sérielles : vous devez toucher le nœud live (ou son clone) et attendre.

Ma règle opinionnée

Si vous pouvez construire un nœud frais et basculer sans toucher dangereusement au plan de données, l’installation propre gagne à la fois sur la vitesse et sur les bugs dans la plupart des environnements de production réels. Si le nœud est une snowflake avec des données « pet » sur disques locaux et des contraintes inconnues, une mise à niveau soigneusement étagée est souvent plus sûre que de prétendre pouvoir le reconstruire de mémoire.

Blague #1 : Une mise à niveau sur place, c’est comme changer un pneu pendant que la voiture avance — parfois ça marche, et vous en apprenez beaucoup sur la physique.

Lequel est moins bogué (et pourquoi « bogué » est généralement « état inconnu »)?

Les « bugs » après un changement sont généralement l’un de ces cas :

• Collisions de dérive de configuration : vos anciens surcharges se battent avec les nouveaux défauts. Le système « fonctionne » mais pas comme vous le pensez.
• Graphes de dépendances incontrôlés : paquets anciens verrouillant des versions, dépôts tiers injectant des surprises, ou changement ABI d’une librairie cassant un binaire.
• Incompatibilité pilote/noyau : GPU, offload NIC, HBA de stockage, ou modules DKMS qui ne se compilent plus après un bump de noyau.
• Transitions de format d’état : migration de format disque de base de données, flags de fonctionnalités du système de fichiers, changements de bootloader.
• Lacunes d’observabilité : vous ne savez pas ce qui a changé parce que vous n’avez pas capturé l’état préalable, donc vous ne pouvez pas prouver la causalité.

Mises à niveau : moins de travail en amont, plus de risques dans les coutures

Une mise à niveau préserve votre baseline connue-bonne — plus votre bazar inconnu-mauvais. Si votre système est propre et bien géré, les upgrades passent. Si c’est un serveur de longue durée avec des modifications manuelles, des agents fournisseurs et des contournements « temporaires », les upgrades amplifient l’incertitude. Le système démarre, mais il démarre dans une vitrine de musée.

Installations propres : plus de travail en amont, moins d’entropie

Une installation propre vous force à redéclarer l’intention : paquets, configuration, services, montages, utilisateurs, secrets, paramètres noyau, tuning. C’est ennuyeux exactement une fois. Après ça, c’est une recette reproductible. La plupart de la « réduction des bugs » après une installation propre revient simplement à supprimer de l’état ancien que vous ne vous souvenez plus avoir ajouté.

Blague #2 : Une installation propre est formidable parce qu’elle supprime tous vos problèmes — jusqu’à supprimer la configuration dont vous aviez vraiment besoin.

Faits intéressants et contexte historique (la version courte et utile)

1. Les mises à niveau in-place sont devenues courantes pour les flottes seulement après la maturation de la gestion de paquets fiable et des idées d’updates transactionnels ; les anciens sites Unix reconstruisaient souvent depuis les médias car les upgrades étaient de la roulette.
2. Le « repair install » Windows et les outils d’upgrade in-place ont été conçus pour préserver l’état utilisateur, parce que le monde desktop considère la perte de données comme un péché cardinal et la friction de réinstallation comme un coût de support.
3. Les distributions Linux préféraient historiquement les installations fraîches pour les sauts majeurs parce que les systèmes d’init, les layouts de fichiers et les daemons par défaut changeaient ; le concept de « chemin d’upgrade supporté » s’est durci avec le temps.
4. ZFS et les systèmes de fichiers modernes ont introduit des flags de fonctionnalités activables après upgrade ; une fois activés, revenir à d’anciennes versions devient plus difficile ou impossible sans planification.
5. UEFI a remplacé les hypothèses BIOS legacy ; les upgrades touchant le bootloader peuvent échouer de nouvelles manières (entrées EFI incorrectes, ESP non monté) que les installations propres gèrent plus systématiquement.
6. La gestion de configuration (CFEngine, Puppet, Chef, Ansible) a poussé l’industrie vers rebuild-and-replace parce que cela réduisait la dépendance au « savoir tribal ».
7. Les approches d’images immuables (golden images, AMIs, images conteneurs) ont rendu l’« installation propre » par défaut dans les organisations cloud-native, car une nouvelle instance coûte moins cher que déboguer une ancienne.
8. L’écosystème des modules noyau (DKMS, pilotes fournisseurs) s’est étendu ; les upgrades sont plus fragiles si vous dépendez de modules hors arbre, surtout pour le stockage et le réseau.
9. L’essor de systemd a changé la gestion des services et les attentes en matière de journalisation ; les upgrades traversant cette frontière étaient réputés pour « ça démarre, mais pas comme avant ».

Trois mini-histoires d’entreprise (parce que la théorie ment)

Mini-histoire 1 : L’incident causé par une fausse supposition

Ils avaient un petit cluster de serveurs applicatifs qui « ne stockaient rien d’important localement ». Cette phrase est apparue dans un document de planification et a vécu là pendant des années, gagnant de l’autorité comme un fossile devient une plaque de musée.

Pendant un trimestre chargé, ils ont choisi les installations propres pour aller vite. Nouvelles images, nouveaux noyaux, tout neuf. Le plan de cutover était simple : drainer le trafic, terminer l’ancien nœud, démarrer le nouveau, répéter. Tout se passait bien — jusqu’à ce que le premier nœud revienne et commence à servir des 500 pour un petit pourcentage de requêtes.

La fausse supposition : le disque local contenait en fait un état important. Pas des données client, mais un cache de templates pré-calculés plus un ensemble de certificats clients TLS par nœud utilisés pour l’auth mutualisée vers une dépendance legacy. Ces certificats avaient été émis il y a des années, copiés manuellement et jamais renouvelés parce que « on réparera plus tard ». Les nouveaux nœuds ne les avaient pas.

L’incident n’était pas spectaculaire. Il était pire : intermittent. Seules les requêtes empruntant certains chemins rencontraient la dépendance cassée, et seuls certains des nouveaux nœuds étaient affectés au fur et à mesure du déploiement.

Correction : ils ont pausé le rollout, extrait l’état manquant d’un ancien nœud, l’ont installé sur les nouveaux, et ensuite — c’est la partie importante — ont déplacé ces certificats dans un vrai mécanisme de distribution de secrets pour que la prochaine reconstruction ne dépende plus de l’archéologie.

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

Une autre entreprise voulait des « upgrades zéro-downtime » sur des réplicas de base de données. Ils ont construit une pipeline astucieuse : snapshot de la VM, mise à niveau OS in-place sur le snapshot, démarrer en isolation, puis permuter. Intelligent, non ?

En grande partie. L’optimisation était d’éviter une validation profonde du stockage parce que « ça ralentit la pipeline ». Ils n’ont pas exécuté de scrubs filesystem ni vérifié la santé SMART ; ils ont supposé que le snapshot était un point sûr.

Après quelques cycles, ils ont rencontré un mode défaillant vicieux : le replica upgradé tournait bien pendant des heures puis paniquait sous charge I/O. Ce n’était pas l’OS. Le stockage sous-jacent avait un SSD marginal corrigeant des erreurs qui devenaient irrécupérables sous écritures soutenues, et le nouveau noyau exposait la faiblesse plus rapidement via l’ordonnanceur I/O.

La pipeline a été blâmée, puis l’OS, puis l’équipe stockage a été appelée à 3h du matin. La cause racine était peu glamour : ils avaient optimisé hors des vérifications ennuyeuses qui auraient montré que le device se dégradait.

Correction : ils ont réintroduit des gates de santé pré-upgrade (SMART, mdadm, ZFS pool status, scrub age) et la « pipeline rapide » est redevenue rapide parce qu’elle a cessé de produire des artefacts cassés.

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

Une organisation SaaS gérait une flotte mixte : certains nœuds étaient d’anciens pets, d’autres de la cattle plus récente. Ils devaient faire un saut OS majeur plus un upgrade de noyau pour conformité. Tout le monde s’attendait à des douleurs.

Mais une équipe avait une habitude terne : avant tout changement, elle capturait un artefact « contrat système » — liste de paquets, services activés, ports à l’écoute, table de montages, deltas sysctl, et un petit ensemble de tests smoke fonctionnels. Ils le stockaient avec la demande de changement. Pas chic, juste consistant.

Ils ont choisi une installation propre pour la plupart des nœuds. Lors de la validation, ils ont remarqué une seule divergence : les nouveaux nœuds ne montaient pas un volume secondaire contenant les logs d’audit. Le service fonctionnait, mais la conformité non. Grâce à l’artefact contrat, ils ont repéré le montage manquant en quelques minutes, pas après qu’un auditeur ait posé une question pointue.

Ils ont corrigé le provisioning pour monter et étiqueter correctement le volume, relancé la construction, et ont continué. Pas d’héroïsme. Pas de devinettes à minuit. Juste des preuves.

Playbook de diagnostic rapide : trouvez le goulet d’étranglement avant de changer de plan

Si vous êtes déjà en pleine mise à niveau (ou reconstruction) et que ça dérape, ne paniquez pas. Diagnostiquez dans une séquence qui réduit rapidement le périmètre du problème.

Première question : est-ce le démarrage/OS, la configuration des services, ou le chemin de données ?

• Couche Boot/OS : noyau, initramfs, bootloader, drivers. Symptômes : ne boot pas, drop en initramfs, root introuvable, kernel panic.
• Couche service : unités systemd, configs, permissions, secrets. Symptômes : boot ok, mais services qui ne démarrent pas, erreurs de bind, échecs d’auth.
• Chemin de données : montages de stockage, intégrité des systèmes de fichiers, routes réseau, DNS, load balancer. Symptômes : services démarrent mais timeout, latence élevée, erreurs intermittentes.

Deuxième étape : classer la défaillance en déterministe ou heisenbug

• Déterministe : échoue à chaque fois, même log. Généralement config, dépendance manquante, mauvais chemin de fichier, module incompatible.
• Heisenbug : intermittent, lié à la charge. Généralement limites de ressources, comportement noyau/driver modifié, problèmes matériels latents, conditions de course exposées par des différences de timing.

Troisième étape : décider rollback, pause, ou poursuivre

• Rollback si : vous ne pouvez pas expliquer le mode de défaillance en moins d’une heure, ou la correction serait « essayer des paquets au hasard ».
• Pause et cloner si : vous avez besoin de temps forensique. Snapshot/cloner le disque/VM, déboguer hors ligne, garder la production stable.
• Poursuivre si : l’erreur est bien circonscrite, vous pouvez valider avec des tests, et vous pouvez revenir en arrière.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Voici les vérifications que j’exécute réellement. Pas parce que j’aime taper, mais parce que deviner coûte cher.

Task 1: Confirm what you’re actually running (kernel + OS)

cr0x@server:~$ uname -r
6.5.0-21-generic
cr0x@server:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
VERSION_ID="22.04"

Ce que cela signifie : Vous ne déboguez pas « Linux ». Vous déboguez ce noyau et cette distribution.

Décision : Si la cible d’upgrade saute des versions majeures, supposez que les configs et valeurs par défaut ont changé. Préférez l’installation propre sauf si vous avez un runbook d’upgrade éprouvé.

Task 2: See what changed recently (packages)

cr0x@server:~$ grep " install \| upgrade " /var/log/dpkg.log | tail -n 5
2026-02-03 10:14:22 upgrade openssl:amd64 3.0.2-0ubuntu1.15 3.0.2-0ubuntu1.16
2026-02-03 10:14:28 upgrade systemd:amd64 249.11-0ubuntu3.12 249.11-0ubuntu3.13
2026-02-03 10:14:31 upgrade linux-image-6.5.0-21-generic:amd64 6.5.0-21.21~22.04.1 6.5.0-21.21~22.04.2

Ce que cela signifie : Une régression survenue « après l’upgrade » corrèle généralement à une courte liste. C’est votre liste de suspects.

Décision : Si un composant central a changé (kernel/systemd/openssl), validez explicitement services et drivers. N’assumez pas que « ça va ».

Task 3: Check failed services fast

cr0x@server:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● nginx.service       loaded failed failed  A high performance web server and a reverse proxy server
● myapp.service       loaded failed failed  MyApp API Service

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

Ce que cela signifie : Si systemd indique un échec, arrêtez de débattre d’architecture. Lisez les logs.

Décision : Si plusieurs services sans rapport échouent après l’upgrade, suspectez des montages manquants, des permissions ou une casse de librairies ; envisagez rollback ou passez à une installation propre avec capture de config.

Task 4: Pull service logs with useful boundaries

cr0x@server:~$ journalctl -u nginx.service -b --no-pager | tail -n 12
Feb 03 10:16:02 server nginx[1123]: nginx: [emerg] cannot load certificate "/etc/nginx/tls/api.pem": BIO_new_file() failed
Feb 03 10:16:02 server systemd[1]: nginx.service: Failed with result 'exit-code'.
Feb 03 10:16:02 server systemd[1]: Failed to start A high performance web server and a reverse proxy server.

Ce que cela signifie : L’OS est correct ; l’état requis par l’app (certificat) est manquant ou les permissions ont changé.

Décision : Mode d’échec typique d’installation propre : secrets/config manquants. Corrigez le provisioning/distribution de secrets, ne copiez pas à la main en mode « juste une fois ».

Task 5: Validate mounts and fstab correctness

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS | head
TARGET  SOURCE        FSTYPE OPTIONS
/       /dev/sda2     ext4   rw,relatime
/boot   /dev/sda1     vfat   rw,relatime,fmask=0022,dmask=0022
/data   /dev/sdb1     ext4   rw,relatime

Ce que cela signifie : Le volume de données est monté là où les services s’y attendent.

Décision : Si les montages attendus sont absents, stoppez. Corrigez les problèmes de stockage/montage avant de diagnostiquer les erreurs applicatives.

Task 6: Confirm filesystem and block device health (SMART)

cr0x@server:~$ sudo smartctl -H /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.5.0-21-generic] (local build)
SMART overall-health self-assessment test result: PASSED

Ce que cela signifie : « PASSED » n’est pas une garantie, mais « FAILED » est une alerte majeure.

Décision : Si SMART échoue ou montre des erreurs média, ne poursuivez pas l’upgrade/rebuild tant que le matériel n’est pas traité. Sinon, vous attribuerez à tort la corruption des données au changement d’OS.

Task 7: If you use mdadm RAID, ensure arrays are clean

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[0] sdb3[1]
      976630336 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Ce que cela signifie : [UU] veut dire que les deux membres sont opérationnels. Tout autre état signifie dégradé.

Décision : Si dégradé, évitez les gros changements. Réparez l’array d’abord ou vous transformerez « upgrade » en « restore from backup ».

Task 8: If you use ZFS, check pool status and feature flags

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:12:11 with 0 errors on Sun Feb  2 01:10:33 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sdc       ONLINE       0     0     0
          sdd       ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Scrub récent, pas d’erreurs. Bonne baseline.

Décision : Si le scrub est ancien ou si des erreurs existent, lancez un scrub et réparez avant tout travail OS. Les problèmes de stockage masqueront les régressions d’upgrade.

Task 9: Compare sysctl deltas (catch performance surprises)

cr0x@server:~$ sysctl -a 2>/dev/null | grep -E 'net.core.somaxconn|vm.swappiness'
net.core.somaxconn = 4096
vm.swappiness = 10

Ce que cela signifie : Ces valeurs affectent l’ordonnancement des queues et le comportement mémoire. Les upgrades peuvent réinitialiser les tunings personnalisés.

Décision : Si les valeurs sont revenues aux défauts (ou diffèrent de votre baseline), réappliquez le tuning via gestion de configuration, pas des edits ad-hoc.

Task 10: Spot a dependency conflict before it burns you

cr0x@server:~$ sudo apt-get -s dist-upgrade | tail -n 12
The following packages will be REMOVED:
  vendor-agent dkms-nvidia
The following packages will be upgraded:
  libc6 openssl systemd
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

Ce que cela signifie : La simulation montre des suppressions. Supprimer des modules noyau ou agents fournisseurs peut casser le réseau/le stockage ou la conformité.

Décision : Si l’upgrade veut supprimer des modules/agents critiques, stoppez et planifiez : pinner des versions, mettre à jour le repo fournisseur, ou choisir une installation propre avec drivers supportés intégrés à l’image.

Task 11: Check bootloader/EFI basics (common upgrade footgun)

cr0x@server:~$ mount | grep -E ' /boot | /boot/efi '
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077)

Ce que cela signifie : La partition système EFI est montée. Les mises à jour du bootloader peuvent y écrire.

Décision : Si /boot/efi n’est pas monté pendant une upgrade qui touche grub/systemd-boot, vous risquez un système qui upgrade mais ne bootera plus. Montez-le et relancez les étapes du bootloader.

Task 12: Validate network identity and routes (post-reinstall classic)

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens160           UP             10.20.30.41/24
cr0x@server:~$ ip route
default via 10.20.30.1 dev ens160
10.20.30.0/24 dev ens160 proto kernel scope link src 10.20.30.41

Ce que cela signifie : Le nommage des interfaces et le routage correspondent aux attentes. Les installations propres renomment parfois les NICs ou oublient la config VLAN.

Décision : Si l’IP/le sous-réseau/la route par défaut diffère de la baseline, corrigez la config réseau avant de blâmer les changements applicatifs.

Task 13: Confirm DNS and resolver behavior (because everything is “the network”)

cr0x@server:~$ resolvectl status | sed -n '1,20p'
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

Ce que cela signifie : Vous utilisez systemd-resolved en mode stub, avec les serveurs DNS attendus.

Décision : Si le mode resolver a changé (commun après des upgrades), ajustez votre image de base et votre monitoring. Les régressions DNS ressemblent à des timeouts applicatifs.

Task 14: Compare open ports and listeners (functional contract)

cr0x@server:~$ sudo ss -lntp | head -n 10
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511    0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1201,fd=6))
LISTEN 0      4096   127.0.0.1:5432     0.0.0.0:*     users:(("postgres",pid=1302,fd=5))

Ce que cela signifie : Les services écoutent là où vous l’attendez. Après un changement, « up » doit signifier « accepte des connexions ».

Décision : Si les listeners manquent ou sont liés à localhost de façon inattendue, corrigez les configs de service, les firewalls, ou les overrides systemd.

Task 15: Catch permission/ownership drift on state directories

cr0x@server:~$ sudo namei -l /var/lib/myapp
f: /var/lib/myapp
drwxr-xr-x root  root  /
drwxr-xr-x root  root  var
drwxr-xr-x root  root  lib
drwx------ root  root  myapp

Ce que cela signifie : Le répertoire est possédé par root avec 0700. Si le service tourne en tant que myapp, il ne peut pas écrire ici.

Décision : Corrigez ownership/permissions dans le provisioning (systemd tmpfiles, postinst de paquet, ou gestion de config). Ne faites pas de chmod au pif sous pression.

Task 16: Performance sanity: is it CPU, memory, or I/O?

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
 1  0      0 521124  80340 942112    0    0    15    38  210  480  3  1 95  1  0
 2  0      0 498300  80344 951020    0    0    12  2100  320  620  5  2 70 23  0

Ce que cela signifie : Un wa élevé (I/O wait) suggère un goulet de stockage. Les noyaux et drivers post-upgrade peuvent changer le comportement I/O.

Décision : Si l’I/O wait augmente, inspectez la latence disque et les paramètres d’ordonnanceur avant de blâmer l’application.

Erreurs courantes : symptômes → cause racine → correctif

1) « Upgrade terminé, mais les services ne démarrent pas »

Symptômes : systemctl montre des échecs ; les logs mentionnent fichiers manquants, directives inconnues, ou permission denied.

Cause racine : changements de format de config, modules retirés, ou répertoires d’état avec ownership incorrect après changements de paquets.

Fix : Différez la config par rapport aux défauts fournisseur ; exécutez des outils de validation de config (ex. nginx -t) ; imposez l’ownership via le provisioning. Si plus de deux services critiques échouent, envisagez rollback et rebuild avec une config contrôlée.

2) « L’installation propre fonctionne, mais des échecs d’auth intermittents »

Symptômes : certaines requêtes échouent en mTLS, tokens API invalides, upstream qui rejette seulement certains nœuds.

Cause racine : secrets mal distribués, certificats/clefs clients manquants, synchronisation temporelle incorrecte, ou mismatch d’identité d’hôte.

Fix : validez l’injection de secrets et la sync temporelle ; assurez-vous que hostnames et SANs des certificats s’alignent ; arrêtez le copying manuel et utilisez un mécanisme unique de distribution.

3) « Après upgrade, les performances disque ont régressé »

Symptômes : latence plus élevée, I/O wait augmenté, bases qui stallent, fsync plus lent.

Cause racine : changements d’ordonnanceur I/O noyau, différences de drivers, changements de politique de write cache, ou un problème matériel latent exposé par de nouveaux patterns.

Fix : comparez scheduler et paramètres de queue ; vérifiez SMART/ZFS/mdadm ; lancez des benchmarks ciblés sur la même charge ; si le matériel est marginal, remplacez-le avant de tuner.

4) « Le système ne boot pas après upgrade »

Symptômes : drop en initramfs, root introuvable, grub rescue, entrée EFI manquante.

Cause racine : initramfs sans drivers de stockage, /boot ou ESP non monté pendant la mise à jour du bootloader, UUID changés, ou fstab incorrect.

Fix : assurez-vous que /boot et /boot/efi sont montés pendant l’upgrade ; régénérez initramfs ; vérifiez les UUID ; gardez une entrée kernel connue-bonne ; testez le reboot en fenêtre de maintenance, pas à 14h.

5) « L’upgrade a supprimé un driver/agent fournisseur »

Symptômes : module DKMS échoue, offload NIC disparaît, chemins de stockage changent, agent de conformité manquant.

Cause racine : dépôt tiers non supporté, conflits de paquets, bump ABI noyau cassant la compilation du module.

Fix : alignez le repo fournisseur sur l’OS cible ; pinner des paquets ; ou choisissez une installation propre avec la version du driver supportée bakeée dans l’image.

6) « L’installation propre a pris plus de temps que l’upgrade… parce qu’on a oublié la moitié du système »

Symptômes : retards répétés de cutover, cron jobs manquants, rotation des logs absente, sysctl manquant, ulimits incorrects.

Cause racine : pas de capture baseline ; la config existait comme savoir tribal et des edits non tracés.

Fix : créez un contrat système : liste de paquets, services, montages, ports, sysctl, cron, utilisateurs/groupes, règles firewall, certificats. Utilisez-le comme critères d’acceptation.

Checklists / plan étape par étape

Checklist de décision : mise à niveau ou installation propre ?

• Localité des données : Des données critiques sont-elles sur disque local sans réplication/snapshots fiables ? Si oui, penchez pour l’upgrade (ou planifiez d’abord une migration de données soigneuse).
• Maturité de l’automatisation : Pouvez-vous provisionner un nouveau nœud prêt en moins d’une heure avec peu d’étapes manuelles ? Si oui, penchez installation propre.
• Support du chemin d’upgrade : Votre saut est-il supporté par le fournisseur/distro ? Si non, penchez installation propre.
• Modules noyau tiers : Dépendrez-vous de modules DKMS/hors-arbre (stockage/NIC/GPU) ? Si oui, testez agressivement ; l’installation propre avec drivers validés gagne souvent.
• Capacité de rollback : Pouvez-vous snapshot/rollback rapidement ? Si oui, le risque d’upgrade diminue. Sinon, préférez rebuild et cutover.
• Dérive de config : Suspectez-vous des années d’édition manuelle ? Si oui, l’installation propre paye la dette—à condition que vous puissiez reconstruire l’état requis.

Étapes : mise à niveau in-place plus sûre (esprit production)

1. Capturer la baseline : OS/noyau, liste de paquets, montages, listeners, statut des services, deltas sysctl.
2. Gates de santé : santé du stockage (SMART/ZFS/mdadm), espace disque libre, pression mémoire, logs d’erreur.
3. Simuler l’upgrade : dry-run des opérations de paquet ; noter les suppressions et transitions majeures de versions.
4. Étager sur un clone : snapshot VM/disque ; exécuter l’upgrade sur le clone ; répéter le reboot.
5. Valider : démarrage des services, ports, tests smoke fonctionnels, sanity des logs, baseline de latence.
6. Exécuter en fenêtre : upgrader la prod, reboot, valider rapidement, puis monitorer au moins un cycle de charge.
7. Critères de rollback : définir une limite de temps stricte et des échecs spécifiques déclenchant le rollback.

Étapes : installation propre avec cutover (l’approche « l’ennuyeux est bon »)

1. Inventorier l’état : ce qui doit persister (volumes de données, secrets, certificats, identité d’hôte, règles firewall).
2. Construire l’image : OS de base, paquets, noyau, drivers, monitoring/agents.
3. Appliquer la configuration : depuis du code ou un runbook strict ; évitez « just ssh in ».
4. Attacher ou monter les données : valider labels/UUIDs du système de fichiers ; vérifier les permissions.
5. Test fonctionnel : endpoint de santé, connexions DB, jobs background, handshake TLS, flux d’auth.
6. Trafic en shadow (si possible) : mirror des lectures en mode read-only ou exécution d’un canary.
7. Cutover : swap derrière le load balancer/DNS ; garder l’ancien nœud pour un backout rapide.
8. Audit post-cutover : comparer listeners, logs, métriques et bruit d’alertes ; puis décommissionner l’ancien nœud.

FAQ

1) Une installation propre est-elle toujours moins boguée ?

Non. Elle est moins boguée si vous pouvez recréer correctement l’état requis. Sinon, c’est une installation propre d’un design cassé, et c’est très efficace pour échouer.

2) Les mises à niveau in-place sont-elles toujours risquées ?

Pas toujours. Elles sont raisonnables pour des chemins d’upgrade supportés sur des systèmes bien gérés avec peu de dérive et un rollback fiable. Le risque augmente avec des modules tiers, des serveurs longtemps vivants, et des edits manuels inconnus.

3) Et « réinstaller mais garder /home » (ou préserver des partitions de données) ?

C’est un hybride qui peut bien fonctionner. Vous obtenez une couche OS propre tout en conservant les données. Le point acéré est les permissions, la consistance UID/GID, et les attentes de montage. Validez ces points explicitement.

4) Pour les bases de données : upgrade ou rebuild ?

Préférez reconstruire les réplicas et effectuer un basculement contrôlé plutôt que d’upgrader le primaire in-place. Pour les bases single-node, les upgrades peuvent convenir, mais seulement avec des backups vérifiés et un plan de rollback testé.

5) Quel est le plus grand time sink caché ?

Les secrets et l’identité : certificats, clés API, auth basée sur l’hôte, et le fichier aléatoire dans /etc qui rend votre système « spécial ». Mettez-les dans un système géré ou vos rebuilds seront lents et sujets à erreurs.

6) Comment décider rollback vs continuer à déboguer ?

Si vous ne pouvez pas formuler une hypothèse falsifiable à partir des logs et diffs en une heure, rollbackez. Déboguer un système à moitié upgradé sous pression, c’est créer du folklore au lieu de correctifs.

7) La containerisation change-t-elle la réponse ?

Oui. Si l’app tourne dans des conteneurs et que l’hôte n’est qu’un substrat, l’installation propre (ou le remplacement immuable de l’hôte) devient la norme. Les upgrades d’hôte restent importants pour le noyau, le stockage et le réseau, mais l’état applicatif est moins emmêlé.

8) Et si les drivers matériels posent problème ?

Vous aurez alors besoin d’un plan de compatibilité plutôt que d’un débat philosophique. Pour les HBA de stockage et les NICs, validez le support des drivers sur l’OS/noyau cible d’abord ; si le support est incertain, l’installation propre ne vous sauvera pas.

9) Quelle est la manière la plus sûre de gérer les sauts de version majeurs ?

Construisez du neuf, testez intensément, basculez progressivement. Les sauts majeurs sont ceux où les comportements par défaut changent et où les réglages dépréciés meurent enfin. Traitez-les comme des migrations, pas comme de simples « upgrades ».

10) Comment éviter que les installations propres deviennent lentes ?

Rendez le système décrivable : gestion de configuration, pipelines d’images, et un artefact contrat système pour validation. La première fois est du travail ; la deuxième fois, c’est rapide.

Prochaines étapes que vous pouvez faire cette semaine

Si vous voulez vitesse et moins de bugs, cessez de traiter upgrades et reinstalls comme des rituels. Traitez-les comme des transitions d’état contrôlées.

1. Créez un script de capture baseline qui enregistre OS/noyau, liste de paquets, services en échec, montages, listeners, et sysctls clés. Stockez-le avec vos tickets de changement.
2. Ajoutez des gates de santé avant tout changement majeur : checks SMART/ZFS/mdadm et exigences de « scrub récent ».
3. Choisissez un service et rendez-le reconstruisible de bout en bout avec un minimum d’étapes manuelles. Mesurez le temps. Corrigez les trois principales frictions (généralement secrets, montages et identité).
4. Définissez des critères de rollback pour les upgrades : limites de temps, budgets d’erreur, et ce que « terminé » signifie en métriques, pas en impressions.
5. Pour les systèmes stateful, concevez l’architecture suivante pour que la réinstallation devienne facile : externalisez l’état, répliquez les données, et gardez les hôtes jetables.

Mon opinion finale : si votre environnement le permet, par défaut choisissez l’installation propre avec cutover. Réservez les mises à niveau in-place aux états vraiment difficiles à migrer ou aux chemins strictement supportés et testés. La production ne récompense pas la bravoure ; elle récompense la répétabilité.