Comment nous avons changé l'état de «toujours en contact» pour éviter l'épuisement professionnel

La traduction de l'article a été préparée spécialement pour les étudiants du cours "DevOps Practices and Tools" .




La mission d'Intercom est de personnaliser le commerce en ligne. Mais la personnalisation d'un produit n'est pas possible lorsqu'il ne fonctionne pas comme il se doit . L'efficacité 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 notre produit . Si notre service ne fonctionne pas, nous ressentons littéralement la douleur de nos clients.

La disponibilité 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 qu'une personne toujours en contact répond aux appels de PagerDuty . Un tel support technique peut être un puissant outil orienté client qui combine l'assistance d'ingénieurs avec ce que les clients reçoivent lorsqu'ils achètent votre produit. Il offre également une excellente occasion d'apprentissage et de croissance, car en fin de compte, les échecs et les erreurs peuvent être un bon domaine pour développer des compétences et comprendre les mécanismes complexes du travail.

Rester «toujours en contact» en dehors des heures de travail est préjudiciable à votre vie.

Mais en même temps, l'état de «toujours en contact» peut avoir un effet néfaste sur votre vie. Vous devez être prêt à répondre rapidement et avec compétence à une alerte indiquant que quelque chose est cassé. Même si vous n'êtes pas appelé par un téléavertisseur à ce moment particulier, l'état de «toujours en contact» instille un sentiment d'anxiété, je le sais moi-même par expérience personnelle. Surtout à cause de cela, la qualité du sommeil se détériore. Un séjour régulier dans la zone d'accès à tout moment de la journée peut conduire à l'épuisement professionnel, à l'apathie, ou en général au désir de ne plus jamais revoir un ordinateur.

Historique de l'état de l'interphone sur Intercom


Dans les tous premiers jours d'Intercom, notre directeur technique Kiaran était à lui seul toute une équipe d'assistance technique 24h / 24, au bureau comme à l'extérieur. Au fur et à mesure que Intercom grandissait, un groupe de travail a été mis en place 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 elles ont déjà assumé toutes les responsabilités de support technique.

À tout moment, il y avait trop de gens «en contact».

À cette époque, cette approche semblait être tenue pour acquise, car c'était un moyen facile de faire évoluer l'équipe d'assistance technique à tout moment, elle répondait à nos valeurs et entretenait notre sentiment d'appartenance . En conséquence, sans aucun plan, nous avons eu quatre ou cinq équipes qui ont régulièrement contacté les clients pendant leurs heures de fermeture. Le reste des équipes de développement n'a pas eu beaucoup de moments difficiles qui pourraient générer une erreur, ils ont donc été rarement, voire jamais, appelés.

Nous avons réalisé que nous étions dans une situation où nous avons la mécanique du support technique, dont nous ne pouvons pas être fiers, et un certain nombre de problèmes critiques que nous voulions éliminer, tels que:

  • Trop de gens étaient prêts à accepter le défi à tout moment. Notre infrastructure n'était pas si grande qu'elle nécessitait un minimum de cinq ingénieurs de développement qui travailleraient sans un week-end normal.
  • La qualité de nos alarmes et de nos procédures d'appel n'a pas été coordonnée entre les équipes; nous avons utilisé des processus spéciaux pour examiner les alertes nouvelles et existantes sur les problèmes. Les instructions contenues dans le runbook (qui doivent être suivies lors de la réception d'une notification concernant un problème) étaient pour la plupart frappantes en leur absence.
  • Selon l'équipe dans laquelle les ingénieurs travaillaient, leurs attentes étaient contradictoires. Par exemple, seule la toute première équipe de support technique a été indemnisée pour les quarts de travail et les week-ends interrompus.
  • Il s'est avéré qu'il existe un niveau général de tolérance pour les appels inutiles à des moments inopportuns.
  • Enfin, ce type de travail ne convient pas à tout le monde. Les circonstances de la vie ont parfois montré que les changements de service n'affectent pas les gens de la meilleure façon.


Recherchez l'état correct de «toujours en contact»


Nous avons décidé de créer une nouvelle équipe virtuelle qui fera le travail de support technique pour chaque équipe en cas de non-travail. L'équipe sera composée de bénévoles et non de rédacteurs d'une équipe de l'organisation. Les ingénieurs d'une équipe virtuelle changent tous les six mois environ, passant des semaines «en contact». 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 est passée de 30 personnes à seulement 6 ou 7.

Cette équipe a ensuite convenu et déterminé à quoi devraient ressembler les alertes et descriptions de problèmes dans le runbook, et a décrit le processus de transmission des alertes à une nouvelle équipe de support. Ils ont identifié toutes les alertes dans le code à l'aide du module Terraform et ont commencé à utiliser le jugement d'experts pour chaque changement. Nous avons introduit un niveau d'indemnisation pour le quart de travail hebdomadaire, qui convenait parfaitement aux personnes en service. Nous avons également créé une équipe de deuxième niveau renforcée, composée uniquement de gestionnaires. Cette équipe devrait être le seul point d'escalade pour les ingénieurs du support technique.

Nous avons eu plusieurs mois de dur labeur, au cours desquels nous avons entamé ce processus, en conséquence, maintenant pas 30 ingénieurs comme auparavant, mais seulement 6 ou 7 sont restés en contact. Pendant les heures de travail, les équipes traitent indépendamment les problèmes avec leurs fonctions ou services, sur ce temps représente généralement le plus grand nombre de pannes, cependant, le reste du temps, les volontaires sont engagés dans le support technique.

Qu'avons-nous 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 un rassemblement général pour résoudre tout problème à l'origine de l'échec. Cependant, nos équipes de développement ont assumé l'entière responsabilité des facteurs à l'origine des défaillances, et toute réaction ultérieure était généralement une action immédiate. Nous devions également éviter une situation dans laquelle la tâche de conseil technique serait renvoyée à l'équipe d'où il venait, afin de ne pas forcer les ingénieurs à entrer en contact après les heures.

Les appels hors bureau sont passés à moins de 10 par mois.

Formellement, notre processus d'escalade a été rarement utilisé. L'opinion la plus courante était que l'ingénieur, qui est actuellement en ligne, aide l'ingénieur de manière informelle, en particulier pour nos gars du bureau de San Francisco. De nombreux problèmes ont été résolus ou leur nombre a été réduit 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 dans son ensemble et sont allés au-delà du support technique habituel. Nous avons été confrontés à une question concernant certains frais généraux, mais l'extension de la composition de notre équipe d'assistance à plusieurs bureaux a joué entre nos mains, car cela s'est avéré être un bon moyen de nouer des relations, de les renforcer et d'en savoir plus sur la pile technologique avec laquelle nous travaillons tous.

Dans nos équipes, le travail des développeurs d'Intercom est devenu plus cohérent, et nous pouvons parler en toute confiance des avantages d'un poste d'ingénieur système sur notre site Carrières , déclarant qu'il n'est pas nécessaire d'être toujours en contact si vous ne le souhaitez pas vous-même.

Parallèlement au travail fondamental de stabilisation et de mise à l'échelle de nos entrepôts de données, l'attention constante portée à la résolution des problèmes a conduit au fait que le nombre d'appels en dehors des heures de travail a été réduit à moins de 10 par mois. Nous sommes très fiers de ce chiffre.

Nous continuons de travailler à la maintenance et à l'amélioration de notre équipe de support technique, et à mesure que Intercom grandit, 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 nombre d'employés doublera. Néanmoins, cette expérience a été extrêmement positive pour notre organisation; elle a considérablement amélioré la qualité de vie de nos ingénieurs de développement, la qualité de nos réponses aux défis et, surtout, l'expérience de nos clients.

Source: https://habr.com/ru/post/fr476742/


All Articles