L’espace en rack n’est pas de la capacité

« Quel est le taux de remplissage de ce rack » ressemble à une question dont la réponse est un nombre. Ce n’en est pas une. Ce sont cinq questions sous un même manteau, et tout tableau de bord qui y répond par un chiffre unique a discrètement choisi laquelle des cinq il entendait, et jeté les quatre autres.

Les cinq sont réellement des choses différentes. Combien d’unités de rack sont prises. Combien des machines qui s’y trouvent sont effectivement en service plutôt qu’en préparation ou en quarantaine. Combien d’entre elles pourraient être vendues à un client demain. Quelle puissance les machines qui s’y trouvent sont budgétées pour tirer, rapportée au budget du rack. Et quelle puissance elles tirent réellement.

Vous pouvez être à quatre-vingt-dix pour cent sur la première et n’avoir rien à vendre, parce que tout ce qui est dans le rack est déjà attribué à un client. Vous pouvez être à quarante pour cent sur la première et ne pas pouvoir ajouter une machine, parce que le budget électrique est épuisé. Ce ne sont pas des cas limites. C’est l’état normal d’un datacenter qui tourne depuis un moment.

Voici comment nous avons construit la réponse sous la forme de cinq relevés distincts et, plus important encore, comment nous avons rendu difficile à une future version de nous-mêmes d’en faire la moyenne.

Cinq axes, cinq réponses différentes

Lisez ce tableau comme une liste de types de retour plutôt que comme une liste de fonctionnalités. Le premier axe renvoie une forme par face. Le deuxième renvoie une table associant un état à un décompte. Le troisième renvoie trois décomptes de machines. Le quatrième renvoie deux valeurs en watts. Le cinquième ne renvoie rien du tout. Aucun des cinq n’est un nombre nu, et ce n’est pas un accident de conception : c’est la première des quatre choses qui empêchent un score combiné d’exister.

Si chaque axe renvoyait un pourcentage, une moyenne tiendrait en une ligne de code. Personne ne la relirait comme une décision, parce qu’elle n’y ressemblerait pas. Elle ressemblerait à une commodité. Rendre les formes de retour structurellement incomparables signifie que quiconque veut un chiffre combiné doit d’abord écrire la conversion qui les aplatit, et une conversion se voit dans un diff comme une division ne se voit pas.

L’inconnu est par axe, et il porte une raison

La deuxième fermeture est ce qui se passe quand un axe ne sait pas.

Trois raisons existent aujourd’hui, et ce sont des clés plutôt que des phrases, parce que le panneau les rend dans neuf langues. Le rack n’a pas de budget électrique enregistré. Une ou plusieurs des machines qui s’y trouvent ne connaissent pas leur propre consommation réservée. Il n’y a pas de capteur.

La différence compte parce que ce sont trois conversations différentes. La première est un trou de saisie dans la fiche du rack. La deuxième est un trou de saisie sur une machine, et elle dit quelque chose de précis : la somme que vous vous apprêtez à lire a un trou dedans. La troisième n’est pas un trou du tout, c’est l’absence d’un matériel dont nous n’avons pas construit la prise en charge.

C’est sur l’axe de la puissance que cela mord. Si le rack n’a pas de budget, il n’y a rien à quoi se mesurer et l’axe est inconnu pour cette raison. Si le rack a un budget mais qu’une machine implantée n’a pas de valeur réservée, l’axe est inconnu pour une autre raison, et c’est le cas qu’une implémentation naïve traite mal. Il est très tentant de traiter une puissance manquante comme un zéro et de continuer à sommer. Cela produit un rack qui a l’air spacieux et qui est plein, ce qui est la réponse fausse la plus coûteuse que ce système puisse donner : quelqu’un planifie une livraison en se fondant dessus.

La règle est qu’un inconnu d’un côté rend l’axe entier inconnu. Une somme avec un trou dedans n’est pas une somme plus petite.

L’axe qui est toujours inconnu

Le cinquième axe, la puissance observée, renvoie inconnu à chaque fois. Il n’y a dans ce produit ni unité de distribution électrique, ni arrivée, ni prise, ni sonde de température. Ni partiellement, ni derrière un indicateur : aucune.

La chose évidente à faire serait de le laisser de côté jusqu’à ce qu’il existe. Nous l’affichons quand même à l’écran, en disant qu’il n’y a pas de capteur, et la raison tient à ce que son absence ferait au lecteur. Avec quatre axes à l’écran dont l’un est intitulé puissance, une personne raisonnable conclut que le chiffre de puissance est une mesure. Il ne l’est pas. C’est un budget : ce que quelqu’un a saisi dans un formulaire comme consommation attendue d’une machine, additionné.

Afficher le cinquième axe comme explicitement inconnu est ce qui garde le quatrième honnête. Une affirmation de capacité assemblée à partir de données incomplètes est exactement le mode de défaillance contre lequel toute cette partie de la conception est écrite, et la défense la moins chère contre lui est de nommer ce que vous n’avez pas mesuré.

Rendre le score impossible plutôt qu’interdit

Rien de ce qui précède ne survit au contact d’un trimestre chargé si rien ne le fait respecter. « Nous étions convenus de ne pas les combiner » est un commentaire, et un commentaire ne peut pas échouer.

Il y a donc un test qui lit le fichier source avec le compilateur TypeScript et affirme trois choses à son sujet.

Aucune fonction exportée de ce fichier ne renvoie un number nu. Il n’y a donc rien dans le module dont on puisse faire la moyenne, pas même par accident.

La fonction qui assemble les cinq relevés ne contient aucun opérateur arithmétique, aucun reduce et aucun Math. Elle parcourt le registre des axes et appelle chaque lecteur. C’est tout ce qu’elle a le droit de faire, et un chiffre combiné naîtrait nécessairement là, parce que c’est le seul endroit où les cinq relevés sont visibles en même temps. C’est la troisième fermeture.

Et les mots eux-mêmes sont bannis : un balayage rejette healthScore, rackHealth, overallScore, combinedScore et capacityScore dans n’importe quelle casse. Ce dernier est grossier et nous l’avons gardé quand même, parce que la défaillance contre laquelle il protège, c’est quelqu’un qui veut rendre service à quatre heures et demie un vendredi.

L’intérêt de l’écrire ainsi n’est pas qu’une règle ne puisse pas être enfreinte. C’est que l’enfreindre exige de supprimer un test, et supprimer un test est une ligne dans une pull request au sujet de laquelle quelqu’un posera une question. Ajouter une division entre deux nombres qui étaient déjà là, non.

Nous avons prouvé la garde rouge avant de lui faire confiance, de deux manières distinctes : une expression arithmétique à l’intérieur de la fonction d’assemblage, et une fonction exportée qui renvoie un nombre. Les deux ont été retirées ensuite. Une garde qui n’a jamais échoué est une garde dont vous n’avez pas vérifié les sélecteurs.

Ajouter un axe doit être une erreur de compilation

Les cinq axes vivent dans un seul registre. Les producteurs vivent dans un enregistrement indexé par ce registre, si bien qu’un sixième axe sans lecteur est une erreur de type plutôt qu’une ligne silencieusement absente. C’est la quatrième.

Cela couvre le code. Cela ne couvre pas l’écran, et l’écran est l’endroit où un axe manquant est le plus dangereux : il n’apparaît tout simplement pas, et le tableau a l’air complet. Une deuxième garde dérive donc la liste des axes du registre et exige, pour chacun, un libellé et une indication dans les neuf catalogues, une branche de rendu qui lui soit propre dans le composant, et une branche inconnue avec une phrase traduite pour chaque raison du registre des raisons.

Cette garde s’est justifiée immédiatement. Elle a trouvé que l’axe de la puissance observée n’était nommé nulle part dans le composant de rendu, ce qui est exactement l’état dans lequel un axe produit une cellule vide au lieu d’une explication, et une cellule vide se lit comme un zéro. Écrire des tests par axe n’aurait pas pu trouver cela, pour la même raison qu’un test par cas ne peut pas trouver un cas manquant : il aurait fallu déjà savoir que l’axe existait.

Le même raisonnement vaut pour la traduction. Un code de raison sans phrase derrière lui est un blanc dans une langue que personne dans l’équipe ne lit, et neuf catalogues font beaucoup d’endroits où un blanc peut se cacher.

Ce que nous écririons

1. 01Décidez de ce en quoi chaque réponse est mesurée avant de décider de son apparence. Des unités qui ne peuvent pas s’additionner sont la défense la moins chère que vous construirez jamais.
2. 02Donnez à l’inconnu sa propre raison par axe, et ne laissez jamais une entrée manquante devenir un zéro en chemin vers une somme.
3. 03Gardez à l’écran l’axe que vous ne pouvez pas mesurer, marqué comme non mesuré, pour que l’axe d’à côté ne soit pas pris pour une mesure.
4. 04Mettez l’interdiction dans un test qui lit la source, pas dans un commentaire, et prouvez le test rouge une fois avant de vous appuyer dessus.
5. 05Dérivez la garde du registre, pour qu’ajouter un sixième axe soit bruyant dans le code et à l’écran plutôt que silencieux dans les deux.

Pour être clair sur l’état des choses : le travail sur la logistique de datacenter est derrière un indicateur de déploiement désactivé par défaut, et derrière un réglage par organisation par-dessus, si bien que rien de tout cela n’est quelque chose que vous pouvez aller acheter aujourd’hui. C’est la forme que nous reconstruirions, et les cinq axes en sont la partie dont nous sommes le plus sûrs. La question voisine de savoir qui a le droit d’écrire dans un rack, et ce qui empêche réellement deux personnes d’affecter le même emplacement, est dans la seule vraie limite à l’occupation d’un rack.

Issu du travail sur les datacenters chez Provibr.