Calculateur de Disponibilité SLA
Calcule le temps d'arrêt autorisé selon le taux SLA.
- Per year
- 8.8 h
- Per month (30d)
- 43.2 min
- Per week
- 10.1 min
- Per day
- 1.4 min
Vue d’ensemble
Les objectifs de disponibilité s’énoncent en pourcentages, et les pourcentages rendent très mal les ordres de grandeur. 99 % et 99,9 % semblent voisins et diffèrent de plus de trois jours par an. Ce calculateur convertit le pourcentage en temps, la seule forme sous laquelle le chiffre est réellement exploitable.
Saisissez une valeur de disponibilité et vous obtenez l’indisponibilité permise sur un an, un mois, une semaine et un jour.
Utilisation
- Saisissez un pourcentage de disponibilité, ou cliquez sur un préréglage.
- Lisez l’indisponibilité permise sur les quatre fenêtres.
Les préréglages couvrent les paliers que l’on rencontre dans les accords réels : 90, 95, 99, 99.9, 99.95, 99.99 et 99.999.
Le tableau de référence
| Disponibilité | Par an | Par mois (30 j) | Par semaine | Par jour |
|---|---|---|---|---|
| 90 % | 36.50 days | 3.00 days | 16.8 h | 2.4 h |
| 95 % | 18.25 days | 1.50 days | 8.4 h | 1.2 h |
| 99 % | 3.65 days | 7.2 h | 1.7 h | 14.4 min |
| 99,9 % | 8.8 h | 43.2 min | 10.1 min | 1.4 min |
| 99,95 % | 4.4 h | 21.6 min | 5.0 min | 43.2 s |
| 99,99 % | 52.6 min | 4.3 min | 1.0 min | 8.6 s |
| 99,999 % | 5.3 min | 25.9 s | 6.0 s | 864 ms |
Deux points méritent l’attention. La colonne journalière est ce dans quoi un seul mauvais déploiement doit tenir. Et en dessous d’environ 99,99 %, l’indisponibilité permise pour une journée est plus courte que le temps qu’il faut habituellement à un humain pour remarquer une alerte, ouvrir un tableau de bord et décider quoi faire — c’est la frontière pratique où la fiabilité cesse d’être un problème d’exploitation pour devenir un problème d’architecture.
Choisir une cible
Raisonnez à rebours depuis les conséquences, et non vers l’avant depuis l’ambition.
Demandez-vous ce qui se passe pendant la panne. Si un traitement par lots s’exécute en retard puis rattrape son retard, la cible peut être basse. Si un client ne peut pas finaliser un achat, la cible suit le chiffre d’affaires. Si un service d’urgence en dépend, la cible n’est plus vraiment la question que vous êtes en train de poser.
Confrontez ensuite la cible à vos dépendances. La disponibilité se compose de façon multiplicative pour tout ce qui est en série : un service qui a besoin de trois composants à 99,9 % chacun est plafonné aux alentours de 99,7 % avant même d’avoir commis la moindre erreur de son côté. Vous ne pouvez pas promettre plus que ce que permet votre chemin critique, et ajouter une reprise ne change rien à l’arithmétique à moins que les défaillances ne soient indépendantes.
Confrontez-la enfin à votre processus de rétablissement. Une cible de 99,99 % avec une bascule manuelle et une astreinte alertée par e-mail n’est pas une cible, c’est un vœu. Le chiffre implique le mécanisme.
SLO et SLA sont deux chiffres différents
Gardez le SLO interne plus strict que le SLA contractuel. L’écart constitue votre marge d’exploitation : la zone où vous avez manqué votre propre objectif et commencé à réagir, sans avoir encore encouru de pénalité.
Un SLO interne de 99,9 % derrière un SLA contractuel de 99,5 % laisse à peu près 2,9 heures de battement par mois entre le premier signal (43 minutes) et le premier avoir sur facture (3,6 heures). Si les deux chiffres sont égaux, l’instant où vous vous en apercevez est aussi celui où vous devez de l’argent, ce qui supprime toute possibilité de traiter le problème discrètement.
Lisez également les exclusions. La plupart des SLA ne comptent ni la maintenance annoncée, ni les défaillances provoquées par la configuration du client lui-même, ni les cas de force majeure. Ces exceptions font qu’un service peut respecter son SLA sur un mois où les utilisateurs ont subi une indisponibilité bien réelle — ce qui est un résultat juridique, pas un résultat d’ingénierie.
Décider ce qui compte comme une panne
Le pourcentage n’est que de l’arithmétique ; la difficulté est dans la définition à laquelle il s’applique. Deux équipes peuvent annoncer des disponibilités différentes pour le même mois sans qu’aucune ne mente.
Mesuré depuis où ? Une sonde placée à l’intérieur de votre propre réseau contourne le CDN, le DNS et le chemin internet — là où se produit une large part des défaillances visibles par les utilisateurs. Mesurer depuis l’extérieur donne un chiffre plus proche du vécu réel, et plus mauvais que celui qu’affiche votre tableau de bord.
Mesuré à quelle fréquence ? Une sonde toutes les cinq minutes est incapable de détecter une panne de moins de cinq minutes, et elle attribuera à une panne de 30 secondes soit zéro, soit cinq minutes d’indisponibilité selon le moment où elle tombe. Sonder grossièrement ne vous rend pas plus fiable ; cela rend seulement votre mesure moins capable de voir.
Quel point d’entrée ? Un contrôle de santé qui renvoie 200 dès lors que le processus tourne annoncera une disponibilité parfaite pendant une panne où toutes les vraies requêtes échouaient. Le contrôle doit solliciter les dépendances qui comptent.
Les pannes partielles. Si un point d’entrée sur vingt est cassé, le service est-il disponible ? Une définition fondée sur le temps répond généralement oui. Les utilisateurs de ce point d’entrée répondent non. C’est la principale raison de définir la disponibilité comme un rapport de requêtes réussies plutôt que comme des intervalles de fonctionnement — voir le calculateur de budget d’erreur pour ce cadrage.
Écrivez la définition avant de vous engager sur le chiffre, parce que c’est sur la définition que le désaccord surviendra plus tard.
Exemples
- Justifier une redondance. 99,9 % autorise 43 minutes par mois ; un déploiement mono-région avec bascule manuelle en dépense régulièrement davantage sur un seul incident.
- Dimensionner une fenêtre de maintenance. Une fenêtre de quatre heures dépasse le budget de tout ce qui vise 99,9 % ou mieux, dès lors qu’elle compte comme de l’indisponibilité. Soit elle ne compte pas contractuellement, soit il vous faut une migration sans interruption.
- Vérifier la promesse d’un fournisseur. Une annonce de 99,99 % sans aucune bascule automatique décrite quelque part dans la documentation est un chiffre marketing.
- Régler un seuil d’alerte. À 99,95 %, une minute d’indisponibilité par semaine représente un cinquième du budget hebdomadaire. C’est l’échelle que votre alerting doit savoir résoudre.
Remarques
Ici, l’année compte 365 jours et le mois 30 jours. Les années bissextiles et les mois calendaires décalent légèrement les chiffres ; si un contrat se joue sur cette différence, appliquez la définition écrite dans le contrat.
Cet outil répond à la question « combien d’indisponibilité ce pourcentage autorise-t-il ». Si vous voulez aussi savoir combien de requêtes en échec tiennent dans le budget, et quelle part vous en avez déjà dépensée, utilisez le calculateur de budget d’erreur — c’est la même arithmétique appliquée au volume de requêtes plutôt qu’au temps.