Comment nous avons modifié l'état Toujours connecté pour éviter l'épuisement professionnel

La traduction de l'article a été préparée spécifiquement pour les étudiants du cours "Pratiques et outils DevOps".

Comment nous avons modifié l'état Toujours connecté pour éviter l'épuisement professionnel

La mission d'Intercom est de personnaliser les affaires en ligne. Mais on ne peut pas personnaliser un produit quand il ne fonctionne pas. comme il se doit. La performance est essentielle au succès de notre entreprise, non seulement parce que nos clients nous paient, mais aussi parce que nous utilisons nous-mêmes avec votre produit. Si notre service ne fonctionne pas, nous ressentons littéralement la douleur de nos clients.

Le bon fonctionnement dépend de nombreux facteurs, tels que l'architecture logicielle et la qualité du travail quotidien. Cependant, bien souvent, tout se résume au fait que la personne qui est toujours en contact répond aux appels de PagerDuty. Ce type de support technique peut constituer un outil puissant centré sur le client, combinant l’aide d’ingénieurs avec ce que les clients obtiennent lorsqu’ils achètent votre produit. C’est également une excellente opportunité d’apprentissage et de croissance, car après tout, les échecs et les erreurs peuvent être une bonne occasion de mettre en pratique des compétences et de comprendre des mécanismes de travail complexes.

Être « toujours actif » en dehors des heures de travail a un effet néfaste sur votre vie.

Mais en même temps, être « toujours connecté » peut avoir un effet néfaste sur votre vie. Vous devez être prêt à répondre rapidement et de manière compétente à une alerte indiquant que quelque chose est cassé. Même si vous n'êtes pas bipé à un moment donné, être « toujours connecté » peut créer de l'anxiété, comme je le sais par expérience personnelle. De ce fait, la qualité du sommeil se détériore particulièrement fortement. Être régulièrement dans la zone d'accès à tout moment de la journée peut conduire à l'épuisement professionnel, à l'apathie ou, en général, à l'envie de ne plus jamais revoir l'ordinateur.

Histoire de l’état « toujours connecté » dans Intercom

Au tout début d'Intercom, notre directeur technique, Ciaran, fournissait à lui seul toute une équipe d'assistance technique XNUMXh/XNUMX et XNUMXj/XNUMX, tant au bureau qu'à l'extérieur. Au fur et à mesure du développement d'Intercom, un groupe de travail a été créé pour aider Ciaran. Peu de temps après, de nouvelles équipes de développement ont commencé à créer de nombreuses nouvelles fonctionnalités et services et ont assumé toutes les responsabilités de support technique.

Il y avait trop de personnes « de garde » à un moment donné.

À l'époque, cette approche semblait évidente car c'était un moyen simple de faire évoluer notre équipe de support technique à tout moment, elle correspondait à nos valeurs et convenait à nos besoins. sentiment d'appartenance. Au final, sans aucun projet, nous nous sommes retrouvés avec quatre ou cinq équipes qui contactaient régulièrement les clients en dehors des heures de travail. Le reste des équipes de développement n'avaient pas beaucoup de problèmes complexes susceptibles de générer une erreur, elles étaient donc rarement, voire jamais, appelées.

Nous avons réalisé que nous étions dans une situation où nous avions des mécanismes de support technique dont nous ne pouvions pas être fiers, et un certain nombre de problèmes critiques que nous voulions résoudre, tels que :

  • Il y avait trop de gens prêts à relever le défi à un moment donné. Notre infrastructure n'était pas suffisamment grande pour nécessiter un minimum de cinq ingénieurs de développement travaillant sans jours de congé réguliers.
  • La qualité de nos alarmes et procédures d'appel n'était pas cohérente dans toutes les équipes, et nous avons utilisé des processus ad hoc pour examiner les alertes de problèmes nouvelles et existantes. Les instructions du runbook (à suivre en cas de notification d'un problème) brillaient pour la plupart par leur absence.
  • Selon l’équipe dans laquelle travaillaient les ingénieurs, ils avaient des attentes contradictoires. Par exemple, seule la toute première équipe d’assistance technique a bénéficié d’une compensation pour les gardes et les week-ends perturbés.
  • Il semble y avoir un niveau général de tolérance à l'égard des appels inutiles à des heures indues.
  • Enfin, ce type de travail ne convient pas à tout le monde. Les circonstances de la vie montraient parfois que les changements de service n'avaient pas le meilleur effet sur les gens.

Trouver le bon état « toujours activé »

Nous avons décidé de créer une nouvelle équipe virtuelle qui effectuerait un travail de support technique pour chaque équipe en dehors des heures de travail. L'équipe sera composée de bénévoles et non de conscrits d'une quelconque équipe de l'organisation. Les ingénieurs de l’équipe virtuelle changeaient environ tous les six mois, passant des semaines « de garde ». Heureusement, nous n’avons eu aucun problème à trouver suffisamment de bénévoles pour constituer une équipe virtuelle.

En conséquence, notre équipe d’assistance a été réduite de 30 personnes à seulement 6 ou 7 personnes.

L'équipe a ensuite convenu et défini à quoi devraient ressembler les alertes et les descriptions de problème dans le runbook, et a décrit un processus de transfert des alertes à la nouvelle équipe d'assistance. Ils ont défini toutes les alertes dans le code à l'aide d'un module Terraform et ont commencé à utiliser l'examen par les pairs pour chaque modification. Nous avons introduit un niveau de rémunération pour un quart de travail hebdomadaire tout à fait satisfaisant pour les agents de service. Nous avons également créé une équipe de deuxième niveau composée uniquement de managers. Cette équipe doit être le point de contact unique pour les ingénieurs du support technique.

Nous avons eu plusieurs mois de travail acharné pendant lesquels nous avons mis en place ce processus, de sorte qu'il n'y avait plus 30 ingénieurs d'astreinte comme avant, mais seulement 6 ou 7. Pendant les heures de travail, les équipes gèrent de manière autonome les problèmes liés à leurs fonctions ou services, c'est à ce moment-là que surviennent généralement le plus grand nombre de pannes, mais à tout autre moment, l'assistance technique est assurée par des bénévoles.

Ce que nous avons appris

Après avoir lancé notre équipe d'assistance technique virtuelle, nous nous attendions à un afflux de nouvelles tâches, comme enquêter sur les causes des problèmes ou se réunir pour résoudre un seul problème provoquant une panne. Cependant, nos équipes de développement ont assumé l’entière responsabilité des facteurs à l’origine des échecs, et toute réponse ultérieure a été généralement immédiate. Nous devions également éviter qu'une tâche de consultation technique soit renvoyée à l'équipe d'où elle émanait, afin de ne pas obliger les ingénieurs à nous contacter en dehors des heures d'ouverture.

Le nombre d'appels en dehors des heures normales est tombé à moins de 10 par mois.

Notre processus de remontée d'informations était rarement utilisé de manière formelle. Une croyance plus répandue était que l'ingénieur avait été officieusement aidé par l'équipe qui était actuellement en ligne, en particulier par nos gars du bureau de San Francisco. De nombreux problèmes ont été éliminés ou réduits grâce au travail d’équipe et à leur résolution à la volée.

Les ingénieurs de notre bureau de San Francisco ont rejoint l'équipe à temps plein et sont allés au-delà du support technique classique. Nous avons été confrontés à certains frais généraux, mais la répartition de la composition de notre équipe d'assistance dans plusieurs bureaux a été à notre avantage car cela s'est avéré être un bon moyen de nouer des relations, de les renforcer et d'en apprendre davantage sur la pile technologique avec laquelle nous travaillons tous.

Le travail des développeurs Intercom est devenu plus cohérent dans nos équipes, et nous pouvons parler en toute confiance des avantages d'être ingénieur système sur notre site Carrières, déclarant qu'il n'est pas nécessaire d'être toujours connecté à moins que vous ne le souhaitiez.

Parallèlement au travail fondamental visant à stabiliser et à faire évoluer nos magasins de données, l'accent continu mis sur la résolution de problèmes a permis de réduire le nombre d'appels en dehors des heures d'ouverture à moins de 10 par mois. Nous sommes très fiers de ce numéro.

Nous continuons à travailler au maintien et à l'amélioration de notre équipe de support technique, et à mesure qu'Intercom se développe, nous devrons peut-être reconsidérer nos décisions, car ce qui fonctionne aujourd'hui ne fonctionnera pas nécessairement la prochaine fois que notre personnel doublera. Cependant, cette expérience a été extrêmement positive pour notre organisation et a grandement amélioré la qualité de vie de nos ingénieurs de développement, la qualité de nos réponses aux appels et surtout, l'expérience de nos clients.

Source: habr.com

Ajouter un commentaire