Hi!
Mi nombre es Mikhail, soy el subdirector de TI de la empresa Sportmaster. Quiero compartir la historia de cómo abordamos los desafíos que surgieron durante la pandemia.
En los primeros días de la nueva realidad, el formato habitual de comercio fuera de línea de Sportmaster se congeló y la carga en nuestro canal en línea, principalmente en términos de entrega a la dirección del cliente, se multiplicó por 10. En tan solo unas semanas transformamos un gigantesco negocio offline en online y adaptamos el servicio a las necesidades de nuestros clientes.
Básicamente, lo que era esencialmente nuestra operación secundaria se convirtió en nuestro negocio principal. La importancia de cada pedido en línea ha aumentado enormemente. Era necesario ahorrar cada rublo que el cliente aportaba a la empresa.
Para responder rápidamente a las solicitudes de los clientes, abrimos un centro de contacto adicional en la oficina principal de la empresa y ahora podemos recibir alrededor de 285 mil llamadas por semana. Al mismo tiempo, trasladamos 270 tiendas a un nuevo formato operativo sin contacto y seguro, que permitió a los clientes recibir pedidos y a los empleados mantener sus puestos de trabajo.
Durante el proceso de transformación, nos encontramos con dos problemas principales. En primer lugar, la carga de nuestros recursos en línea ha aumentado significativamente (Sergey le contará cómo lo solucionamos). En segundo lugar, el flujo de operaciones poco comunes (anteriores a la COVID) se ha multiplicado muchas veces, lo que a su vez requirió una gran cantidad de automatización rápida. Para solucionar este problema, tuvimos que transferir rápidamente recursos de áreas que antes eran las principales. Elena te contará cómo abordamos esto.
Operación de servicios en línea.
Kolesnikov Sergey, responsable del funcionamiento de la tienda online y microservicios.
Desde el momento en que nuestras tiendas minoristas comenzaron a cerrar a los visitantes, comenzamos a registrar un aumento en métricas como la cantidad de usuarios, la cantidad de pedidos realizados en nuestra aplicación y la cantidad de solicitudes a las aplicaciones.
Número de pedidos del 18 de marzo al 31 de marzoNúmero de solicitudes a microservicios de pago onlineNúmero de pedidos realizados en el sitio web
En el primer gráfico vemos que el aumento fue de aproximadamente 14 veces, en el segundo, 4 veces. Consideramos que la métrica del tiempo de respuesta de nuestras aplicaciones es la más indicativa.
En este gráfico vemos la respuesta de frentes y aplicaciones, y por nuestra parte determinamos que no notamos ningún crecimiento como tal.
Esto se debe principalmente a que a finales de 2019 iniciamos los trabajos preparatorios. Ahora nuestros servicios están reservados, la tolerancia a fallos está garantizada a nivel de servidores físicos, sistemas de virtualización, acopladores y servicios en los mismos. Al mismo tiempo, la capacidad de los recursos de nuestro servidor nos permite soportar múltiples cargas.
La principal herramienta que nos ayudó en toda esta historia fue nuestro sistema de seguimiento. Es cierto que hasta hace poco no teníamos un sistema único que nos permitiera recopilar métricas en todos los niveles, desde el nivel de equipo físico y hardware hasta el nivel de métricas comerciales.
Formalmente, existía un seguimiento en la empresa, pero por regla general estaba disperso y estaba en el área de responsabilidad de departamentos específicos. De hecho, cuando ocurría un incidente, casi nunca teníamos un entendimiento común de lo que sucedió exactamente, no había comunicación y, a menudo, esto nos llevaba a correr en círculos para encontrar y aislar el problema para poder solucionarlo.
En algún momento, pensamos y decidimos que ya estábamos hartos de soportar esto: necesitábamos un sistema unificado para ver el panorama completo. Las principales tecnologías que se incluyen en nuestra pila son Zabbix como centro de almacenamiento de métricas y alertas, Prometheus para recopilar y almacenar métricas de aplicaciones, Stack ELK para registrar y almacenar datos de todo el sistema de monitoreo, así como Grafana para visualización, Swagger, Docker. y otras cosas útiles y que le resulten familiares.
Al mismo tiempo, no sólo utilizamos tecnologías disponibles en el mercado, sino que también desarrollamos algunas propias. Por ejemplo, creamos servicios para integrar sistemas entre sí, es decir, algún tipo de API para recopilar métricas. Además, estamos trabajando en nuestros propios sistemas de seguimiento: a nivel de métricas comerciales utilizamos pruebas de interfaz de usuario. Y también un bot en Telegram para notificar a los equipos.
También estamos tratando de hacer que el sistema de monitoreo sea accesible para los equipos para que puedan almacenar y trabajar con sus métricas de forma independiente, incluida la configuración de alertas para algunas métricas específicas que no se utilizan ampliamente.
En todo el sistema nos esforzamos por la proactividad y la localización de las incidencias lo más rápido posible. Además, la cantidad de nuestros microservicios y sistemas ha aumentado significativamente recientemente y, en consecuencia, la cantidad de integraciones ha aumentado. Y como parte de la optimización del proceso de diagnóstico de incidencias a nivel de integración, estamos desarrollando un sistema que permite realizar comprobaciones entre sistemas y mostrar el resultado, lo que permite encontrar los principales problemas asociados a las importaciones e interacción de sistemas con entre sí.
Por supuesto, todavía tenemos espacio para crecer y desarrollarnos en términos de sistemas operativos, y estamos trabajando activamente en ello. Puedes leer más sobre nuestro sistema de seguimiento .
Pruebas técnicas
Orlov Sergey, dirige el centro de competencias para el desarrollo web y móvil
Desde que comenzaron los cierres de tiendas físicas, hemos enfrentado varios desafíos desde una perspectiva de desarrollo. En primer lugar, el aumento de carga como tal. Está claro que si no se toman las medidas adecuadas, cuando se aplica una carga elevada al sistema, puede convertirse en una calabaza con un estrépito triste, degradarse por completo su rendimiento o incluso perder su funcionalidad.
El segundo aspecto, un poco menos obvio, es que el sistema sometido a una carga elevada tuvo que cambiarse muy rápidamente, adaptándose a los cambios en los procesos de negocio. A veces, varias veces al día. Muchas empresas tienen la regla de que si hay mucha actividad de marketing, no es necesario realizar ningún cambio en el sistema. Ninguno en absoluto, déjalo funcionar mientras funcione.
Y básicamente tuvimos un Black Friday interminable, durante el cual fue necesario cambiar el sistema. Y cualquier error, problema o falla en el sistema sería muy costoso para el negocio.
De cara al futuro, diré que logramos hacer frente a estas pruebas, todos los sistemas resistieron la carga, se escalaron fácilmente y no experimentamos fallas técnicas globales.
Hay cuatro pilares sobre los que descansa la capacidad del sistema para soportar altas sobretensiones. El primero de ellos es el seguimiento, sobre el que leyó justo arriba. Sin un sistema de monitoreo incorporado, es casi imposible encontrar cuellos de botella en el sistema. Un buen sistema de monitorización es como la ropa de casa: debe ser cómoda y hecha a tu medida.
El segundo aspecto son las pruebas. Nos tomamos este punto muy en serio: escribimos unidades clásicas, pruebas de integración, pruebas de carga y muchas otras para cada sistema. También estamos escribiendo una estrategia de prueba y, al mismo tiempo, estamos tratando de aumentar el nivel de prueba hasta el punto de que ya no necesitemos verificaciones manuales.
El tercer pilar es CI/CD Pipeline. Los procesos de creación, prueba e implementación de una aplicación deben automatizarse tanto como sea posible; no debe haber intervención manual. El tema de CI/CD Pipeline es bastante profundo y solo lo abordaré brevemente. Solo vale la pena mencionar que tenemos una lista de verificación de canalización de CI/CD, que cada equipo de producto revisa con la ayuda de los centros de competencia.
Y aquí está la lista de verificación.
De esta manera se consiguen muchos objetivos. Se trata de control de versiones de API y alternancia de funciones para evitar el tren de lanzamiento y lograr cobertura de varias pruebas a un nivel tal que las pruebas estén completamente automatizadas, las implementaciones sean fluidas, etc.
El cuarto pilar son los principios arquitectónicos y las soluciones técnicas. Podemos hablar mucho de arquitectura durante mucho tiempo, pero quiero enfatizar un par de principios en los que me gustaría centrarme.
Primero, debes elegir herramientas especializadas para tareas específicas. Sí, suena obvio, y está claro que los clavos deben clavarse con un martillo y los relojes de pulsera deben desmontarse con destornilladores especiales. Pero en nuestra época, muchas herramientas luchan por la universalización para cubrir el segmento máximo de usuarios: bases de datos, cachés, frameworks y demás. Por ejemplo, si toma la base de datos MongoDB, funciona con transacciones de múltiples documentos y la base de datos Oracle funciona con json. Y parece que todo sirve para todo. Pero si defendemos la productividad, entonces debemos comprender claramente las fortalezas y debilidades de cada herramienta y utilizar las que necesitamos para nuestra clase de tareas.
En segundo lugar, a la hora de diseñar sistemas, cada aumento de complejidad debe estar justificado. Debemos tener esto presente constantemente; el principio de bajo acoplamiento es conocido por todos. Creo que debería aplicarse a nivel de un servicio específico, a nivel de todo el sistema y a nivel del paisaje arquitectónico. También es importante la capacidad de escalar horizontalmente cada componente del sistema a lo largo de la ruta de carga. Si tienes esta habilidad, escalar no será difícil.
Hablando de soluciones técnicas, pedimos a los equipos de productos que prepararan un nuevo conjunto de recomendaciones, ideas y soluciones, que implementaron en preparación para la próxima ola de carga de trabajo.
Keshi
Es necesario abordar conscientemente la elección de cachés locales y distribuidos. A veces tiene sentido usar ambos dentro del mismo sistema. Por ejemplo, tenemos sistemas en los que algunos de los datos son esencialmente un caché de exhibición, es decir, la fuente de actualizaciones se encuentra detrás del propio sistema y los sistemas no cambian. estos datos. Para este enfoque utilizamos Caffeine Cache local.
Y hay datos que el sistema cambia activamente durante el funcionamiento, y aquí ya estamos usando un caché distribuido con Hazelcast. Este enfoque nos permite utilizar los beneficios de una caché distribuida donde realmente se necesitan y minimizar los costos del servicio de circulación de datos del clúster Hazelcast donde podemos prescindir de ellos. Hemos escrito mucho sobre cachés. и .
Además, cambiar el serializador a Kryo en Hazelcast nos dio un buen impulso. Y la transición de ReplicatedMap a IMap + Near Cache en Hazelcast nos permitió minimizar el movimiento de datos a través del clúster.
Un pequeño consejo: en caso de invalidación masiva del caché, a veces se aplica la táctica de calentar el segundo caché y luego cambiar a él. Parecería que con este enfoque deberíamos conseguir el doble de consumo de memoria, pero en la práctica, en aquellos sistemas donde se practicaba, el consumo de memoria disminuyó.
Pila reactiva
Usamos la pila reactiva en una gran cantidad de sistemas. En nuestro caso, se trata de Webflux o Kotlin con corrutinas. La pila reactiva es especialmente buena cuando esperamos operaciones de entrada y salida lentas. Por ejemplo, llamadas a servicios lentos, trabajando con el sistema de archivos o sistemas de almacenamiento.
El principio más importante es evitar bloquear llamadas. Los marcos reactivos tienen una pequeña cantidad de subprocesos de servicio en vivo que se ejecutan bajo el capó. Si descuidadamente nos permitimos realizar una llamada de bloqueo directo, como una llamada al controlador JDBC, el sistema simplemente se detendrá.
Intente convertir los errores en su propia excepción de tiempo de ejecución. El flujo real de ejecución del programa cambia a marcos reactivos y la ejecución del código se vuelve no lineal. Como resultado, es muy difícil diagnosticar problemas mediante seguimientos de pila. Y la solución aquí sería crear excepciones de tiempo de ejecución claras y objetivas para cada error.
Elasticsearch
Cuando utilice Elasticsearch, no seleccione datos no utilizados. Esto, en principio, también es un consejo muy simple, pero la mayoría de las veces es lo que se olvida. Si necesita seleccionar más de 10 mil registros a la vez, debe utilizar Scroll. Para usar una analogía, es un poco como un cursor en una base de datos relacional.
No utilice postfiltro a menos que sea necesario. Con una gran cantidad de datos en el ejemplo principal, esta operación carga enormemente la base de datos.
Utilice operaciones masivas cuando corresponda.
API
Al diseñar una API, incluya requisitos para minimizar los datos transmitidos. Esto es especialmente cierto en relación con el frente: es en este cruce donde vamos más allá de los canales de nuestros centros de datos y ya estamos trabajando en el canal que nos conecta con el cliente. Si tiene el más mínimo problema, demasiado tráfico provoca una experiencia de usuario negativa.
Y por último, no tirar un montón de datos, tener claro el contrato entre consumidores y proveedores.
Transformación organizacional
Eroshkina Elena, subdirectora de TI
En el momento en que llegó la cuarentena y surgió la necesidad de acelerar drásticamente el ritmo de desarrollo en línea e introducir servicios omnicanal, ya estábamos en el proceso de transformación organizacional.
Parte de nuestra estructura fue transferida para trabajar de acuerdo con los principios y prácticas del enfoque de producto. Se han formado equipos que ahora son responsables de la operación y desarrollo de cada producto. Los empleados de dichos equipos están 100% involucrados y estructuran su trabajo utilizando Scrum o Kanban, según lo que prefieran, configurando un canal de implementación, implementando prácticas técnicas, prácticas de control de calidad y mucho más.
Por suerte, la mayor parte de nuestros equipos de productos estaban en el área de servicios online y omnicanal. Esto nos permitió cambiar al modo de trabajo remoto en el menor tiempo posible (en serio, literalmente en dos días) sin pérdida de eficiencia. El proceso personalizado nos permitió adaptarnos rápidamente a las nuevas condiciones de trabajo y mantener un ritmo bastante alto de entrega de nuevas funciones.
Además, tenemos la necesidad de fortalecer aquellos equipos que están en la frontera del negocio online. En ese momento quedó claro que sólo podíamos hacerlo utilizando recursos internos. Y unas 50 personas en dos semanas cambiaron el área donde trabajaban antes y se involucraron en un producto que era nuevo para ellos.
Esto no requirió ningún esfuerzo de gestión especial, porque además de organizar nuestro propio proceso, mejorar técnicamente el producto y prácticas de control de calidad, enseñamos a nuestros equipos a autoorganizarse, a gestionar su propio proceso de producción sin involucrar recursos administrativos.
Pudimos centrar nuestros recursos de gestión exactamente donde era necesario en ese momento: en la coordinación junto con la empresa: qué es importante para nuestro cliente en este momento, qué funcionalidad debería implementarse primero, qué se debe hacer para aumentar nuestra capacidad de rendimiento. para entregar y procesar pedidos. Todo esto y un claro modelo a seguir hicieron posible durante este período cargar nuestros flujos de valor de producción con lo realmente importante y necesario.
Está claro que con el trabajo remoto y un alto ritmo de cambio, cuando los indicadores de negocio dependen de la participación de todos, no se puede confiar sólo en los sentimientos internos de la serie “¿Nos va todo bien? Sí, parece bueno”. Se necesitan métricas objetivas del proceso de producción. Los tenemos, están disponibles para cualquiera que esté interesado en las métricas de los equipos de productos. En primer lugar, el propio equipo, el negocio, los subcontratistas y la dirección.
Una vez cada dos semanas se realiza un status con cada equipo, donde se analizan métricas durante 10 minutos, se identifican cuellos de botella en el proceso de producción y se desarrolla una solución conjunta: qué se puede hacer para eliminar esos cuellos de botella. Aquí puede pedir ayuda inmediatamente a la dirección si algún problema identificado está fuera de la zona de influencia de los equipos o de la experiencia de colegas que ya hayan encontrado un problema similar.
Sin embargo, entendemos que para acelerar varias veces (y este es exactamente el objetivo que nos propusimos), todavía necesitamos aprender mucho e implementarlo en nuestro trabajo diario. En este momento continuamos ampliando nuestro enfoque de productos a otros equipos y nuevos productos. Para hacer esto, tuvimos que dominar un nuevo formato para nosotros: una escuela de metodólogos en línea.
Los metodólogos, personas que ayudan a los equipos a construir un proceso, establecer comunicaciones y mejorar la eficiencia del trabajo, son esencialmente agentes de cambio. En este momento, los graduados de nuestra primera cohorte están trabajando con equipos y ayudándolos a tener éxito.
Creo que la situación actual nos abre oportunidades y perspectivas de las que quizás nosotros mismos todavía no somos plenamente conscientes. Pero la experiencia y la práctica que estamos adquiriendo ahora confirman que hemos elegido el camino correcto de desarrollo, no perderemos estas nuevas oportunidades en el futuro y podremos responder con la misma eficacia a los desafíos que enfrentará Sportmaster.
Hallazgos
Durante este momento difícil, hemos formulado los principios fundamentales sobre los que se basa el desarrollo de software, que creo que serán relevantes para todas las empresas que se ocupan de este tema.
personas. En esto se basa todo. Los empleados deben disfrutar de su trabajo y comprender los objetivos de la empresa y los objetivos de los productos en los que trabajan. Y, por supuesto, podrían desarrollarse profesionalmente.
Tecnología. Es necesario que la empresa adopte un enfoque maduro para trabajar con su tecnología y desarrollar competencias donde realmente se necesitan. Suena muy simple y obvio. Y muchas veces ignorado.
Процессы. Es importante organizar adecuadamente el trabajo de los equipos de producto y los centros de competencia, establecer interacción con la empresa para poder trabajar con ella como socio.
En general, así es como sobrevivimos. La principal tesis de nuestro tiempo quedó confirmada una vez más, con un sonoro clic en la frente.
Incluso si tiene una gran empresa fuera de línea con muchas tiendas y un montón de ciudades donde opera, desarrolle su negocio en línea. Esto no es sólo un canal de ventas adicional o una bonita aplicación a través de la cual también puedes comprar algo (y también porque la competencia también las tiene bonitas). Esta no es una llanta de repuesto por si acaso para ayudarlo a capear la tormenta.
Esta es una necesidad absoluta. Para lo cual no sólo deben estar preparadas tus capacidades técnicas e infraestructura, sino también tu gente y procesos. Después de todo, puede comprar rápidamente memoria y espacio adicionales, implementar nuevas instancias, etc. en un par de horas. Pero las personas y los procesos deben estar preparados de antemano para ello.
Fuente: habr.com