Si visita nuestras tiendas más de una vez al año para comprar artículos deportivos o ropa, lo más probable es que tenga nuestra tarjeta del club (azul, plata u oro). Mi nombre es Maxim, soy subdirector del departamento de desarrollo, implementación y mantenimiento de software, y en esta publicación hablaremos con colegas sobre el establecimiento del programa del club Sportmaster, sobre la colección de rastrillos que recolectamos en el proceso y cómo nuestro programa del club difiere de las tarjetas de descuento habituales de otros redes comerciales.
Entonces
El año 2004 estaba en el patio. Lo que sucedió fue el programa del club Sportmaster y 27 rublos cada uno. Lo que no era: Internet normal en el campo y canales de comunicación estables en las tiendas.
En esos años, nosotros mismos escribimos un sistema de lealtad que normalmente podía hacer un seguimiento de los puntos de bonificación de cada usuario. Pero dado que ya teníamos muchas tiendas, a diferencia de las instalaciones de procesamiento de datos, nuestra base de datos de bonificaciones completa se encontraba en un archivo, que simplemente se enviaba a las tiendas y se reparaba localmente, y se devolvieron los cambios del día. Por cierto, esta fue la causa principal del hecho de que los bonos se pueden gastar solo al día siguiente después de la compra, y no los requisitos del negocio y garantizar la devolución de los clientes; durante el día, todo esto simplemente no tuvo tiempo de actualizarse y contarse correctamente.
En otras palabras, en ese momento los bonos podrían comenzar a funcionar y, en general, el quinto día, hasta que esta tabla con los bonos recién calculados llegue a todas las tiendas.
Las tarjetas en sí funcionaron de manera bastante simple: cada tarjeta simplemente acumulaba una cierta cantidad de bonos que su propietario podía gastar alegremente y con sentimiento. Es decir, para la base parecía simple, en términos generales, una tarjeta, un dígito. Con las tarjetas doradas fue un poco más complicado: allí, además del número con bonos, también había puntos de servicio. Esto es cuando compraste una bicicleta, y después de seis meses querías apretar la cadena, revisar los frenos, la campana comenzó a calentar tu alma y ahuyentar a los transeúntes, etc. (o afinar los patines para la nueva temporada y arreglar la tabla de snowboard, por ejemplo).
Al mismo tiempo, las bonificaciones se calcularon utilizando las capacidades de una solución basada en la inteligencia natural: tuvimos un empleado especial que escribió las selecciones y las hizo, luego agregó las bonificaciones en una placa especial, y el sistema levantó esta placa. Y sí, si esta persona de repente decidiera animar un poco o qué más, algunos clientes podrían quedarse sin bonos en estos días difíciles.
Por supuesto, esta situación era bastante costosa para las empresas, y de hecho era peligrosa e impredecible, y la empresa quería transferir el sistema a rieles normales (automáticos).
Primero decidimos estudiar el mercado. Nos dimos cuenta de que hay varios sistemas excelentes con excelentes características y etiquetas de precios que son superiores a estas características. Además, con un sistema de licencias de este tipo, según el cual se suponía que debía recoger sobornos no solo por el uso de capacidades o por el software en sí, sino por cada usuario activo en dicho sistema de bonificación. Lo que no pudo sino alegrar a los autores del sistema. Pero nuestro negocio era triste.
El segundo problema también fue el hecho de que con el crecimiento de la base de clientes y el número de tiendas, había una situación en la que una base cada vez más fuerte tenía que enviarse a más y más tiendas. Y un buen día, esta base simplemente dejó de arrastrarse por los canales de comunicación existentes. También se revisó en todas las tiendas en un corto período de tiempo con un gran crujido.
Las bases no tenían tiempo para comprar, a veces debido a esto, las tiendas olvidaron actualizarlas y obtuvieron gachas francas: en la tienda Una persona compró algo útil y recibió un bono, y la tienda B después de un par de días todavía no sabe que una persona podría y deducir bonos de una nueva compra.
Y luego Alexander Afanasyev
(ahora el director de TI de otra compañía) descubrió cómo hacer todo esto usted mismo sin comprar software de terceros. Recogí de la empresa una serie de requisitos para este sistema por su parte y registré nuevas oportunidades. Al principio es solo en forma de características agradables, por ejemplo, ahora los bonos no son solo un número, sino un sistema complejo completo. Puede dar bonos a una persona por un cumpleaños, puede dar un bono por separado solo en esquís y productos relacionados, puede ofrecer bonos solo en productos de la marca Columbia y en ciertos períodos de tiempo, y todo esto, combinar, combinar, combinar.
Afortunadamente, el desarrollo de la red ha llegado al punto en que Internet ya ha aparecido en casi todas partes, y fue posible poner la solución en línea. Es decir, el esquema de trabajo se ha vuelto así: hay una tienda con un canal de red estable, se pone en contacto con la base de datos para el resto (y ahora la base de datos es la más fresca y sabrosa), toma el resto de las bonificaciones de la base de datos y ya funciona con ella. Y todo esto, mientras el comprador se comunica felizmente con un vendedor amigable.
El tercer problema era el desempeño de las operaciones de quema de bonificaciones. Tenemos lo mismo: puede ganar puntos durante todo el año fervientemente, pero el 1 de marzo siempre se agotan traidoramente si no logra gastarlos.
La primera versión del sistema (llamada CARDS) normalmente podría tenerlos en cuenta, pero cuando se cambió al modo de planta incineradora de bonificación, comenzaron los problemas. Después de todo, la quema de bonos es un paso completo a través de toda la base con cambios. Dado el tamaño de la base, esto podría tomar de 3 a 4 días. Además, en el proceso, ella se desaceleró terriblemente y fue estúpida, por lo que a veces se interrumpió la quema de bonos, y resultó que en alguna tienda, el camarada Petrov, que había venido por nuevas pelotas de ping-pong, todavía tenía bonos, y Sidorov, que había ido por desafortunadamente, no hay uno nuevo genial.
Nueva versión del sistema.
Hicimos un prototipo en algún lugar en 3-4 días, luego un par de días lo probamos en cheques en vivo. Resultó que el sistema es bastante funcional por sí mismo, y puede usarlo para generar diferentes condiciones de bonificación y generar textos de comunicación.
Por cierto, sobre las comunicaciones: desde el principio lo hicimos para que el sistema de fidelización en el momento adecuado formara los textos de las comunicaciones con los clientes, extrayendo puntos de bonificación de la base de datos y enviándolos a los clientes. Teníamos muchos clientes, por lo que utilizamos proveedores externos en ese momento para enviar SMS.
La interacción con ellos fue algo como esto:
- el proveedor entendió que era un cliente importante y comenzó a alegrarse
- un cliente importante en la forma de nosotros especificó si el proveedor realmente manejaría dichos correos
- el proveedor dijo que dominará, por supuesto
- el proveedor recibió la tarea de enviar una gran cantidad de SMS en un corto período de tiempo y decidió acostarse para descansar
Entonces, sobre el prototipo. En principio, se decidió que todo el sistema se rediseñó en gran medida, porque inicialmente se agudizó solo por bonos y no por trabajo en línea, por lo que se esperaba que dejara de hacer frente a la devolución. Además, cayó, por supuesto, en momentos de alta carga. Es decir, en el momento más delicioso para la tienda: Año Nuevo, 8 de marzo, 23 de febrero y otras fechas agradables.
El sistema cae -> cae el estado de ánimo del negocio -> cae el estado de ánimo de todos.
Junto con un colega, reescribimos el sistema de acuerdo con el siguiente principio.
Componente 1. Preprocesamiento que da la respuesta a las tiendas lo más rápido posible.
Componente 2. Procesamiento, la misma caja mágica, bonos difíciles e ingeniosamente acreditables en cheques de productos.
Componente 3. Marketing, reuniendo todo esto y formando textos de comunicaciones.
Además, resolvimos el problema de quemar bonificaciones. El nuevo sistema simplemente no los quemó. Después de todo, si no obliga al sistema a quemar bonos, no tiene problemas para quemar bonos.
En la nueva versión, el sistema simplemente almacena los bonos de cada cliente en la base de datos, pero en algún momento deja de considerarlos activos. Es decir, ahora siempre hay bonificaciones, pero cada una con su propio período de actividad. Lo cual, por cierto, permitió la introducción de promociones y campañas más precisas y más urgentes.
El viejo sistema en realidad solo guardaba registros de tarjetas y bonos en estas tarjetas. El nuevo sistema no prioriza una tarjeta, sino la cuenta de una persona. Podemos identificarlo por número de teléfono (esto nos funciona desde el principio, fuimos uno de los primeros en implementar la autorización por número de teléfono).
Una característica adicional del nuevo sistema son los llamados bonos de producto, funciona así:
- cada producto tiene atributos (nombre, categoría de producto, tamaño, color, deporte, otro, otro, otro).
- El sistema combina estos atributos, formando una condición lógica para acumular bonos.
- cuando llega un cheque, esta condición siempre se verifica.
Mostramos este prototipo en el trabajo empresarial. Los negocios dieron el visto bueno.
Comenzamos a escribir el sistema el 1 de marzo, lo pusimos en funcionamiento el 27 de octubre de 2013 (escribimos juntos, sí). De hecho, la fecha de entrega prevista era el 1 de septiembre, pero la contraparte principal del sistema no tenía tiempo: las tiendas minoristas. Las tiendas no tuvieron tiempo por varias razones, además, no todos actualizaron el software de la caja registradora (y actualizar el software de la caja registradora en una red bastante grande sigue siendo un problema). Por lo tanto, lo pospusieron, los esperaron y comenzaron el 27 de octubre.
Ideología del sistema
Establecieron la idea principal: ni la tienda ni el software de la caja registradora ya funcionan con la lógica de los bonos. La tienda ahora solo envía la cesta del cliente al Centro, el Centro procesa todo, le da a la tienda un cálculo de bonificaciones.
Ahora los bonos se reparten así:
- En primer lugar, los bonos se reparten por todo el cheque de manera uniforme, para todos los artículos básicos. Esto es útil para análisis y ayuda en caso de devolución de bienes.
- Introdujimos el concepto de bonos prioritarios. Los bonos son productos básicos, hay bonos para cumpleaños, que tienen un corto período de validez, hay otros regulares (los más tenaces). Por lo tanto, primero cancelamos bonos específicos. Es decir, una persona vino a esquiar, principalmente cancelaremos las bonificaciones que tiene en los esquís. Y resulta que vino a esquiar, cancelamos los bonos regulares. Una semana después vendrá por una chaqueta, y le daremos un hombre, solo tienes bonificaciones por esquiar. Quieres esquiar Lo mismo con las compras durante los períodos de cumpleaños, primero cancele y luego las regulares.
- Llevamos operaciones de back office y el frente. Ahora, las tiendas que vienen con solicitudes no afectan el trabajo y el rendimiento del servicio que calcula los bonos, y viceversa.
En general, fue posible obstruir todos los problemas antiguos y, en lugar de problemas nuevos, agregar nuevas funciones.
En lugar de retraso, tuvimos este cuaderno de Alexander.
Lanzar una nueva versión del sistema.
Dado que el nuevo sistema era diferente del anterior, no solo técnicamente, sino también ideológicamente, no podíamos implementarlo de manera parcial, en la mitad de las tiendas o de alguna manera. Solo tuvimos que apagar el viejo y encender el nuevo.
Suena bien, pero de hecho se reduce a un par de limitaciones.
En primer lugar, debido a la gran cantidad de tiendas (más de 1200), tuvimos que hacer todo en 3 horas. Mientras que una tienda cierra a medianoche en una zona horaria, otra tiene un horario completamente diferente, y luego también hay una tienda de conveniencia. En general, para convertir todos los datos del sistema anterior, alimentar el nuevo, iniciar en tres servidores a la vez, 3 horas.
Las trampas fueron así:
- El sistema se cortó inmediatamente en toda la red. Si todo es bueno en todas partes, todo funciona en toda la red. Si algo cae, sí, cae en toda la red.
- Cuando enciende el nuevo sistema, debe contener todos los datos que estaban en el sistema antiguo en el momento en que cerraron las tiendas y se emitió la última bonificación. Nos lanzamos a 4 países a la vez. La base de datos era más de un terabyte y almacenaba cientos de miles de millones de registros.
- A las 23.00 tuvimos que apagar el sistema. Convierte todo. Vierte en el nuevo sistema. Incluye todo. En este caso, todo debería funcionar.
Entrenamos durante mucho tiempo, colgamos guiones en la mayoría de los placeres. Después de largas pruebas e intentos de hacer todo lo más rápido posible, logramos el mejor resultado a las 9 en punto.
Lo cual era ligeramente diferente de la cifra prevista de 3 horas.
Luego decidimos hacer primero el preprocesamiento, que mantuvo los restos en nosotros mismos. Levantó el servidor principal, contactó a las tiendas. Al mismo tiempo, no sabía que todo el sistema aún no había aumentado, y en ese momento estábamos rodando valientemente todo lo demás.
Pero aún así, tal volumen de datos en máquinas estándar no se pudo hacer de manera oportuna.
Y aquí debe tenerse en cuenta Oracle Exadata. Los chicos de Oracle hicieron una pieza especial de hardware que funciona muy bien con su propia base de datos, e incluso en unidades flash. En general, se tomó una decisión decidida de usar Exadata. Con su ayuda en las pruebas, dominamos hacer todo lo que necesita en 2 horas en lugar de 9 y nos dimos cuenta: tenemos que tomarlo.
Dado que somos hombres meticulosos, en el proceso de configuración y trabajo, recogimos un montón de errores y fallamos en el soporte de Oracle con un margen. Por ejemplo, hubo un error interesante: debido a un error en el procesamiento interno de la solicitud, Oracle comenzó a consumir intensamente TEMP. Notamos esto a tiempo, y le lanzamos archivos TEMP'ovyh, fue muy interesante cuando se emborrachó. Pero como la pieza de hierro resultó ser muy sensata y bien informada, usó 3 Tb TEMP con sentimiento durante 10 minutos, se dio cuenta de que ya no estaba y se retiró. Tuve que encontrar soluciones alternativas.
Por un lado, fue genial que todo en términos de conversión lo hicimos en 2 horas. Por otro lado, en todo el proceso de conversión limpia, 2 horas, y también planeamos:
- Vuelva a cargar todos los datos de los servidores del sistema anterior a exadata, porque cuenta todo muy rápido.
- Convierta datos de estructuras antiguas a nuevas.
- Vierta todo esto convertido bien en tres servidores diferentes.
Al mismo tiempo, en cada base de datos había un montón de información de servicio útil, como los mismos índices que podrían ayudar durante la reconstrucción, pero obtuvimos un puntaje y decidimos reconstruir todo nuevamente en los servidores de batalla.
Preparación
Nos preparamos con poder y principal. Estábamos durmiendo en el trabajo. Nos colgamos no solo con scripts, sino también con muchas métricas.
A las 23.00 todos los días comenzamos el proceso y monitoreamos las métricas. Hicimos los cambios necesarios, como resultado, configuramos todo para que nada salga mal.
Por supuesto, el día del lanzamiento algo salió mal.
Para nuestro honor, el cant no estaba de nuestro lado. En algún lugar, la red parpadeó estúpidamente. Es decir, te sientas así, ajustas todo para que el mosquito no solo no socave su nariz, sino que ni siquiera tenga tiempo para pensarlo, y en algún lugar, alguien simplemente tire del cable equivocado.
De todos modos, logramos iniciar el primer servidor a tiempo. La fecha límite general era las 5 de la mañana, para esta hora todos los servidores deberían estar alegres y alegres, porque las primeras tiendas en el Lejano Oriente abren a las 10 en su horario.
Así que el último servidor comenzó a las 11 de la mañana. Pero como construimos el sistema de tal manera que todo estaba aislado, todo funcionó bien.
Ahora
Actualmente, 14 desarrolladores y 8 analistas están trabajando en el sistema del club. Teniendo en cuenta todos los beneficios con los que nos juntamos, ya no se trata solo de una tarjeta que le brinda una cierta cantidad de bonos disponibles para gastar en las tiendas.
Comenzamos a combinar completamente las bonificaciones. El criterio principal para una combinación exitosa para el sistema es el beneficio máximo para el comprador. Puede haber muchas utilidades y promociones, por ejemplo:
- el usuario ha acumulado una buena cantidad de bonos regulares;
- más ahora el período cuando hay una acción en una marca en particular;
- Además ahora los descuentos también en un grupo de productos y subgrupo específicos;
- y también puede haber un descuento en una ciudad en particular o en una tienda en particular.
Escribimos un algoritmo que recibe un cheque de una tienda, atropella los artículos del producto en el cheque, le aplica todas las promociones y descuentos posibles en una fecha determinada y en una ciudad determinada, y brinda el resultado más beneficioso para el usuario. Luego lo devuelve todo a la tienda. Y todavía hay direcciones de desarrollo:
- Desarrollo de un mecanismo para lanzar complejas campañas de marketing multidireccional, incluido el envío de correos, la provisión de bonos, descuentos y ofertas de personalización para un cliente
- Conexión de nuevos canales de comunicación, como mensajería instantánea, redes sociales, etc.
Un cliente agradecido puede recordar en este momento que también quería comprar calcetines y pide agregarlos al cheque. Por supuesto, agregar calcetines (o lo que sea) requiere un recuento completo.
Pero también nos ocuparemos de esto. Y en una de las publicaciones futuras le contaremos la historia de la creación del sitio del Sportmaster.