Ce qu'un pourcentage de disponibilité autorise réellement

La fenêtre décide plus que le neuf

Une disponibilité est une fraction d'une période, et la période ne fait pas partie du nombre. Prends 99,9 % de trois façons : sur un an, elle autorise 525,60 minutes d'arrêt ; sur un mois, 43,20 ; sur un jour, 1,44. C'est le même pourcentage. Une panne de quatre heures viole cinq fois un 99,9 % mensuel et passe un 99,9 % annuel avec encore trois cents minutes en réserve. Quand on t'annonce une cible sans fenêtre, on ne t'a presque rien dit.

Cet outil n'a aucun réglage de fenêtre. Les quatre cases du haut convertissent une cible en quatre périodes, ce qui est utile, mais la case inverse en dessous — celle qui retransforme une panne observée en pourcentage — divise toujours par le même mois de trente jours. Si ton contrat se mesure au trimestre, sur vingt-huit jours glissants ou par mois calendaire, cette case répond à une autre question que la tienne. L'arithmétique reste juste ; elle est simplement appliquée à une période que tu n'as pas choisie.

Le mois de trente jours est une simplification défendable, et l'outil le dit dans sa propre note. Ce qu'il ne dit pas, c'est que le même identifiant d'outil porte une seconde définition : le calcul de repli enregistré à côté du composant utilise un mois de 43 800 minutes, soit 30,42 jours, quand le composant lui-même en utilise 43 200. À 99,9 %, cela fait 43,80 minutes contre 43,20 — le même outil, deux mois, 36 secondes d'écart. Aucune des deux valeurs n'est fausse comme moyenne ; elles ne sont simplement pas la même moyenne.

Février ne fait pas trente jours, et la case inverse l'ignore

Les fournisseurs facturent le mois qu'ils ont réellement. Amazon définit le pourcentage de disponibilité mensuel d'EC2 comme 100 % moins le pourcentage de minutes du mois pendant lesquelles le service était indisponible, sur un cycle de facturation mensuel — un vrai mois, de 28 à 31 jours. À 99,9 %, un février de 28 jours autorise 40,32 minutes, le mois de 30 jours de l'outil en autorise 43,20 et un mars de 31 jours 44,64. La case inverse est donc 2,88 minutes trop généreuse en février et 1,44 minute trop sévère en mars. C'est peu, jusqu'au jour où un incident tombe à trois minutes d'un seuil — c'est précisément le jour où l'on ouvre un calculateur.

Le même contrat dit aussi ce qui se passe quand le chiffre n'est pas tenu, et c'est rarement ce qu'on imagine. Amazon s'engage sur 99,99 % de disponibilité mensuelle pour des instances réparties sur plusieurs zones de disponibilité et sur 99,5 % pour une instance isolée, et le remède est un avoir sur la facture : 10 % des sommes dues entre 99,0 % et l'engagement, 30 % entre 95,0 % et 99,0 %, et 100 % en dessous de 95,0 %. Un avoir n'est pas une indemnisation de ce que la panne t'a coûté, et aucun calcul de cette page n'y change rien.

Chaque neuf coûte dix fois plus et achète dix fois moins

Le graphique de la page est tracé en échelle logarithmique pour une raison : sur une échelle linéaire, on ne peut pas voir 99 % et 99,999 % en même temps, car ils diffèrent d'un facteur dix mille. Par mois, l'outil donne 7 h 12 min à 99 %, 43 min 12 s à 99,9 %, 4 min 19 s à 99,99 % et 26 s à 99,999 %. Lis cela comme une échelle d'ingénierie et non de marketing. Le passage de trois neuf à quatre récupère environ huit heures par an, et ces huit heures s'achètent avec un basculement qu'il faut désormais construire, tester et maintenir testé.

Le format de durée cache la queue. Il n'affiche que les deux unités non nulles les plus significatives : 99 % sur un an s'écrit « 3 d 15 h » alors que le vrai budget est 3 j 15 h 36 min, et 99,5 % s'écrit « 1 d 19 h » pour 1 j 19 h 48 min. À l'autre extrémité, l'arrondi joue dans l'autre sens : le budget journalier à 99,999 % vaut 0,86 seconde et la case affiche « 1 s », parce que le formateur arrondit à la seconde entière avant de formater. Ni l'un ni l'autre n'est une erreur de calcul, et les deux méritent d'être connus avant de coller un chiffre dans une procédure.

Être en ligne n'est pas servir les requêtes

Ce calculateur mesure la disponibilité en temps, définition retenue par les contrats parce que c'est celle qu'une horloge peut trancher. Le livre SRE de Google en signale la limite : pour un service qui peut être partiellement disponible, ou dont la charge varie dans la journée, une mesure agrégée — requêtes réussies divisées par requêtes totales — est plus utile que le décompte des minutes, car dix minutes pendant lesquelles la moitié du trafic échoue à midi ne sont pas le même événement que dix minutes sans trafic à quatre heures du matin. Un chiffre en temps ne sait pas les distinguer, et cette page non plus.

Deux comportements encore, à connaître avant de te fier à la case inverse. Une cible de 100 % est acceptée et donne un budget de 0 s : une seule minute d'arrêt renvoie alors 99,9977 % et le verdict « En dessous de la cible » — arithmétiquement juste, et bonne illustration de la raison pour laquelle personne n'écrit 100 % dans un contrat. Et une cible hors de l'intervalle 0 à 100 remplace tout le bloc de résultats par un message d'une ligne au lieu d'afficher un chiffre faux, ce qui est le bon comportement et plus rare qu'il ne devrait l'être.

Questions fréquentes

Un 99,9 % mesuré au mois est-il la même promesse qu'un 99,9 % mesuré à l'année ?

Non, et l'écart est d'un facteur 12,17. Mesuré sur un an, 99,9 % autorise 525,60 minutes d'arrêt ; mesuré sur un mois de 30 jours, 43,20. Un seul incident de quatre heures tient largement dans l'engagement annuel et fait exploser le mensuel. La fenêtre annuelle est la plus généreuse des deux, contrairement à ce qu'on suppose d'ordinaire, et c'est aussi celle qui permet à un prestataire d'absorber une très mauvaise journée en affichant une année propre. Si tu compares deux offres, compare les fenêtres avant de comparer les neuf.

Pourquoi la page affiche-t-elle déjà « En dessous de la cible » au chargement ?

Parce que les deux cases arrivent préremplies, et que les deux valeurs par défaut se contredisent volontairement. La cible démarre à 99,9 %, ce qui autorise 43 min 12 s sur un mois de 30 jours, et la case d'arrêt observé démarre à 51 minutes, ce qui donne 99,8819 %. Huit minutes de dépassement, c'est un manquement crédible plutôt qu'une catastrophe : la page s'ouvre donc sur la situation avec laquelle on arrive vraiment — le lendemain matin, à vouloir savoir si le chiffre qu'on a viole le chiffre qu'on a promis. Change l'un des deux champs et le verdict se met à jour.

Combien de temps dure un mois, pour cet outil ?

Trente jours à l'écran, et 30,42 jours dans le calcul de repli enregistré sous le même nom d'outil. Le composant avec lequel tu interagis utilise 43 200 minutes ; le calcul déclaratif qui se tient derrière le même identifiant en utilise 43 800. À 99,9 %, cela donne 43,20 et 43,80 minutes, soit 36 secondes d'écart ; à 99 %, 432 et 438. L'année fait 365 jours dans les deux cas et le jour 86 400 secondes dans les deux : le mois est le seul endroit où ils divergent. Prends la valeur à 30 jours si tu raisonnes sur une fenêtre fixe, et le mois calendaire de ton prestataire si tu discutes une facture.

Mon prestataire promet 99,99 %. Cela fait-il quatre minutes d'arrêt ?

Quatre minutes dix-neuf secondes par mois, ou cinquante-deux minutes trente-quatre secondes par an, si la fenêtre est celle que tu supposes. Mais lis le contrat sur trois points avant de bâtir dessus. D'abord, ce qui compte comme indisponible : beaucoup d'accords ne comptent qu'une perte totale de connectivité externe, si bien qu'un service qui répond lentement, ou qui échoue une requête sur dix, peut être « en ligne » au sens qui compte. Ensuite, ce qui est exclu : maintenance programmée, ta propre configuration, tout ce qui est en amont. Enfin, ce qui se passe en cas de manquement : chez Amazon EC2, le remède est un avoir de 10, 30 ou 100 % des sommes dues pour les ressources concernées, et c'est à toi de le réclamer.

Faut-il mesurer la disponibilité en minutes ou en requêtes échouées ?

Les deux, pour des publics différents. Le temps est ce qu'un contrat peut faire respecter, parce qu'une horloge tranche le débat, et ce calculateur travaille exactement dans cette monnaie. Mais le livre SRE de Google fait valoir que pour des services qui peuvent être partiellement disponibles, ou dont le trafic est irrégulier dans la journée, un chiffre agrégé — requêtes réussies sur requêtes totales — décrit mieux l'expérience réelle. Les deux peuvent diverger fortement : une panne de cinq minutes à l'heure de pointe et une panne de cinq minutes à trois heures du matin sont identiques en minutes et très différentes en requêtes échouées. Donne l'agrégat à ton équipe et le chiffre temporel à ton client, et ne laisse jamais l'un se substituer discrètement à l'autre.