Principes SRE : Les 7 règles fondamentales

Les sept principes SRE viennent d’une entreprise qui possède ses centres de données, son réseau, ses équilibreurs de charge et chaque ligne de code entre les deux. Votre pile ne ressemble probablement pas à ça. Une bonne partie de ce que vos utilisateurs expérimentent tourne sur une infrastructure dans laquelle vous ne pouvez pas SSH : un CDN, un fournisseur d’authentification, une passerelle de paiement, DNS, un gestionnaire de tags, une API partenaire.

Cet écart est important, car les principes s’appliquent toujours en dehors de Google. Mais plusieurs d’entre eux changent de forme dès lors que le composant en panne n’est pas le vôtre à réparer. Un budget d’erreur se comporte différemment lorsqu’un tiers de ce budget est consommé par une panne d’un autre. Les quatre signaux d’or sont différents vus de l’extérieur du pare-feu par rapport à l’intérieur. Et le risque que vous ne pouvez pas éliminer par l’ingénierie, vous devez le mesurer.

Cet article passe en revue les sept principes tels que définis dans le livre SRE de Google, puis ajoute ce que le livre oublie : à quoi ressemble chaque principe quand vous dépendez de services que vous ne contrôlez pas. Si vous êtes novice dans ce rôle, commencez par ce que fait un ingénieur fiabilité site et revenez ensuite.

Quels sont les principes SRE ?

Les principes SRE sont les règles de travail que Google a codifiées pour faire fonctionner des systèmes fiables à grande échelle : adopter et gérer le risque, les objectifs de niveau de service, éliminer le travail fastidieux, le monitoring, l’automatisation, l’ingénierie des mises en production, et la simplicité. Ensemble, ils répondent à une question : à quel niveau de fiabilité ce service doit-il fonctionner, et quelle est la manière la moins coûteuse et durable d’y parvenir ?

La liste n’a pas changé depuis la publication du livre SRE en 2016. Ce qui a changé, c’est la pile moyenne. Microservices, dépendances SaaS, et scripts tiers signifient qu’une partie de votre fiabilité est maintenant dans les mains d’autres entreprises. Chaque section ci-dessous couvre le principe tel qu’écrit, puis ce qui foire quand la dépendance n’est pas la vôtre. En fin, une liste courte des meilleures pratiques SRE tirées des sept.

Principe 1 – Adopter et gérer le risque

La formulation Google : viser une fiabilité à 100 % est une erreur. Les utilisateurs vous atteignent par des réseaux et appareils qui tombent en panne naturellement, donc au-delà d’un certain point, obtenir plus de “neuf” coûte cher et personne ne voit la différence. Choisissez un objectif de fiabilité défendable par l’entreprise, et traitez l’écart entre cet objectif et la perfection comme un budget à dépenser pour livrer des fonctionnalités. Le chapitre Adopter le risque explique cela en détail.

Chez Google, cela fonctionne car le risque est un bouton qu’ils peuvent tourner. Plus de réplications, plus de redondance, déploiements plus lents : dépensez de l’argent, obtenez plus de “neuf”.

En dehors de Google, une partie de ce bouton n’est reliée à rien. Vous ne pouvez pas ajouter une réplique à votre passerelle de paiement. Vous ne pouvez pas régler le comportement de basculement de votre fournisseur DNS. Leur fiabilité est une clause contractuelle, pas un paramètre d’ingénierie.

Le principe change donc de forme : pour les composants que vous possédez, gérez le risque par l’ingénierie. Pour ceux que vous ne possédez pas, gérez-le par la mesure. Vous devez connaître la disponibilité réelle de votre fournisseur d’authentification telle que mesurée depuis le côté internet de vos utilisateurs, pas le chiffre de leur page de statut. Les pages de statut affichent souvent du vert lors de pannes partielles, et une dépendance qui fonctionne dans son propre centre de données peut être injoignable depuis le vôtre. La mesure indépendante transforme un soupçon de “le CDN est instable” en une discussion de renouvellement appuyée par des données. C’est le premier travail que fait Dotcom-Monitor ici : mettre une vérification externe sur chaque dépendance critique. Une vérification DNS vers les serveurs de noms du fournisseur, une vérification HTTP(S) en bout de CDN, une vérification API vers la passerelle de paiement. Chacune construit son propre historique de disponibilité et temps de réponse depuis un réseau mondial. Et là où les chiffres le justifient, contournez le risque : un second fournisseur DNS, un chemin de paiement de repli, une copie mise en cache du script tiers.

Comment mettre en œuvre la gestion du risque

• Listez chaque dépendance touchée par une requête utilisateur (DNS, CDN, auth, paiements, tags tiers) et indiquez celles que vous pouvez ingénier et celles que vous ne pouvez qu’évaluer par la mesure.
• Créez un dispositif Dotcom-Monitor pour chaque dépendance mesurable seulement : une tâche DNS pointant vers les serveurs de noms du fournisseur, une tâche HTTP(S) en bordure CDN, une tâche web services contre le point de terminaison paiement ou authentification.
• Exécutez ces vérifications de plusieurs emplacements dans les régions de vos utilisateurs, pour qu’une panne régionale chez le fournisseur ne puisse masquer une autre région en bonne santé.
• Apportez chaque rapport de disponibilité dans la discussion avec le fournisseur, et ajoutez des chemins de repli (DNS secondaire, voie de paiement de secours) là où les données montrent que le risque justifie le coût.

Principe 2 – Objectifs de niveau de service (SLA, SLO, SLI)

Trois termes sont souvent confondus, voici la distinction :

• SLA (Service Level Agreement / Accord de niveau de service) : le contrat. Ce que vous promettez aux clients, avec des pénalités en cas de manquement.
• SLO (Service Level Objective / Objectif de niveau de service) : la cible fixée pour un indicateur de niveau de service, souvent interne et plus stricte que le SLA pour déclencher vos alertes avant de violer le contrat. Par exemple, 99,9 % de disponibilité, finaliser un achat en moins de 3 secondes, ce genre d’objectif.
• SLI (Service Level Indicator / Indicateur de niveau de service) : la mesure en elle-même. Le chiffre réel de disponibilité, le temps de réponse observé, le taux d’erreur mesuré.

Le SLI mesure, le SLO cible, le SLA promet. Tout ce qui découle, y compris les rapports de disponibilité et SLA remis au client, dépend de la fiabilité du SLI.

C’est là que la plupart des équipes ont un angle mort : le budget d’erreur n’est précis qu’au niveau de la mesure qui le soutient. Si vos vérifications tournent toutes les 5 minutes, chaque panne enregistrée a un début et une fin connus seulement à +/- 5 minutes, et les pannes plus courtes que cet intervalle peuvent se terminer sans jamais être vues. Voici ce que cela donne pour un budget d’erreur mensuel à travers différents objectifs SLO, sur un mois de 30 jours (43 200 minutes) :

Vous ne pouvez pas mesurer un SLO mensuel à 99,99 % avec des vérifications toutes les 5 minutes. Une seule intervalle de vérification dépasse tout votre budget mensuel.

Les probabilités sont aussi impitoyables. Avec un intervalle de vérification de I minutes, une panne aléatoire durant D minutes (où D est plus courte que I) est détectée avec une probabilité approximative de D/I, en supposant que le début de panne est indépendant du planning des vérifications. Donc une panne de 4 minutes contre un intervalle de 5 minutes est détectée environ 4 fois sur 5, et le 1 sur 5 restant correspond à une panne qui tombe entièrement entre deux vérifications et n’est jamais enregistrée. Pour les pannes plus longues que l’intervalle, le délai moyen de détection est d’environ la moitié de l’intervalle, donc 5 minutes d’intervalle ajoutent en moyenne 2,5 minutes avant que quelqu’un ne sache.

Un avertissement : ce tableau suppose une seule vérification planifiée et une comptabilisation du temps d’arrêt basée sur l’intervalle. La confirmation multi-locale et les SLI basés sur les requêtes changent les détails, mais pas le problème d’échantillonnage.

Les pannes courtes ne sont pas un cas marginal non plus. Parmi les pannes détectées par Dotcom-Monitor, environ 38 % se résolvent en moins de 5 minutes. Ce sont principalement des fluctuations de routage réseau, des redémarrages, relances, et basculements qui se corrigent avant qu’une intervention humaine soit possible, et notre filtre de réponse retarde l’alerte pour cette raison exacte. Mais être filtré des alertes ne signifie pas être filtré de l’enregistrement : ce temps d’arrêt compte toujours contre le SLA, quel qu’il soit, et doit être comptabilisé. Parmi les pannes qui génèrent une alerte, plus de 56 % se résolvent dans les 15 minutes suivant la première notification, environ 18 % dépassent l’heure, et environ 3 % s’étalent au-delà de 24 heures. La proportion varie légèrement selon les types de services, mais la forme reste : plus d’un tiers des pannes se situent dans la tranche que les vérifications 5 minutes voient à peine. C’est pour cela que la fréquence de vérification est une décision de mesure, pas simplement financier : à des intervalles de 1 minute, la quantique de mesure tombe à 2,3 % d’un budget mensuel à 99,9 % au lieu de 11,6 %, et les pannes courtes qui dominent les comptes d’incidents commencent à apparaître dans vos registres. C’est pourquoi Dotcom-Monitor exécute des vérifications parfois toutes les minutes et construit ses rapports SLA sur ces mêmes données : le chiffre de conformité que vous montrez à un client n’est fiable que dans la mesure où l’échantillonnage derrière l’est.

Comment mettre en œuvre les objectifs de niveau de service

• Définissez deux ou trois SLI que vos utilisateurs reconnaîtraient, comme la disponibilité mesurée depuis un vrai navigateur ou le temps de finalisation d’achat, et faites d’une vérification Dotcom-Monitor la source officielle pour chacun.
• Fixez chaque SLO plus strict que le SLA qu’il protège, puis ajustez la fréquence de vérification de l’appareil en conséquence : selon le tableau ci-dessus, tout au-delà de 99,9 % nécessite des vérifications à 1 minute.
• Programmez les rapports de disponibilité et SLA vers les personnes responsables de la conversation SLA, pour que le chiffre de conformité provienne du même registre que les alertes.
• Convenir en amont de ce qui se passe lorsque le budget d’erreur est épuisé, pendant qu’aucun incident précis n’est en débat.

Principe 3 – Éliminer le travail répétitif (toil)

Le travail répétitif est tout travail manuel, répétitif, qui croît avec la taille du service et ne produit aucune valeur durable. Le chapitre Éliminer le travail répétitif fixe une limite célèbre : les SRE ne devraient pas y passer plus de la moitié de leur temps, le reste étant consacré à des travaux d’ingénierie qui font disparaître ce travail répétitif.

Les définitions abstraites rendent le travail répétitif facile à reconnaître mais difficile à identifier précisément. Alors nommez-le. Dans la plupart des équipes, il ressemble à ça :

• Quelqu’un se connecte chaque matin pour vérifier que le parcours d’achat fonctionne toujours.
• Quelqu’un teste manuellement le formulaire d’inscription après chaque déploiement.
• Quelqu’un garde un rappel de calendrier pour les dates d’expiration des certificats SSL.
• Quelqu’un teste manuellement une API partenaire quand les tickets support explosent, pour vérifier si le problème est chez vous ou chez eux.

Chacun d’eux est une transaction scriptée en attente d’être écrite, et c’est là que Dotcom-Monitor montre sa valeur directe. Un script enregistré avec EveryStep, son enregistreur de transactions en point-clic, suit régulièrement ce parcours d’achat depuis un vrai navigateur et déclenche une alerte dès qu’une étape échoue. Ses vérifications de certificats scrutent les dates d’expiration sans calendrier. Ses vérifications API appellent régulièrement le point de terminaison partenaire et conservent l’historique des temps de réponse qui tranche d’un coup d’œil l’argument “c’est nous ou eux”.

Le critère de ce qu’on automatise en premier n’est pas la sophistication, mais la récurrence. La vérification qu’un humain fait tous les jours est celle que la machine doit faire toutes les minutes.

Comment mettre en œuvre l’élimination du travail répétitif

• Gardez une trace hebdomadaire de toutes les vérifications manuelles sur l’équipe ; c’est la récurrence, pas la difficulté, qui décide ce qu’on automatise en premier.
• Enregistrez la plus fréquente comme script EveryStep en parcourant le flux une fois, puis laissez-la tourner toutes les quelques minutes au lieu d’une fois par jour.
• Remplacez le calendrier d’expiration des certificats par les vérifications SSL Dotcom-Monitor, et placez les API partenaires sous surveillance programmée pour qu’aucune ne dépende de la mémoire d’une personne.
• Suivez le nombre d’heures de vérification manuelle éliminées chaque trimestre, afin que le travail d’automatisation reste visible et financé.

Principe 4 – Monitoring et les quatre signaux d’or

Le chapitre sur le Monitoring des systèmes distribués nomme quatre signaux d’or : latence, trafic, erreurs, saturation. Surveillez-les et vous attraperez la plupart des problèmes.

Le chapitre mentionne le monitoring “black-box” (boîte noire), mais la plupart des équipes instrumentent les quatre signaux depuis l’intérieur du système. Surveillez-les depuis l’endroit où se trouvent vos utilisateurs, et trois des quatre changent :

Lisez honnêtement le tableau et la conclusion n’est pas que l’extérieur est meilleur. C’est que ni l’un ni l’autre ne voient tout. Le trafic et la saturation appartiennent à vos outils internes : Prometheus, Datadog, New Relic, quelle que soit votre pile APM. La latence telle que vécue et les erreurs telles que vécues appartiennent au monitoring synthétique externe. C’est la moitié couverte par Dotcom-Monitor. Les vérifications en vrai navigateur depuis un réseau global chargent vos pages comme le font les utilisateurs et mesurent tout le chemin : résolution DNS, poignée de main TLS, bord CDN, rendu de page, étapes utilisateur scriptées. Les vérifications protocolaires HTTP(S), API, DNS, TCP, et ICMP surveillent les dépendances autour de la page. Les deux ne s’opposent pas ; ce sont des vues différentes des mêmes quatre signaux, et vous avez besoin des deux.

La règle pratique : chaque signal que vos utilisateurs peuvent ressentir doit avoir au moins une mesure prise depuis là où ils sont. Un tableau de bord APM affichant du vert pendant que le CDN sert des pages d’erreur en cache à la moitié de l’Europe n’est pas une hypothèse. C’est le mode d’échec standard du monitoring interne seul.

Comment mettre en œuvre le monitoring

• Gardez le trafic et la saturation sur votre pile APM ou Prometheus ; confiez la latence et les erreurs aux vérifications Dotcom-Monitor en vrai navigateur opérant depuis les régions où sont vos utilisateurs.
• Configurez des assertions de contenu sur ces vérifications, pas seulement des contrôles de codes statut, pour que le parcours d’achat cassé derrière un HTTP 200 échoue comme pour l’utilisateur.
• Script les transactions importantes (connexion, recherche, achat) avec EveryStep, de sorte que le monitoring suive le même chemin que vos utilisateurs.
• Comparez régulièrement les chiffres intérieurs et extérieurs ; l’écart est votre couche CDN, DNS et tiers.

Principe 5 – Automatisation

L’argument SRE pour l’automatisation est la cohérence à grande échelle. Les humains oublient des étapes, les machines non, et toute réponse devant se produire à 3h du matin ne devrait pas dépendre d’un humain alerte à 3h du matin.

Ce qui change hors de Google : l’automatisation n’est efficace que si le signal qui la déclenche est fiable. Scripts de basculement, jobs de rollback, règles d’auto-scaling s’activent sur un événement de détection, donc chaque minute de retard détecté allonge le temps avant la réponse automatisée. Les calculs du chapitre SLO s’appliquent directement : une bascule automatisée déclenchée par une vérification toutes les 5 minutes donne en moyenne 2,5 minutes de délai avant réponse.

Et certains déclencheurs d’automatisation ne peuvent venir que de l’extérieur. Un script qui bascule vers un fournisseur de paiement de secours doit savoir que le principal échoue pour les utilisateurs, pas seulement que son endpoint de santé répond aux pings depuis le même réseau. Dotcom-Monitor boucle ce mécanisme en déclenchant alertes et webhooks depuis ses vérifications externes, pour que le basculement s’active sur ce que vivent les utilisateurs, pas ce que dit l’endpoint santé.

Comment mettre en œuvre l’automatisation

• Commencez par les réponses que vous effectuez déjà manuellement lors d’incidents : redémarrages, basculements, rollbacks.
• Connectez les webhooks d’alerte Dotcom-Monitor aux scripts qui les exécutent, pour que l’activation soit une panne confirmée depuis l’extérieur et non un endpoint interne.
• Utilisez des groupes d’escalade d’alerte pour que la première notification atteigne la personne ou système qui agit, pas une boîte partagée que personne ne surveille à 3h du matin.
• Laissez le filtre de réponse absorber les petits incidents auto-résolus pour ne pas déclencher vos automatisations, et revoyez trimestriellement les déclencheurs en fonction des taux de faux positifs.

Principe 6 – Ingénierie des mises en production

L’ingénierie des mises en production est la discipline consistant à construire et livrer des logiciels toujours de la même manière : builds versionnés, pipelines reproductibles, rollbacks qui fonctionnent car répétés.

Le CI/CD moderne couvre beaucoup de cela dans le pipeline. Tests validés, artefacts construits, déploiements derrière des flags. Ce que le pipeline ne vous dit pas, c’est si le système fonctionne réellement pour les utilisateurs après la mise en ligne. Le CI prouve la build ; seul, il ne dit rien du registre DNS non propagé, du cache CDN qui sert l’ancienne version, du tag tiers cassé en combinaison avec votre nouveau code, ou de la valeur de config qui existe uniquement en production.

C’est ce que la vérification post-déploiement comble. Un script EveryStep qui parcourt le chemin critique (charger la page, se connecter, finaliser la transaction), exécuté depuis le réseau Dotcom-Monitor contre la production immédiatement après chaque mise en ligne, est le seul test réel de ce que les utilisateurs obtiennent. Les équipes qui l’utilisent considèrent cela comme la dernière étape du pipeline : déployer, vérifier depuis l’extérieur, et ensuite seulement marquer la mise en production comme réussie. Si la vérification échoue, le rollback déclenche pendant que l’impact est encore mesuré en minutes.

Comment mettre en œuvre l’ingénierie de mise en production

• Versionnez chaque build et faites du rollback une action répétée et en une étape plutôt qu’improvisée.
• Faites d’une transaction EveryStep contre la production l’étape finale du pipeline de déploiement, lancée depuis le réseau Dotcom-Monitor pour que DNS, cache CDN et tags tiers fassent partie du test.
• Dirigez le webhook d’alerte de la vérification vers le pipeline, pour que l’échec post-déploiement devienne un signal automatique de rollback, et non un ticket à traiter le matin.
• Gardez la même vérification active entre les mises en ligne ; son historique est votre base de référence pour savoir si un déploiement a ralenti le système.

Principe 7 – Simplicité

Le chapitre Simplicité soutient que fiabilité et complexité s’opposent : chaque composant ajouté est un composant susceptible de tomber en panne, et le logiciel doit être exactement aussi complexe que la tâche le requiert.

Appliquez cela à la pile de monitoring elle-même, car c’est là que la complexité s’accumule silencieusement. Les équipes finissent avec un outil APM, une plateforme de logs, un uptime pinger, un service de page de statut, et trois tableaux de bord que personne n’ouvre. Chaque outil alerte selon son propre timing, et le résultat cumulé est la fatigue d’alerte : tant de notifications que celles qui comptent sont noyées.

Un fournisseur de monitoring vous conseillant de réduire vos outils est un argument inhabituel, mais justement c’est pourquoi il mérite d’être entendu. Le test de simplicité d’une pile de monitoring pose deux questions. Premièrement : pour chaque chose que vous surveillez, savez-vous quel outil est l’autorité quand deux d’entre eux ne sont pas d’accord ? Deuxièmement : chaque alerte a-t-elle une personne chargée d’agir dessus ? Si un outil ne répond pas aux deux questions pour tout ce qu’il surveille, ce n’est pas du monitoring, c’est du bruit avec abonnement. Consolider surveillance de disponibilité, transactions, API, et contrôle d’infrastructure dans une seule plateforme avec un seul canal d’alerte est d’abord un choix de simplicité, avant d’être un choix d’achat. C’est ainsi que Dotcom-Monitor est conçu : toutes ces vérifications en un seul endroit, une seule voie d’alerte, fonctionnant en parallèle avec l’outil APM qui surveille l’intérieur, sans s’y substituer.

Comment mettre en œuvre la simplicité

• Faites l’inventaire de vos outils de monitoring et notez, pour chacun, ce dont il est l’autorité.
• Supprimez toute alerte sans propriétaire et sans action associée ; si personne ne réagit, c’est du bruit.
• Intégrez les vérifications externes (disponibilité, page, transaction, API, infrastructure) dans Dotcom-Monitor en une seule plateforme avec un seul canal d’alerte, et laissez votre APM gérer l’intérieur.
• Répétez l’audit chaque année ; les piles de monitoring regagnent de la complexité par elles-mêmes.

Meilleures pratiques SRE

Les principes indiquent l’objectif à atteindre. Voici les pratiques qui tiennent dans des équipes ne possédant pas toute la pile :

• Fixez les SLO sur ce que les utilisateurs vivent, pas ce que les serveurs rapportent. “Finalisation de l’achat en moins de 4 secondes depuis un vrai navigateur” est un SLO que les utilisateurs reconnaîtraient. “API p95 sous 200 ms” est une donnée d’entrée.
• Adaptez la fréquence des vérifications à votre SLO. D’après le tableau du budget d’erreur ci-dessus : à 99,95 %, un quantum de 5 minutes consomme déjà 23 % du budget mensuel, et à 99,99 %, il dépasse complètement le budget. Considérez les vérifications à 1 minute comme plancher pratique à partir de 99,95 %.
• Surveillez vos dépendances comme vous vous surveillez. DNS, CDN, paiement, auth : une vérification externe par dépendance critique, avec son propre historique de temps de réponse. Quand leur page de statut est verte et que vos utilisateurs disent “c’est cassé”, ces données tranchent le litige.
• Écrivez la politique de budget d’erreur avant de dépenser le budget. Convenir à l’avance de ce qui arrive quand il est épuisé : gel des fonctionnalités, sprints fiabilité, priorités postmortem. Un budget sans politique est un graphique dont personne ne se sert.
• Répétez les réponses aux incidents avant de les vivre. Astreinte, escalades, postmortems sans blâme sont couverts en détail dans notre guide SRE incident management.
• Gardez le compte d’outils honnête. Auditez la pile de monitoring chaque année selon les deux questions de simplicité ci-dessus. Notre synthèse des outils SRE couvre les catégories à conserver.
• Faites du reporting de fiabilité une habitude, pas une précipitation. Rapports programmés de disponibilité et SLA signifient que la conversation de conformité démarre sur des chiffres partagés et non une plongée dans les logs après litige.

En résumé

Les sept principes SRE ont survécu au départ de Google. Ce qui n’a pas survécu est l’hypothèse sous-jacente : que l’équipe qui applique les principes contrôle la pile complète. Ce n’est pas votre cas, et cela change le travail. Le risque que vous ne pouvez pas éliminer par l’ingénierie doit être mesuré. Les budgets d’erreur ne sont valables que dans la mesure où l’intervalle de vérification qui les soutient l’est. L’outillage interne gère trafic et saturation ; la latence vécue et les erreurs ne sont visibles que depuis un point de vue externe. La vérification post-déploiement doit s’exécuter de l’extérieur, car c’est le seul endroit où le système complet existe.

Le fil commun est la mesure depuis l’extérieur. Chaque principe, appliqué à une pile composée de composants que vous ne possédez pas, nécessite une vue indépendante : vérifications par dépendance pour le risque, intervalles d’une minute pour les budgets d’erreur, vrais navigateurs pour les signaux d’or, transactions scriptées pour le travail répétitif et les mises en production, une plateforme unique pour la simplicité. C’est le rôle de Dotcom-Monitor sur les sept principes. Pas une préférence d’outil — c’est ce que les principes exigent dès que la pile cesse d’être la vôtre.

Questions fréquemment posées