Le problème apparaît quand une application interne annonce 99,9 % de disponibilité alors que la clôture mensuelle a encore terminé après l’ouverture. Le serveur répond, mais les équipes compensent par des exports, des reprises manuelles et des appels au support. Le chiffre est précis ; la promesse ne correspond à aucun travail réel.
Le vrai enjeu est de choisir un petit nombre de mesures qui permettent au métier et à la technique d’arbitrer ensemble. Un SLI observe une expérience, un SLO fixe une cible interne et un SLA formalise un engagement avec ses conséquences. Les trois ne sont ni interchangeables ni tous obligatoires.
Contre-intuitivement, une application réservée aux salariés peut exiger un objectif plus fin qu’un site public. Son indisponibilité peut bloquer paie, logistique ou soin sur une fenêtre courte. En revanche, promettre la même disponibilité toute la nuit peut financer une astreinte sans valeur.
Dans une application interne développée sur mesure, la fiabilité suit parcours, calendrier et reprise. Ce guide définit événements valides, faibles volumes, dépendances et budget d’erreur, puis prépare des objectifs mesurables sans transformer le SLO en contrat juridique par accident.
Distinguer indicateur, objectif et engagement
Le SLI décrit une proportion ou une distribution
Le service level indicator mesure des événements valides sur des événements éligibles, une durée, une fraîcheur ou un autre résultat. Il possède source, calcul, fenêtre et exclusions. « Disponibilité » sans requête éligible ni succès défini reste une étiquette.
Le service level objective fixe une cible sur ce SLI pour une période. Il guide priorisation et réaction. Le service level agreement ajoute une promesse entre parties, un mode de preuve et des conséquences. Un document interne peut convenir sans devenir SLA.
Ne pas appeler contrat une ambition
Un SLA nécessite validation des responsables concernés. L’équipe technique ne crée pas seule un engagement opposable en ajoutant un panneau. Elle peut proposer SLI et SLO, puis laisser juridique, achats ou direction définir l’accord si nécessaire.
Partir du travail que les équipes doivent finir
La carte retient trois à cinq parcours : préparer un colis, clôturer une période, accéder à un dossier, valider une paie. Pour chacun, elle note utilisateurs, horaires, résultat, délai, modes dégradés et coût de récupération.
La page d’accueil disponible ne prouve pas que le travail avance. Le SLI peut suivre proportion de dossiers terminés dans vingt minutes, exports prêts avant 7 h 30 ou recherches renvoyant un résultat autorisé. Le choix garde une conséquence compréhensible.
Qualifier la population
Un parcours peut concerner cinquante utilisateurs dont cinq critiques. Les cohortes sont explicites sans exposer les personnes. Site, rôle, fuseau ou type de dossier peuvent séparer des promesses différentes si leur volume permet une mesure honnête.
Construire un SLI sur des événements valides
Le numérateur compte les événements qui respectent la promesse ; le dénominateur contient tous les événements éligibles. Les annulations utilisateur, doublons et erreurs de validation sont classés selon la promesse. Les retirer silencieusement améliore le score sans améliorer le service.
La source la plus proche de l’expérience est préférée : statut métier durable, mesure synthétique ou observation côté utilisateur. Une métrique interne du serveur peut compléter mais pas remplacer. Le calcul est versionné et les changements de définition annotés.
Distinguer inconnu et mauvais
Si la collecte est absente, le résultat devient inconnu, pas bon. La politique décide comment l’inconnu affecte l’objectif. Une longue panne de télémétrie doit empêcher une conclusion positive et ouvrir son propre incident.
Mesurer la latence selon le résultat
La latence des succès et des erreurs est séparée. Une erreur rapide ne tient pas la promesse. Une distribution ou une proportion sous un seuil observe les queues mieux qu’une moyenne. Sur faible volume, les cas individuels et la durée maximale sont plus lisibles.
Le seuil vient de l’usage. Deux secondes pour une recherche interactive peuvent être raisonnables localement ; vingt minutes pour un export peut convenir si le métier le reçoit avant son besoin. Ces nombres sont négociés et testés, jamais copiés d’un benchmark général.
Choisir le point de départ
Pour un traitement asynchrone, la durée commence à l’acceptation métier, pas à la prise du worker. Elle inclut attente de file. Pour un batch planifié, elle peut mesurer écart entre heure due et résultat disponible.
Couvrir batch, fraîcheur et files
Les applications internes vivent de jobs et synchronisations. Un SLI de fraîcheur mesure âge de la donnée ; un SLI de complétude mesure part des dossiers traités ; un SLI de ponctualité vérifie une échéance. Le process sorti avec code zéro n’est qu’un signal technique.
Une file suit âge du plus ancien, proportion finie dans la fenêtre et erreurs définitives. La profondeur seule ne dit pas si la promesse est tenue. Les reprises sont incluses : un dossier réparé après action manuelle peut être bon ou mauvais selon l’objectif défini.
Tracer le résultat inconnu
Après timeout externe, le dossier n’est ni succès ni erreur certaine. Une catégorie inconnu déclenche rapprochement. La masquer derrière retry peut doubler un effet et fausser le SLI.
Définir les fenêtres réellement utiles
Une application peut avoir des heures ouvrées, une clôture mensuelle et un batch nocturne. Chaque promesse indique fuseau, jours, exceptions planifiées et traitement des périodes de maintenance. Exclure une maintenance après coup est interdit.
Hors fenêtre, une panne peut rester importante si elle compromet le prochain démarrage. L’objectif de préparation vérifie que données et dépendances sont prêtes avant ouverture. Le mode dégradé possède aussi un niveau de service.
Prévoir les calendriers irréguliers
Jours fériés, fin de mois et campagne saisonnière modifient volume et criticité. Le calendrier est versionné avec le produit. Un objectif mensuel peut masquer une heure critique ; une fenêtre glissante ou un objectif par échéance complète la vue.
Fixer une cible avec le métier
La cible compare tolérance utilisateur, modes dégradés, coût d’amélioration et performance actuelle. Une baseline saine fournit un point de départ, mais ne devient pas la promesse. Le métier choisit ce qui est acceptable ; la technique explique coût et incertitude.
Le guide Google SRE Workbook sur la mise en œuvre des SLO part de parcours et événements valides. Le projet adapte l’approche à son contexte. Il ne prétend pas qu’un objectif précis garantit seul la satisfaction.
Garder une marge de décision
100 % laisse aucune marge pour maintenance et découverte. Une cible trop basse normalise l’échec. Le bon niveau permet d’arbitrer : si la perte dépasse la tolérance, l’équipe réduit le risque avant de poursuivre les changements non urgents.
Utiliser le budget d’erreur pour arbitrer
Le budget représente l’écart toléré sur la fenêtre. Il n’autorise pas à provoquer des erreurs ; il rend comparable la fiabilité consommée. Le tableau montre rythme de consommation, événements contributifs et cohorte.
La politique précise actions à plusieurs niveaux : surveillance, revue, limitation des changements risqués ou travail de fiabilité. Elle reste adaptée à l’équipe. Un budget épuisé par une seule panne critique appelle une analyse différente d’une série de petites lenteurs.
Ne pas punir l’équipe produit
La décision concerne risque, pas une opposition feature/ops. Fiabilisation peut inclure meilleure instrumentation, réduction du périmètre ou simplification. Le budget ne remplace pas la priorité d’un incident de sécurité ou de conformité.
Réserver le SLA aux engagements nécessaires
Un SLA interne peut clarifier horaires, support, reprise et responsabilités entre une plateforme et ses utilisateurs. Il est utile lorsque capacité, budget ou dépendance organisationnelle exigent un engagement formel. Sinon, un SLO et un catalogue de service suffisent souvent.
Le SLA définit mesure, exclusions préalables, escalade et conséquences. Il évite des formulations impossibles à vérifier. La cible SLA peut être moins ambitieuse que le SLO afin que l’équipe détecte et corrige avant la rupture contractuelle.
Aligner les dépendances
Promettre mieux que le fournisseur peut être possible grâce au cache ou au mode dégradé, mais cette architecture doit être prouvée. Sinon l’accord explicite la dépendance et la récupération, sans transférer une promesse irréaliste à l’exploitation.
Traiter honnêtement les faibles volumes
Sur dix événements, un échec fait varier le taux de dix points. Un percentile n’est pas stable. Le dashboard montre compte, cas et durée plutôt qu’une précision trompeuse. Une fenêtre plus longue peut aider si la promesse le permet.
Un événement rare mais critique peut être suivi par objectif binaire par échéance : clôture prête ou non, restauration exercée ou non. Le SLO ne doit pas diluer cet événement dans des millions de consultations sans risque.
Une équipe peut compléter le résultat par une série de contrôles préalables : données reçues, capacité disponible, dépendance joignable et procédure de secours exercée. Ces contrôles ne remplacent pas l’issue métier, mais ils rendent l’échec rare moins surprenant. La revue présente chaque cas, sa cause probable et la confiance du diagnostic au lieu d’extrapoler une tendance sur deux occurrences.
Qualifier les dépendances hors contrôle
Le SLI utilisateur inclut l’échec du partenaire si le travail échoue. Une seconde vue attribue la cause technique. Exclure toutes les dépendances produirait un score vert pendant une interruption réelle.
Le contrat suit quotas, latence, erreurs et mode dégradé. Le producteur peut limiter la demande ou mettre en file. La récupération après retour est mesurée : un partenaire disponible n’a pas restauré le service tant que le backlog reste vieux.
Conserver la causalité prudente
Une corrélation entre perte de SLI et fournisseur renforce l’hypothèse. Les traces, réponses et expériences bornées confirment. Le rapport distingue dépendance contributive et cause interne de reprise lente.
Cas concret : clôture comptable interne
Cas concret hypothétique. Une application annonce 99,9 % d’uptime. Le batch de clôture finit pourtant deux fois après 8 h. L’équipe définit un SLI : clôtures éligibles dont fichiers et écritures sont disponibles avant 7 h 30, avec exactitude validée.
Le SLO pilote exige toutes les clôtures mensuelles réussies sur six mois et une alerte de marge à 6 h 30. Ce choix binaire vient du faible volume ; il ne prétend pas fournir une probabilité fine. Un second SLI suit âge du backlog pendant l’exécution.
Lors d’un incident, un import concurrent sature la base. Le runbook suspend l’import, termine la clôture puis rapproche les écritures. L’objectif est manqué même si la reprise finit à 8 h 10. La prévention sépare les ressources et teste le calendrier de fin de mois.
Pour qui formaliser ces objectifs
Produit interne, métier, exploitation et plateforme définissent ensemble. La direction arbitre le coût d’une promesse ; la sécurité garde ses exigences propres. Un utilisateur pilote valide que le SLI représente vraiment son travail.
Une petite application peut commencer avec deux parcours et une revue mensuelle. Une plateforme critique ajoute budget, astreinte et SLA. Le niveau de formalisation suit impact et coordination, pas une mode SRE.
Éviter les erreurs fréquentes de SLO
Copier 99,9 %
La cible ne dit rien sans fenêtre, parcours et coût. Elle est négociée depuis le travail et la récupération. Une précision excessive peut être trompeuse sur faible volume.
Mesurer le serveur plutôt que le résultat
Le healthcheck vert ne prouve pas la clôture ou la fraîcheur. Un SLI métier durable est associé aux signaux techniques de diagnostic.
Exclure les périodes gênantes après coup
Maintenance et événements éligibles sont définis avant la fenêtre. Une instrumentation en panne produit inconnu. La définition versionnée préserve la comparaison.
Arbitrer fiabilité, delivery et mode dégradé
Si le budget se consume rapidement, alors les changements qui augmentent le risque sont limités. En revanche, une correction ou une simplification peut continuer. Dans ce cas, l’arbitrage examine contribution probable, capacité de repli et urgence métier.
Un mode dégradé peut tenir la promesse essentielle avec saisie différée, lecture seule ou traitement manuel. Son coût humain et sa capacité sont mesurés. Il ne devient pas une excuse permanente pour un parcours cassé.
- D’abord, qualifier l’événement mauvais et la population éligible.
- Ensuite, comparer consommation, cause et capacité de reprise.
- Puis, choisir fiabilisation, limitation ou mode dégradé.
- Enfin, reprendre le delivery lorsque cible et marge redeviennent comprises.
Fermer le contrat de mesure
Les entrées sont événements versionnés, calendrier et population. Les sorties sont SLI, cible, budget et verdict. Les responsabilités séparent définition métier, collecte, action et engagement. La journalisation relie les cas ; le monitoring contrôle fraîcheur.
Les dépendances, exclusions, seuils et rétentions sont explicites. Le rollback restaure la requête précédente. Le runbook couvre données inconnues, violation et reprise. Un test synthétique vérifie le calcul sans fabriquer un résultat métier.
Versionner la fiche de chaque indicateur
La fiche nomme le responsable métier, le propriétaire technique, la source, la requête, la fréquence de calcul, le fuseau et la date d’effet. Elle donne des exemples classés bon, mauvais, exclu et inconnu. Une modification de filtre ou d’événement crée une version et une annotation ; elle ne réécrit pas silencieusement l’historique.
Le tableau affiche numérateur et dénominateur avec le pourcentage. Cette transparence évite qu’un taux sur onze opérations soit lu comme une statistique stable. La requête peut être rejouée sur une fenêtre de recette connue, et son coût est surveillé pour que le calcul du SLI ne charge pas le service qu’il observe.
Les droits suivent la sensibilité des attributs. Un rapport de direction peut agréger par site tandis que l’équipe autorisée ouvre les événements individuels pour diagnostiquer. La rétention répond au besoin de comparaison et aux règles de données, pas au désir de tout conserver. Une suppression est testée comme une fonction du pipeline.
Une recette injecte erreur, lenteur, collecte coupée et backlog. Le tableau doit classer chacun correctement. Une personne non auteure explique l’impact et applique la politique sans recalcul manuel.
Plan d’action sur six semaines
Semaines 1 et 2 : choisir les promesses
L’équipe interroge utilisateurs, incidents et modes dégradés. Elle sélectionne trois parcours, écrit bon/mauvais/inconnu, horaires et dépendances. Une baseline sur les données existantes révèle trous et faibles volumes sans devenir la cible.
Chaque parcours reçoit un exemple réel anonymisé et une conséquence chiffrée localement : minutes opérateur, retard d’ouverture ou dossiers à reprendre. Le groupe confronte ces coûts aux périodes creuses. Il écarte tout indicateur dont personne ne saurait modifier une décision après un écart.
Semaines 3 et 4 : instrumenter et négocier
Les événements métier sont ajoutés, la collecte et les calculs versionnés. Produit et métier testent les cas limites. Chaque cible reçoit une justification, une politique et un runbook. Les coûts et engagements éventuels sont revus par les responsables compétents.
Le tableau pilote montre compte, inconnus et consommation avant d’afficher une couleur. Une revue hebdomadaire confronte résultat et tickets, sans déplacer les exclusions après lecture. Si la baseline manque de volume, alors l’équipe garde les cas unitaires et reporte toute cible statistique trop précise.
Semaines 5 et 6 : exercer la politique
Le pilote provoque panne, backlog, faible volume et collecte absente. L’équipe observe budget et prend une décision réelle. Elle joue mode dégradé et reprise. Les faux signaux et exclusions ambiguës sont corrigés.
Une seconde équipe rejoue le calcul et suit la procédure avec les seuls documents publiés. Elle chronomètre détection, qualification et retour au service attendu. Les écarts deviennent des tâches propriétaires et datées. La cible n’entre en gouvernance que lorsque cette répétition produit le même classement.
La revue finale vérifie que les utilisateurs comprennent la promesse et que l’exploitation sait agir. Elle retire les SLI décoratifs, documente les limites statistiques et choisit un nouveau parcours uniquement si les trois premiers guident déjà une décision.
Relier SLO, workflow et support
L’observabilité des workflows fournit les événements valides, et les tests d’exceptions vérifient mauvais et inconnu.
Le monitoring de performance explique la dérive. Une migration Symfony compatible préserve la mesure pendant deux versions.
- Définir événement, population, calendrier et source.
- Négocier cible, mode dégradé et politique de budget.
- Exercer données inconnues, violation et récupération.
Conclusion : promettre ce qui aide à décider
Un SLI pertinent mesure le travail réellement accompli. Un SLO rend une tolérance explicite. Un SLA formalise seulement les engagements qui ont besoin de conséquences et de gouvernance.
Pour une application interne, horaires, batch, faible volume et mode dégradé comptent autant que la disponibilité HTTP. La définition doit survivre à un incident et rester compréhensible par l’utilisateur.
Le bon objectif ouvre un arbitrage avant la crise. Il ne garantit pas la qualité par un chiffre ; il relie fiabilité, coût et reprise sur une fenêtre connue.
Dawap peut cadrer et instrumenter ces objectifs dans une mission de développement web métier, avec un accompagnement expert jusqu’à la politique de run et son exercice.
