Améliorer la fiabilité commence par définir le résultat que le service doit rendre à ses utilisateurs. Un tableau de serveurs disponibles ne suffit pas si une opération critique échoue. SRE propose notamment de relier les objectifs de service aux décisions de changement et aux travaux de réduction du risque.
Définir un service observable
Commencer par un parcours : soumettre une demande, consulter un document ou exécuter un traitement. Identifier ce qui compte pour ce parcours : réussite, délai, fraîcheur ou intégrité du résultat. Le signal choisi doit se rapprocher de l’expérience réellement attendue.
La documentation Google SRE sur les objectifs de service distingue SLI, SLO et SLA. Le SLI mesure ; le SLO fixe une cible ; le SLA formalise un engagement dont les conséquences dépendent de l’accord concerné. Employer ces termes comme synonymes brouille les décisions.
Un indicateur doit définir précisément ses événements éligibles. Exclure les erreurs difficiles à mesurer peut améliorer le chiffre sans améliorer le service. Les exclusions doivent être justifiées, visibles et réexaminées.
Choisir un objectif qui aide à décider
Un objectif de 100 % paraît simple, mais ne laisse aucune place explicite au risque. Le chapitre Google SRE sur l’acceptation du risque examine l’arbitrage entre fiabilité et autres objectifs du service. La cible doit se discuter avec les attentes et les conséquences d’un échec.
Exemple pédagogique : sur un million d’opérations éligibles, un SLO de réussite de 99,9 % autorise mathématiquement 1 000 échecs sur la fenêtre retenue. Ce calcul illustre un budget d’erreur fondé sur les événements. Il ne signifie ni que 1 000 erreurs sont souhaitables, ni qu’une erreur critique est acceptable.
Les pourcentages agrégés peuvent masquer un incident touchant un petit groupe d’utilisateurs ou une fonction essentielle. Compléter l’objectif global par les segments et les contraintes réellement critiques.
Faire du budget d’erreur une politique
Un budget d’erreur sans règle d’action devient un graphique supplémentaire. Il faut définir ce qui change lorsqu’il est consommé trop vite : réduire certaines mises en production, traiter une fragilité, revoir une dépendance ou renforcer un contrôle.
La mise en œuvre des SLO décrit ce lien entre objectif et décision. Dans une proposition de gouvernance, la politique indique les signaux, la fenêtre, les exceptions possibles et l’autorité qui les approuve.
La suspension de changements peut elle-même prolonger un risque si une correction est urgente. Distinguer les évolutions ordinaires, les actions de restauration et les modifications nécessaires à la sécurité évite une règle appliquée mécaniquement.
Mesurer pour diagnostiquer, alerter pour agir
La télémétrie sert à comprendre ; une alerte doit déclencher une action utile. Une hausse de CPU peut expliquer une saturation sans constituer, isolément, une raison de réveiller une personne. À l’inverse, une dégradation du parcours utilisateur mérite une investigation même si les machines paraissent disponibles.
| Signal | Usage proposé | Question associée |
|---|---|---|
| Résultat du parcours | Évaluer le service | L’utilisateur obtient-il ce qu’il attend ? |
| Latence | Détecter une dégradation | La réponse arrive-t-elle dans un délai utile ? |
| Dépendances | Localiser un problème | Quel composant limite le parcours ? |
| Saturation | Anticiper une limite | Dispose-t-on d’une marge exploitable ? |
Une alerte devrait indiquer le symptôme, son périmètre, la première vérification et le responsable. Si personne ne sait quoi faire du signal, il faut revoir le signal ou la procédure.
Chercher les défaillances communes
Ajouter une deuxième instance ne protège pas d’une dépendance commune : même identité, même réseau, même erreur de configuration ou même échéance de certificat. La résilience se juge par les modes de défaillance, pas uniquement par le nombre de composants.
Une revue de fiabilité peut parcourir les dépendances du service et demander : que se passe-t-il si ce composant ralentit, renvoie une réponse incohérente ou devient indisponible ? Quelles limites empêchent la propagation ? Quelle observation permet de reconnaître la situation ?
Les réponses doivent être testées sur un périmètre autorisé et maîtrisé. Un exercice de défaillance sans condition d’arrêt peut créer un risque supérieur au bénéfice attendu.
Transformer l’incident en travaux précis
Une analyse utile décrit les conditions qui ont permis l’incident, les signaux disponibles et les points où une intervention aurait changé son déroulement. Elle doit déboucher sur des actions attribuées, pas sur « être plus vigilant ».
Une action efficace peut réduire la probabilité de l’erreur, sa portée ou le délai de diagnostic. Ces bénéfices sont différents. Les prioriser demande d’examiner le risque, le coût et les dépendances plutôt que de multiplier les tâches après chaque incident.
Démarrer avec une boucle courte
Choisir un parcours, une mesure compréhensible et un objectif discuté. Observer une fenêtre suffisante pour comprendre les variations. Associer ensuite une politique et un petit nombre de travaux de fiabilité. Réviser l’ensemble lorsque le service ou ses utilisateurs changent.
La comparaison DevOps, SRE et IT Production clarifie les rôles. Piloter un projet d’infrastructure critique relie ces exigences au passage en production. Le dossier Infrastructure & Reliability rassemble ces perspectives.