C'est quoi un SLA, et comment calculer celui de votre application

« Disponible 99,99 % du temps »

Vous avez déjà lu ce genre de phrase : « notre service est disponible 99,99 % dans l'année, et en cas de bug nous vous répondons sous 2 heures. » Ça s'appelle un SLA, pour Service Level Agreement. C'est un contrat entre un fournisseur de service et son client — et dans ce cas, le client, c'est votre application.

Les « X neufs »

Un SLA porte surtout sur l'uptime, et on l'exprime en nombre de neufs.

• 99,5 % : le service est indisponible 1 jour, 19 heures et 48 minutes dans l'année.
• 99,9 % (trois neufs) : indisponible 8 heures et 45 minutes dans l'année.
• 99,99 % (quatre neufs) : indisponible 52 minutes dans l'année.

Ajouter un neuf coûte cher, en maintenance comme en infrastructure. Mais dans certains cas, ne pas le payer coûte encore plus. Prenez un système financier qui traite 10 000 € de transactions par minute : avec un SLA de 99,9 %, les 525 minutes d'arrêt annuelles représentent environ 5,2 millions d'euros de transactions non traitées.

C'est pour ça que le SLA compte autant sur les gros logiciels mondiaux.

Calculer le SLA de votre application

Imaginons une application monolithique hébergée chez un cloud provider — AWS, Google Cloud, peu importe. Il vous promet 99,9 % d'uptime. Votre SLA vaut donc 99,9 %, puisque vous dépendez de lui.

Avec le temps, vous ajoutez une base de données externe qui, elle, promet 99,5 %. Votre SLA vient de baisser à cause d'elle. Les disponibilités ne se moyennent pas, elles se multiplient :

SLA = 99,9 % × 99,5 % = 0,999 × 0,995 = 0,994 ≈ 99,4 %

Une seule dépendance et le budget de panne passe de 8 heures à plus de 52 heures par an.

Remonter le SLA avec un fallback

Il y a toujours des solutions. On peut ajouter un fallback à SLA élevé pour faire remonter l'ensemble — une queue, ou une deuxième base de données. Le composant n'est indisponible que si le primaire et le secours tombent en même temps, donc on multiplie les indisponibilités :

SLA composant = 1 - [(1-  Primary Availability)* (1 - Fallback Availability)] 
= 1 - [(1 - 0,995) × (1 - 0,999)] = 0,999995 ≈ 99,999 %

Le composant base de données est remonté. On recalcule le SLA de l'application entière :

SLA application = 0,999 × 0,999995 ≈ 99,9 %

On est revenu au plafond imposé par l'hébergeur. Mais à quel coût ?

Ce que le calcul ne dit pas

Deux limites à garder en tête avant d'annoncer un chiffre à un client.

D'abord, la formule du fallback suppose que les deux bases ne tombent jamais en même temps. Deux répliques dans la même zone de disponibilité, chez le même fournisseur, mises à jour par le même script, ne sont pas indépendantes. Le 99,999 % est un plafond théorique.

Ensuite, un chemin de secours jamais emprunté ne fonctionne pas le jour où on en a besoin. S'il n'est pas testé en conditions réelles, il ajoute du code et de la facture, pas de la disponibilité.

Souvent, l'option la moins chère n'est pas d'ajouter une brique mais d'en retirer une du chemin critique : rendre un appel asynchrone, servir une réponse dégradée depuis un cache. Un composant qui n'est plus obligatoire pour répondre ne multiplie plus votre SLA.

À retenir

• Le SLA est un contrat, pas une intention. Traduisez toujours le pourcentage en heures d'arrêt par an.
• Vos dépendances se multiplient entre elles : votre SLA réel est plus bas que celui de votre pire composant.
• Un fallback fait remonter un composant très haut, mais seulement si ses pannes sont indépendantes de celles du primaire.
• Chaque neuf supplémentaire s'arbitre en euros par minute d'arrêt.

Reste une question, et elle n'est pas triviale : les cloud providers, eux, sur quoi calculent-ils le SLA qu'ils vous vendent ?