La traducción del artículo fue preparada específicamente para estudiantes del curso. .
La misión de Intercom es personalizar los negocios online. Pero no se puede personalizar un producto cuando no funciona. . El rendimiento es fundamental para el éxito de nuestro negocio, no sólo porque nuestros clientes nos pagan, sino también porque nosotros mismos utilizamos . Si nuestro servicio no funciona, literalmente sentimos el dolor de nuestros clientes.
El buen funcionamiento depende de muchos factores, como la arquitectura del software y la calidad del trabajo diario. Sin embargo, muy a menudo todo se reduce al hecho de que la persona que siempre está en contacto responde a las llamadas de . Este tipo de soporte técnico puede ser una poderosa herramienta centrada en el cliente que combina la ayuda de los ingenieros con lo que los clientes obtienen cuando compran su producto. Esta también es una gran oportunidad para aprender y crecer, porque después de todo, los fracasos y los errores pueden ser una buena oportunidad para practicar habilidades y comprender mecanismos de trabajo complejos.
Estar “siempre activo” fuera del horario laboral tiene un efecto perjudicial en su vida.
Pero al mismo tiempo, estar “siempre conectado” puede tener un efecto perjudicial en su vida. Debe estar preparado para responder de forma rápida y competente a una alerta de que algo está roto. Incluso si no te están llamando en un momento dado, estar "siempre conectado" puede generar ansiedad, como lo sé por experiencia personal. Debido a esto, la calidad del sueño se deteriora especialmente. Estar habitualmente en la zona de acceso a cualquier hora del día puede provocar agotamiento, apatía o, en general, el deseo de no volver a ver el ordenador nunca más.
Historia del estado “siempre conectado” en Intercom
En los primeros días de Intercom, nuestro director técnico, Ciaran, proporcionó por sí solo un equipo completo de soporte técnico las XNUMX horas, los XNUMX días de la semana, tanto dentro como fuera de la oficina. A medida que Intercom crecía, se creó un grupo de trabajo para ayudar a Ciaran. Poco después, nuevos equipos de desarrollo comenzaron a crear muchas funciones y servicios nuevos y asumieron todas las responsabilidades de soporte técnico.
Había demasiada gente "de guardia" en un momento dado.
En ese momento, este enfoque parecía una obviedad porque era una manera fácil de ampliar nuestro equipo de soporte técnico en cualquier momento, se alineaba con nuestros valores y se adaptaba a nuestras necesidades. . Al final, sin ningún plan, terminamos con cuatro o cinco equipos que contactaban regularmente con los clientes durante sus horas no laborales. El resto de los equipos de desarrollo no tuvieron muchos problemas complejos que pudieran generar un error, por lo que rara vez, o nunca, fueron llamados.
Nos dimos cuenta de que estábamos en una situación en la que teníamos mecanismos de soporte técnico de los que no podíamos estar orgullosos y una serie de problemas críticos que queríamos solucionar, como por ejemplo:
- Había demasiada gente dispuesta a asumir el desafío en un momento dado. Nuestra infraestructura no era lo suficientemente grande como para requerir que un mínimo de cinco ingenieros de desarrollo trabajaran sin días libres regulares.
- La calidad de nuestras alarmas y procedimientos de llamadas no fue consistente en todos los equipos, y utilizamos procesos ad hoc para revisar alertas de problemas nuevos y existentes. Las instrucciones en el runbook (a seguir cuando se notifica un problema) brillaban en su mayoría por su ausencia.
- Dependiendo del equipo en el que trabajaban los ingenieros, tenían expectativas contradictorias. Por ejemplo, solo el primer equipo de soporte técnico recibió compensación por turnos de guardia y fines de semana interrumpidos.
- Parecía haber un nivel general de tolerancia hacia las llamadas innecesarias a horas intempestivas.
- Finalmente, este tipo de trabajo no es para todos. Las circunstancias de la vida a veces mostraban que los turnos de trabajo no tenían el mejor efecto en las personas.
Encontrar el estado correcto "siempre activo"
Decidimos crear un nuevo equipo virtual que realizaría trabajo de soporte técnico para cada equipo durante el horario no laboral. El equipo estará formado por voluntarios, no reclutas de ningún equipo de la organización. Los ingenieros del equipo virtual rotaban aproximadamente cada seis meses y pasaban semanas "de guardia". Afortunadamente, no tuvimos problemas para encontrar suficientes voluntarios para formar un equipo virtual.
Como resultado, nuestro equipo de soporte se redujo de 30 personas a solo 6 o 7.
Luego, el equipo acordó y definió cómo deberían verse las alertas y descripciones de problemas en el runbook, y describió un proceso para reenviar alertas al nuevo equipo de soporte. Definieron todas las alertas en el código utilizando un módulo Terraform y comenzaron a utilizar la revisión por pares para cada cambio. Introdujimos un nivel de compensación por un turno semanal que resultó bastante satisfactorio para los oficiales de servicio. También creamos un equipo escalado de segundo nivel que estaba formado únicamente por gerentes. Este equipo debe ser el único punto de escalada para los ingenieros de soporte técnico.
Tuvimos varios meses de arduo trabajo durante los cuales establecimos este proceso, como resultado, ahora no había 30 ingenieros de guardia como antes, sino solo 6 o 7. Durante las horas de trabajo, los equipos resuelven de forma independiente los problemas con sus funciones o servicios, en este es el momento en el que se suelen producir un mayor número de averías, pero en el resto de momentos el soporte técnico lo prestan voluntarios.
lo que aprendimos
Después de que lanzamos nuestro equipo de soporte técnico virtual, esperábamos una afluencia de nuevas tareas, como investigar las causas de los problemas o reunirnos para resolver un solo problema que estaba causando una interrupción. Sin embargo, nuestros equipos de desarrollo asumieron toda la responsabilidad por los factores que causaron las fallas y cualquier respuesta posterior fue generalmente inmediata. También necesitábamos evitar una situación en la que una tarea de consulta técnica se devolviera al equipo del que procedía, para no obligar a los ingenieros a ponerse en contacto fuera de horario.
El número de llamadas fuera de horario se ha reducido a menos de 10 por mes.
Nuestro proceso de escalada rara vez se utilizó formalmente. Una creencia más común era que el ingeniero recibió ayuda extraoficial del equipo que estaba actualmente en línea, especialmente nuestros muchachos en la oficina de San Francisco. Muchos problemas se eliminaron o redujeron mediante el trabajo en equipo y resolviéndolos sobre la marcha.
Los ingenieros de nuestra oficina de San Francisco se unieron al equipo a tiempo completo y fueron más allá del soporte técnico típico. Nos enfrentamos a algunos costos generales, pero distribuir los miembros de nuestro equipo de soporte en varias oficinas fue una ventaja para nosotros, ya que resultó ser una buena manera de construir relaciones, fortalecerlas y aprender más sobre la tecnología con la que todos trabajamos.
El trabajo de los desarrolladores de Intercom se ha vuelto más consistente en nuestros equipos y podemos hablar con confianza de los beneficios de ser ingeniero de sistemas en nuestro sitio. , afirmando que no es necesario estar siempre conectado a menos que así lo desees.
Junto con el trabajo fundamental para estabilizar y escalar nuestros almacenes de datos, un enfoque continuo en la resolución de problemas ha hecho que la cantidad de llamadas fuera de horario se reduzca a menos de 10 por mes. Estamos muy orgullosos de este número.
Seguimos trabajando para mantener y mejorar nuestro equipo de soporte técnico y, a medida que Intercom crece, es posible que tengamos que reconsiderar nuestras decisiones, porque lo que funciona hoy no necesariamente funcionará la próxima vez que nuestro personal se duplique. Sin embargo, esta experiencia ha sido sumamente positiva para nuestra organización y ha mejorado enormemente la calidad de vida de nuestros ingenieros de desarrollo, la calidad de nuestras respuestas a las llamadas y, sobre todo, la experiencia de nuestros clientes.
Fuente: habr.com