Principes et pratiques majeurs de l’ingénierie de fiabilité de site : L’aspect humain de l’ingénierie de fiabilité de site
Un processus opérationnel réussi permet d’atteindre et de maintenir la fiabilité souhaitée. Un tel processus dépend autant de la façon dont il traite les personnes responsables de cet environnement que de la façon dont il traite les machines. L’ingénierie de fiabilité de site reconnaît cette réalité de plusieurs manières qui sont essentielles à son application pratique.
Labeur
La première met l’accent sur la notion de « labeur ». Dans un contexte d’ingénierie de fiabilité de site, le labeur fait référence au travail d’opérations effectué par une personne disposant de certaines caractéristiques. Il n’a pas de valeur à long terme. Cela ne fait pas progresser le service de manière significative. Il est souvent répétitif et en grande partie manuel (même s’il peut être automatisé). À mesure que le service ou les systèmes prendront de l’ampleur, le nombre de demandes pour ce système augmentera probablement également en quantité à un rythme proportionnel et nécessitera encore plus de travail manuel.
Par exemple, un service peut exiger que l’équipe SRE endosse des charges opérationnelles comme celles-ci qui sont considérées comme un labeur :
- Réinitialisation de quelque chose chaque semaine.
- Provisionnement manuel de nouveaux comptes et de l’espace disque.
- Redémarrage à plusieurs reprises d’un processus manuellement.
L’exécution de ces actions n’améliore pas le service de façon durable. Il est également probable que ces actions doivent être répétées encore et encore.
Notes
Même si vous conservez les requêtes de cette nature dans une sorte de système de tickets (comme le font de nombreuses organisations), l’exécution de l’action et la résolution d’un ticket constituent toujours un labeur. Simplement un labeur avec un bon suivi.
Les SRE détestent le labeur. Ils travaillent à l’éliminer chaque fois que cela est possible et approprié. C’est l’un des objectifs de l’ingénierie de fiabilité de site où l’automatisation intervient. Si ces requêtes peuvent être gérées automatiquement, l’équipe est libre de travailler sur des choses plus gratifiantes et importantes que vider la file d’attente des requêtes.
L’utilisation du mot « approprié » en ce qui concerne le labeur est similaire à son utilisation en matière de fiabilité. Il existe des cas où le travail d’élimination du labeur est moins prioritaire que d’autres travaux. Mais généralement, la suppression du labeur d’un service est une priorité clé pour un ingénieur de fiabilité de site.
Travail de projet et travail « d’opérations » réactif
Pour effectuer le travail nécessaire à la suppression du labeur ou à l’amélioration de la fiabilité d’un système, le temps d’un ingénieur de fiabilité de site doit être alloué de manière appropriée. Il ne doit pas en consacrer l’intégralité à éteindre des incendies, à répondre à des pages ou à traiter une file d’attente de tickets. Il doit disposer du temps nécessaire pour écrire du code afin d’éliminer le labeur, créer une automatisation en libre-service afin que les tickets ne soient pas nécessaires, et générer des projets qui rendent le service et les personnes plus efficaces. Le chiffre généralement cité (tiré du modèle Google d’origine) est que la charge opérationnelle sur une équipe ne doit pas dépasser 50 %.
Notes
50 % est un chiffre quelque peu arbitraire, mais dans la pratique il semble fonctionner comme objectif raisonnable pour de nombreuses personnes.
Il y a des périodes dans la vie d’un ingénieur de fiabilité de site où tout son temps est consacré à éteindre les incendies, mais cela ne doit pas être un état stable. Si le travail « d’opérations » réactif d’une équipe (pour la plupart du labeur) occupe plus de 50 % de son temps pendant une période prolongée, vous courez droit vers le burnout et une fiabilité médiocre. Dans cette situation, les cycles vertueux évoqués précédemment ne peuvent pas fonctionner ni être créés. De même, l’ingénierie de fiabilité de site prête attention au mauvais équilibrage de la charge d’astreinte, car le potentiel d’un fort impact négatif sur l’équipe est réel.
Maintenant que nous avons eu l’occasion de voir certains des principes et pratiques majeurs de l’ingénierie de fiabilité de site, voyons un peu comment démarrer.