Qu'est-ce que le SRE site reliability engineering ?
Résumé
Le SRE (site reliability engineering) traite l'exploitation comme un problème logiciel. Vous fixez une cible de fiabilité mesurable, vous suivez les écarts, et ce chiffre arbitre entre nouvelles fonctionnalités et réparations. Les notions clés sont le SLI, le SLO, le SLA et le budget d'erreur. Pour un side project, une mise en place d'une soirée suffit : un SLI, un SLO à 99,5 %, un point de contrôle et des alertes sur le burn rate.
Un matin, un utilisateur vous écrit : « le site ne répond plus ». Vous regardez votre tableau de bord, rien ne clignote, rien n'est rouge, et personne ne sait depuis combien de temps ça dure. Voilà le problème que traite la discipline. Qu'est-ce que le SRE site reliability engineering ? C'est traiter l'exploitation comme un problème de logiciel : vous fixez un objectif de fiabilité mesurable, vous suivez la fréquence à laquelle vous le manquez, et ce chiffre décide si vous livrez des fonctionnalités ou si vous réparez. Google a popularisé le terme, mais l'idée marche à toute taille. Pour un dev solo avec une application et quelques utilisateurs, cela veut dire décider à l'avance combien de panne vous acceptez.
La plupart des side projects n'ont pas ce chiffre. Ils sont « up » jusqu'au jour où quelqu'un vous écrit. Ce guide explique le SRE en termes simples, puis le réduit à quelque chose qu'une personne peut mettre en place un week-end.
Qu'est-ce que le SRE, vraiment ?
Le point de départ, c'est le livre SRE de Google : le SRE, c'est ce qu'on obtient quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation. Au lieu de redémarrer des serveurs à la main, on écrit du code qui le fait, puis on mesure les résultats.
Trois idées portent l'essentiel. La fiabilité est une fonctionnalité avec une cible, pas une impression. Le travail manuel répétitif (le livre parle de « toil ») est un bug à automatiser. Et la panne est attendue, donc on prévoit comment en tirer une leçon plutôt que comment éviter de pointer quelqu'un du doigt.
DevOps et SRE se recouvrent beaucoup. La différence pratique : DevOps est une culture où l'on livre et fait tourner le code ensemble, alors que le SRE vous donne des outils précis pour en discuter avec des chiffres. Inutile de choisir un camp pour utiliser les chiffres.
Dans une grande entreprise, une journée de SRE se partage entre astreinte, gestion d'incidents, planification de capacité et automatisation. Le livre de Google recommande de plafonner le travail opérationnel à environ la moitié du temps d'un ingénieur, pour que l'autre moitié aille au développement. Ce plafond est une contrainte de conception, pas un vœu pieux.
Concrètement, le travail récurrent ressemble à ceci :
définir des SLO avec les équipes produit, et alerter sur la consommation du budget plutôt que sur chaque raté ;
tenir des astreintes et écrire des runbooks, pour que l'alerte de 3 h du matin ait une checklist ;
piloter la gestion d'incident, puis rédiger un postmortem sans recherche de coupable ;
automatiser tout ce qu'on fait à la main plus de quelques fois ;
relire les mises en production sous l'angle du risque pour la fiabilité.
Les feature flags illustrent bien cette logique. Un flag permet de couper une mauvaise version en quelques secondes, sans redéploiement, ce qui protège votre budget. Faut-il un outil hébergé pour ça ? Cela dépend du nombre de flags : une simple variable d'environnement suffit pour les trois premiers.
SLI, SLO, SLA : trois sigles, une idée chacun
Un SLI (service level indicator) est une mesure. Pour une application web, c'est en général la part de requêtes qui réussissent, ou la part qui répondent en moins de 300 ms. Choisissez-en un ou deux, pas douze.
Un SLO (service level objective) est la cible que vous fixez sur cette mesure, par exemple « 99,9 % des requêtes réussissent sur 30 jours ». C'est un objectif interne, une promesse faite à vous-même.
Un SLA (service level agreement) est un contrat avec un client, en général assorti de remboursements si l'objectif est manqué. Si personne ne vous paie pour la disponibilité, vous n'avez pas encore de SLA, et il ne faut pas en écrire un par accident dans le texte de votre page tarifs.
Le budget d'erreur, la partie qui change votre façon de travailler
Le budget d'erreur, c'est simplement 100 % moins votre SLO. Une cible de 99,9 % sur 30 jours laisse environ 43 minutes de panne permise. C'est le budget que vous pouvez dépenser en déploiements risqués, migrations et expériences.
L'intérêt tient à la règle qui y est attachée. Tant qu'il reste du budget, vous livrez. Quand il est épuisé, vous arrêtez les fonctionnalités et vous réparez la fiabilité jusqu'à ce que le budget se reconstitue. Le chapitre du livre sur la gestion du risque présente cela comme un moyen de trancher le débat entre « on va plus vite » et « on ne casse rien » avec un chiffre partagé, plutôt qu'avec une négociation.
Le livre insiste aussi sur un point qui vaut d'être répété : 100 % n'est presque jamais la bonne cible. Un utilisateur sur un réseau mobile capricieux ne voit pas la différence entre 99,99 % et 99,9 %, et chaque neuf supplémentaire coûte bien plus cher que le précédent. Ce n'est pas une cible parfaite, c'est une cible utilisable.
Si vous voulez la démarche concrète pour choisir vos indicateurs et écrire votre premier objectif, le workbook SRE de Google sur la mise en place des SLO est le chapitre le plus pratique, et il reste court.
Faut-il du SRE quand on construit seul ?
Trois raisons de le faire, une raison de ne pas le faire.
Les raisons de le faire : votre projet finira par vous réveiller, un objectif écrit vous empêche de sur-ingénierer, et « je fais tourner la production avec un SLO » passe bien quand quelqu'un décide s'il vous fait confiance. La raison de ne pas le faire : si votre projet n'a pas encore d'utilisateurs, vous vous entraînez à un problème que vous n'avez pas. Construisez d'abord, mesurez quand quelqu'un dépend de ce que vous faites.
Donc, pas tout l'attirail. Ne payez pas un service d'astreinte pour une application de loisir, ne faites pas tourner Kubernetes pour avoir l'air sérieux, et n'écrivez pas un modèle d'incident de dix pages. Ça vaut la peine dès que vous avez une dizaine d'utilisateurs réels : un point de contrôle, un SLO, et un endroit où regarder quand ça casse.
Une mise en place d'une soirée pour un side project
Voici le minimum qui tient, même à 10 000 utilisateurs. Cela prend une soirée. Testé. Pas optimal. Voici pourquoi on le fait quand même : c'est ennuyeux, et l'ennuyeux survit.
D'abord, choisissez un SLI : la part des requêtes HTTP qui renvoient autre chose qu'un 5xx. Ensuite, fixez le SLO à 99,5 % sur 30 jours, soit environ 3,6 heures de budget. Commencez large, resserrez plus tard. Enfin, ajoutez une sonde de disponibilité externe qui interroge un vrai point de contrôle.
Un point de contrôle utile vérifie ce qui casse réellement, pas seulement que le processus est vivant :
// GET /healthz
app.get("/healthz", async (req, res) => {
try {
await db.query("select 1"); // base joignable
await cache.ping(); // cache joignable
res.status(200).json({ ok: true });
} catch (err) {
res.status(503).json({ ok: false });
}
});Ensuite, envoyez les alertes là où vous les verrez, une notification push sur le téléphone plutôt qu'une boîte mail. Et tenez un fichier texte postmortems.md : après chaque panne, ajoutez quatre lignes sur ce qui s'est passé, pourquoi, combien de temps, et ce qui change. C'est l'outil de fiabilité le plus sous-estimé que vous aurez.
Alerter sur le burn rate, et écrire des postmortems qu'on lira
Une erreur classique de débutant : se faire alerter chaque fois qu'une seule requête échoue. Vous coupez le canal en une semaine. Un meilleur signal est le burn rate : la vitesse à laquelle vous consommez le budget d'erreur, comparée au rythme qui l'épuiserait exactement à la fin de la fenêtre.
Pour un side project, restez simple. Une notification push si le taux d'erreur sur les 10 dernières minutes dépasse 5 %, et un résumé par email si le taux hebdomadaire glisse vers un SLO manqué. Cela fait deux niveaux : se lever maintenant, ou regarder lundi. Le reste peut attendre que les utilisateurs se plaignent du premier niveau.
Pour le postmortem, restez court et sans recherche de coupable. « Sans recherche de coupable » ne veut pas dire que personne n'est responsable. Cela veut dire qu'on se demande ce qui, dans le système, a permis l'erreur, et non qui l'a commise. Quand vous êtes seul dans l'équipe, c'est plus important qu'il n'y paraît, parce que la tentation est de se sentir mal et de sauter la rédaction.
Quatre rubriques suffisent : ce qui s'est passé, pourquoi, combien de temps les utilisateurs ont été touchés, et ce qui change. La dernière doit nommer une action que vous ferez vraiment, avec une date. « Faire plus attention » n'est pas une action. « Ajouter une vérification en staging pour les migrations avant la prochaine version » en est une.
Sur un an, ce fichier devient une carte de vos points faibles. Après trois pannes causées par le même certificat expiré, la règle est simple : si une même cause revient deux fois, automatisez-la. Il a fallu une soirée pour ajouter la surveillance du renouvellement, et le problème ne s'est plus reproduit.
Où l'IA aide, et où elle ne doit pas décider
Les assistants sont utiles sur la part répétitive : écrire le point de contrôle, le Terraform d'une sonde de disponibilité, un premier jet de runbook, ou un script qui compte le taux de 5xx dans les logs. Ils sont mauvais pour décider de votre SLO, parce que c'est une décision produit sur ce que vos utilisateurs tolèrent.
Pendant un incident, soyez prudent. Un assistant peut proposer un correctif plausible que vous appliquez en production à 2 h du matin sans l'avoir lu. Utilisez-le pour expliquer une trace d'erreur ou rédiger le postmortem après coup, et gardez la décision de rollback à un humain qui est réveillé.
Les contrôles de qualité du code font aussi partie du tableau. Beaucoup de pannes viennent d'un changement qui semblait anodin en relecture. L'analyse statique en CI ne vous donnera pas la fiabilité, mais elle élimine une classe d'erreurs bêtes avant qu'elles ne coûtent du budget.
Ce qu'on build ensuite, et si le SRE vous plaît
Est-ce un bon chemin pour un dev qui aime construire ? Ça dépend de ce que vous aimez. Les métiers de SRE conviennent à ceux qui aiment les systèmes, les modes de panne et l'automatisation plus que la livraison d'interfaces. Si vous trouvez de la satisfaction à rendre le pager plus silencieux, vous aimerez. Si vous voulez voir des utilisateurs cliquer sur votre nouvelle fonctionnalité, probablement pas.
Le chemin d'entrée passe en général par le backend ou l'infrastructure : vous commencez par posséder les déploiements et les alertes d'un service, puis vous prenez davantage de sa fiabilité. Les compétences qui se transposent : bases de Linux, réseau, un fournisseur cloud, une pile de supervision, et l'habitude d'écrire les choses. Les side projects sont un bon terrain pour tout ça, puisque vous êtes toute l'équipe.
Choisissez une chose que vous faites déjà tourner, même une application gratuite, et écrivez son SLI, son SLO et l'action exacte que vous prendrez quand le budget sera épuisé. Si vous ne pouvez pas dire ce que vous arrêteriez de faire, le chiffre n'est qu'une décoration. Lequel de vos projets remarqueriez-vous en panne avant qu'un utilisateur vous le dise ?