Ports avec fonctionnalités manquantes : « C’est là » ne veut pas dire que ça fonctionne

Ce que ce problème est vraiment (et pourquoi il se répète)

« Port » est un mot surchargé. Parfois cela signifie « ça compile et ça passe les tests unitaires. » Parfois cela signifie « on peut le construire dans notre distro. » Parfois cela signifie « on a exposé l’API, mais l’implémentation est un no-op. » Et parfois cela signifie « ça marche si vous plissez les yeux et évitez la moitié des fonctionnalités. »

En production, un port avec fonctionnalités manquantes est généralement l’un des cas suivants :

• Présence à la compilation sans capacité à l’exécution. Le binaire inclut du code, mais le noyau, le système de fichiers, le matériel ou les permissions bloquent le chemin.
• Implémentation partielle. Le « happy path » fonctionne, les conditions limites non, et ce sont précisément ces limites que la production rencontre : erreurs, congestion, resynchronisation, rollback.
• Décalage des verrous de fonctionnalité. L’interrupteur existe, mais l’activation ne prend pas effet parce qu’un prérequis manque (config noyau, option de module, sysctl, firmware).
• Repli silencieux. Le système affirme le succès, mais retombe sur un mode plus lent ou moins sûr. Vous ne le remarquez qu’après le premier incident — ou la première facture.
• Dérive de version et d’ABI. Un port correspond aux en-têtes upstream mais pas au comportement upstream ; assez compatible pour compiler, suffisamment différent pour casser la sémantique.

Pourquoi cela se répète est plus simple que nous voudrions l’admettre : les ports sont souvent financés pour atteindre « ça tourne », pas « ça se comporte ». Les tests se concentrent sur la correction fonctionnelle, pas sur la correction par absence : que se passe-t-il quand la fonctionnalité est manquante, à moitié présente, ou présente mais incompatible.

Et la pire catégorie est la « correction de la documentation » sans « correction opérationnelle ». Si votre page de fonctionnalité s’arrête à « régler enable=true », félicitations — vous avez écrit un communiqué de presse, pas un guide d’exploitation.

Une vérité opérationnelle sèche : la parité fonctionnelle est rarement binaire. C’est une matrice : version du noyau × patchs de la distro × libc × système de fichiers × firmware × modèle de sécurité × couche d’orchestration × profil de charge de travail. Un port peut être « là » sur six de ces dimensions et manquer sur la septième. Devinez laquelle la production trouve.

Blague n°1 : Une fonctionnalité qui ne marche qu’en laboratoire s’appelle « une démo ». En production, on l’appelle « une répétition d’incident ».

Le piège du « porté » : les déclarations de compatibilité ne sont pas des promesses de performance

Une lecture courante : « Pris en charge » est interprété comme « rapide », « sûr » ou « équivalent ». Les fournisseurs et équipes plateforme internes signifient souvent une promesse plus étroite : « ne plantera pas immédiatement » ou « fonctionne avec les paramètres par défaut ».

Pour le stockage et la fiabilité, cela ne suffit pas. Vous devez répondre à :

• Est-ce que cela préserve les semantiques de durabilité (fsync, barrières, vidage de cache) en cas de perte d’alimentation ?
• Gère-t-il correctement le mode dégradé (basculement multipath, reconstruction RAID, backfill d’un store d’objets) ?
• Maintient-il les SLO de latence sous compaction, GC, resync et snapshotting ?
• Expose-t-il de l’observabilité (compteurs, tracepoints, logs) pour prouver qu’il fonctionne ?

Si vous ne pouvez pas le prouver sous contrainte, vous n’avez pas une fonctionnalité. Vous avez une opinion.

Quelques faits et contexte historique à garder en tête

Ce ne sont pas des anecdotes pour la forme. Ils expliquent pourquoi « c’est là » signifie si souvent « pas vraiment ».

1. La compatibilité POSIX a toujours été un spectre. Différentes variantes d’UNIX ont historiquement « supporté POSIX » tout en divergeant sur des cas limites comme les signaux, les sémantiques I/O et le verrouillage de fichiers.
2. Les implémentations NFS sous Linux ont évolué de manière inégale selon les versions. Des fonctionnalités comme les délégations NFSv4 et le mappage d’identifiants ont traversé de longues périodes où elles existaient mais restaient fragiles en production, surtout entre versions mixtes client/serveur.
3. Les options de journalisation d’EXT4 sont devenues un champ de mines de compatibilité. Des modes comme data=ordered, les barrières et le comportement d’écriture ont changé avec les améliorations du noyau et la correction des vidages de cache des périphériques.
4. Les histoires de multipath NVMe et SCSI diffèrent. dm-multipath a été conçu pour le comportement de l’ère SCSI ; NVMe a introduit ANA et des sémantiques de multipath natives, et « c’est multipath » ne signifie pas qu’il bascule comme vous l’attendez.
5. Les flags de fonctionnalités ZFS ont été pensés pour éviter les pièges de mise à niveau des pools. C’est un bon système, mais cela signifie que « ZFS est disponible » n’assure toujours pas que « ce pool est compatible partout où vous prévoyez de l’importer ».
6. Les conteneurs ont rendu les sémantiques de système de fichiers visibles côté utilisateur. Les systèmes de fichiers en overlay et les mounts en union exposent des comportements de cas limites (rename, xattrs, whiteouts) que beaucoup d’apps n’ont jamais testés hors CI.
7. glibc vs musl n’est pas que taille et licence. Des différences dans la résolution DNS, les défauts de pile de threads, les locales et les codes d’erreur peuvent modifier le comportement d’exécution sans changer votre code.
8. Les piles crypto ont une longue tradition du « compile bien, échoue bizarrement ». Entre versions d’OpenSSL, fournisseurs, modes FIPS et crypto noyau, des algorithmes peuvent sembler présents mais être désactivés par une politique ou manquer d’accélération.
9. Les offloads réseau sont déjà sortis cassés plus d’une fois. TSO/GSO/GRO, le checksum offload et la segmentation peuvent être « supportés » par une NIC mais bogués dans une combinaison pilote+firmware spécifique.

Modes de défaillance : comment les fonctionnalités « portées » échouent dans les systèmes réels

1) La configuration no-op : flag activé, rien ne change

C’est le classique : une option de configuration existe parce que l’upstream l’a, et votre port a repris le schéma de configuration. Mais le module sous-jacent n’a pas été compilé avec la dépendance requise, ou l’environnement d’exécution le bloque.

Exemples : activer TRIM/discard dans une VM où l’hyperviseur ne le transmet pas ; activer I/O asynchrones dans une combinaison libc/noyau où le code utilise silencieusement des I/O synchrones ; activer « chiffrement » alors que seule la gestion des clés existe mais que la couche de chiffrement est absente ou désactivée par la politique.

2) « Pris en charge » mais sur un seul chemin de code

Les ports implémentent souvent le cas courant et passent outre les parties pénibles : récupération, gestion d’erreurs et concurrence. Ça a l’air correct jusqu’à ce que vous rencontriez une tempête de retries, une élection de leader, ou qu’un disque renvoie des erreurs média.

3) Fonctionnalité présente, sémantique différente

Celle-ci est dangereuse car vous ne verrez pas d’échec évident. Vous obtenez des résultats subtilement erronés : garanties d’ordre différentes, comportement fsync différent, timeouts différents, verrouillages différents.

En termes de stockage, la sémantique compte plus que la vitesse. Un système de fichiers rapide qui ment sur la durabilité n’est pas « rapide ». Il est juste « silencieusement optimiste ».

4) Repli silencieux vers le « mode compatibilité »

Certaines systèmes tentent une fonctionnalité, échouent à la négocier, et continuent. C’est convivial — jusqu’à ce que cela devienne un problème d’SLO. Votre application continue de fonctionner, mais désormais vous êtes sur un algorithme plus lent, une version de protocole plus ancienne ou un mode plus sûr mais plus coûteux.

5) Lacune d’observabilité : vous ne pouvez pas prouver que ça marche

Les ports omettent parfois des tracepoints, des compteurs ou des logs structurés. La fonctionnalité peut fonctionner, mais vous ne pouvez pas le confirmer. Quand ça tourne mal, vous n’avez pas de miettes diagnostiques. C’est fonctionnellement équivalent à « non pris en charge », parce que vous ne pouvez pas l’exploiter.

6) Chutes de performance sous charges réelles

Le port peut passer des tests de correction et même des benchmarks de base, puis s’effondrer avec des schémas I/O réalistes : petites écritures aléatoires, lectures/écritures mixtes, charges lourdes sur les métadonnées, écritures sync en rafales, ou snapshots concurrents.

Il y a une idée paraphrasée souvent attribuée à W. Edwards Deming : Sans données, vous n’êtes qu’une autre personne avec une opinion. En ops : sans mesure, vous n’êtes qu’une autre personne avec un pager.

Blague n°2 : Le système de stockage le plus rapide est celui qui abandonne les écritures. C’est aussi celui dont se souviendront vos auditeurs.

Feuille de route diagnostic rapide : trouvez le goulot avant d’argumenter

Quand une « fonctionnalité portée » ne se comporte pas, les gens débattent immédiatement d’architecture. Ne le faites pas. Établissez d’abord la réalité en trois passes : négocier, observer, valider.

Première passe : prouvez la négociation (la fonctionnalité est-elle réellement activée de bout en bout ?)

• Vérifiez les flags à l’exécution (pas les fichiers de config) : sysfs, procfs, info du pilote, options de montage du système de fichiers.
• Vérifiez les ensembles de capacités versionnés : flags de fonctionnalité ZFS, versions de protocole NFS, listes de chiffrements TLS, options de config du noyau.
• Vérifiez « l’autre côté » : serveur vs client, hyperviseur vs invité, contrôleur vs initiateur.

Deuxième passe : observez le comportement (prend-il le chemin de code prévu ?)

• Utilisez compteurs et traçage : iostat, perf, bpftrace, zpool iostat, nfsstat, statistiques ethtool.
• Cherchez des preuves de repli : messages de log, rétrogradations de protocole négociées, bannières « mode sûr », avertissements dmesg du noyau.
• Mesurez la distribution des latences : p95/p99 vous parlent des falaises ; la moyenne les masque.

Troisième passe : validez la sémantique (fait-il ce que vous pensiez qu’il ferait ?)

• Tests de durabilité : simuler une perte d’alimentation pour tester le comportement fsync est difficile, mais vous pouvez au moins valider les commandes de flush, les barrières et la politique de cache.
• Tests de modes d’échec : coupez un chemin, tuez un nœud, corrompez un bloc, remplissez le disque. Si le port ne se comporte pas sous contrainte, il ne se comporte pas.
• Tests de compatibilité : importer/exporter des pools, monter depuis des clients mixtes, monter/desmonter composants lors d’upgrade/downgrade.

Si vous faites ces trois passes, vous arrêterez de vous disputer sur les ressentis et commencerez à prendre des décisions fondées sur des preuves : « ce port manque la fonctionnalité X sur le noyau Y », ou « la fonctionnalité est négociée mais retombe en repli sous charge », ou « la sémantique diffère ; il faut la restreindre par charge de travail ».

Tâches pratiques : 12+ commandes qui indiquent ce qui est réellement pris en charge

Voici le type de contrôles que vous pouvez exécuter pendant un incident, pendant une migration, ou avant de laisser une plateforme « portée » toucher des données clients. Chaque tâche inclut ce que signifie la sortie et la décision qu’elle entraîne.

Task 1: Identify the real kernel and build flavor

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-01-23) x86_64 GNU/Linux

Que cela signifie : La version du noyau et le build de la distro importent car les ports ciblent souvent « Linux » au sens large mais dépendent de backports ou de configs spécifiques.

Décision : Si la fonctionnalité dépend d’une plage de noyau spécifique, ne devinez plus. Verrouillez le noyau ou migrez vers un build connu bon.

Task 2: Check kernel config for a supposedly “supported” feature

cr0x@server:~$ zgrep -E 'DM_MULTIPATH|NVME_MULTIPATH|BTRFS_FS|OVERLAY_FS' /proc/config.gz
CONFIG_DM_MULTIPATH=m
CONFIG_NVME_MULTIPATH=y
CONFIG_BTRFS_FS=m
CONFIG_OVERLAY_FS=y

Que cela signifie : Le noyau ne peut fournir que ce pour quoi il a été construit. « Pris en charge par la distro » signifie parfois « module optionnel que vous n’avez pas installé ».

Décision : Si une option requise manque, inutile d’affiner l’espace utilisateur. Corrigez le noyau/modules d’abord.

Task 3: Confirm module presence and parameters (runtime, not theory)

cr0x@server:~$ lsmod | egrep 'nvme|dm_multipath|zfs|overlay'
nvme_fabrics           24576  0
nvme_core             200704  2 nvme_fabrics,nvme
overlay               155648  2

Que cela signifie : Si le module n’est pas chargé, la fonctionnalité n’est pas active. Simple. Brutal.

Décision : Chargez le module et validez le comportement. S’il ne se charge pas, capturez dmesg et cessez d’affirmer que la fonctionnalité existe.

Task 4: Verify filesystem mount options and actual filesystem type

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/lib/postgresql
/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro,data=ordered

Que cela signifie : Beaucoup de « fonctionnalités » sont des options de montage (barrières, discard, noatime) et elles peuvent manquer ou être écrasées.

Décision : Si l’option attendue est absente (par ex. discard), activez-la explicitement ou lancez un trim périodique — ne supposez pas qu’elle s’exécute.

Task 5: Check whether discard/TRIM is actually supported by the block device

cr0x@server:~$ lsblk -D -o NAME,ROTA,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME        ROTA DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1        0      512B       2G         0
nvme0n1p2      0      512B       2G         0

Que cela signifie : Si DISC-MAX est 0B, discard n’est pas pris en charge via cette pile. Cela peut arriver avec certains contrôleurs RAID, hyperviseurs ou périphériques mal configurés.

Décision : N’activez pas des options discard qui ne font rien ; elles peuvent ajouter une surcharge ou une fausse confiance. Utilisez un chemin de stockage qui propage discard si vous en avez besoin.

Task 6: Confirm write cache and flush behavior exposure

cr0x@server:~$ sudo hdparm -W /dev/sda
/dev/sda:
 write-caching =  1 (on)

Que cela signifie : Le cache d’écriture activé n’est pas intrinsèquement mauvais, mais cela change votre discours sur la durabilité. La question importante est de savoir si les flushs sont honorés jusqu’au bas de la pile.

Décision : Si vous ne pouvez pas garantir une protection correcte du cache (BBU, PLP), vous devez considérer les sémantiques fsync comme suspectes et adapter votre conception de stockage.

Task 7: Measure I/O latency and saturation quickly

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0-18-amd64 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.21    0.00    1.10    8.42    0.00   87.27

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
nvme0n1        120.0   980.0  4800.0 64000.0     0.0     0.0   92.1   14.3

Que cela signifie : Un %util élevé et une await qui monte indiquent une saturation du périphérique ou une mise en file d’attente. Si votre « fonctionnalité portée » était censée réduire la latence, elle ne l’est pas.

Décision : Si le périphérique est saturé, arrêtez de blâmer l’application. Corrigez le chemin I/O, la profondeur de file, l’ordonnanceur ou le provisioning.

Task 8: Confirm I/O scheduler and queue settings (common port mismatch)

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Que cela signifie : Certains ordonnanceurs se comportent mieux pour certaines charges ; des guides d’optimisation « portés » supposent souvent un ordonnanceur qui n’est pas en service.

Décision : Si votre charge est sensible à la latence et que vous êtes sur un ordonnanceur inadapté, testez des changements — mais consignez-les et restreignez-les par classe de périphérique.

Task 9: Check negotiated TLS capabilities (crypto ports love silent downgrades)

cr0x@server:~$ openssl version -a
OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)
built on: Tue Oct 10 10:10:10 2023 UTC
platform: debian-amd64

Que cela signifie : Les versions majeures d’OpenSSL changent le comportement des providers. Quelque chose « supporté » en 1.1.1 peut nécessiter une configuration en 3.x.

Décision : Si le comportement crypto diffère entre environnements, considérez-le comme un risque de port. Validez les chiffrements et protocoles négociés, n’assumez pas.

Task 10: Verify NFS protocol and client/server capabilities

cr0x@server:~$ nfsstat -m
/var/lib/app from nfs01:/export/app
 Flags: rw,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.10

Que cela signifie : Vous voyez la version NFS négociée. Si vous pensiez être en 4.2 avec certaines sémantiques et que vous êtes en 4.1, votre « fonctionnalité » peut être absente.

Décision : Forcer la version voulue et tester. Si le serveur ne peut pas, ne comptez pas sur la magie côté client.

Task 11: Validate NVMe multipath and ANA state

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:2f2a...
\
 +- nvme0 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live optimized
 +- nvme1 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live non-optimized

Que cela signifie : Le multipath « existe » seulement si les chemins sont visibles et que les états ont du sens. Les chemins « non optimisés » peuvent être en veille ou mal utilisés selon la politique.

Décision : Si les chemins ne sont pas présents ou que les états sont incorrects, corrigez le zoning du fabric, la configuration hôte ou les paramètres multipath du noyau avant d’ajuster les applications.

Task 12: Catch silent filesystem fallbacks in container storage

cr0x@server:~$ docker info | sed -n '/Storage Driver/,$p' | head -n 8
 Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd

Que cela signifie : Le comportement d’overlay dépend des fonctionnalités du système de fichiers sous-jacent. Si le support d_type est absent, overlay peut mal se comporter. Si userxattr est false, certaines fonctionnalités de sécurité/métadonnées peuvent être indisponibles.

Décision : Si des fonctionnalités overlay critiques ne sont pas prises en charge, migrez le runtime vers un système de fichiers qui les supporte, ou changez le driver de stockage en acceptant les compromis.

Task 13: ZFS pool feature flags and compatibility reality

cr0x@server:~$ zpool get -H -o name,property,value ashift,autotrim,feature@async_destroy rpool
rpool	ashift	12
rpool	autotrim	off
rpool	feature@async_destroy	active

Que cela signifie : Les flags de fonctionnalité ZFS sont explicites. Un pool peut être importé mais avoir des fonctionnalités actives qu’anciens ports ne peuvent pas gérer en toute sécurité.

Décision : Si vous avez besoin de portabilité inter-hôtes, contrôlez les upgrades de pool et l’activation des fonctionnalités. « Ça s’importe » n’est pas synonyme de « c’est sûr partout ».

Task 14: Check for runtime warnings that indicate stubs or disabled paths

cr0x@server:~$ dmesg -T | egrep -i 'fallback|disable|unsupported|unknown|deprecated' | tail -n 10
[Wed Jan 22 00:12:44 2026] nvme nvme0: missing or invalid ANA log, disabling ANA support
[Wed Jan 22 00:12:45 2026] overlayfs: upper fs does not support xattr, falling back to index=off

Que cela signifie : Le noyau vous dit parfois directement qu’il a désactivé la fonctionnalité. Les gens ignorent ça parce que c’est « juste un avertissement ».

Décision : Traitez ces lignes comme des exigences. Si la fonctionnalité est désactivée, cessez de concevoir en fonction d’elle.

Task 15: Confirm syscalls and behavior differences (glibc/musl, seccomp)

cr0x@server:~$ strace -f -e trace=io_uring_setup,openat,fsync -o /tmp/trace.log ./app --once
cr0x@server:~$ tail -n 6 /tmp/trace.log
12345 io_uring_setup(256, {flags=0, sq_thread_cpu=0, sq_thread_idle=0}) = -1 EPERM (Operation not permitted)
12345 openat(AT_FDCWD, "/var/lib/app/data", O_RDONLY|O_CLOEXEC) = 3
12345 fsync(3) = 0

Que cela signifie : Votre app « supporte io_uring », mais dans un conteneur avec seccomp ou des privilèges insuffisants, il peut être bloqué et retomber silencieusement sur des I/O plus anciens.

Décision : Si l’appel système visé est refusé, ajustez la politique du sandbox (avec prudence) ou acceptez le repli et dimensionnez la capacité en conséquence.

Trois mini-histoires du monde de l’entreprise (anonymes, douloureusement réelles)

Mini-histoire 1 : L’incident causé par une fausse hypothèse

Une équipe plateforme a déployé une nouvelle image de base « durcie » pour les services internes. Elle était présentée comme un remplacement sans accroc : mêmes paquets, noyau légèrement plus récent, surface d’attaque réduite. Le plan de migration était propre : créer des AMI, déploiement en rolling, surveiller les dashboards.

Un service — une API à écritures intensives avec une file locale — a commencé à montrer des pics périodiques de latence ressemblant à des pauses GC. Le CPU allait bien. La mémoire allait bien. Le réseau allait bien. Pourtant toutes les quelques minutes, le p99 montait et le débit chutait. Tout le monde regardait les traces applicatives parce que, évidemment, cela devait être l’application.

Ce n’était pas le cas. L’image de base changeait subtilement la pile de stockage : les options de montage du système de fichiers n’incluaient plus discard, et le disque virtuel sous-jacent n’annonçait de toute façon pas discard. L’ancienne image exécutait un job trim hebdomadaire ; la nouvelle non. Avec le temps, le stockage SSD a commencé à se comporter comme un historien pessimiste : il se souvenait de chaque écriture, et il vous en a voulu.

La « fonctionnalité portée » était la promesse que la nouvelle image était équivalente opérationnellement. Elle l’était. Sauf pour un comportement de maintenance ennuyeux qui n’était pas documenté comme exigence, et donc non testé. La correction n’a pas été héroïque : restaurer le trim, valider le support discard bout en bout, et ajouter une vérification explicite dans la pipeline d’image pour échouer les builds quand les hypothèses de stockage changent.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe stockage a migré une flotte de LUNs iSCSI vers NVMe over Fabrics. La démo du vendeur était excellente. La latence s’améliorait dans des tests contrôlés. Quelqu’un a remarqué que le noyau avait un support NVMe multipath natif et a décidé de supprimer dm-multipath pour « réduire la surcharge ». Pile plus propre, moins d’éléments mobiles.

En quelques semaines, des erreurs intermittentes sont apparues lors d’événements de maintenance du fabric. Rien de catastrophique — juste des blocages brefs qui causaient des timeouts en amont. La charge de travail était une base de données distribuée. Les bases distribuées sont émotionnellement sensibles. Quelques secondes d’incertitude I/O deviennent une cascade de changements de leader, retries et compactions. Tout semblait être un problème applicatif parce que c’était l’app qui criait.

La cause racine était des hypothèses de parité fonctionnelle : le multipath NVMe du noyau existait, mais la combinaison spécifique de firmware et de comportement du fabric produisait des transitions d’état ANA que le port ne gérait pas bien. Le système gardait des chemins « live » mais mal classait optimisé vs non-optimisé pendant certains événements. Ce n’était pas cassé tout le temps, juste assez pour empoisonner la latence de queue.

La correction a été d’abandonner l’élégance au profit de la prévisibilité : restaurer une configuration multipath validée, ajouter des vérifications de santé qui affirment la correction des états de chemin, et répéter les basculements en staging avec le même firmware. La leçon a été douloureuse : supprimer des couches n’est pas toujours une simplification ; parfois c’est juste supprimer des garde-fous.

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

Une entreprise de taille moyenne exploitait un cluster Kubernetes privé avec un driver CSI pour le stockage bloc. Ils avaient deux distributions internes disponibles : « Linux standard » et un OS minimal pour hôtes conteneurs. L’OS minimal était populaire car il démarrquait vite et était plus facile à durcir. Il avait aussi la mauvaise habitude d’omettre des modules noyau que « tout le monde suppose ».

Avant de l’accepter en production, un SRE a insisté pour une suite de tests de « contrat de capacité ». Ce n’était pas glamour. Elle démarrait un nœud, attachait un volume, exécutait une série de vérifications sysfs, validait les options de montage, réalisait un stress fsync, puis effectuait un detach/reattach forcé. Elle vérifiait aussi des avertissements noyau spécifiques et refusait de poursuivre si des chaînes de « repli » apparaissaient dans dmesg.

Lors de la première exécution, la suite a échoué immédiatement : le nœud pouvait monter des volumes, mais ne supportait pas une fonctionnalité de système de fichiers requise pour les snapshots. Le driver CSI prétendait que les snapshots étaient pris en charge parce que les objets API existaient. En coulisses, il retombait sur un comportement lent de copie complète qui fonctionnait, mais qui aurait fait exploser leur budget de stockage et ruiné les temps de restauration.

La pratique qui les a sauvés était banale : codifier les hypothèses sous forme de tests. Ils ne « faisaient pas confiance au port ». Ils testaient le port. L’OS minimal a continué d’être proposé, mais avec une étiquette claire : pas de snapshots tant que l’ensemble module noyau et fonctionnalités système de fichiers ne respecte pas le contrat. Personne n’a reçu de page, et le CFO est resté joyeusement ignorant de la proximité de leur festival surprise de copies de données.

Erreurs courantes : symptôme → cause racine → correction

1) « Nous l’avons activé, mais les performances n’ont pas changé »

Symptôme : Basculer une fonctionnalité (discard, compression, multipath, I/O async). Les métriques restent identiques.

Cause racine : La fonctionnalité n’est pas négociée de bout en bout ou est désactivée à l’exécution en raison d’une capacité manquante.

Correction : Validez du bas vers le haut : support du périphérique (lsblk -D), avertissements noyau (dmesg), options de montage (findmnt), et stats du pilote.

2) « Ça marche jusqu’au basculement, puis ça cale »

Symptôme : Latence normale jusqu’à une défaillance de chemin ou maintenance ; puis la latence de queue explose.

Cause racine : Implémentation partielle des sémantiques de basculement, politique de chemin incorrecte, ou port ne gérant pas correctement les états transitoires.

Correction : Répétez les basculements délibérément. Vérifiez l’état et la santé du multipath. Préférez des configurations conservatrices validées plutôt que des « piles propres » quand la fiabilité compte.

3) « Les snapshots existent, mais les restaurations sont douloureusement lentes »

Symptôme : L’API snapshot réussit ; la restauration prend une éternité et écrase le stockage.

Cause racine : Le port expose des objets snapshot mais manque de copy-on-write ou de support natif ; il retombe sur une copie complète.

Correction : Vérifiez l’implémentation : capacité du système de fichiers, support du backend stockage, et schémas I/O réels de restauration. Gâtez l’usage des snapshots par type de backend.

4) « Le chiffrement est activé, mais le CPU explose »

Symptôme : Activer TLS ou chiffrement disque fait chuter le débit.

Cause racine : Accélération matérielle manquante, comportement différent du provider crypto, ou politique désactivant certains algorithmes si bien que la négociation choisit des options lentes.

Correction : Inspectez les chiffrements négociés, profils CPU et disponibilité d’accélération crypto. Choisissez les chiffrements délibérément ; n’acceptez pas ce que la poignée de main propose par défaut.

5) « Les conteneurs ont commencé à échouer avec des erreurs bizarres de système de fichiers »

Symptôme : Erreurs du stockage overlay, échecs de rename étranges, bizarreries de permissions.

Cause racine : Le système de fichiers sous-jacent manque de fonctionnalités requises (d_type, xattrs), ou l’implémentation noyau d’overlay diffère de celle attendue par votre runtime.

Correction : Validez les prérequis overlay et changez le système de fichiers ou le driver. Ne faites pas tourner overlay sur « ce qui était monté par hasard ».

6) « Même app, distro différente, comportement différent »

Symptôme : Timeouts, problèmes DNS, gestion d’erreurs différente après un changement d’image de base.

Cause racine : Différences de libc, comportement du resolver, défauts de threading, ou valeurs sysctl du noyau modifiées.

Correction : Traitez l’image de base et la libc comme partie de l’API plateforme. Verrouillez les versions, exécutez des tests de compatibilité et differez les sysctls.

7) « La fonctionnalité est présente, mais on ne peut pas l’observer »

Symptôme : Pas de métriques ni de logs pour confirmer le comportement ; seulement des inférences indirectes.

Cause racine : Le port omet des compteurs/tracepoints ou ne les a pas reliés à votre télémétrie.

Correction : Ajoutez des exigences d’observabilité explicites aux critères d’acceptation. Si vous ne pouvez pas l’observer, vous ne pouvez pas l’exploiter.

Listes de contrôle / plan pas à pas : comment livrer des ports en sécurité

Étape par étape : construire un « contrat de capacité » pour votre plateforme

1. Listez les sémantiques non négociables par charge de travail. Pour les bases : correction fsync et latence ; pour l’object storage : durabilité et comportement de rebuild ; pour le streaming : latence de queue sous backpressure.
2. Transformez les sémantiques en contrôles vérifiables. « Supporte discard » devient « DISC-MAX > 0 et option de montage réglée ou trim périodique vérifié. » « Supporte les snapshots » devient « la restauration n’exige pas une copie complète. »
3. Documentez explicitement les prérequis. Options noyau, modules requis, firmware minimum, et fonctionnalités système de fichiers nécessaires.
4. Créez une suite de validation automatisée. Exécutez-la sur chaque nouveau noyau, image de base et backend stockage. Echouez vite quand les capacités dérivent.
5. Incluez des exercices de défaillance. Déconnecter un chemin, redémarrer un nœud, remplir le disque à 95%, forcer un resync, faire pivoter des certificats. Mesurez l’impact sur les SLO.
6. Définissez votre politique de repli. Si une fonctionnalité ne se négocie pas, le système doit-il refuser de démarrer, ou fonctionner en mode dégradé avec alertes sonores ?
7. Gatez le déploiement par capacité, pas par nom d’hôte. « prod-storage-02 » n’est pas une capacité. « discard pris en charge end-to-end » l’est.
8. Tenez une matrice de compatibilité. Ce n’est pas une nouveauté ; un tableau : versions du noyau, versions de pilotes, firmware, flags de fonctionnalité, caveats connus.

Checklist opérationnelle : avant d’accepter qu’un « port » soit « prêt pour la production »

• Pouvez-vous prouver que la fonctionnalité est négociée de bout en bout (client + serveur + noyau + périphérique) ?
• Pouvez-vous prouver que la fonctionnalité change le comportement sous charge (pas seulement l’état de configuration) ?
• Avez-vous au moins un test négatif où la fonctionnalité manque et le système échoue bruyamment ?
• Avez-vous de l’observabilité : compteurs, logs et tableaux de bord clairs montrant la santé de la fonctionnalité ?
• Avez-vous testé le « chemin moche » : basculement, resync, disque plein, haute latence, perte de paquets ?
• Le rollback est-il sûr (flags de pool, rétrogradations de protocole, compatibilité de config) ?

Règles de décision (opinionnées, parce que vous êtes occupé)

• Si la fonctionnalité affecte la durabilité ou l’intégrité et que vous ne pouvez pas la valider, désactivez-la et concevez autour de cette réalité.
• Si la fonctionnalité affecte la performance et peut retomber silencieusement, alert sur le repli ou traitez les affirmations de performance comme du marketing.
• Si la fonctionnalité est une dépendance pour votre réponse aux incidents (snapshots, vitesse de restauration, observabilité), ne pas livrer sans elle.
• Si votre équipe plateforme dit « ça devrait marcher », demandez : preuve de config noyau, preuve de capacité négociée, et rapport d’exercice de défaillance.

FAQ

1) Quelle est la différence entre « la fonctionnalité existe » et « la fonctionnalité marche » ?

« Existe » signifie que vous pouvez voir un bouton, un module, une API ou une option de config. « Marche » signifie que le système prend le chemin de code prévu dans des conditions réalistes, et que vous pouvez le prouver par l’observation et les tests.

2) Pourquoi les ports sont-ils livrés avec des fonctionnalités factices ?

Parce que livrer la parité d’API est souvent plus facile que livrer la parité sémantique. Les stubs réduisent la friction d’intégration et achètent du temps. Le problème survient quand personne n’étiquette le stub comme tel.

3) Comment surviennent les repli silencieux ?

Beaucoup de systèmes priorisent la disponibilité. Si la négociation échoue, ils choisissent un protocole plus ancien, un algorithme plus lent, ou un mode plus sûr et continuent de fonctionner. C’est idéal pour les démos et terrible pour les SLO à moins de détecter et alerter la rétrogradation.

4) Les « matrices de compatibilité » valent-elles l’effort ?

Oui, si vous les gardez courtes et liées à des tests d’acceptation. La valeur n’est pas dans le document ; c’est la discipline de savoir quelles combinaisons sont testées et lesquelles relèvent du wishful thinking.

5) Quel est le moyen le plus rapide pour savoir si une fonctionnalité de stockage est réelle ?

Vérifiez la capacité du périphérique (sysfs/lsblk), vérifiez les avertissements noyau (dmesg), puis mesurez le comportement (latence iostat, tests de rebuild/basculement). Si une couche contredit, considérez la fonctionnalité comme non réelle.

6) Comment gérer les affirmations « supporté sur Linux » des vendeurs ?

Transformez cette affirmation en : quelles versions du noyau, quels modules, quels systèmes de fichiers, quels firmwares, et quels scénarios d’échec sont validés. S’ils ne peuvent pas répondre, vous êtes le labo de test.

7) Devrait-on préférer moins de couches (par exemple, supprimer dm-multipath) ?

Préférez moins de couches seulement quand vous pouvez prouver que la couche restante gère la défaillance et l’observabilité au moins aussi bien. « Moins » n’est pas automatiquement « plus simple » en modes d’échec.

8) Et si une fonctionnalité manquante n’est qu’un problème de performance, pas de correction ?

Les échecs de performance deviennent des échecs de fiabilité quand ils déclenchent timeouts, retries, élections ou backpressure. Traitez la latence de queue comme un risque de disponibilité, pas seulement une nuisance de vitesse.

9) Comment faire cesser les équipes de se disputer sur l’app ou la plateforme ?

Faites publier par la plateforme un contrat de capacité avec tests et preuves, et demandez aux services de déclarer les capacités dont ils dépendent. Alors les désaccords deviennent des diffs et des résultats de tests, pas des réunions.

Conclusion : quoi faire la semaine prochaine, pas le trimestre prochain

Les ports avec fonctionnalités manquantes ne sont pas des bugs rares. Ils sont le résultat naturel du fait de livrer la « présence » avant le « comportement ». La correction n’est pas plus d’optimisme. C’est plus de vérification, des contrats explicites, et moins de repli silencieux.

Actions concrètes à court terme :

1. Créez un contrat de capacité pour votre plateforme : la poignée de fonctionnalités dont vous dépendez vraiment (durabilité, snapshots, comportement multipath, négociation crypto, observabilité).
2. Automatisez les vérifications ci-dessus dans le CI pour les images de base, noyaux et builds de nœuds. Echouez vite quand les prérequis dévient.
3. Exécutez un exercice de défaillance par fonctionnalité critique en staging : perte de chemin, reboot de nœud, resync, restauration de snapshot, injection de haute latence.
4. Rendez les repliers bruyants : si le système rétrograde, alertez. S’il ne peut pas fournir une fonctionnalité requise, refusez de démarrer.

Quand quelqu’un dit « c’est là », votre rôle est de demander : « Pouvons‑nous prouver que c’est actif, observable, et correct en cas de défaillance ? » Si non, traitez‑le comme manquant. La production le fera.