Le site reliability engineering, c'est ce qu'on obtient quand on traite les opérations comme un problème logiciel : une équipe d'ingénieurs qui prend en charge la fiabilité d'un service en production, la mesure du côté de l'utilisateur, et passe au moins la moitié de son temps à écrire du code qui supprime du travail opérationnel au lieu de faire ce travail à la main. Un SRE n'est ni un sysadmin rebaptisé ni un ingénieur DevOps avec un pager. Le rôle a un périmètre défini, un ensemble défini de choses qu'il surveille, et une relation définie avec les développeurs. Ce billet couvre les trois.

Ceci est la Partie 1 de Budget for Failure, une série en quatre parties sur ce qu'est le site reliability engineering et sur la façon de le pratiquer. Les Parties 1 et 2 sont de niveau 101 : le rôle, puis les chiffres sur lesquels il tourne (SLI, SLO, SLA, budgets d'erreur). Les Parties 3 et 4 sont de niveau 201 : ce qu'un SRE doit maîtriser dans le code, et ce qu'il faut vérifier côté fournisseur, que ce soit un cloud ou votre propre data center. Les exemples sont sur AWS ; la pratique n'est pas propre à AWS.

D'où vient le rôle

Le terme vient de Google, où Ben Treynor Sloss a monté la première équipe en 2003 et l'a décrite plus tard en une ligne dans le SRE book : le SRE, c'est ce qui se passe quand vous demandez à un ingénieur logiciel de concevoir une équipe d'exploitation. La réponse de l'ingénieur à un service en croissance n'a pas été d'embaucher des opérateurs proportionnellement au trafic. Elle a été d'automatiser le travail de l'opérateur, et de plafonner strictement la quantité de travail manuel que l'équipe avait le droit d'accepter.

La relation au DevOps se résume d'habitude, toujours chez Google, par « class SRE implements interface DevOps ». DevOps est un ensemble de principes : responsabilité partagée, petits changements, automatisation, mesure. Le SRE est une implémentation concrète de ces principes, avec des opinions attachées, comme la façon exacte dont la fiabilité se mesure et ce qui se passe exactement quand la mesure dit qu'un service n'est pas assez fiable.

De quoi un SRE est responsable

Le SRE book énonce le périmètre en une phrase : une équipe SRE est responsable de la disponibilité, de la latence, de la performance, de l'efficacité, de la gestion du changement, de la supervision, de la réponse aux urgences et de la planification de capacité de ses services. Déplié en ce que cela veut dire sur une semaine de travail :

  • Disponibilité et latence. Définir ce que « ça marche » veut dire pour les utilisateurs sous forme d'un chiffre, le mesurer, et le défendre. La Partie 2 ne parle que de cela.
  • Gestion du changement. La plupart des pannes sont causées par un changement. Le SRE possède la machinerie qui rend le changement sûr : déploiements progressifs, rollback automatisé, et les preuves qu'une release est saine.
  • Supervision et alerting. Décider quels signaux méritent un humain à 03:00 et lesquels ont leur place sur un dashboard. Une alerte qui n'appelle aucune action est un défaut de l'alerting, et le SRE le corrige comme n'importe quel autre défaut.
  • Réponse aux urgences. Être d'astreinte (on-call), conduire les incidents avec une structure de commandement claire, et rétablir le service d'abord, diagnostiquer ensuite.
  • Postmortems. Après un incident, une analyse écrite et sans blâme de ce qui s'est passé et du correctif systémique qui empêche cette classe de défaillance. Le sans blâme est une exigence technique : des gens qui s'attendent à une sanction arrêtent de rapporter ce qu'ils ont vu.
  • Planification de capacité. Savoir quelle marge existe, comment la demande croît, et combien de temps met la nouvelle capacité à arriver, en minutes sur un cloud, en mois on-prem.
  • Efficacité et performance. Une fiabilité achetée avec une capacité de réserve illimitée, ce n'est pas de l'ingénierie. Le coût par requête est aussi un chiffre SRE.
  • Éliminer le toil. Traité plus bas, parce que c'est la partie qui rend le reste possible.

Ce qu'un SRE regarde

Un ingénieur DevOps venu de l'infrastructure a tendance à surveiller des ressources : CPU, mémoire, disque, nombre de nœuds. Un SRE commence une couche plus haut, à ce que l'utilisateur a vécu, et n'utilise les métriques de ressources que pour l'expliquer. L'ensemble de départ standard, ce sont les quatre golden signals du chapitre sur la supervision du SRE book :

SignalQuestion à laquelle il répondOù il vit sur AWS
LatenceCombien de temps prennent les requêtes, en séparant succès et échecs ?Percentiles de TargetResponseTime de l'ALB, Latency d'API Gateway, traces applicatives
TraficQuelle demande pèse sur le système ?RequestCount de l'ALB, messages SQS envoyés, Invocations Lambda
ErreursQuelle fraction des requêtes échoue ?HTTPCode_Target_5XX_Count et HTTPCode_ELB_5XX_Count de l'ALB, Errors Lambda
SaturationÀ quel point la ressource la plus contrainte est-elle pleine ?Connexions RDS rapportées à max_connections, âge des files, réservation CPU ECS, consommation des service quotas

Deux détails séparent une lecture SRE de ces signaux d'une lecture ordinaire. La latence se lit comme une distribution, jamais comme une moyenne : le 99e percentile, c'est là que sont les utilisateurs mécontents. Et la saturation se lit par rapport à la limite qui sera réellement atteinte en premier, et c'est rarement le CPU. C'est le pool de connexions de la base de données, l'allocation de ports de la NAT gateway, la concurrence Lambda au niveau du compte, ou le budget d'IOPS du volume EBS.

Au-delà des quatre signaux, un SRE surveille ce qui prédit l'incident du mois prochain : le rythme et le taux d'échec des changements, l'âge de la plus vieille dépendance non patchée, la part de la semaine passée partie en travail manuel, et le nombre d'alertes reçues par l'ingénieur d'astreinte.

La règle des 50 pour cent et le toil

Ce qui distingue le SRE d'une équipe d'exploitation avec un meilleur titre, c'est un plafond. Dans le modèle de Google, un SRE passe au moins 50 pour cent de son temps sur du travail d'ingénierie, en moyenne sur quelques trimestres. Le reste peut aller au travail opérationnel : tickets, astreinte, tâches manuelles.

La partie manuelle a un nom, le toil, et une définition précise : du travail lié à l'exploitation d'un service en production qui tend à être manuel, répétitif, automatisable, tactique, sans valeur durable, et qui croît linéairement avec le service. Redémarrer un worker bloqué, renouveler un certificat à la main, approuver une demande de quota, copier une base de données pour un développeur. Chaque tâche est petite. Ensemble, elles sont la raison pour laquelle une équipe de cinq ne fait plus aucune ingénierie.

Le plafond est ce qui donne au SRE la légitimité pour dire non. Quand le toil dépasse la moitié du temps de l'équipe, la réponse n'est pas l'héroïsme. C'est d'automatiser la source la plus grosse, ou de rendre la charge opérationnelle à l'équipe qui la génère jusqu'à ce qu'elle diminue. L'astreinte suit la même logique : le SRE book place une charge soutenable autour de deux incidents par tour d'astreinte, parce que chaque incident demande un suivi et un postmortem, et qu'une personne qui reçoit cinq alertes par nuit ne fait ni l'un ni l'autre.

Comment un SRE aide les développeurs

La pire version de ce rôle est une barrière : les développeurs jettent une release par-dessus un mur et une équipe fiabilité décide si elle peut passer. La version utile traite les développeurs comme le client et la fiabilité comme un produit que le SRE construit pour eux. Quatre formes concrètes :

La voie pavée (paved road). Un template de service livré avec logging structuré, métriques, tracing, health checks, un pipeline de déploiement avec canary et rollback, et des alarmes raisonnables déjà câblées. Un développeur qui prend le défaut obtient un service fiable sans lire un runbook. C'est la chose à plus forte valeur qu'une équipe SRE livre.

La production readiness review. Avant qu'un nouveau service ne prenne du vrai trafic, le SRE le passe en revue avec les développeurs : de quoi dépend-il, que se passe-t-il quand chaque dépendance est lente, quels sont les timeouts, comment le rollback se fait, qui est alerté. C'est une revue de conception, faite assez tôt pour changer la conception. La Partie 3 détaille ce qu'il faut chercher.

Le budget d'erreur (error budget). Un chiffre partagé, convenu à l'avance, qui dit aux deux camps quand il est sûr de livrer vite et quand ralentir. Il remplace la dispute sur le fait qu'une release soit « trop risquée » par une lecture. La Partie 2 le construit.

L'astreinte partagée. Des développeurs qui portent le pager pour leur propre service écrivent un code différent. Beaucoup d'organisations démarrent un service sur la rotation des développeurs et ne le transfèrent au SRE qu'une fois qu'il atteint un niveau de fiabilité, et le lui rendent s'il redescend en dessous. Le travail du SRE est de rendre cette rotation humaine, avec de bonnes alertes et de bons runbooks, pas d'absorber la douleur pour que personne en amont ne la sente.

SRE et DevOps : là où le travail diffère

Si vous faites tourner des pipelines, Terraform et Kubernetes pour gagner votre vie, l'essentiel de l'outillage se transfère. Ce qui change, c'est la question à laquelle chaque outil répond.

En tant qu'ingénieur DevOps, vousEn tant que SRE, vous aussi
Construisez le pipeline CI/CDDécidez quelle preuve arrête un déploiement automatiquement, et mesurez combien de fiabilité chaque release coûte
Posez des alarmes sur CPU, mémoire et disqueN'alertez que sur des symptômes visibles par l'utilisateur, et gardez les métriques de ressources pour le diagnostic
Provisionnez l'infrastructure as codeConnaissez ses domaines de défaillance, ses quotas, et ce qui se passe quand le control plane du fournisseur est en panne
Corrigez l'incidentConduisez l'incident, écrivez le postmortem, et livrez le correctif qui supprime la classe de défaillance
Automatisez une tâche quand on vous le demandeSuivez le toil comme un chiffre et refusez de le laisser dépasser la moitié du temps de l'équipe
Considérez le code applicatif comme le domaine des développeursLe lisez, relisez ses timeouts et ses retries, et lui envoyez des pull requests

La dernière ligne est celle que la plupart des ingénieurs infrastructure sous-estiment. Un SRE qui ne sait pas lire le code du service ne peut observer les défaillances que de l'extérieur. La fiabilité se décide dans la façon dont une fonction gère une dépendance lente, et cela se trouve dans le dépôt, pas dans le cluster.

Modes de défaillance et ce qu'il faut surveiller

Le renommage. Une équipe d'exploitation qui reçoit le titre SRE et la même file de tickets n'a rien changé. Sans le plafond de toil et l'autorité qui va avec, il n'y a pas de temps pour l'ingénierie, et le titre décrit une aspiration.

Le gardien de la porte. Une équipe fiabilité qui approuve les releases devient le goulot que l'organisation contourne. L'influence vient de la voie pavée et des données, pas d'un veto.

Le héros. Un ingénieur qui connaît chaque système et répare chaque panne est un point de défaillance unique avec un salaire. Les incidents qui se terminent par « Sam a mis vingt minutes » ont besoin d'un runbook, pas d'applaudissements.

La fiabilité sans chiffre. « Aussi fiable que possible » ne se planifie pas, ne se dote pas en effectifs, et ne se négocie pas contre des fonctionnalités. Tout ce billet repose sur la capacité à dire à quel point un service doit être fiable et s'il l'est en ce moment. C'est le vocabulaire des SLI, des SLO et des budgets d'erreur, et c'est la Partie 2.

À lire ensuite

Pour du conseil en AWS, architecture cloud, pratique SRE, pipelines CI/CD, Linux et plus encore, commencez par ercanermis.com.

Références