Disponibilité et fiabilité : « neuf », MTBF, MTTR et tolérance aux pannes

Quatre mots souvent confondus

Pour les utilisateurs, un système fonctionne ou ne fonctionne pas. Les architectes ont besoin de mots plus fins, car chaque mot appelle une réponse de conception différente. La disponibilité est la proportion du temps (ou des requêtes) pendant laquelle le système est prêt à fournir son service quand on le lui demande. La fiabilité est la probabilité que le système fonctionne correctement, sans défaillance, pendant une période donnée et dans des conditions données. La tolérance aux pannes est la capacité à continuer de fournir le service même lorsqu’une partie est défaillante. La résilience est la capacité plus large à absorber une perturbation, à maintenir le service essentiel (éventuellement dégradé) puis à revenir à la normale.

L’ISO/IEC 25010:2023 range la disponibilité, la tolérance aux pannes et la capacité de récupération, ainsi que l’absence de défauts (qui a remplacé le terme maturité de 2011), parmi les sous-caractéristiques de la fiabilité. Bass, Clements et Kazman, dans Software Architecture in Practice, traitent la disponibilité comme un attribut de qualité à part entière, parce qu’elle oriente un très grand nombre de décisions architecturales. Aucune de ces deux visions n’est fausse ; utilisez celle qui facilite la discussion, mais précisez bien de quel mot vous parlez.

La différence entre disponibilité et fiabilité compte en pratique. Imaginez un service qui plante une fois par heure et redémarre en une seconde. Sa disponibilité est de 3599 / 3600 = 99,97 %, ce qui semble excellent. Sa fiabilité sur un traitement par lots de deux heures est médiocre : si les défaillances surviennent au hasard au rythme d’une par heure, la probabilité de tourner deux heures sans aucune est de e^-2, soit environ 13,5 %. Un terminal de paiement se soucie de la disponibilité ; un long calcul scientifique, un robot chirurgical ou un avion se soucient de la fiabilité sur toute la durée de la mission.

Faute, erreur et défaillance

La communauté de la sûreté de fonctionnement (Avižienis, Laprie, Randell et Landwehr, 2004) distingue trois idées que le langage courant confond. Une faute (fault) est la cause : un bogue, un disque en panne, une erreur de configuration, un certificat expiré. Une faute peut rester dormante pendant des années. Lorsqu’elle est activée, elle produit une erreur : une partie de l’état interne du système qui est incorrecte, comme un enregistrement corrompu ou une valeur erronée en mémoire. Si l’erreur atteint la frontière du service, il en résulte une défaillance (failure) : le service fourni aux utilisateurs s’écarte de ce qu’il devrait être.

Bass, Clements et Kazman reprennent la même idée plus simplement : une défaillance est un écart par rapport à la spécification que les utilisateurs du système peuvent observer, et la cause d’une défaillance est une faute. Pour l’architecte, l’essentiel est que chaque maillon de la chaîne est un point d’intervention. Vous pouvez empêcher les fautes d’apparaître (revue de code, retrait d’un composant du service avant son usure), détecter les erreurs avant qu’elles ne se propagent (validation, contrôles de santé) et contenir ou masquer les erreurs pour qu’elles ne deviennent jamais des défaillances (redondance, nouvelles tentatives, transactions).

Compter les « neuf »

Les objectifs de disponibilité s’écrivent généralement sous forme de pourcentage avec un certain nombre de « neuf » : 99,9 %, ce sont « trois neuf ». Il est utile de convertir chaque objectif en temps d’indisponibilité admis, car un pourcentage masque le peu de temps dont vous disposez réellement. Le calcul est simple : indisponibilité = (1 - disponibilité) x période. Une année de 365 jours compte 525 600 minutes, donc 99,9 % autorise 0,001 x 525 600 = 525,6 minutes, soit environ 8,76 heures. Pour un mois de 30 jours (43 200 minutes), cela autorise 43,2 minutes.

Chaque « neuf » supplémentaire divise la marge par dix, alors que le coût d’ingénierie augmente généralement bien plus vite. À 99,99 %, vous disposez d’environ 4,3 minutes par mois : moins que le temps nécessaire pour qu’une personne d’astreinte soit alertée, se réveille, se connecte et comprenne ce qui ne va pas. Au-delà de trois ou quatre « neuf », le rétablissement doit donc être automatique ; les humains sont trop lents pour être dans la boucle.

MTBF, MTTF et MTTR

Trois moyennes relient les défaillances et les réparations. Le temps moyen jusqu’à la défaillance (MTTF) est la durée moyenne de fonctionnement d’un composant avant qu’il ne tombe en panne. Le temps moyen de réparation (MTTR) est la durée moyenne entre la défaillance et le rétablissement du service (certaines organisations lisent le R comme recover ou restore ; l’idée est la même, mais précisez quel chronomètre vous utilisez : à partir de la défaillance, de la détection ou de la première alerte). Le temps moyen entre défaillances (MTBF) est la durée moyenne entre une défaillance et la suivante.

La formule classique en régime permanent est A = MTBF / (MTBF + MTTR). En toute rigueur, pour un système réparable, MTBF = MTTF + MTTR, et l’expression exacte est MTTF / (MTTF + MTTR) : le temps de fonctionnement divisé par le temps de fonctionnement plus le temps d’arrêt. Les manuels écrivent souvent MTBF là où ils veulent dire temps de fonctionnement moyen ; lorsque les réparations sont courtes par rapport au temps entre défaillances, ce qui est généralement le cas, la différence est négligeable. La formule suppose une moyenne sur le long terme et ne dit rien de la répartition des pannes : c’est pourquoi elle se combine bien avec une mesure de fiabilité et avec des percentiles du temps de réparation.

Composants en série et en parallèle

Les systèmes réels sont des chaînes de composants. Si une requête a besoin du niveau web, du serveur d’application et de la base de données, les trois doivent fonctionner : les composants sont en série, et leurs disponibilités se multiplient. Comme chaque facteur est inférieur à un, le produit est toujours plus faible que le maillon le plus faible. Dix composants à 99,9 % chacun donnent 0,999¹⁰ = 0,990, soit seulement 99,0 %.

Si, au contraire, une seule de plusieurs copies identiques suffit, les copies sont en parallèle (redondance). L’ensemble ne tombe en panne que lorsque toutes les copies tombent en panne en même temps, si bien qu’on multiplie les indisponibilités : A_parallèle = 1 - (1 - A)ⁿ pour n copies identiques. Deux serveurs à 99 % chacun donnent 1 - 0,01 x 0,01 = 99,99 %.

Tactiques de disponibilité : détecter, rétablir, prévenir

Bass, Clements et Kazman regroupent les tactiques de disponibilité en trois familles. Ce sont des options de conception, pas une liste de contrôle à appliquer intégralement ; chacune a un coût.

Choisir entre actif-passif et actif-actif

L’actif-passif est plus simple à raisonner, en particulier pour les composants avec état comme une base de données relationnelle avec un seul primaire accessible en écriture. Ses coûts sont le secours inactif, un délai de failover (détection plus promotion, souvent plusieurs dizaines de secondes) et le risque que le secours se soit discrètement désynchronisé. Un piège classique est le split brain (cerveau divisé) : le réseau entre les deux est coupé, chacun croit l’autre mort, et tous deux acceptent des écritures. Pour s’en prémunir, il faut un quorum ou un arbitre externe.

L’actif-actif utilise toute la capacité et n’a pas d’étape de promotion, mais chaque nœud doit être dimensionné pour supporter toute la charge si son partenaire tombe en panne. Deux nœuds fonctionnant chacun à 70 % d’utilisation seront sollicités à 140 % quand l’un d’eux tombe, et le survivant s’effondre : une conception redondante qui échoue quand même. L’actif-actif vous oblige aussi à résoudre la cohérence des données entre les copies, un vaste sujet en soi (voir cohérence, CAP et PACELC).

Reprise après sinistre : RTO et RPO

La redondance au sein d’un seul centre de données ne vous protège pas contre la perte du centre de données entier, d’une région, d’un compte cloud ou de vos données à cause d’un rançongiciel. La planification de la reprise après sinistre s’appuie sur deux chiffres qui devraient venir du métier, pas des ingénieurs. L’objectif de temps de reprise (RTO) est la durée maximale acceptable pour restaurer le service après un sinistre. L’objectif de point de reprise (RPO) est la perte de données maximale acceptable, mesurée en temps : un RPO de 15 minutes signifie que vous pouvez perdre au plus les 15 dernières minutes de modifications.

Ces deux chiffres conduisent à des conceptions et à des coûts très différents. Des sauvegardes nocturnes copiées dans une autre région donnent un RPO pouvant aller jusqu’à 24 heures et un RTO de nombreuses heures (restaurer des téraoctets prend du temps). Une réplication asynchrone continue vers un secours tiède dans une autre région peut donner un RPO de quelques secondes et un RTO de quelques minutes, pour un coût d’infrastructure peut-être doublé. La réplication synchrone peut ramener le RPO près de zéro, mais ajoute à chaque écriture le temps d’aller-retour entre les sites. Les fournisseurs cloud décrivent une échelle de stratégies : sauvegarde et restauration, pilot light (veilleuse), warm standby (secours tiède) et actif-actif multisite, chacune plus rapide et plus coûteuse que la précédente. Les détails relèvent de multirégion et reprise après sinistre.

Quelle que soit la stratégie, une sauvegarde que vous n’avez jamais restaurée n’est pas une sauvegarde. Testez les restaurations à intervalles réguliers et chronométrez-les ; le temps de restauration mesuré est votre RTO réel.

Des objectifs aux SLI, SLO et SLA

Les pratiques d’exploitation modernes expriment la disponibilité avec trois termes liés, traités en détail dans SLI, SLO et budgets d’erreur. Un indicateur de niveau de service (SLI) est la mesure, par exemple la proportion de requêtes de paiement qui aboutissent en moins de 800 ms. Un objectif de niveau de service (SLO) est la cible interne pour cette mesure sur une fenêtre donnée, par exemple 99,9 % sur 30 jours. Un accord de niveau de service (SLA) est un contrat avec les clients qui prévoit des conséquences, comme des avoirs de service, si un niveau n’est pas atteint ; il est normalement fixé moins strictement que le SLO, pour que l’équipe soit avertie avant que le contrat ne soit violé.

Le SLO transforme la disponibilité en budget. Un SLO mensuel de 99,9 % autorise l’échec de 0,1 % des requêtes ; avec 2 millions de requêtes par mois, cela fait 2000 requêtes en échec, soit environ 43 minutes de panne totale. Les équipes dépensent ce budget d’erreur en prises de risque : mises en production, expériences, migrations. Quand il est épuisé, elles ralentissent et investissent dans la fiabilité. Cela relie les « neuf » abstraits de cette section aux décisions du quotidien.

Erreurs courantes

Promettre des « neuf » sans tenir compte des dépendances : un service à 99,99 % bâti sur une seule base de données à 99,9 % ne peut pas atteindre son objectif. Ajouter de la redondance sans supprimer les causes communes (la même version, le même déploiement de configuration, le même certificat qui expire sur tous les nœuds à minuit). Mesurer la disponibilité depuis l’intérieur du système, où tout semble au vert, alors que les utilisateurs ne peuvent pas l’atteindre à cause du DNS ou d’un réseau de diffusion de contenu. Prévoir un failover sans jamais le répéter ; l’ingénierie du chaos existe précisément pour exercer ces chemins délibérément (ingénierie du chaos). Enfin, courir après un chiffre pour lui-même : un système de planning du personnel utilisé aux heures de bureau n’a pas besoin de cinq neuf, et l’argent sera mieux dépensé ailleurs.

Pour rendre la disponibilité testable, écrivez-la sous forme de scénario (section 2.3) : Lorsque le serveur de base de données primaire tombe en panne aux heures de pointe, le système le détecte en moins de 10 secondes et recommence à accepter des commandes en moins de 60 secondes, sans perdre aucune commande confirmée. Chaque élément de cette phrase devient un choix de conception et un test.