Mesurer la fiabilité de votre cloud : guide pratique 2026

Temps de lecture : 8 min

Pourquoi les métriques de disponibilité classiques vous mentent

Mon constat de départ était simple : nos chiffres internes de disponibilité ne correspondaient pas à la perception de nos clients. Entre 99,5% et 99,9% de disponibilité mensuelle, les variations dépendaient plus de notre propension à déclarer un incident critique que de la santé réelle de la plateforme. Les clients continuaient d’ouvrir des tickets, mais la métrique restait aveugle à leurs douleurs.

L’ancienne méthode, basée sur les incidents déclarés, avait un défaut structurel majeur : pendant un incident, elle considérait que 100% du produit était indisponible pour 100% des clients ; en dehors, que tout allait bien. Impossible de représenter un impact partiel. De plus, la moyenne globale était calculée sur une trentaine de produits sans aucune pondération par volume de trafic. Un produit avec quelques centaines de requêtes par jour tirait la moyenne vers le bas autant que notre produit phare Droplets.

La solution : diviser pour mieux régner

J’ai donc décidé de ne plus traiter toutes les indisponibilités de la même manière. Une réponse lente de l’API lors de la création d’un Droplet n’est pas la même chose qu’un Droplet inaccessible. L’une est une gêne, l’autre une vraie douleur client. Les mélanger dans un même chiffre, c’était cacher le signal dans le bruit.

J’ai séparé les mesures en deux plans, chacun avec sa propre méthodologie SLI :

• Plan de contrôle : tout ce qui concerne l’orchestration (appels API, opérations Cloud Panel). Le SLI est le taux de succès des requêtes valides. Seules les erreurs 5xx comptent comme échec. Une requête 4xx (mal formée) n’est pas un signe de fiabilité plateforme.
• Plan de données : les instances de produits réelles (Droplets CPU/GPU, clusters Kubernetes, buckets Spaces, endpoints d’inférence, agents IA). La mesure est plus nuancée : pour les ressources qui existent et sont saines, j’utilise les « minutes-ressource » ; pour celles qui servent directement des requêtes, j’utilise une approche basée sur le taux de succès.

Comment pondérer la disponibilité par le trafic réel

Un problème concret : comment agréger la disponibilité sur plusieurs régions quand les volumes de trafic sont très différents ? J’utilise une moyenne pondérée par le volume. Concrètement, je somme les compteurs bruts de succès et de total sur toutes les régions avant de calculer le ratio. Une région qui ne gère que 20% du trafic ne contribue qu’à hauteur de 20% au signal. Plus besoin de pondération manuelle.

Exemple avec NYC3 et TOR1 : sans pondération, NYC3 à 99,99% et TOR1 à 99,95% donnent une moyenne de 99,97%. Mais si TOR1 ne représente que 20% du trafic, cette moyenne est faussée. En sommant les compteurs bruts (741 897 401 succès sur 742 030 952 requêtes), j’obtiens 99,982%, un chiffre bien plus proche de la réalité perçue par les clients.

Des métriques brutes aux règles d’enregistrement Prometheus

Avec la mécanique mathématique en place, j’ai buté sur un problème pratique : interroger des données brutes à haute cardinalité sur des fenêtres de 30 jours dans Prometheus ne fonctionne pas à notre échelle. Les requêtes timeout ou surchargeaient les bases de données de séries temporelles.

J’ai donc ajouté des règles d’enregistrement Prometheus. Au lieu de calculer la disponibilité au moment de la requête, j’ai configuré ces règles à intervalles fixes pour stocker les points de données sous forme de nouvelles séries temporelles. Cela transforme des agrégations coûteuses sur 30 jours en consultations rapides de données pré-calculées par heure.

La convention de nommage suit un schéma standardisé : sli::availability:. Par exemple, pour le plan de contrôle, j’ai des règles comme sli:control-plane:availability:1h. Pour un produit comme les bases de données managées, j’utilise la pondération par magnitude : le nombre d’instances multiplié par la disponibilité moyenne, normalisé par le temps-instance total.

Cartographier les parcours produit

Un produit n’existe pas comme un service unique. Par exemple, notre service Kubernetes s’étend de l’edge jusqu’à l’API, l’authentification, les services de base, et le reconciler. Si l’un de ces composants se dégrade, le client le ressent. Pour capturer cela, j’ai construit des « Product Journeys » : une cartographie de la chaîne de dépendances de services pour un produit.

Chaque boîte dans ce diagramme a son propre SLI de disponibilité. L’edge est notre signal principal, car c’est là que les clients interagissent avec le produit. Les services internes derrière l’edge nous donnent la décomposition : quand la disponibilité de l’edge chute, je peux tracer quel composant de la chaîne en est la cause.

Alerting multi-fenêtres et multi-burn-rate

Avec les règles d’enregistrement produisant des SLI de disponibilité, l’étape suivante était l’alerting. J’ai commencé avec une alerte basée sur un unique taux d’épuisement sur une fenêtre d’une heure. Mais cela avait une limite : des pics brefs déjà résolus déclenchaient des pages, et de vrais incidents maintenaient l’alerte active jusqu’à une heure après leur résolution.

Pour corriger cela, j’ai adopté une approche multi-fenêtres et multi-burn-rate, suivant la pratique issue du Google SRE Workbook. Concrètement :

• Multi-fenêtres : une fenêtre longue confirme la significativité statistique, une fenêtre courte confirme que le problème est actif. Fini les faux positifs et les alertes persistantes.
• Multi-burn-rate : un second seuil pour détecter les dégradations lentes. Une fuite d’erreurs sur plusieurs heures passerait sous le radar d’un seul seuil élevé, tout en consumant le budget d’erreur.

Les budgets d’erreur comme politique d’ingénierie

Avec les SLI et l’alerting multi-fenêtres en place, j’ai commencé à suivre strictement les budgets d’erreur. Le budget d’erreur est l’inverse du SLO : si l’objectif est 99,95% de disponibilité, nous avons un budget de 0,05% d’échecs sur la fenêtre de mesure. J’utilise une fenêtre glissante de 30 jours, car la confiance client ne se réinitialise pas le premier du mois.

Le budget d’erreur n’est pas une simple métrique de reporting. Il influence directement ce que les équipes peuvent déployer et comment elles allouent leur temps. J’ai défini quatre zones :

• Vert : tout va bien, les équipes peuvent déployer rapidement et prendre des risques.
• Orange : les déploiements majeurs sont stoppés, la majeure partie du sprint passe sur la fiabilité.
• Rouge : tout s’arrête sauf la stabilisation.

Cela fait du budget d’erreur un outil de décision, pas juste une métrique de dashboard. Quand un incident de haute sévérité impacte plusieurs produits et consomme le budget partout, la politique rend la réponse automatique.

Du cœur de métier à l’inférence IA

Tout ce que j’ai décrit a été construit pour les produits d’infrastructure de base : Droplets CPU, Spaces, Bases de données managées. Mais le même cadre s’applique directement aux nouvelles gammes de produits, y compris les GPU Droplets, la plateforme d’inférence, et les agents IA. C’était intentionnel.

J’ai construit un cadre avec des principes clairs (séparation plan de contrôle / données, pondération par magnitude, règles d’enregistrement, alerting multi-fenêtres, politique de budget d’erreur), et je les ai appliqués d’abord aux produits de base. Une fois les schémas prouvés, étendre aux nouveaux produits est une question de définition des bons SLI, pas de reconstruction de l’infrastructure.

Les GPU Droplets suivent le même modèle que les Droplets CPU : le SLI du plan de contrôle suit le taux de succès des requêtes API pour les opérations de cycle de vie des instances GPU, et le SLI du plan de données suit la disponibilité des instances GPU en utilisant la même approche minutes-ressource. Pour la plateforme d’inférence et les agents IA, j’ai déjà commencé à appliquer le même cadre. Par exemple, la disponibilité de l’inférence serverless est basée sur le taux de succès des requêtes au niveau du service.

Les chiffres de disponibilité sont faciles à publier. Ce qui est plus difficile, c’est de construire un cadre de mesure auquel vous faites réellement confiance, où les chiffres reflètent ce que les clients vivent vraiment, plutôt que la manière dont vous avez choisi de compter les incidents. C’est ce que ce système apporte : une vision précise et pondérée de la santé de la plateforme, qui ne nous flatte pas quand les choses sont partiellement cassées et ne nous punit pas pour être honnêtes sur les échecs.

Nicolas D.

Développeur full-stack depuis 25 ans, je suis passé du PHP des années 2000 aux stacks modernes (Next.js, React Native, IA). J’accompagne entrepreneurs et créateurs dans leurs projets digitaux avec une approche pragmatique : du code aux résultats concrets.