Chiffrer la disponibilité : SLA, MTTR, RTO, RPO et points uniques de défaillance

Objectif

Avant d'installer HAProxy ou Pacemaker, savoir ce que l'on doit garantir : mesurer la disponibilité réelle d'un service, comprendre ce qui la fait baisser, et repérer les composants dont la panne arrête tout.

L'essentiel

• La disponibilité se calcule à partir des incidents réels, en suivant les règles du contrat (ce qui est exclu, comment on mesure).
• A = MTBF ÷ (MTBF + MTTR) : on gagne autant en réparant plus vite (MTTR) qu'en tombant moins souvent (MTBF).
• RTO (durée d'arrêt acceptable) et RPO (perte de données acceptable) se traduisent directement en technologies : bascule automatique ou manuelle, réplication synchrone ou asynchrone, sauvegarde.
• Un point unique de défaillance (SPOF) est tout élément présent en un seul exemplaire sur le chemin d'une requête : un serveur, mais aussi un commutateur, une alimentation, un certificat, un administrateur.
• Ajouter de la redondance ajoute de la complexité : chaque mécanisme de bascule devient lui-même une source de pannes s'il n'est pas testé.

Les bases (tableau des « neuf », SLA d'un fournisseur cloud, règle 3-2-1) sont dans le cours Cloud — fondamentaux ; le SLO et le budget d'erreur dans Observabilité. Ici, on passe au calcul sur une plateforme que vous exploitez vous-même.

1. Mesurer une disponibilité au sens du contrat

Un contrat de service (SLA) précise toujours :

Le calcul sur un journal d'incidents :

# date;type;minutes;description
awk -F';' '$2=="imprevu" {s += $3} END {printf "%.2f %%\n", 100 * (1 - s/43200)}' incidents.csv

Le chiffre « contractuel » n'est pas le chiffre vécu par les clients : une maintenance planifiée d'une heure un samedi soir ne compte pas dans le SLA, mais la boutique était bien fermée. Suivez les deux : la disponibilité contractuelle (pour les pénalités) et la disponibilité réelle (pour décider des investissements).

2. MTBF, MTTR : réparer vite compte autant que ne pas tomber

• MTBF (mean time between failures) : temps moyen entre deux pannes.
• MTTR (mean time to repair/restore) : temps moyen pour rétablir le service.

A = MTBF / (MTBF + MTTR)

Une panne par mois (MTBF ≈ 720 h) réparée en 4 h  : 720 / 724   = 99,45 %
La même panne réparée en 30 min                    : 720 / 720,5 = 99,93 %

Le MTTR se décompose : détecter (supervision), diagnostiquer (journaux, procédures), réparer (accès, pièces, sauvegardes), vérifier. Une bascule automatique réduit surtout la réparation ; une bonne alerte réduit la détection. Une équipe d'astreinte à Casablanca qui reçoit l'alerte en 1 minute au lieu de 20 gagne plus qu'avec un second serveur mal configuré.

3. RTO et RPO : du besoin métier à la technique

Points à retenir :

• RPO = 0 exige une réplication synchrone (DRBD protocole C, PostgreSQL synchronous_commit) : chaque écriture attend le second serveur, donc la latence augmente.
• Le RPO réel d'une sauvegarde quotidienne est de 24 h dans le pire cas (panne juste avant la sauvegarde suivante), pas « quelques heures ».
• Le RTO réel se mesure lors d'un test de bascule, chronomètre en main. Un RTO jamais testé est une hypothèse.

4. Inventorier les points uniques de défaillance

Suivez le chemin d'une requête, du client jusqu'au disque, et notez chaque étape :

client ─► DNS ─► lien Internet ─► pare-feu ─► ml-lb-01 ─► ml-web-0[1-3] ─► ml-app-0[1-2] ─► ml-db-0[1-2]
                                                    │
                                              ml-nfs-01 (fichiers clients)

# Un inventaire simple : composant;rôle;exemplaires
awk -F';' 'NR > 1 && $3 == 1 {print "SPOF :", $1, "(" $2 ")"}' architecture.txt

Les SPOF que l'on oublie le plus souvent :

Pour chaque SPOF, trois réponses possibles : le doubler, réduire son MTTR (pièce de rechange, procédure écrite, supervision de l'expiration), ou accepter le risque en l'écrivant noir sur blanc.

5. Le prix de la redondance

Doubler un composant ne double pas la fiabilité si :

• les deux exemplaires partagent une cause commune (même baie, même version logicielle boguée, même configuration erronée poussée partout) ;
• le mécanisme de bascule n'est jamais testé ;
• personne ne remarque qu'un des deux est déjà en panne (redondance « dormante » : on découvre la panne du second le jour où le premier tombe).

Règle d'exploitation : toute redondance doit être supervisée. Un répartiteur qui sert le trafic avec un seul serveur sur trois vivant doit lever une alerte, même si les clients ne voient rien.

Selon la version

Pièges fréquents

• Compter les maintenances planifiées dans un calcul de SLA qui les exclut, ou l'inverse : lisez le contrat avant de calculer.
• Confondre RPO et fréquence de sauvegarde : une sauvegarde toutes les 24 h donne un RPO de 24 h, pas de 12 h « en moyenne ».
• Oublier les dépendances : deux serveurs web redondants qui montent le même NFS unique restent à la merci de ce NFS.
• Promettre 99,99 % (4 min par mois) avec une procédure de bascule manuelle qui demande 20 minutes.

Lab

Sur une machine Debian 12, vous disposez du journal d'incidents de septembre de la boutique MasterLinux et d'un inventaire de son architecture. Vous allez :

1. calculer la disponibilité au sens du contrat ;
2. dire si le SLA de 99,9 % est tenu ;
3. calculer le MTTR ;
4. extraire la liste des points uniques de défaillance ;
5. donner le RPO réel d'une sauvegarde nocturne unique.

Quiz

1. Pourquoi deux équipes peuvent-elles annoncer deux disponibilités différentes pour le même mois ?
2. Une panne par mois, réparée en 30 minutes au lieu de 4 heures : quel indicateur s'améliore ?
3. Quelle réplication faut-il pour un RPO de zéro, et quel en est le coût ?
4. Citez trois points uniques de défaillance qui ne sont pas des serveurs.
5. Qu'est-ce qu'une redondance « dormante » et comment l'éviter ?