Éliminer le toil

Au cœur de la fonction d'ingénieur en fiabilité (Site Reliability Engineering, SRE) se trouve une ambition simple à énoncer et difficile à tenir : consacrer son temps à des projets d'ingénierie de long terme plutôt qu'à du travail opérationnel. Mais le mot « opérationnel » est trop vague, trop chargé d'interprétations : ce que l'un trouve fastidieux, l'autre le trouve apaisant. Les équipes de Google ont donc forgé un terme précis pour nommer l'ennemi à combattre — le toil. Comme le résume Carla Geisser, SRE chez Google : « Si un opérateur humain doit toucher votre système en fonctionnement normal, vous avez un bug. » Ce chapitre définit rigoureusement le toil, explique pourquoi en réduire la part est un objectif central du SRE, et pose la règle célèbre du plafond à 50 %.

Ce que le toil n'est pas

Avant de définir le toil, il faut dissiper trois confusions fréquentes. Le toil n'est pas simplement « le travail que je n'aime pas faire ». Les goûts varient d'une personne à l'autre, et certains ingénieurs apprécient sincèrement les tâches manuelles et répétitives. Le toil n'est pas non plus l'équivalent des corvées administratives, que le livre range dans une catégorie distincte : la charge annexe (overhead). La charge annexe regroupe le travail qui n'est pas directement lié à l'exploitation d'un service de production — réunions d'équipe, fixation et évaluation des objectifs, comptes rendus hebdomadaires (les fameux « snippets »), paperasse RH. C'est nécessaire, mais ce n'est pas du toil.

Enfin, le travail ingrat (grungy work) n'est pas du toil dès lors qu'il a une valeur durable. Nettoyer entièrement la configuration des alertes d'un service et en retirer le bruit accumulé est une tâche pénible, parfois rébarbative — mais comme elle améliore durablement le service, ce n'est pas du toil. La distinction ne tient donc pas au plaisir ni à la propreté du travail, mais à sa nature et à ses effets.

La définition du toil : six attributs

Le toil est le type de travail lié à l'exploitation d'un service de production qui présente, à des degrés divers, six caractéristiques. Toutes ne sont pas réunies pour chaque tâche, mais plus une tâche en cumule, plus elle relève du toil.

Attribut	Description
Manuel (manual)	Le temps qu'un humain passe « les mains dans le cambouis ». Lancer manuellement un script qui automatise une tâche reste du toil : c'est le temps de présence humaine qui compte, pas le temps écoulé.
Répétitif (repetitive)	Un travail qu'on refait encore et encore. Faire une tâche pour la première ou la deuxième fois n'est pas du toil. Résoudre un problème inédit, inventer une solution nouvelle, non plus.
Automatisable (automatable)	Si une machine peut accomplir la tâche aussi bien qu'un humain, ou si le besoin pouvait être supprimé par conception, c'est du toil. Si le jugement humain est essentiel, c'est probablement autre chose.
Tactique (tactical)	Le toil est piloté par les interruptions et réactif, plutôt que stratégique et proactif. Traiter une alerte d'astreinte (pager) est du toil. On ne l'élimine jamais totalement, mais on doit sans cesse le minimiser.
Sans valeur durable (no enduring value)	Si le service reste dans le même état après la tâche, c'était sans doute du toil. S'il en sort durablement amélioré, ce n'en était probablement pas — même au prix d'un peu de travail ingrat.
En O(n) avec la croissance	Si la charge de travail croît linéairement avec la taille du service, le volume de trafic ou le nombre d'utilisateurs, c'est probablement du toil.

Le dernier attribut est le plus structurant, et mérite qu'on s'y arrête. Un service idéalement conçu et géré devrait pouvoir croître d'au moins un ordre de grandeur (un facteur dix) sans travail supplémentaire, hormis quelques efforts ponctuels pour ajouter des ressources. C'est l'opposé exact du toil, qui enfle au même rythme que le service.

Comportement du travail face à la croissance du service

Charge de
travail
humain   ▲
         │                                   ╱ TOIL : O(n)
         │                               ╱       (chaque nouvelle unité de
         │                           ╱           service ajoute du travail)
         │                       ╱
         │                   ╱
         │               ╱
         │           ╱
         │       ╱
         │   ╱  ────────────────────────────  INGÉNIERIE : O(1)
         │ ╱   (un effort ponctuel absorbe
         │╱     dix fois plus de charge)
         └────────────────────────────────────►  Taille du service / trafic

Qu'est-ce qui qualifie comme « ingénierie » ?

Si le toil est l'un des pôles, l'autre est le travail d'ingénierie (engineering work) : un travail nouveau, qui exige intrinsèquement du jugement humain, produit une amélioration permanente du service et est guidé par une stratégie. Il est souvent créatif et innovant, adoptant une approche pilotée par la conception (design-driven) — et plus la solution est généralisable, mieux c'est. C'est ce travail qui permet à une équipe, ou à toute l'organisation SRE, de gérer un service plus grand, ou davantage de services, à effectif constant.

Le livre répartit les activités typiques d'un SRE en quatre catégories, dont seules les deux premières sont de l'ingénierie au sens strict.

Catégorie	Nature	Exemples
Génie logiciel (software engineering)	Écrire ou modifier du code, avec la conception et la documentation associées	Scripts d'automatisation, outils et frameworks, fonctionnalités de passage à l'échelle et de fiabilité, durcissement du code d'infrastructure
Génie des systèmes (systems engineering)	Configurer ou documenter les systèmes de production de façon à produire une amélioration durable à partir d'un effort ponctuel	Mise en place et mise à jour du monitoring, configuration de la répartition de charge, réglage des paramètres système, conseil en architecture et en mise en production aux équipes dev
Toil	Travail directement lié à l'exploitation du service, répétitif, manuel, etc.	Réponse aux interruptions, gestes manuels de déploiement, traitement réactif des alertes
Charge annexe (overhead)	Travail administratif non lié directement à l'exploitation	Recrutement, paperasse RH, réunions, hygiène de la file de bugs, snippets, revues entre pairs, formations

La règle de répartition est limpide : chaque SRE doit passer au moins 50 % de son temps sur du travail d'ingénierie, en moyenne sur quelques trimestres ou sur une année. Le toil étant irrégulier (« spiky »), maintenir exactement 50 % d'ingénierie en continu n'est pas réaliste pour toutes les équipes ; certaines passeront sous la barre certains trimestres. Mais si la part consacrée aux projets s'établit durablement et nettement sous les 50 % sur le long terme, l'équipe concernée doit prendre du recul et comprendre ce qui ne va pas.

Pourquoi moins de toil vaut mieux

L'organisation SRE de Google affiche un objectif clair : maintenir le travail opérationnel — le toil — sous les 50 % du temps de chaque SRE. L'autre moitié, au minimum, doit aller à des projets d'ingénierie qui réduiront le toil futur ou ajouteront des fonctionnalités au service. Le développement de fonctionnalités vise généralement à améliorer la fiabilité, la performance ou l'utilisation des ressources — ce qui, par un effet de second ordre, réduit souvent le toil à son tour.

Pourquoi un tel plafond, énoncé si explicitement ? Parce que le toil, laissé sans contrôle, tend à s'étendre jusqu'à remplir 100 % du temps de chacun. Le travail de réduction du toil et de passage à l'échelle des services constitue précisément l'« Engineering » de Site Reliability Engineering. C'est ce travail qui permet à l'organisation SRE de croître de façon sous-linéaire par rapport à la taille des services, et de les gérer plus efficacement qu'une équipe purement dev ou purement ops. Il y a même un enjeu de parole donnée : quand Google recrute de nouveaux SRE, on leur promet que ce n'est pas une organisation d'exploitation classique, en citant cette règle des 50 %. Laisser une équipe SRE dériver vers une pure équipe ops, ce serait trahir cette promesse.

Calculer le toil

Si l'on veut plafonner le toil à 50 %, encore faut-il savoir où passe ce temps. Il existe un plancher incompressible de toil dès lors qu'on est d'astreinte (on-call). Un SRE type assure une semaine d'astreinte primaire et une semaine d'astreinte secondaire par cycle. Dans une rotation à six personnes, cela représente au moins deux semaines sur six dédiées aux gardes et au traitement des interruptions — soit une borne basse de 2/6 ≈ 33 % du temps. Dans une rotation à huit personnes, la borne tombe à 2/8 = 25 %.

Plancher de toil selon la taille de la rotation d'astreinte
(2 semaines de garde par cycle : primaire + secondaire)

Rotation à 6 personnes :  2 / 6  ≈  33 %  ◄── borne basse du toil
Rotation à 8 personnes :  2 / 8  =   25 %  ◄── borne basse du toil

Plus la rotation est large, plus le plancher de toil est bas.

Les sondages confirment cette intuition : la première source de toil rapportée par les SRE, ce sont les interruptions (messages et courriels non urgents liés au service). Vient ensuite la réponse d'astreinte urgente, puis les livraisons et déploiements (releases and pushes) — qui, même fortement automatisés, gardent une marge d'amélioration. En moyenne, les enquêtes trimestrielles montrent un temps de toil d'environ 33 %, donc bien en deçà de la cible de 50 %. Mais la moyenne masque les cas extrêmes : certains SRE déclarent 0 % de toil (projets purs, sans astreinte), d'autres jusqu'à 80 %. Quand un SRE rapporte un toil excessif, c'est souvent le signal qu'un manager doit répartir la charge plus équitablement dans l'équipe et l'aider à trouver des projets d'ingénierie satisfaisants.

Le toil est-il toujours mauvais ?

Non — et c'est une nuance essentielle. Le toil ne rend pas tout le monde malheureux en permanence, surtout à petites doses. Les tâches prévisibles et répétitives peuvent être franchement apaisantes : elles procurent un sentiment d'accomplissement et de petites victoires rapides, et constituent des activités à faible risque et faible stress. Certaines personnes sont naturellement attirées par ce type de travail et y prennent même plaisir.

Le livre est donc explicite : une certaine dose de toil est inévitable dans le rôle de SRE, comme dans presque tout métier d'ingénierie. À petites doses, et si l'on s'en accommode, le toil n'est pas un problème. Il devient toxique en grandes quantités. Si vous croulez sous le toil, vous devez vous en inquiéter vivement et vous plaindre haut et fort. Parmi les nombreuses raisons pour lesquelles un excès de toil est néfaste, le livre en détaille plusieurs, qui touchent l'individu d'abord, puis l'organisation.

Dommage	Sur qui ?	Mécanisme
Stagnation de carrière (career stagnation)	L'individu	On ne fait pas carrière sur du travail ingrat ; trop peu de projets et la progression ralentit ou s'arrête.
Démoralisation (low morale)	L'individu	Chacun a sa limite de tolérance ; trop de toil mène au burn-out, à l'ennui, au mécontentement.
Crée de la confusion	L'organisation	Une équipe SRE qui croule sous le toil brouille le message : on cesse de comprendre que le SRE est une organisation d'ingénierie.
Ralentit le progrès	L'organisation	Une équipe trop occupée à éteindre des incendies déploie les nouvelles fonctionnalités plus lentement : la vélocité produit chute.
Crée un précédent	L'organisation	Trop de complaisance et les équipes dev seront incitées à déverser encore plus de tâches opérationnelles sur les SRE.
Favorise l'attrition (attrition)	L'organisation	Même si vous tolérez le toil, vos meilleurs coéquipiers, eux, iront chercher un poste plus gratifiant ailleurs.
Rompt la confiance	L'organisation	Les nouveaux venus recrutés sur la promesse de projets se sentent floués : mauvais pour le moral.

Inventer plus, peiner moins

La conclusion du chapitre tient en une formule mobilisatrice : « Inventons davantage, peinons moins » (« Let's invent more, and toil less »). Si chaque SRE s'engage à éliminer un peu de toil chaque semaine par un peu de bonne ingénierie, les services se nettoient progressivement, et l'effort collectif peut se déplacer vers ce qui compte vraiment : l'ingénierie de passage à l'échelle, l'architecture de la génération suivante de services, et la construction d'outils transverses à toute l'organisation SRE.

Le calcul économique sous-jacent est celui de l'automatisation. Tant qu'une tâche reste manuelle, son coût croît en O(n) avec le service ; bien automatisée et conçue, elle devient un coût ponctuel, en O(1), qu'une croissance d'un facteur dix n'affecte plus. C'est ce basculement de O(n) vers O(1) qui distingue une organisation d'ingénierie d'une organisation d'exploitation, et qui permet au SRE de tenir sa promesse fondatrice : gérer des systèmes toujours plus grands sans recruter proportionnellement plus de monde.

À retenir

• Le toil est le travail lié à l'exploitation d'un service qui est manuel, répétitif, automatisable, tactique, sans valeur durable et croissant en O(n) avec la taille du service — il ne se définit pas par le déplaisir qu'il procure.
• Le toil n'est ni la charge annexe (réunions, RH, snippets), ni le travail ingrat porteur de valeur durable : ces catégories ne comptent pas dans le plafond du toil.
• À l'opposé se trouve le travail d'ingénierie — nouveau, exigeant du jugement, durable, guidé par une stratégie — réparti en génie logiciel et génie des systèmes ; il fait croître l'organisation de façon sous-linéaire.
• La règle des 50 % est un plafond, pas une cible : au moins la moitié du temps de chaque SRE va à l'ingénierie, faute de quoi le toil s'étend jusqu'à 100 % et l'équipe dérive en équipe d'exploitation.
• L'astreinte impose un plancher de toil (≈ 33 % en rotation à six, 25 % à huit) ; les interruptions en sont la première source, devant la réponse urgente et les déploiements.
• Le toil n'est pas toujours mauvais : à petites doses, il est prévisible et apaisant. C'est l'excès qui devient toxique — stagnation de carrière, burn-out, confusion, ralentissement, précédent dangereux, attrition et rupture de confiance.
• Le remède est l'automatisation, qui fait passer le coût d'exploitation de O(n) à O(1) ; le mot d'ordre : « inventer davantage, peiner moins ».