Qu'est-ce que SRE (Site Reliability Engineering) ?

À quoi sert le SRE

Le Site Reliability Engineering (SRE) est une discipline formalisée par Google au début des années 2000 et popularisée par le livre éponyme en 2016. Son idée centrale : appliquer des pratiques d'ingénierie logicielle (automatisation, mesure, abstraction) aux problèmes d'exploitation traditionnellement gérés par des sysadmins. Un SRE ne fait pas que maintenir des serveurs ; il écrit du code pour rendre l'infrastructure auto-gérée.

Le SRE répond à une tension fondamentale en production : les équipes développement veulent livrer vite, les équipes exploitation veulent la stabilité. Le SRE résout cette tension par la quantification : on définit des objectifs de fiabilité mesurables, et on autorise les changements rapides tant qu'on respecte ces objectifs.

Les concepts centraux

SLI (Service Level Indicator) : une métrique quantifiée du comportement du service, par exemple la latence p95, le taux d'erreur 5xx ou la disponibilité mesurée par sondes externes. Toujours du côté de l'expérience utilisateur, jamais une métrique interne.

SLO (Service Level Objective) : la cible chiffrée d'un SLI, par exemple « 99,9% des requêtes en moins de 300 ms sur 30 jours glissants ». Le SLO est un engagement interne, pas commercial.

SLA (Service Level Agreement) : le contrat commercial avec les clients, généralement avec engagements financiers (pénalités). Le SLA est moins exigeant que le SLO pour garder une marge opérationnelle.

Error budget : le complément mathématique du SLO. Avec un SLO à 99,9%, le budget d'erreur est de 0,1%, soit environ 43 minutes d'indisponibilité par mois. Tant qu'on est dans le budget, l'équipe produit peut prendre des risques ; au-dessus, les déploiements ralentissent et la priorité passe à la fiabilité.

SRE vs DevOps

Le SRE est une implémentation concrète de la culture DevOps, pas une alternative. DevOps répond au « pourquoi et comment culturel » (rapprocher dev et ops, automatiser, propriété partagée). SRE répond au « comment mesurable et opérationnel » (quels métriques, quels seuils, quels arbitrages).

En Suisse romande, nous voyons généralement les organisations adopter DevOps avant SRE. Le passage à SRE devient pertinent au-delà de 500 collaborateurs ou quand plusieurs équipes produit consomment la même plateforme. Pour une PME de moins de 200 personnes, une équipe DevOps avec quelques pratiques SRE (SLO, post-mortems blameless) suffit largement.

Le rôle SRE en pratique

Un SRE consacre idéalement 50% de son temps à l'automatisation et 50% au support des équipes produit. Le seuil critique se situe autour de 30% de temps d'exploitation pur : au-delà, le SRE bascule en mode pompier permanent et perd sa valeur d'ingénierie.

Quand SRE n'est pas adapté

Les organisations très petites (<50 personnes), les startups en phase de découverte produit, et les environnements purement bureautiques ne tirent pas de bénéfice immédiat du SRE. La formalisation des SLO suppose un produit en exploitation stable avec un trafic mesurable.

Services Hidora associés

• SLA Expert : contrat de compétence sur appel avec SLO contractuels mesurés.
• Managed Services : exploitation avec SLO mensuel, rapports de fiabilité, error budgets partagés.
• DevOps et Observabilité : prérequis culturels et techniques de la pratique SRE.