Qu'est-ce que l'ingénierie de la fiabilité ?

Qu'est-ce que l'ingénierie de la fiabilité (reliability engineering) ?

L'ingénierie de la fiabilité est la pratique qui consiste à concevoir, exploiter et améliorer des systèmes pour qu'ils atteignent un objectif de fiabilité mesurable, comme la part de requêtes réussies ou un percentile de latence. L'objectif est écrit et mesuré, et l'équipe arbitre en fonction de lui, par exemple livrer plus vite ou d'abord corriger la stabilité. Le Site Reliability Engineering (SRE) en est la version logicielle la plus connue.

Ingénierie de la fiabilité, SRE et DevOps

Ces termes se recoupent mais désignent des choses différentes. L'ingénierie de la fiabilité est le but : le système atteint ses objectifs. Le SRE est le modèle d'exploitation de Google pour y parvenir. Selon le livre SRE, Benjamin Treynor Sloss l'a lancé chez Google en 2003, et le livre définit le SRE comme « what happens when you ask a software engineer to design an operations team ». Google plafonne le travail d'exploitation à 50 % du temps d'un SRE pour que le reste aille à l'ingénierie. Le DevOps est une culture et un ensemble d'outils qui rapprochent développement et exploitation.

Un test pratique : si votre équipe a un chiffre de fiabilité qu'elle défend, elle fait de l'ingénierie de la fiabilité, quels que soient les intitulés de poste.

Les briques de base

• SLI (indicateur de niveau de service). Une mesure quantitative soigneusement définie d'un aspect du service, comme la latence des requêtes ou le taux d'erreurs.
• SLO (objectif de niveau de service). Une valeur ou une plage cible pour un SLI, par exemple « 99,9 % des requêtes réussissent ».
• SLA (accord de niveau de service). Un contrat assorti de conséquences si les objectifs ne sont pas atteints. Sans conséquence explicite, il s'agit probablement d'un SLO. Voir la gestion des SLA.
• Budget d'erreurs. Un moins l'objectif de disponibilité. Avec 99,99 %, il reste 0,01 % à dépenser en livraisons et expériences. Dans le modèle de Google, les livraisons sont suspendues quand le budget est épuisé.
• Gestion des incidents et post-mortems sans blâme. Les post-mortems se concentrent sur les causes contributives, sans mettre en cause une personne ou une équipe, et sont rédigés pour les incidents significatifs.
• Réduction du toil. Le toil est un travail manuel, répétitif et automatisable qui croît avec le service. L'objectif du SRE est de le garder sous 50 % du temps de chaque ingénieur.
• Capacité et architecture. Redondance, isolation des dépendances et dégradation maîtrisée, vérifiées par des tests de capacité.

Exemple : un SLO et son budget

Les chiffres sont illustratifs. Supposons que le SLI soit la part des requêtes /checkout qui réussissent en moins de 1 500 ms et que le SLO soit de 99,9 % sur 30 jours. Le budget d'erreurs est de 0,1 %. Avec 1 000 000 de requêtes de paiement sur la période, cela autorise 1 000 requêtes en échec. Si la moitié du budget est dépensée dès la première semaine, l'équipe ralentit les livraisons risquées et travaille sur la stabilité. S'il est à peine entamé, elle peut livrer plus vite ou resserrer le SLO.

Le livre SRE donne de bons conseils pour choisir les chiffres : partez de ce qui compte pour les utilisateurs, utilisez peu d'indicateurs, préférez les percentiles aux moyennes (pourquoi les percentiles valent mieux que les moyennes, en anglais), ne recopiez pas votre performance actuelle dans un SLO et commencez par une cible plus souple que vous resserrerez. Lisez-le dans le chapitre sur les objectifs de niveau de service (en anglais).

Les indicateurs suivis par les équipes de fiabilité

• Atteinte du SLO : la part de l'objectif du SLO tenue par service sur la période.
• Vitesse de consommation du budget d'erreurs : à quel rythme il est dépensé et quand il sera épuisé à ce rythme.
• MTTD (délai moyen de détection) : du début d'un incident à la première alerte.
• MTTR (délai moyen de rétablissement) : du début d'un incident au rétablissement visible par les utilisateurs.
• Taux d'échec des changements : la part des déploiements qui provoquent un incident ou un retour arrière.
• Part de toil : la fraction du temps d'un ingénieur passée sur du travail manuel et répétitif.

Erreurs courantes

• Viser 100 %. Le livre SRE affirme que 100 % n'est probablement jamais le bon objectif de fiabilité : les utilisateurs ne voient pas la différence et le coût grimpe fortement.
• Trop d'indicateurs. Une poignée d'indicateurs représentatifs suffit pour juger de la santé d'un système.
• Juger sur les moyennes. Une bonne moyenne peut cacher une queue lente que les vrais utilisateurs ressentent.
• Un budget d'erreurs que personne n'applique. Il ne fonctionne que si son épuisement change ce que fait l'équipe.
• Des SLO jamais revus. Confrontez-les au comportement réel des utilisateurs et aux plans produit.
• Des post-mortems sans suite. Confiez chaque action à un responsable et suivez-la jusqu'au bout.
• Ne jamais tester sous charge. Un SLO de latence que vous n'avez vu qu'aux heures creuses n'est qu'une supposition.

La place des tests de charge et de la surveillance

On ne peut pas défendre un SLO de latence sans preuve que le système tient sous une concurrence réaliste. Les tests de charge avant les lancements et après les gros changements apportent cette preuve. Avec les tests de charge LoadFocus, vous pouvez fixer des seuils de réussite ou d'échec sur le temps de réponse P95 et P99, le taux d'erreurs et le débit, si bien que chaque exécution reçoit un verdict, et une GitHub Action peut bloquer un déploiement quand un seuil est dépassé. Votre SLO devient ainsi une barrière avant la mise en production.

En production, la surveillance d'API vérifie vos endpoints selon un calendrier depuis plusieurs régions et vous alerte quand les assertions échouent. La surveillance d'API de LoadFocus propose une offre gratuite avec des contrôles toutes les 5 minutes. Les pages de statut peuvent afficher la disponibilité calculée à partir de ces contrôles et publier les incidents. Les métriques, logs et traces relèvent de l'observabilité, et notre guide des bonnes pratiques de surveillance (en anglais) décrit les habitudes qui les entourent.

Questions fréquentes

Quelle différence entre ingénierie de la fiabilité et SRE ?

L'ingénierie de la fiabilité est la discipline qui fait atteindre à un système des objectifs de fiabilité mesurables. Le SRE en est une manière précise, née chez Google, où des ingénieurs logiciel exploitent la production avec des SLO, des budgets d'erreurs et un plafond sur le travail d'exploitation.

Qu'est-ce qu'un budget d'erreurs ?

C'est un moins l'objectif de disponibilité. Avec un objectif de 99,99 %, le budget est de 0,01 %. Les équipes le dépensent en livraisons et expériences, et ralentissent ou arrêtent les changements risqués quand il est épuisé.

Quelle différence entre un SLO et un SLA ?

Un SLO est un objectif interne pour un niveau de service mesuré par un SLI. Un SLA est un contrat avec les utilisateurs qui prévoit des conséquences si les objectifs ne sont pas atteints. Sans conséquence explicite, il s'agit probablement d'un SLO.

100 % de disponibilité est-il un bon objectif ?

En général non. Le livre SRE soutient que 100 % n'est probablement jamais le bon objectif, car les utilisateurs remarquent rarement la différence et chaque « neuf » supplémentaire coûte plus cher. Choisissez un objectif adapté aux besoins des utilisateurs et à ce que vous pouvez financer.

Comment démarrer ?

Choisissez un parcours critique pour l'utilisateur, définissez-lui un SLI, fixez un SLO souple et mesurez-le à partir des données de production. Calculez le budget d'erreurs, convenez de ce qui se passe quand il est épuisé et menez un post-mortem sans blâme après chaque incident significatif.