Mucho se ha dicho sobre las ventajas de trabajar en una empresa de abarrotes, y es difícil ser original aquí. Pero lejos de todo el mundo sabe cómo mantener la "salud" de un producto y lo que es posible hacer en una empresa de alimentos, además de desarrollar la funcionalidad. Le diremos cómo operamos el producto en Juno y cómo el departamento de operaciones y los especialistas técnicos están involucrados en esto.
No declaramos que nuestro camino es el más correcto. Intentamos constantemente, cometemos errores y tratamos de aprender de nuestros errores. Esperamos que nuestra experiencia le sea de utilidad.
Acerca de nosotros: Juno es un servicio de ocultación de viajes que opera en el mercado estadounidense y que forma parte del grupo de compañías Gett.
Juno escribe código en los idiomas Go, Swift, Kotlin, Python, React.js como parte de los equipos de aplicaciones móviles, Backend, Frontend, Data Science, Technical Operation Support, creando un servicio que se ha convertido en parte de la vida diaria de decenas de miles de conductores y cientos de miles de nuevos residentes. York
De qué se trata la gestión de productos
Comprendamos el proceso de operación en Juno e intentemos descomponerlo en sus partes constituyentes.
Hemos identificado tres componentes clave para nosotros mismos:
- Oficina operativa
- Métricas y Monitoreo
- Investigación de incidentes
El propósito de operar el producto es responder de manera oportuna a los problemas y cambios emergentes, independientemente de su naturaleza.
Para hacer esto, necesitas:
- Definir indicadores de salud del sistema.
- Comprender cómo los cambios dentro del sistema afectan las métricas
- Comprender cómo los cambios del mercado afectan el rendimiento
- Comprender cuándo el cambio se convierte en un problema
Con este enfoque, las decisiones comerciales se basan en datos. Nuestro equipo operativo trabaja en Nueva York, ya que el servicio de Juno actualmente solo está disponible para los residentes de esta metrópoli.
La lista de tareas diarias del equipo se ve así:
- Rastree y responda rápidamente a los cambios regulatorios. Los cambios comunes incluyen la aparición de una nueva carretera de peaje y la transferencia de un área de espera para los conductores en el aeropuerto. Tan pronto como recibamos información sobre tales eventos, el empleado deja el lugar para actualizar correctamente el mapa y analizar la lista de posibles problemas. Cuando el equipo de desarrollo actualiza el mapa en los servidores, el empleado prueba los cambios en las "condiciones de campo" y se asegura de que funcione correctamente.
- Realizar investigaciones de "campo". Cuando lanzamos el servicio en Nueva York, el plan era reclutar primero un cierto número de conductores para la operación estable del servicio en cualquier área de la ciudad. Por esta razón, durante un par de meses, los conductores que se unieron a nosotros primero condujeron sin pasajeros y solo ocasionalmente recibieron viajes de probadores beta. Estos viajes no fueron suficientes para reunir la información necesaria. Luego, decidimos enviar el equipo de operaciones a los "campos" para evaluar la calidad del servicio y descubrir las quejas de los conductores sobre la aplicación. Este enfoque resultó ser útil y lo usamos constantemente cuando publicamos cambios significativos o para probar hipótesis.
- Noticias "Calendario de eventos" : una lista de eventos, vacaciones y eventos climáticos que pueden afectar la cantidad y la calidad de los viajes. Esto ayuda a comprender y anticipar cambios en los indicadores clave (por ejemplo, la cantidad de viajes o la cantidad de conductores en línea) que no son obvios para el equipo de desarrollo de Minsk. Algunos eventos se pueden buscar en Google (condiciones climáticas, finales de SuperBowl, maratones, carreras de bicicletas, etc.), pero hay algunos que son más difíciles. Por ejemplo, en el primer año de trabajo, nos sorprendió que el Ramadán afectara en gran medida el número de conductores dispuestos a aceptar un pedido. El hecho es que en los Estados Unidos, muchos musulmanes trabajan como conductores, y no van a trabajar en vacaciones. Es difícil tener en cuenta este hecho mientras que en Minsk.
- Rastree el cambio en las métricas comerciales. En el tercer mes después del lanzamiento de Juno y el rápido crecimiento en el número de viajes, descubrimos que no había suficientes conductores en línea, lo que afectó el tiempo de entrega del automóvil y el deseo de los pasajeros de viajar con nosotros. Resultó que un competidor lanzó una campaña que garantizaba a los conductores un mayor pago por los viajes en las horas pico de la mañana y de la tarde. La información se transmitió rápidamente a Minsk, y en poco tiempo también tuvimos la oportunidad de ofrecer tales condiciones. Este paso nos ayudó a recuperar los conductores y seguir creciendo.
Métricas y Monitoreo
En Juno, todos los equipos tienen métricas, que acordamos dividir en:
- Métricas de negocios.
- Métrica técnica.
Las métricas empresariales son una serie de indicadores que miden la "salud" de un producto. Los dividimos condicionalmente en dos partes:
- En línea Los obvios son la cantidad de conductores y pasajeros en línea, la cantidad de viajes por estado. Menos obvio es el número de nuevos usuarios, la conversión de la pantalla con el precio preliminar del viaje para reservar un viaje, el tiempo de espera promedio para un automóvil en un área específica, la velocidad de la cola en el aeropuerto, etc.
- Fuera de línea No toda la información se puede obtener y procesar rápidamente en tiempo real, y no siempre es necesaria. Cuando planificamos promociones para conductores o nuevas funciones, nos interesan las tendencias a largo plazo o las reacciones de los usuarios al experimento A / B, ya sea un nuevo diseño, una nueva función o un descuento adicional.
Para crear informes analíticos basados en las métricas recopiladas, utilizamos Tableau. Para dichos informes, somos responsables del equipo de Business Intelligence (BI). Trabajan en la oficina de Tel Aviv al lado del equipo de supermercados. Ambos equipos trabajan en estrecha colaboración con colegas en Nueva York, lo que permite a los analistas basados en BI evaluar el éxito de las acciones tomadas, formular hipótesis para la verificación en los "campos" y ajustar el plan de desarrollo del producto.
Por otro lado, hay una serie de métricas técnicas que de alguna manera afectan al sistema en su conjunto.
Las métricas técnicas son una serie de indicadores que indican el funcionamiento sin errores de componentes individuales, sobre la base de los cuales se llega a una conclusión sobre el funcionamiento del sistema en su conjunto. Muestran cuánto tiempo toman las llamadas entre servicios, cuánta memoria consumen y si hay algún error crítico al transferir mensajes entre ellos. Hay muchas de esas métricas en Juno. Son algo redundantes, pero en situaciones críticas ayuda a encontrar rápidamente la causa del problema. El seguimiento y el uso de métricas técnicas nos ayudan a:
- Panel de control : muestra signos vitales significativos del sistema. Cada equipo de desarrollo compila su propio conjunto de métricas que les ayudan a comprender cómo un cambio en particular afectó a los microservicios que se les confiaron. Entonces, por ejemplo, un equipo monitorea las métricas relacionadas con el pago de dinero a los conductores y los pagos de pasajeros, y el otro analiza la métrica responsable del tiempo de búsqueda del conductor o el número de coordenadas recibidas.
- Registros Registramos eventos desde dispositivos móviles y microservicios de backend. En 2017, ocuparon 400-500 gigabytes por semana, en 2018 esta cifra se duplicó. Estamos interesados en los siguientes eventos: llamadas de microservicios a fuentes externas de información, a otros microservicios, solicitudes de clientes recibidas y enviadas, todo tipo de errores (comerciales y técnicos). Vale la pena señalar que la información está anonimizada: los datos personales, como contraseñas e información bancaria, no se registran.
Para monitorear el rendimiento, utilizamos Grafana y Prometheus. Al desarrollar un nuevo servicio o agregar una nueva función, los desarrolladores agregan las métricas necesarias al servicio, y luego cada equipo configura alertas por sí mismo.
Gracias a las alertas personalizadas, el equipo de soporte técnico realiza un análisis inicial y escala el problema al desarrollo o a los equipos comerciales para una mayor resolución.
Si el problema es de naturaleza técnica y amenaza la operación normal del servicio, el equipo de soporte técnico crea un incidente de producción. Gracias al proceso automatizado, las partes interesadas son notificadas de inmediato, incluido el equipo de atención al cliente (servicio al cliente, también conocido como servicio de asistencia, también conocido como soporte L1), que se prepara para una posible afluencia de llamadas.
Investigación de incidentes
Con el tiempo, llegamos a la conclusión de que después de cada incidente grave, se produce una especie de "interrogatorio". Estamos realizando cambios en los procesos que nos ayudan a evitar o enfrentar mejor eventos similares en el futuro.
Los elementos mencionados anteriormente: métricas, paneles, alertas y registros ayudan a comprender lo que sucedió. Los equipos se sientan juntos, analizan los cambios en los indicadores técnicos y comerciales, toman en cuenta los errores y extraen lecciones por sí mismos.
Tenemos que lidiar con incidentes de producción, así como con cualquier otra situación en la que sea imposible responder rápidamente "lo que sucedió". Y aquí el equipo de soporte técnico ayuda (TechSupport, también conocido como soporte L2).
¿Qué problemas se resuelven en el soporte técnico? Se cree que este es un trabajo aburrido, como en la serie IT Crowd, donde tres nerds en el sótano simplemente hacen lo que dicen: "intenta apagar y encender la computadora". De hecho, surgen preguntas complejas y controvertidas.
El primer nivel de soporte (servicio al cliente) está organizado por el principio de "seguir al sol" (seguir al sol). Con este enfoque, la asistencia al usuario durante todo el día es posible sin turnos nocturnos. En tiempos europeos, una oficina se encuentra en Tel Aviv, y en horario estadounidense, en Portland. La tarea de este equipo es escuchar y comprender el "dolor" del conductor o pasajero, calmarse, ayudar si es posible. Los chicos que trabajan allí son responsables de las preguntas relacionadas con el funcionamiento del servicio. Al mismo tiempo, el equipo no es "técnico", y tan pronto como llega el momento en que es necesario profundizar en los matices técnicos, la solicitud se redirige al equipo de soporte técnico. Este equipo trabaja en Minsk y es parte del centro de desarrollo. Los chicos resuelven problemas exclusivamente técnicos y no se comunican directamente con los conductores y los pasajeros. Tarea de equipo: investigación de incidentes y automatización de procesos.
En el caso de un incidente de producción, la tarea para el equipo de soporte técnico es la siguiente: se encontró un error o se produjo una falla durante la implementación, notamos un problema, lo solucionamos, pero aún tenemos que descubrir cómo afectó el sistema y qué debe restaurarse desde el punto de vista de la administración del producto:
- ¿Se dañan los datos o se viola su integridad?
- ¿Cómo afectó este incidente a los usuarios?
- ¿Están afectados todos los usuarios?
- ¿Qué se puede arreglar?
Las preguntas son simples, pero para responderlas, debe comprender muy bien cómo funciona el sistema y cómo cambió su comportamiento durante el incidente. Al responder la pregunta, vale la pena considerar el proceso de implementación en curso, como la probabilidad de que algo pueda cambiar en cada minuto.
Como ejemplo, cuando se necesitaba soporte técnico para que el producto funcionara correctamente, considere el caso "No hice un viaje". El conductor tomó otro pasajero e hizo un viaje por el cual nuestro pasajero no quiere pagar. En este caso, es necesario distinguir entre una solicitud legítima y un intento de fraude cuando el usuario intenta no pagar por los servicios prestados.
Si la solicitud llega repetidamente, es automatizada por el equipo de soporte técnico y se proporciona al equipo de soporte al usuario en forma de una aplicación web. Este enfoque le permite reducir el tiempo que lleva procesar la solicitud de un usuario y no "inflar" el equipo de soporte técnico. Sin embargo, la vacante del ingeniero de soporte técnico siempre está abierta para nosotros, a medida que los chicos crecen y se trasladan a otros equipos de desarrollo.
Todos los caminos llevan a Roma
Una descripción detallada del trabajo del equipo de soporte técnico en el marco de este artículo no es accidental. Sucedió que se convirtió en un lugar donde la información fluye de todas las fuentes. Un único punto de contacto reduce el número de intérpretes y, por lo tanto, reduce el número de distorsiones.
Esto no significa que el equipo de soporte técnico sea el eslabón principal en la gestión del producto de la operación, porque la compañía del producto es un organismo vivo: todos los órganos son importantes y necesarios. Es imposible elegir qué es más importante para una persona: el cerebro o el corazón, los pulmones o el sistema circulatorio. Solo el desarrollo armonioso y la interacción de todos los órganos garantiza el funcionamiento saludable del cuerpo o de la empresa de TI.
¡Salud para usted y sus productos!