La traduction de l'article a été préparée spécifiquement pour les étudiants du cours
La mission d'Intercom est de personnaliser les affaires en ligne. Mais on ne peut pas personnaliser un produit quand il ne fonctionne pas.
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
Ê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.
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
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