La traducción del artículo fue preparada específicamente para estudiantes del curso "Prácticas y herramientas de DevOps" .
La misión de Intercom es hacer que el negocio en línea sea personalizado. Pero personalizar un producto es imposible cuando no funciona
como debería . La eficiencia es crítica para el éxito de nuestro negocio, y no solo porque nuestros clientes nos pagan, sino también porque usamos
nuestro producto nosotros mismos. Si nuestro servicio no funciona, literalmente sentimos el dolor de nuestros clientes.
El tiempo de actividad depende de muchos factores, como la arquitectura del software y la calidad del trabajo diario. Sin embargo, a menudo todo se reduce al hecho de que una persona que siempre está en contacto responde llamadas de
PagerDuty . Dicho soporte técnico puede ser una herramienta poderosa orientada al cliente que combina la asistencia de ingenieros con lo que los clientes reciben cuando compran su producto. También ofrece una excelente oportunidad para el aprendizaje y el crecimiento, porque al final, los fracasos y errores pueden ser un buen campo para desarrollar habilidades y comprender los complejos mecanismos de trabajo.
Mantenerse "siempre en contacto" fuera del horario laboral es perjudicial para su vida.Pero al mismo tiempo, el estado de "siempre en contacto" puede tener un efecto perjudicial en su vida. Debe estar preparado para responder de manera rápida y competente a una alerta de que algo está roto. Incluso si no es llamado por un buscapersonas en este momento en particular, el estado de "siempre en contacto" infunde un sentimiento de ansiedad, yo mismo lo sé por experiencia personal. Especialmente debido a esto, la calidad del sueño se está deteriorando. Una estadía regular en el área de acceso en cualquier momento del día puede provocar agotamiento, apatía o, en general, el deseo de no volver a ver una computadora.
Historial de estado del intercomunicador en Intercom
En los primeros días de Intercom, nuestro director técnico Kiaran solo era un equipo completo de soporte técnico las 24 horas, tanto en la oficina como en el exterior. A medida que Intercom crecía, se creó un grupo de trabajo para ayudar a Ciaran. Poco después, los nuevos equipos de desarrollo comenzaron a crear muchas características y servicios nuevos, y ya asumieron todas las responsabilidades de soporte técnico.
En cualquier momento había demasiada gente "en contacto".En ese momento, este enfoque parecía darse por sentado, ya que era una forma fácil de escalar el equipo de soporte técnico en cualquier momento, cumplía con nuestros valores y entretenía nuestro
sentido de propiedad . Como resultado, sin ningún plan, obtuvimos cuatro o cinco equipos que se pusieron en contacto regularmente con los clientes durante sus horas posteriores. El resto de los equipos de desarrollo no tuvieron muchos momentos difíciles que podrían arrojar 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 contamos con la mecánica de soporte técnico, de la cual no podemos estar orgullosos, y una serie de problemas críticos que queríamos eliminar, como:
- Demasiadas personas estaban listas para aceptar el desafío en un momento dado. Nuestra infraestructura no era tan grande que requería un mínimo de cinco ingenieros de desarrollo que trabajarían sin un fin de semana normal.
- La calidad de nuestras alarmas y procedimientos de llamada no se coordinó entre los equipos; utilizamos procesos especiales para revisar alertas nuevas y existentes sobre problemas. Las instrucciones en el runbook (que deben seguirse al recibir una notificación sobre un problema) fueron principalmente sorprendentes en 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 tuvo alguna compensación por turnos de trabajo y fines de semana rotos.
- Resultó que hay un nivel general de tolerancia para llamadas innecesarias en momentos inoportunos.
- Finalmente, este tipo de trabajo no es adecuado para todos. Las circunstancias de la vida a veces mostraron que los cambios de deber afectan a las personas no de la mejor manera.
Busque el estado correcto de "siempre en contacto"
Decidimos crear un nuevo equipo virtual que hará el trabajo de soporte técnico para cada equipo cuando tenga un tiempo no laborable. El equipo estará formado por voluntarios, no reclutas de ningún equipo de la organización. Los ingenieros de un equipo virtual cambiaban aproximadamente cada seis meses, pasando semanas "en contacto". Afortunadamente, no tuvimos problemas para encontrar suficientes voluntarios para armar un equipo virtual.
Como resultado, nuestro equipo de soporte se redujo de 30 personas a solo 6 o 7.Luego, este equipo acordó y determinó cómo deberían verse las alertas y descripciones del problema en el runbook, y describió el proceso de reenvío de alertas a un nuevo equipo de soporte. Identificaron todas las alertas en el código usando el módulo Terraform, y comenzaron a usar el juicio de expertos para cada cambio. Introdujimos un nivel de compensación para el turno semanal, que era bastante adecuado para quienes estaban de servicio. También creamos un equipo de segundo nivel escalado, que consistía solo en gerentes. Este equipo debería ser el único punto de escala para los ingenieros de soporte técnico.
Tuvimos varios meses de arduo trabajo, durante el cual comenzamos este proceso, como resultado, ahora no 30 ingenieros como antes, pero solo 6 o 7 se mantuvieron en contacto. Durante las horas de trabajo, los equipos abordan de forma independiente los problemas con sus funciones o servicios, en esta vez generalmente representa la mayor cantidad de averías, sin embargo, el resto del tiempo los voluntarios se dedican al soporte técnico.
Que aprendimos
Después de lanzar nuestro equipo virtual de soporte técnico, esperábamos una afluencia de nuevas tareas, como investigar las causas de los problemas o la recopilación general para resolver cualquier problema que causó la falla. Sin embargo, nuestros equipos de desarrollo asumieron toda la responsabilidad por los factores que causaron las fallas, y cualquier reacción posterior fue generalmente una acción inmediata. También necesitábamos evitar una situación en la que la tarea de asesoramiento técnico se devolviera al equipo del que había llegado, para no obligar a los ingenieros a ponerse en contacto después de horas.
Las llamadas fuera de la oficina disminuyeron a menos de 10 por mes.Formalmente, nuestro proceso de escalado raramente se usaba. La opinión más común era que el ingeniero, que actualmente está en línea, ayuda al ingeniero de manera informal, especialmente para nuestros muchachos de la oficina en San Francisco. Se solucionaron muchos problemas o se redujo su número a través del trabajo en equipo y su resolución sobre la marcha.
Los ingenieros de nuestra oficina de San Francisco se unieron al equipo en su conjunto y fueron más allá del soporte técnico habitual. Nos enfrentamos a una pregunta sobre ciertos costos generales, sin embargo, extender la membresía del equipo de soporte a varias oficinas en nuestras manos, porque resultó ser una buena manera de construir relaciones, fortalecerlas y aprender más sobre la tecnología con la que todos trabajamos.
En nuestros equipos, el trabajo de los desarrolladores de Intercom se ha vuelto más consistente, y podemos hablar con confianza sobre las ventajas de un puesto de ingeniero de sistemas en nuestro sitio web de
carreras , afirmando que no es necesario estar siempre en contacto si no lo desea usted mismo.
Junto con el trabajo fundamental para estabilizar y escalar nuestros almacenes de datos, la atención constante a la resolución de problemas ha llevado al hecho de que el número de llamadas durante las horas libres se ha reducido a menos de 10 por mes. Estamos muy orgullosos de este número.
Continuamos trabajando en el mantenimiento y la mejora de 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 se duplique nuestro número de empleados. Sin embargo, esta experiencia fue extremadamente positiva para nuestra organización; mejoró significativamente la calidad de vida de nuestros ingenieros de desarrollo, la calidad de nuestras respuestas a los desafíos y, sobre todo, la experiencia de nuestros clientes.