Le renfort doit pouvoir réduire la charge opérationnelle
Supposons que vos développeurs interrompent régulièrement leur travail pour rétablir un service. Avant de choisir entre un recrutement en Site Reliability Engineering (SRE) et un développeur supplémentaire, nous vous proposons de préciser ce qui éviterait de répéter ces interventions. Un recrutement SRE peut convenir si vous devez confier la fiabilité d’un service à une personne capable de construire et d’entretenir des automatismes, avec les moyens d’agir. Si les changements nécessaires concernent surtout le code du produit, un renfort de développeurs peut être plus pertinent, à condition de lui réserver du temps pour ces corrections. Si vous ignorez encore quels changements réaliser ou qui pourra les mener, commencez par ce cadrage.
Dans son ouvrage consacré au SRE, Google explique que, sans effort continu de développement technique, la croissance de la charge opérationnelle appelle davantage de personnel. Cette observation décrit son approche de l’exploitation. Elle invite ici à distinguer deux besoins : absorber les interventions actuelles et réaliser les changements qui pourraient en réduire la répétition. Elle ne désigne pas, à elle seule, le poste à ouvrir.
Les interventions récurrentes rendent le besoin visible
Pour préparer votre décision, demandez aux personnes qui interviennent en production de consigner les tâches effectuées, leur fréquence et le temps mobilisé, en précisant la période observée. Ajoutez les interruptions du développement, la cause lorsqu’elle est connue et le changement envisagé. Une cause inconnue doit rester identifiée comme telle : elle appelle une investigation avant de décider d’une automatisation.
Google décrit le travail opérationnel répétitif, appelé « toil », comme un travail notamment manuel, répétitif et automatisable, qui n’apporte pas d’amélioration durable. Toute intervention ne réunit pas ces caractéristiques. Dans votre relevé, séparez donc le rétablissement immédiat du service du travail qui modifie durablement son fonctionnement. Le temps passé à intervenir indique une charge, mais ne suffit pas à expliquer comment la réduire.
Prenons un exemple hypothétique : une équipe relance régulièrement un traitement qui échoue. Automatiser la relance et corriger le défaut du traitement sont deux travaux différents. Demandez ce que chaque option supprimerait, quelles interventions resteraient nécessaires et qui pourrait entretenir la solution. Si la correction porte sur le code du produit, le besoin peut relever des développeurs qui connaissent ce code. Si vous identifiez un ensemble de travaux d’automatisation et de supervision sur un service, il peut être pertinent de confier explicitement la responsabilité de sa fiabilité.
Le Site Reliability Workbook de Google recommande de suivre les mesures de charge avant, pendant et après les efforts de réduction. Il invite aussi à comparer le temps gagné au temps nécessaire pour réaliser puis entretenir une solution automatisée. Utilisez cette comparaison pour choisir les travaux à engager, sans réduire la décision aux seules heures économisées : le même ouvrage précise qu’une automatisation peut provoquer une panne. Une solution partielle peut également convenir. Le résultat à rechercher doit donc être explicite, avec les risques et le travail humain qui subsistent.
Un recrutement consacré à la fiabilité exige des moyens d’action
Si votre diagnostic fait apparaître des travaux à mener pour améliorer durablement la fiabilité, décrivez le service concerné et ce que la personne devra pouvoir modifier. Les responsabilités SRE présentées par Google comprennent notamment la disponibilité, la supervision et la réponse aux incidents. Google cite aussi la création de scripts d’automatisation et d’outils parmi les activités de développement SRE. Ces descriptions permettent de préciser un mandat, sans présumer des compétences de chaque candidat.
Demandez au responsable technique de relier les travaux prioritaires aux moyens nécessaires : compétence de programmation, connaissance de la production, accès aux mesures et coopération des développeurs responsables du code. Faites préciser qui autorisera les changements et quel temps restera disponible pour les réaliser après les interventions courantes. Le Workbook souligne le rôle du soutien managérial pour protéger le travail de réduction de charge contre de nouvelles demandes.
Le mandat pourrait ainsi prévoir un automatisme maintenable pour une tâche identifiée et préciser comment vérifier son effet sur les interventions. Ce résultat attendu est une proposition de cadrage, pas une garantie attachée au titre SRE. Si la personne ne peut que répondre aux incidents, vous ajoutez une capacité d’intervention supplémentaire, sans avoir encore organisé le travail qui en réduirait la répétition.
La coopération avec les développeurs du produit doit également rester explicite. Dans le chapitre de Google consacré aux interventions SRE, les développeurs restent chargés d’un travail de correction et de prévention dans la conception et le code. Il propose un objectif de niveau de service mesuré et convenu pour guider les priorités communes. Avant le recrutement, faites définir le service et la mesure qui permettront de discuter des améliorations attendues.
Le renfort de développeurs doit permettre de consacrer du temps aux travaux de fiabilité
Si les changements prioritaires concernent le code applicatif, demandez ce qui empêche les développeurs actuels de les réaliser. Le renfort devient une option cohérente lorsque la capacité manquante est identifiée et que le responsable des priorités accepte de l’affecter aux corrections. Dans sa fiche « Développeur F/H », l’Apec inclut les corrections documentées et les tests réguliers parmi les activités du métier. Cette description précise les activités du métier, sans prouver les compétences d’exploitation d’une personne.
Avant de valider le poste, faites préciser quels changements seront confiés au renfort, qui en arbitrera la priorité et comment les corrections seront testées. Si toute la capacité supplémentaire est déjà affectée à de nouvelles fonctionnalités, ne comptez pas simultanément sur elle pour les travaux de fiabilité. Le choix porte autant sur l’allocation du temps que sur l’effectif.
Si vous souhaitez également confier l’exploitation aux développeurs du produit, examinez les appuis disponibles. Dans le modèle Distributed DevOps d’Amazon Web Services, les développeurs applicatifs assurent développement et exploitation de leurs applications, tandis qu’une équipe plateforme fournit notamment des outils de supervision, de sauvegarde et de restauration, ainsi que le réseau. Ce modèle décrit une organisation équipée pour cette répartition des responsabilités.
Amazon Web Services reconnaît par ailleurs que les équipes applicatives peuvent manquer de compétences d’architecture et d’exploitation cloud, et que l’accompagnement ne les rend pas nécessairement autonomes. Demandez donc qui apportera les compétences manquantes et comment vous vérifierez la capacité à exploiter le service. Si ces appuis ne sont pas disponibles, un recrutement de développeur ne suffit pas à rendre réaliste la prise en charge de l’exploitation par les développeurs du produit.
Le poste se cadre à partir du changement attendu
Avant d’ouvrir le poste, faites rédiger un mandat reliant le changement attendu, son responsable et les moyens accordés. Une responsabilité SRE se cadre autour des travaux de fiabilité identifiés et de la capacité à les mener avec les développeurs. Un renfort produit se cadre autour des corrections applicatives et du temps qui leur sera effectivement réservé. Ces choix peuvent nécessiter une coopération, plutôt qu’un transfert intégral de la production à une personne.
Nous vous proposons de suspendre le choix de l’intitulé tant que vous ne pouvez pas nommer le travail prioritaire ou lui attribuer les moyens nécessaires. La prochaine action est alors de documenter les interventions, d’établir leur cause ou d’arbitrer le temps disponible. Les pratiques citées aident à structurer cette décision, mais ne permettent pas de déterminer avec certitude quel recrutement améliorera la fiabilité dans votre organisation.
Sources
Amazon Web Services : Cloud operations and platform enablement (COPE)
