Qu'est-ce que la Reliability Engineering ?

Qu'est-ce que la reliability engineering ?

La reliability engineering est la discipline qui consiste à concevoir, opérer et améliorer continuellement des systèmes pour qu'ils atteignent un objectif mesurable d'availability, de latence et de correction. La sortie est faite de chiffres concrets : 99,95% de requests réussis, latence p99 sous 800 ms, zéro perte de données sur un trimestre. Le travail couvre les choix d'architecture (redondance, isolation, capacity), la pratique opérationnelle (incident response, post-incident reviews, on-call) et l'instrumentation (les métriques et traces qui prouvent que le système a atteint son objectif).

En logiciel, la reliability engineering est la discipline mère. Le Site Reliability Engineering (SRE) en est la variante moderne la plus courante, née chez Google vers 2003 et codifiée dans le SRE book. La reliability engineering existe aussi hors du logiciel (aérospatial, fabrication, réseaux électriques) mais la variante logicielle est celle que la plupart des équipes mettent en production aujourd'hui.

Reliability engineering vs DevOps vs SRE

Les trois termes se chevauchent dans l'usage industriel mais se centrent sur des choses différentes :

• Reliability engineering est le résultat-parapluie : faire en sorte que le système atteigne ses targets de fiabilité. Outils et structure d'équipe sont les moyens.
• SRE est un modèle opérationnel spécifique pour la reliability engineering : des software engineers font tourner la production avec un error budget lié à un SLO, en visant moins de 50% du temps en toil. Pionnier chez Google.
• DevOps est un mouvement culturel et d'outils centré sur la fermeture du fossé entre dev et ops : ownership partagé, CI/CD, infrastructure as code. C'est la pratique ; SRE est une implémentation prescriptive ; reliability engineering est le résultat.

Lecture pratique : une équipe qui fait tourner un on-call style SRE avec error budget fait de la reliability engineering. Une équipe en DevOps sans SLOs explicites peut aussi faire de la reliability engineering, juste moins formellement. Le marqueur clé est si tu as un nombre que tu défends.

Ce que couvre la reliability engineering

• Définition SLI/SLO/SLA : choisis les quelques métriques de user journey qui comptent, définis un percentile cible et seuil, écris-le pour que l'équipe et le business soient d'accord.
• Error budgets : l'inverse du SLO. Si ton SLO est 99,9% d'availability, ton error budget est 0,1% des requests. Brûle le budget en vélocité features ; pause quand tu l'épuises.
• Incident response : rotations on-call, runbooks, politique de paging, classification de severity et une limite dure au time-to-acknowledge et time-to-mitigate.
• Post-incident reviews : write-ups blameless dans les jours suivant chaque Sev-1, action items suivis jusqu'à completion, learnings repliés dans les runbooks et l'architecture.
• Capacity et architecture : redondance entre zones et régions, isolation des dépendances, chemins de graceful degradation, capacity testing et load testing périodiques.
• Réduction de toil : automatise le travail que le on-call répète. La cible SRE est moins de 50% du temps en toil ; mesure-le.

Métriques clés de reliability engineering

1. Pourcentage de SLO attainment : sur les 28 ou 30 derniers jours, quel pourcentage de la cible SLO as-tu atteint par service.
2. Burn rate d'error budget : au rythme actuel, combien de jours avant épuisement du budget.
3. MTTD (mean time to detect) : du début de l'incident au premier alert acquitté.
4. MTTR (mean time to restore) : du début de l'incident à la mitigation visible utilisateur, la métrique qui mappe à l'impact business.
5. Change-failure rate : pourcentage de déploiements qui causent un incident ou rollback (une métrique DORA, s'applique proprement ici).
6. Pourcentage de toil : par engineer on-call, quelle fraction du temps est partie en travail manuel répétitif automatisable.

Comment pratiquer la reliability engineering

Commence par écrire un SLO par journey critique utilisateur : "99,9% des requests vers /checkout complètent sous 1500 ms p95 sur 28 jours." Instrumente la métrique pour que le SLO soit calculable depuis la télémétrie production. Mets une alerte error budget à 80% et 100% de burn. Tiens un post-mortem blameless après chaque Sev-1 avec action items assignés et suivis. Planifie des load tests et chaos drills avant les lancements pour que capacity et graceful-degradation soient prouvés avant que le trafic n'arrive. Révise le SLO trimestriellement contre le comportement réel utilisateur et la vélocité d'ingénierie ; serre quand c'est facile, desserre quand c'est nécessaire.

Le load testing est un input fondamental de la reliability engineering : tu ne peux pas défendre un SLO de latence sans preuve périodique que le système tient sous charge concurrente réaliste. Voir load testing et spike testing pour les techniques et observability pour l'instrumentation production qui alimente le SLO.

Pour les équipes qui veulent une matrice périodique de load tests conçue par des ingénieurs comme partie de leur programme de fiabilité plutôt qu'un one-off, LoadFocus propose des services de load testing avec cycles trimestriels, rapports de capacity headroom et décompositions liées directement à tes SLOs.