Aller au contenu

Toil management

Identifier, mesurer et éliminer le toil pour récupérer du temps d'engineering a valeur ajoutee.


Définition du toil selon le SRE Book

Le toil (Google SRE Book) désigne le travail opérationnel qui présente toutes les caractéristiques suivantes :

Caractéristique Description
Manuel Nécessité une intervention humaine directe
Repetitif Se répété de manière recurrente, identique ou quasi-identique
Automatisable Pourrait être exécuté par une machine
Sans valeur durable Ne laisse pas de valeur permanente une fois la tâche accomplie
Scale lineaire Augmente proportionnellement au volume du système
Reactif Déclenché par une interruption externe, pas planifie

Une tâche qui n'a qu'une ou deux de ces caractéristiques n'est pas necessairement du toil. C'est la combinaison qui définit le problème.


Identifier le toil

Exemples concrets

Catégorie Exemples de toil
Redémarrage de services Restart manuel d'un service qui crashe régulièrement
Dimensionnement Augmenter manuellement la taille d'une instance ou d'un volume
Provisioning de tickets Créer les mêmes ressources à la demande sans self-service
Rotation de certificats Renouveler manuellement des certs TLS a date fixe
Nettoyage Purger des logs ou des données temporaires a intervalles fixes
Validation manuelle Approuver des déploiements sans vérification automatique

Arbre de décision

graph TD
    A["Cette tache est-elle manuelle ?"] -->|Non| Z["Pas du toil"]
    A -->|Oui| B["Se repete-t-elle regulierement ?"]
    B -->|Non| Z
    B -->|Oui| C["Pourrait-elle etre automatisee ?"]
    C -->|Non| Z
    C -->|Oui| D["Laisse-t-elle une valeur durable ?"]
    D -->|Oui| Z
    D -->|Non| E["TOIL — a eliminer"]

Le toil est insidieux — trackez-le ou il absorbe tout

Sans mesure explicite, le toil peut occuper 80-100% du temps d'une équipe ops. Personne ne le remarque car chaque tâche prise individuellement "ne prend que 10 minutes".


Mesurer le toil

Méthodes de mesure

  • Time tracking hebdomadaire : chaque membre categorise ses activités en toil / engineering / projets
  • Tagging des tickets : labelliser les tickets JIRA/GitLab avec toil pour compter automatiquement
  • Revue d'astreinte : analyser le journal on-call pour identifier les interventions repetitives

Tableau de suivi

Tâche Fréquence Durée unitaire Durée mensuelle Priorité élimination
Restart service X 3x/semaine 15 min 3h Haute
Provisioning compte 10x/mois 20 min 3h20 Haute
Rotation certs 1x/mois 45 min 45 min Moyenne
Nettoyage logs 1x/semaine 10 min 40 min Basse

Le budget 50% engineering

Le SRE Book etablit une règle fondamentale : les SRE ne doivent pas consacrer plus de 50% de leur temps au toil. L'autre moitie doit aller a des projets d'engineering qui améliorent les systèmes de façon durable.

Pourquoi ce seuil

  • Au-dessus de 50%, l'équipe n'a plus le temps de réduire la dette opérationnelle
  • Le toil croit avec le système : sans investissement continu, il dépassé toujours la capacité
  • Les ingénieurs qui ne font que du toil se demotivent et quittent l'équipe

Si le seuil est dépassé

  • Escalader aupres du management avec les chiffres (pas des impressions)
  • Negocier un "toil sprint" pour automatiser les 3-5 tâches les plus coutieuses
  • Envisager une réduction temporaire de périmètre si les ressources ne suivent pas

Éliminer le toil

Priorisation : fréquence x temps x risque

Calculer un score de priorité pour chaque tâche de toil :

Score = frequence_mensuelle × duree_unitaire_heures × facteur_risque

Le facteur risque est 1 (faible), 2 (moyen) ou 3 (critique selon impact incident).

Avant / après : exemples d'élimination

Toil Solution Gain
Restart service X Liveness probe + self-healing K8s 3h/mois eliminées
Provisioning compte Self-service portal (Backstage, ServiceNow) 3h20/mois + satisfaction utilisateur
Rotation certs cert-manager (Let's Encrypt auto) 45 min/mois + risque expiration eliminé
Nettoyage logs Politique de rétention automatique 40 min/mois eliminées

Éliminer le toil = investissement, pas optimisation prematuree

Automatiser une tâche qui prend 10 minutes par semaine peut sembler anecdotique. Mais multiplier par 5 membres d'équipe, 50 semaines et 10 tâches similaires, et on arrive à des centaines d'heures recupportees vers l'engineering.