Comment le modèle DevOps impacte le télétravail (2/2)
Si le modèle DevOps a été bénéfique pour surmonter la crise sanitaire, il faut en adopter tous les préceptes pour éviter l’épuisement des collaborateurs IT. Il est toutefois intéressant pour les retardataires de la transformation numérique.
Dans le deuxième volet de ce dossier consacré aux impacts de la méthodologie DevOps sur le Télétravail, Beth Pariseau relate les difficultés et l’épuisement constaté par les développeurs des grands groupes.
Lors du confinement, les entreprises qui ont adopté le cloud ont plus facilement géré les ressources techniques que leurs ressources humaines. Les contraintes liées à l’isolement et aux frontières floues entre le travail et la vie privée ont eu des répercussions sur les performances des employés dans l’ensemble du secteur technologique et des DSI.
Dans une enquête menée en août auprès de plus de 9 000 professionnels, par le réseau professionnel en ligne anonyme TeamBlind, on demandait : « Le travail à domicile nuit-il à votre santé mentale ? ». 66 % des personnes interrogées ont répondu par l’affirmative. Les travailleurs ayant répondu « oui » provenaient majoritairement de grandes entreprises technologiques telles qu’Amazon, Microsoft et Google.
Même chez les géants de la technologie tels que le service de streaming vidéo Netflix, dont l’utilisation a explosé au cours du confinement, les effets de la crise sur le personnel IT se ressentent clairement.
Faire face à l’épuisement des collaborateurs
« Pour chacun d’entre nous, la notion du temps a été extrêmement comprimée », déclare J. Paul Reed, ingénieur senior en résilience appliquée chez Netflix, lors d’une présentation sur la réponse aux incidents provoqués par la COVID-19 lors d’un événement virtuel « SRE from Home » le 23 juillet. « Et c’est très douloureux. C’est douloureux sur le plan cognitif ».
Dans le cadre du modèle DevOps, de nombreuses entreprises transfèrent les tâches quotidiennes de gestion des applications aux développeurs et confient aux services informatiques le rôle d’ingénieur de fiabilité du site (SRE). Les SRE s’occupent de la réponse aux incidents informatiques et appliquent les leçons tirées des incidents pour rendre les systèmes informatiques plus fiables et plus efficaces dans leur ensemble.
Chez Netflix, les SRE ont traité la hausse du trafic provoquée par la pandémie comme un incident IT permanent. Pour que la situation reste gérable, l’équipe SRE a défini clairement les rôles des différentes équipes IT concernées, ainsi que des critères de sortie spécifiques pour clore l’incident.
« Nous avons très vite compris que ce n’était pas un problème qui durerait deux ou trois semaines », indique Tim Heckman, senior SRE chez Netflix. « C’était un incident, mais ce n’était pas le branle-bas de combat, et nous n’avons pas eu quelqu’un dans le canal Slack 24 heures sur 24, 7 jours sur 7, pour réagir aux événements. La plupart du temps, nous observions et essayions de prédire comment le système change autour de nous ».
L’équipe a également dû ajuster les paramètres de surveillance du système qu’elle utilisait pour comprendre quand ce type d’incident de longue durée se résorbait.
« Nous ne nous sommes pas dit qu’il dit qu’il fallait surveiller certaines métriques quand elles atteignaient un seuil », affirme J. Paul Reed. « Nous avons pris la dérivée de certaines métriques afin de voir si ces courbes continuaient de rebondir ou si les changements effectués stabilisaient ces trajectoires ».
« Nous avons constaté que… les systèmes peuvent avoir besoin de s’adapter, et nous pouvons avoir besoin de faire des changements pour répondre à une nouvelle demande mondiale, [mais] c’est très différent de la façon dont nos collègues, les gens que nous aimons et avec qui nous travaillons, peuvent être touchés par cela », considère Tim Heckman.
Tim HeckmanSenior SRE, Netflix
« Ainsi, le rôle de l’équipe SRE n’était pas seulement de surveiller les systèmes et de renforcer leur fiabilité, mais aussi de gérer les communications avec les autres employés », ajoute-t-il. « Non seulement pour qu’ils soient au courant de ce que nous pensons, suggérons et vers quoi nous nous dirigeons, mais aussi pour leur donner une certaine confiance dans le fait que l’encadrement est bienveillant ».
Les SRE, parfois garants des relations humaines
Des principes similaires doivent être appliqués pour gérer l’impact humain d’un passage à plus long terme au télétravail, selon Jaime Woo, co-fondateur d’Incident Labs, une société de formation et de conseil SRE, dans une présentation séparée lors de l’événement SRE from Home.
« En ce qui concerne les ressources techniques et humaines, les entreprises doivent utiliser des techniques de surveillance pour anticiper les problèmes, et se concentrer sur les facteurs organisationnels changeants à l’échelle du système qui améliorent la résilience », estime-t-il.
Jaime Woo a même établi une recette pour le stress. Il s’agit alors de mesurer la nouveauté, l’imprévisibilité d’une situation, l’ego d’une personne et le possible manque de contrôle résultant de cette situation, afin de comprendre ce niveau de stress.
Pour d’autres, comme Holly Hallen, responsable SRE chez Slack, il faut impérativement établir et maintenir des limites claires concernant le temps de travail lorsque les employés jonglent avec de nouveaux horaires et engagements en télétravail.
Le modèle DevOps pour les retardataires de la transformation numérique
Les témoignages ci-dessus reflètent la réalité pour des entreprises qui ont déjà effectué leur transformation numérique. Les organisations moins avancées ont encore eu plus de mal à gérer cette crise.
« Nous n’en sommes qu’au tout début », affirme Milan May'r, ingénieur logiciel dans une entreprise du Fortune 500 dont il a demandé à taire le nom. « En ce moment, deux d’entre nous créent sur leur temps libre des métriques de temps de fonctionnement pour un site web interne. Il semble que personne ne puisse même mesurer le temps de fonctionnement total pour un portail vital ».
Au lieu de cela, Milan May’r déclare dans une interview séparée que les professionnels des opérations IT de son entreprise se concentrent sur des tâches traditionnelles, telles que la réponse à des incidents individuels, plutôt que sur l’amélioration de la résilience du système. La difficulté à faire collaborer les gens à distance en restant connecté via des applications de chat et en allumant des caméras pour les vidéoconférences a encore compliqué les choses, selon lui.
« Les entreprises qui n’ont pas totalement adopté la méthodologie DevOps sont maintenant prises dans un cercle vicieux », estime Sanjeev Sharma, co-fondateur et analyste principal chez Accelerated Strategies Group.
« Les entreprises réalisent qu’elles doivent accélérer leur transformation, mais la plupart des équipes opérationnelles ont été trop accaparées par le passage au télétravail pour prendre du recul et mettre en œuvre des changements dans les processus de travail », ajoute-t-il.
Sanjeev SharmaAnalyste principal, Accelerated Strategies Group
Sanjeev Sharma recommande à ses clients d’assigner une petite équipe aux tâches de transformation, tandis que le reste du personnel s’occupe du dépannage au quotidien. « C’est plus facile à faire qu’à dire dans un contexte de crise et de pénurie de compétences, mais ce n’est pas impossible », admet-il.
La plupart des entreprises connaissent les principes DevOps qui représentent un changement radical, comme les mises à jour fréquentes des applications et le déploiement à grande vitesse, connu dans les cercles de DevOps et de Lean manufacturing sous le nom de kaikaku.
Mais les organisations qui démarrent leur transition numérique peuvent également se tourner vers un concept moins accentué de changement progressif, ou kaizen, selon Dawn Parzych, developer advocate chez LaunchDarkly, lors de l’événement SRE from Home. Elle rappelle les grands principes de la méthodologie DevOps qui repose sur trois principes : le flux, qui consiste à établir des processus de travail stable et prévisible, les retours d’expérience et l’apprentissage continu. « Le DevOps est fondé sur les trois voies du flux, du feed-back et de l’apprentissage […]. Vous voulez un retour d’information en cycles courts et amplifiés, et puis vous prenez ce feed-back et l’intégrez [dans vos processus] ».