Résumé

  • Des métriques d’infrastructure au vert peuvent masquer une sortie erronée après une modification de configuration ou de logique.
  • Shruthi Sepuri veut vérifier les résultats du workflow en production et réinjecter les écarts observés dans les tests.

Un tableau de bord vert est un témoin appliqué, mais myope. Il certifie que les serveurs répondent, que la latence reste basse et que peu d’erreurs sont remontées. Il ne certifie pas que la décision rendue par le service est correcte.

C’est la distinction au cœur de la présentation de Shruthi Sepuri à NANOG 98 : « From Testing to Reliability: Detecting Silent Failures in Production Systems ». Le programme de NANOG situe cette intervention de trente minutes à Miami, le 19 octobre 2026. Son résumé décrit le piège des systèmes complexes : une modification de configuration, de règle ou de dépendance peut changer le comportement automatisé sans faire bouger les indicateurs suivis par l’exploitation.

Les diapositives donnent forme au problème par un scénario. L’infrastructure demeure au vert ; le moteur de règles échoue, la décision devient fausse, une validation est sautée et le journal d’audit comporte une lacune. Les documents publics ne nomment ni service touché ni incident réel : il s’agit d’un modèle de défaillance, pas d’un retour d’expérience attribué. La distinction reste nette : « le service fonctionne » et « le service a bien décidé » sont deux propositions différentes.

Sepuri propose donc de mesurer le trajet entre l’entrée et la conséquence. Elle cite le taux de sorties correctes, la couverture des validations de configuration, les variations de distribution des résultats et l’exécution des règles face à des cas connus. Elle recommande aussi de rejouer du trafic synthétique dans la logique de production, de comparer les sorties après changement à une référence connue et de transformer le comportement observé en nouveaux cas de test.

Ajouter une courbe ne suffit pas. Un contrôle utile désigne la décision attendue, les entrées susceptibles de la modifier et la preuve qui révélerait une sortie fausse. Dans un workflow piloté par des règles, cela peut signifier vérifier les champs requis avant exécution, confirmer le chemin de règle appliqué et garder assez de contexte pour relier le résultat à une modification.

Une distribution qui bouge déclenche une enquête, pas un verdict. Le trafic, la demande ou une politique ont peut-être changé volontairement. Il faut relier l’alerte à la fenêtre de changement et à une personne capable d’expliquer le résultat attendu. Sans ce lien, la nouvelle métrique produit surtout du bruit.

La proposition de Sepuri élargit la définition de la fiabilité : il faut observer le système tel qu’il tourne, pas seulement les machines qui l’hébergent. Les tests doivent atteindre la production par un rejeu sûr et en revenir avec des preuves. Sinon, un tableau impeccable peut certifier la mauvaise décision jusqu’aux étapes suivantes.

Sources : page de la session NANOG 98 · diapositives officielles · portrait officiel de l’intervenante.