29. La fiabilité : tenir des promesses réalistes
Pourquoi ce chapitre existe
La fiabilité est parfois exprimée comme une exigence absolue : « zéro panne ». Cette formule masque les arbitrages réels. Rendre chaque chemin disponible en toute circonstance a un coût qui peut dégrader la vitesse de changement, le prix du service ou d'autres propriétés de sécurité. L'ingénierie de fiabilité commence lorsqu'une organisation définit quelles promesses comptent pour quels usages, mesure leur tenue et décide consciemment comment investir lorsque ces promesses sont menacées.
Les idées essentielles
- La fiabilité est une propriété de service perçue par les utilisateurs, pas le simple état d'une infrastructure.
- Un SLI mesure un résultat ; un SLO exprime le niveau attendu ; un budget d'erreur rend explicite la marge d'imperfection acceptée.
- La résilience comprend prévention, détection, limitation et récupération ; aucune couche seule ne suffit.
- Les objectifs doivent guider des décisions de produit et de livraison, pas seulement produire des tableaux de bord.
Définir une promesse utile
Un objectif comme « 99,9 % de disponibilité » n'a de sens qu'avec son indicateur : sur quel parcours, quels utilisateurs, quelles erreurs, quelle fenêtre de mesure ? Une API peut répondre 200 tout en retournant une donnée périmée ou un calcul erroné. Choisir un indicateur proche du résultat utilisateur — confirmation réussie, lecture fraîche, tâche terminée — rend le SLO plus exigeant et plus utile.
| Élément | Exemple |
|---|---|
| SLI | Pourcentage de confirmations de commande terminées sans erreur utilisateur |
| SLO | 99,9 % sur 28 jours, hors annulations explicites par le client |
| Budget | La marge restante d'échecs avant de devoir réduire le risque de livraison |
| Action | Ralentir l'exposition, fiabiliser une dépendance ou accepter temporairement un niveau dégradé |
Le budget d'erreur ne doit pas devenir une sanction automatique. Il crée une conversation fondée sur des faits : si le service consomme trop rapidement sa marge, continuer à augmenter son risque sans investir dans la stabilité revient à contredire la promesse faite aux utilisateurs.
Concevoir la récupération
La fiabilité ne dépend pas seulement de la prévention. Une dépendance tombera, une configuration sera erronée, un volume inattendu arrivera. Timeouts, limites de concurrence, idempotence, files d'attente, dégradation et restauration constituent des mécanismes de récupération. Leur valeur se mesure au temps et à la qualité de retour au service, pas à leur présence dans un diagramme.
Une stratégie de failover ou de restauration non exercée reste une hypothèse. Les exercices ciblés révèlent souvent des permissions manquantes, des données impossibles à réconcilier ou un temps de reprise incompatible avec l'objectif affiché.
Anti-patterns
Mesurer la santé par les seuls composants
Un cluster peut être vert alors que le parcours client échoue par manque de capacité métier, dépendance externe ou donnée incorrecte. Les signaux de composants servent au diagnostic ; les objectifs de fiabilité doivent partir du service rendu.
Appliquer le même objectif à tout
Une page de contenu et une opération de paiement ne demandent pas la même disponibilité, fraîcheur ni récupération. Des objectifs différenciés permettent d'investir là où la défaillance produit le plus de dommage.
Accumuler la redondance sans comprendre le mode de panne
Dupliquer un composant ne protège pas d'un bug commun, d'une mauvaise donnée, d'une dépendance unique ou d'une erreur de déploiement. L'analyse doit examiner les causes communes et le comportement du système pendant le basculement.
Bonnes pratiques
Lier objectifs et arbitrages de livraison
Les données de fiabilité doivent influencer le choix de déployer, d'élargir une cohorte ou de réserver du temps à une amélioration. Si elles n'ont aucune conséquence, elles ne sont qu'un rapport rétrospectif.
Favoriser les dégradations honnêtes
Afficher une donnée datée, mettre une demande en attente ou rendre une fonctionnalité temporairement indisponible peut être préférable à un résultat faux. Le comportement de dégradation doit être conçu avec le produit, visible pour l'utilisateur et récupérable ensuite.
Checklist — Une promesse de fiabilité guide-t-elle l'action ?
- Quel résultat utilisateur mesure l'indicateur, avec quelles exclusions justifiées ?
- Quel niveau de service est attendu, et quel dommage évite-t-il ?
- Quelle marge d'erreur reste acceptable et que déclenche sa consommation ?
- Quels modes de panne, y compris communs, ont été analysés ?
- Peut-on limiter, dégrader ou restaurer le service dans le délai pertinent ?
- Les objectifs influencent-ils réellement les décisions de livraison et d'investissement ?
À retenir
La fiabilité est une promesse négociée et mesurée envers les utilisateurs. Les SLO et budgets d'erreur rendent cette promesse actionnable en reliant les défaillances observées aux décisions de conception, de livraison et de récupération.