L'interruption mondiale des principaux services de Facebook Inc. - notamment WhatsApp, Messenger, Instagram et Facebook - lundi a impacté plusieurs travailleurs et peut-être même le rendement des développeurs. Haystack a publié mardi un rapport dans lequel il déclare avoir constaté que la panne mondiale de Facebook avait poussé les développeurs à être 32 % plus productifs. Cette augmentation ne concerne toutefois pas le développement de nouvelles fonctionnalités, mais plutôt la validation des demandes de fusion. Le rapport relance le débat sur les pertes de temps que les réseaux sociaux peuvent causer aux équipes d'ingénieurs.Haystack analyse les données git historiques pour vous donner une idée claire (et précise) de la santé de vos équipes. Lundi, l'équipe Haystack a analysé les données à sa disposition pour voir quel impact la panne mondiale de Facebook avait sur la productivité des développeurs (nombre de Pull Requests fusionnées) et a consigné ses résultats dans un rapport. Pour rappel, la panne fait suite à la disparition subite de préfixes de routage de tables BGP (Border Gateway Protocol). Le protocole BGP fait fonctionner Internet et permet aux appareils d'un côté du monde d'atteindre les appareils de l'autre côté en utilisant des préfixes ou « routes ».
Comme le registre de domaine et les serveurs DNS de Facebook sont hébergés sur le propre préfixe de routage de la firme, lorsque les préfixes BGP ont été supprimés des tables de routage, personne ne pouvait se connecter à leurs adresses IP ou aux services dépendants d'elles. « Dans ce cas, l'Internet ne sait plus où retrouver les adresses IP de Facebook. Un symptôme est que les requêtes DNS échouent. Cependant, c'est juste le résultat de l'hébergement par Facebook de ses serveurs DNS à l'intérieur de son propre réseau », explique Johannes Ulrich du SANS Technology Institute. Haystack relate les faits suivants dans son rapport.
Chronologie
Selon DownDetector, un site Web qui présente en temps réel les problèmes et les pannes pour toutes sortes de services en ligne, la panne des services de Facebook a commencé à 15:24 UTC (soit 17:24 en France). À 22:46 UTC (00:46 en France), le directeur technique de Facebook a indiqué sur Twitter que les services étaient de nouveau en ligne, mais que cela pouvait prendre un certain temps pour atteindre 100 %. L'incident a été en grande partie résolu dans la nuit profonde. Tout au long de la journée, l'équipe Haystack a constaté que le rendement des développeurs a continué à suivre la ligne de base (voir l'image).
Cependant, elle a déclaré que cela a changé de manière significative après 21:00 UTC (23:00 en France). Selon l'équipe, bien qu'il soit tout à fait habituel de voir une augmentation du rendement à cette heure le lundi, la croissance a été beaucoup plus importante que d'habitude. Entre 21:00 UTC et minuit (23:00 et 02:00 en France), elle a constaté une augmentation d'environ 2,6 fois le nombre de demandes de mise à jour en cours de fusion. Pour situer le contexte, minuit UTC correspond à 17h, heure du Pacifique (où se trouvent de nombreux clients de Haystack).
Causes
Alors que la productivité des développeurs a augmenté, Haystack a constaté que le délai d'exécution (délai entre le premier commit et la fusion du Pull Requests) a augmenté de façon spectaculaire pour ces demandes de fusion. Cela indique que la véritable raison de cette augmentation est plutôt que les développeurs ont utilisé le temps supplémentaire à la fin de leur journée pour faire le ménage dans les anciennes demandes de fusion, en fermant les anciennes demandes de fusion en cours depuis longtemps.
En fait, Haystack, en tant que produit, offre aux équipes de développement des alertes sur les demandes de fusion en cours (comme celles qui ont déjà été examinées et qui attendent d'être fusionnées). Plutôt que de constater une augmentation spectaculaire de la productivité de la programmation, elle a vu les développeurs s'occuper de leurs tâches ménagères. « La panne de Facebook a poussé les développeurs à nettoyer leur jardin », explique le directeur technique Kan Yilmaz.
Cela ne justifie pas une microgestion
« En tant qu'outil d'analyse des développeurs, Haystack veille à ne pas favoriser la microgestion. Contrairement à nos concurrents, nous ne comparons pas les ingénieurs », a déclaré Haystack. « Les recherches menées sur les équipes d'ingénierie logicielle n'ont cessé de montrer que la microgestion nuit à l'efficacité de l'équipe et que la sécurité psychologique est essentielle pour améliorer la productivité, traiter la fiabilité des logiciels et prévenir l'épuisement professionnel », a ajouté l'équipe.
Selon elle, le fait qu'elle n'a pas constaté de baisse substantielle de la productivité pendant l'intervalle où l'incident a fait l'objet d'un discours sur d'autres plateformes de médias sociaux montre que les développeurs sont moins enclins à être distraits de leur travail productif que l'on peut le penser. En outre, elle estime que la clef pour encourager la productivité soutenue des développeurs réside dans la création d'une expérience de développement axée sur le flux, où le processus manuel est remplacé par l'automatisation et les outils.
« Lorsque les développeurs sont libérés des processus inefficaces - de la bureaucratie et de la dette technique - le travail peut circuler rapidement sans compromettre la fiabilité ni provoquer d'épuisement. C'est pourquoi de plus en plus d'organisations technologiques mettent en place des équipes EngProd pour se concentrer sur la suppression de ces obstacles », a conclu l'équipe.
EngProd est la façon dont les équipes d'ingénierie logicielle d'élite fournissent des logiciels fiables en fonction des résultats commerciaux tout en assurant le bien-être de l'équipe. Les entreprises comme Google ont des équipes de productivité des ingénieurs (EngProd), et d'autres entreprises comme Netflix les appellent des équipes de productivité des développeurs (Developer Productivity - DevProd).
Source : Haystack
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi
83 % des développeurs de logiciels souffrent d'épuisement professionnel, selon une étude de Haystack Analytics Facebook dévoile les raisons de la récente panne de six heures sur ses services WhatsApp, Instagram et Messenger : l'entreprise pointe des changements de configurations de routeurs du doigt Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ? Retour de discussion avec un Microsoft User Group La perte de temps sur des tâches qui n'apportent pas de valeur est une préoccupation majeure pour 56 % des responsables du développement, selon une nouvelle étude de Tempo 
Envoyé par sergio_is_back
