A tradución do artigo foi elaborada expresamente para o alumnado do curso .
A misión de Intercom é personalizar o negocio en liña. Pero non podes personalizar un produto cando non funciona. . O rendemento é fundamental para o éxito do noso negocio, non só porque os nosos clientes nos pagan, senón tamén porque nós mesmos utilizamos . Se o noso servizo non funciona, sentimos literalmente a dor dos nosos clientes.
O bo funcionamento depende de moitos factores, como a arquitectura do software e a calidade do traballo diario. Non obstante, moitas veces todo se reduce ao feito de que a persoa que está sempre en contacto responde ás chamadas de . Este tipo de soporte técnico pode ser unha poderosa ferramenta centrada no cliente que combina a axuda dos enxeñeiros co que os clientes obteñen cando compran o teu produto. Esta é tamén unha gran oportunidade para aprender e crecer, porque despois de todo, os fracasos e os erros poden ser unha boa oportunidade para practicar habilidades e comprender mecanismos de traballo complexos.
Estar "sempre aceso" fóra do horario laboral ten un efecto prexudicial na túa vida.
Pero ao mesmo tempo, estar "sempre aceso" pode ter un efecto prexudicial na túa vida. Debe estar preparado para responder de forma rápida e competente a unha alerta de que algo está roto. Aínda que non sexas paxinado nun momento dado, estar "sempre conectado" pode crear ansiedade, como sei por experiencia persoal. Debido a isto, a calidade do sono deteriorase especialmente. Estar regularmente na zona de acceso a calquera hora do día pode levar ao esgotamento, a apatía ou, en xeral, o desexo de non volver ver nunca o ordenador.
Historia do estado "sempre conectado" en Intercom
Nos primeiros días de Intercom, o noso Director Técnico, Ciaran, proporcionou por si só un equipo completo de soporte técnico XNUMX/XNUMX, tanto dentro como fóra da oficina. A medida que Intercom creceu, creouse un grupo de traballo para axudar a Ciaran. Pouco despois, os novos equipos de desenvolvemento comezaron a crear moitas funcións e servizos novos e asumiron todas as responsabilidades de soporte técnico.
Había demasiada xente "de garda" nun momento dado.
Naquel momento, este enfoque parecía unha obviedade porque era un xeito doado de escalar o noso equipo de soporte técnico en calquera momento, aliñaba cos nosos valores e se adaptaba aos nosos . Ao final, sen ningún plan, acabamos con catro ou cinco equipos que contactaban regularmente cos clientes durante as súas horas non laborables. O resto dos equipos de desenvolvemento non tiñan moitos problemas complexos que puidesen xerar un erro, polo que raramente se lles chamaba.
Démonos conta de que estabamos nunha situación na que tiñamos mecánicas de soporte técnico dos que non podíamos estar orgullosos e unha serie de problemas críticos que queriamos solucionar, como:
- Había demasiada xente preparada para asumir o reto en cada momento. A nosa infraestrutura non era o suficientemente grande como para requirir un mínimo de cinco enxeñeiros de desenvolvemento para traballar sen días de descanso regulares.
- A calidade das nosas alarmas e procedementos de chamada non foi coherente en todos os equipos e utilizamos procesos ad hoc para revisar alertas de problemas novas e existentes. As instrucións do runbook (que se deben seguir cando se notifica un problema) destacaban na súa maioría pola súa ausencia.
- Segundo o equipo no que traballaban os enxeñeiros, tiñan expectativas conflitivas. Por exemplo, só o primeiro equipo de soporte técnico tiña algunha compensación por quendas de garda e fins de semana interrompidas.
- Parecía haber un nivel xeral de tolerancia para as chamadas innecesarias en horas estrañas.
- Finalmente, este tipo de traballo non é para todos. As circunstancias da vida ás veces mostraron que os cambios de deber non tiñan o mellor efecto sobre as persoas.
Atopar o estado "sempre activado" correcto
Decidimos crear un novo equipo virtual que realizaría traballos de soporte técnico para cada equipo durante as horas non laborables. O equipo estará formado por voluntarios, non por reclutas de ningún equipo da organización. Os enxeñeiros do equipo virtual rotaban aproximadamente cada seis meses, pasando semanas "de garda". Por sorte, non tivemos problemas para atopar voluntarios suficientes para montar un equipo virtual.
Como resultado, o noso equipo de apoio reduciuse de 30 persoas a só 6 ou 7.
A continuación, o equipo acordou e definiu como deberían ser as alertas e descricións de problemas no runbook e describiu un proceso para reenviar alertas ao novo equipo de soporte. Definiron todas as alertas no código mediante un módulo Terraform e comezaron a utilizar a revisión por pares para cada cambio. Introducimos un nivel de compensación para unha quenda semanal que era bastante satisfactorio para os axentes de servizo. Tamén creamos un equipo escalado de segundo nivel que estaba formado só por directivos. Este equipo debería ser o único punto de escalada para os enxeñeiros de soporte técnico.
Levamos varios meses de duro traballo, durante os cales establecemos este proceso, polo que xa non había 30 enxeñeiros de garda como antes, senón só 6 ou 7. Durante as horas de traballo, os equipos tratan de forma independente os problemas coas súas funcións ou servizos, en Este é o momento no que adoita producirse o maior número de avarías, pero no resto de momentos, o apoio técnico é proporcionado por voluntarios.
O que aprendemos
Despois de que lanzamos o noso equipo de soporte técnico virtual, esperabamos unha afluencia de novas tarefas, como investigar as causas dos problemas ou reunirnos para resolver un único problema que estaba a provocar unha interrupción. Non obstante, os nosos equipos de desenvolvemento asumiron a total responsabilidade dos factores que causaron os fallos e calquera resposta posterior adoitaba ser inmediata. Tamén necesitabamos evitar unha situación na que unha tarefa de consulta técnica fose enviada de volta ao equipo do que procedía, para non obrigar aos enxeñeiros a contactar fóra do horario.
O número de chamadas fóra do horario laboral baixou a menos de 10 ao mes.
O noso proceso de escalada raramente se utilizou formalmente. Unha crenza máis común era que o enxeñeiro recibiu axuda extraoficial polo equipo que estaba actualmente conectado, especialmente os nosos mozos da oficina de San Francisco. Moitos problemas foron eliminados ou reducidos mediante o traballo en equipo e solucionalos sobre a marcha.
Os enxeñeiros da nosa oficina de San Francisco uníronse ao equipo a tempo completo e foron máis aló do soporte técnico típico. Enfrontámonos a algúns custos xerais, pero a difusión do noso equipo de asistencia en varias oficinas funcionou para nós, xa que resultou ser unha boa forma de construír relacións, fortalecelas e aprender máis sobre a pila tecnolóxica coa que todos traballamos.
O traballo dos desenvolvedores de Intercom fíxose máis consistente nos nosos equipos e podemos falar con confianza sobre os beneficios de ser enxeñeiro de sistemas no noso sitio. , indicando que non hai que estar sempre conectado a menos que queiras estar.
Xunto co traballo fundamental para estabilizar e escalar os nosos almacéns de datos, un enfoque continuo na resolución de problemas fixo que o número de chamadas fóra do horario caeu a menos de 10 ao mes. Estamos moi orgullosos deste número.
Seguimos traballando para manter e mellorar o noso equipo de soporte técnico e, a medida que Intercom medra, é posible que teñamos que reconsiderar as nosas decisións, porque o que funciona hoxe non necesariamente funcionará a próxima vez que o noso persoal se duplique. Non obstante, esta experiencia foi moi positiva para a nosa organización e mellorou moito a calidade de vida dos nosos enxeñeiros de desenvolvemento, a calidade das nosas respostas ás chamadas e, sobre todo, a experiencia dos nosos clientes.
Fonte: www.habr.com