Site Reliability Engineer

Un SLI est la mesure réelle, par exemple le pourcentage de requêtes qui aboutissent avec succès en moins de 300 millisecondes. Un SLO est l'objectif interne que l'on fixe pour ce SLI, disons que 99,9% des requêtes respectent ce seuil sur une fenêtre glissante de 30 jours. Un SLA est différent par nature, pas seulement par degré : c'est un engagement externe, souvent contractuel, envers un client, généralement avec des conséquences financières ou de réputation en cas de non-respect, et il est en général fixé plus large que le SLO interne pour donner de la marge à l'équipe. Je traite le SLO comme le chiffre qui pilote réellement les décisions au quotidien, et je réserve la conversation sur le SLA à ce que l'on communique aux clients et au juridique, car confondre les deux pousse les équipes soit à surinvestir dans une fiabilité que personne ne finance, soit à sous-investir et risquer de rompre un vrai contrat.

L'error budget est simplement 1 moins le SLO, exprimé comme une quantité de défaillance acceptable sur une fenêtre de temps. Si notre SLO est de 99,9% sur 30 jours, l'error budget est de 0,1%, ce qui sur un service à fort trafic se traduit en un nombre concret de minutes d'indisponibilité ou de requêtes en échec que l'on peut se permettre. Je l'utilise comme un outil de décision, pas seulement une métrique de reporting : quand le budget est sain, l'équipe a de la marge pour aller plus vite et prendre plus de risques, y compris des mises en production plus risquées ou des changements d'infrastructure. Quand le budget approche de l'épuisement, on recentre l'effort sur la fiabilité et on ralentit ou suspend les nouvelles fonctionnalités jusqu'à ce qu'il se reconstitue. L'intérêt de ce cadre est qu'il transforme la question « est-ce sûr de déployer » d'un débat subjectif en un chiffre partagé que l'ingénierie et le produit peuvent regarder ensemble et accepter.

Je traite l'error budget comme le mécanisme qui résout cette tension plutôt que d'essayer de la régler à coups de réunions de négociation. Tant que le budget est sain, produit et ingénierie peuvent avancer à pleine vitesse, puisque les données montrent que le service peut absorber ce niveau de risque. Une fois que le budget commence à s'épuiser, cela devient un signal automatique et convenu à l'avance pour prioriser le travail de fiabilité : corriger les causes racines des incidents récents, réduire le toil, ou renforcer une dépendance fragile, avant d'ajouter plus de risque fonctionnel. Je suis aussi le toil séparément, le temps passé sur du travail opérationnel manuel et répétitif, car un toil élevé érode discrètement la vélocité même quand le SLO a l'air bon sur le papier. Bien calibrer cet équilibre dépend d'abord de fixer le SLO avec rigueur : un SLO trop strict épuise toute l'équipe à poursuivre une fiabilité que personne ne demande vraiment, et un SLO trop lâche laisse s'accumuler de vrais problèmes de fiabilité sans qu'on s'en aperçoive.

J'utilise des outils d'observabilité avec détection d'anomalies pour repérer des schémas inhabituels de latence ou de taux d'erreur avant qu'ils ne franchissent un seuil d'alerte, ce qui donne à l'équipe de l'avance sur les problèmes émergents. Pendant un incident actif, j'ai utilisé la synthèse de logs assistée par IA pour extraire rapidement les lignes pertinentes d'un volume énorme de bruit, ce qui accélère les dix premières minutes quand tout le monde essaie de comprendre le périmètre. Certains de nos runbooks proposent maintenant des prochaines étapes suggérées par IA en fonction de l'alerte déclenchée, même si je traite toujours cela comme une hypothèse de départ, pas une instruction à suivre aveuglément. Ce qui reste entièrement humain, c'est le rôle d'incident commander et l'analyse du post-mortem : décider ce qui s'est réellement passé, ce qui y a contribué, et quels changements valent la peine d'être faits nécessite un jugement sur le contexte organisationnel et les compromis que les outils ne peuvent pas voir.

Notre base de données principale a connu un problème d'épuisement du pool de connexions qui a mis le paiement hors service pendant environ 22 minutes lors d'un pic de trafic promotionnel. J'étais incident commander : mon premier réflexe a été de déclarer l'incident formellement et de mobiliser un spécialiste base de données et un ingénieur backend plutôt que d'essayer de déboguer seul. Nous avons mitigé d'abord, pas cherché la cause racine d'abord : nous avons augmenté la limite du pool de connexions et redémarré les instances du service concerné, ce qui a rétabli le paiement en environ huit minutes, puis passé le reste de l'incident à confirmer la stabilité. J'ai publié une mise à jour de statut toutes les dix minutes dans notre canal d'incident, même sans nouvelle information, car un silence côté parties prenantes est pire qu'une mise à jour répétée du type « toujours en cours d'investigation ». Une fois le service stabilisé, j'ai transmis l'investigation de la cause racine au spécialiste base de données et clôturé l'incident actif, car garder un incident ouvert au-delà de la mitigation ajoute de la charge de process sans aider les utilisateurs.

Après qu'une panne du pipeline de déploiement a causé un retard de deux heures dans un correctif de sécurité critique, j'ai mené le post-mortem et posé la règle de base dès le départ : nous nommons les facteurs contributifs dans le système et le processus, pas la personne qui a cliqué sur déployer. Nous avons construit la chronologie ensemble en groupe plutôt que moi la présentant seul, ce qui a fait remonter un détail que j'aurais manqué : l'alerte qui aurait dû détecter la panne avait été mise en sourdine trois semaines plus tôt pendant une session de débogage sans rapport et jamais réactivée. Chaque action a reçu un responsable nommé et une échéance dès la même réunion, sans rester un suivi vague, et nous avons d'abord revu les actions du post-mortem précédent pour confirmer qu'elles avaient réellement été réalisées. Le post-mortem a fonctionné parce que personne n'a dépensé d'énergie à se défendre : l'ingénieur qui avait mis l'alerte en sourdine a spontanément partagé ce détail une fois qu'il est devenu clair que la salle cherchait des causes, pas un coupable.

Le produit voulait déployer une refonte majeure du paiement deux semaines avant notre période de trafic la plus chargée de l'année, et notre error budget pour ce service était déjà tombé à environ 15% restant pour le mois après quelques semaines difficiles en incidents. Je n'ai pas simplement dit non. J'ai apporté les données de l'error budget à la réunion de planification et présenté cela comme une décision de risque partagée : déployer maintenant, avec un chemin de code non testé, pendant le pic de trafic, avec presque plus de budget, était un risque précis et chiffré, pas une inquiétude vague. J'ai proposé de déployer la refonte sur un petit pourcentage du trafic immédiatement, de surveiller le SLO pendant une semaine, et de ne généraliser que si cela tenait, plutôt qu'un lancement complet juste avant le pic. Le produit a accepté une fois le risque présenté en chiffres plutôt qu'en prudence générale, et le déploiement progressif a détecté une fuite mémoire sous charge qui aurait causé un vrai incident pendant le pic de trafic si nous avions déployé intégralement selon le calendrier initial.

J'ancre mes métriques autour des quatre golden signals : latence, trafic, taux d'erreur et saturation, car ensemble ils couvrent l'essentiel de ce qui indique qu'un service est en bonne santé sans noyer l'équipe sous le bruit. Pour un seul service, ces informations viennent des métriques, mais dès qu'on a une chaîne d'appels à travers plusieurs services, les métriques seules ne suffisent plus, et c'est là que le tracing distribué justifie son coût : une trace montre exactement quel maillon d'une requête a ajouté de la latence au lieu de simplement dire que l'ensemble a ralenti. Je garde les logs structurés, avec des champs cohérents comme l'ID de requête et le nom du service, spécifiquement pour qu'ils puissent être corrélés avec une trace pendant un incident au lieu d'être parcourus manuellement. Je suis délibéré sur l'échantillonnage sur les services à fort volume, car capturer 100% des traces devient coûteux rapidement et apporte rarement plus de valeur qu'un taux d'échantillonnage bien conçu combiné à une capture complète de tout ce qui génère une erreur.

Je définis le toil comme du travail manuel, répétitif, tactique, qui croît linéairement avec la croissance du service plutôt que d'apporter une valeur d'ingénierie durable, des choses comme redémarrer manuellement une tâche bloquée ou modifier à la main une configuration pour chaque nouveau client intégré. La première étape consiste à le mesurer avec précision : je suis la part du temps d'astreinte réellement consacrée au toil par rapport à la vraie réponse aux incidents, car les équipes sous-estiment systématiquement cela tant qu'elles ne l'ont pas mesuré pendant quelques semaines. Tout ce qui revient plus qu'une poignée de fois passe un test clair : est-ce que cela peut être automatisé avec un effort d'ingénierie raisonnable, et est-ce que le supprimer libère assez de temps pour justifier cet effort. J'ai automatisé des choses comme le renouvellement de certificats et le nettoyage de ressources obsolètes de cette façon, ce qui a retiré du vrai toil de l'astreinte de façon permanente plutôt que de simplement rendre chaque occurrence un peu plus rapide. Je protège aussi du temps sur la roadmap spécifiquement pour ce travail, car la réduction du toil perd toujours face à la pression fonctionnelle si elle n'est pas explicitement planifiée.

Je pars du chiffre de croissance réel attendu par le produit, pas d'un vague « beaucoup plus de trafic », et je le convertis en un objectif précis de taux de requêtes. Je regarde les tendances de croissance historiques d'événements similaires passés pour vérifier si la projection est réaliste, puis je lance des tests de charge sur un environnement de staging configuré pour ressembler le plus possible à la production, car tester sur un environnement sous-dimensionné donne une fausse confiance. Je fixe un objectif de marge, en général en prévoyant sensiblement plus que le pic projeté, pas juste de quoi l'atteindre exactement, car le trafic réel est plus en pics qu'une projection lissée ne le suggère. Je vérifie spécifiquement les limites d'autoscaling, car un service peut avoir une capacité théorique confortable mais échouer quand même si le nombre maximal d'instances de l'autoscaler ou la limite de connexions d'une dépendance en aval le plafonne en dessous du besoin. Le coût fait aussi partie de la conversation : je présente un plan avec la marge que je recommande et son coût, pour que la décision d'accepter plus de risque contre un coût plus faible soit prise explicitement par l'entreprise, pas par défaut.