Se você visitar nossas lojas mais de uma vez por ano para artigos esportivos ou roupas, provavelmente terá o nosso cartão do clube (azul, prata ou ouro). Meu nome é Maxim, sou vice-diretor do departamento de desenvolvimento, implementação e manutenção de software e, neste post, falaremos com colegas sobre o estabelecimento do programa de clubes da Sportmaster, sobre a coleta de rakes que coletamos no processo e como nosso programa de clubes difere dos cartões de desconto comuns de outros redes de negociação.
Então
O ano de 2004 estava no quintal. O que aconteceu foi o programa de clubes da Sportmaster e 27 rublos cada. O que não era - Internet normal no campo e canais de comunicação estáveis nas lojas.
Naqueles anos, nós mesmos escrevemos um sistema de fidelidade que normalmente poderia acompanhar os pontos de bônus de cada usuário. Porém, como já tínhamos muitas lojas, em contraste com as instalações de processamento de dados, todo o nosso banco de dados de bônus estava localizado em um arquivo, que era simplesmente enviado às lojas e atendido localmente, e as alterações do dia foram retornadas. A propósito, essa foi a principal razão pela qual os bônus podem ser gastos apenas no dia seguinte à compra, e não os requisitos dos negócios e a provisão de devoluções dos clientes - durante o dia, tudo isso simplesmente não tinha tempo para ser atualizado e recontado adequadamente.
Em outras palavras, naquele momento os bônus poderiam começar a funcionar e, em geral, no quinto dia - até que esta tabela com os bônus calculados recentemente chegue a todas as lojas.
As próprias cartas funcionavam de maneira bastante simples - cada uma delas acumulava um certo número de bônus que seu dono podia gastar com alegria e emoção. Ou seja, para a base, parecia simples, grosso modo, um cartão - um dígito. Com os cartões de ouro era um pouco mais complicado - ali, além do número com bônus, havia também pontos de serviço. Foi quando você comprou uma bicicleta e, após seis meses, queria apertar a corrente, checar os freios, o sino começou a aquecer sua alma e afugentar os transeuntes e assim por diante (ou afiar os patins para a nova temporada e consertar o snowboard, por exemplo).
Ao mesmo tempo, os bônus foram calculados usando os recursos de uma solução baseada em inteligência natural - tivemos um funcionário especial que escreveu e fez seleções, depois adicionou bônus em um prato especial e o sistema puxou esse prato. E sim, se essa pessoa de repente decidisse torcer um pouco ou o que mais - alguns clientes poderiam ficar sem bônus nesses dias difíceis.
Obviamente, essa situação era muito cara para os negócios e, de fato, era perigosa e imprevisível, e os negócios queriam transferir o sistema para trilhos normais (automáticos).
Primeiro, decidimos estudar o mercado. Percebemos que existem vários sistemas excelentes com ótimos recursos e preços que são superiores a esses recursos. Além disso, com esse sistema de licenciamento, de acordo com o qual ele deveria coletar subornos, não apenas pelo uso de capacidades ou pelo próprio software, mas por cada usuário ativo em um sistema de bônus. O que não podia deixar de alegrar os autores do sistema. Mas nosso negócio era triste.
O segundo problema também foi o fato de que, com o crescimento da base de clientes e o número de lojas, havia uma situação em que uma base cada vez mais pesada tinha que ser enviada para mais e mais lojas. E um belo dia, essa base simplesmente parou de rastrear os canais de comunicação existentes. Também foi revisado em todas as lojas em um curto período de tempo, com um grande rangido.
As bases não tinham tempo para fazer compras, às vezes as lojas se esqueciam de atualizá-las e tinham mingau franco - na loja Uma pessoa comprou algo útil e recebeu um bônus, e a loja B depois de alguns dias ainda não está ciente de que uma pessoa poderia e deduzir bônus de uma nova compra.
E então Alexander Afanasyev
(agora diretor de TI de outra empresa) descobriu como fazer tudo isso sozinho sem comprar software de terceiros. Reuni no negócio vários requisitos para esse sistema e registrei novas oportunidades. No início, é apenas na forma de recursos agradáveis - por exemplo, agora os bônus não são apenas um número, mas todo um sistema complexo. Você pode dar bônus a uma pessoa por um aniversário, você pode dar bônus separadamente apenas em esquis e itens de produtos relacionados, você pode oferecer bônus apenas em produtos da marca Columbia e em determinados períodos de tempo - e tudo isso, combinar, combinar, combinar.
Felizmente, o desenvolvimento da rede chegou ao ponto em que a Internet já apareceu em quase todos os lugares, e foi possível colocar a solução online. Ou seja, o esquema de trabalho tornou-se assim - há uma loja com um canal de rede estável, ele vai para a base pelo resto através da rede (e agora a base é a mais fresca e deliciosa), pega o restante dos bônus da base e já trabalha com ela. E tudo isso, enquanto o comprador se comunica alegremente com um vendedor amigável.
O terceiro problema foi o desempenho de operações de queima de bônus. Temos a mesma coisa - você pode ganhar pontos o ano todo fervorosamente, mas em 1º de março eles sempre se esgotam traiçoeiramente se você não conseguir gastá-los.
A primeira versão do sistema (chamada CARDS) normalmente poderia levá-los em consideração, mas quando mudou para o modo de instalação de incinerador de bônus, os problemas começaram. Afinal, queimar bônus é uma passagem completa por toda a base com alterações. Dado o tamanho da base, isso pode levar de 3 a 4 dias. Além disso, no processo, ela desacelerou terrivelmente e foi estúpida, por causa da qual às vezes a queima de bônus era interrompida, e, em algumas lojas, o camarada Petrov, que havia buscado novas bolas de pingue-pongue, ainda tinha bônus, e Sidorov, que procurava infelizmente, nenhum novo grande.
Nova versão do sistema
Fizemos um protótipo em algum lugar em 3 a 4 dias e, em alguns dias, testamos em testes ao vivo. Verificou-se que o sistema é bastante funcional para si próprio, e você pode usá-lo para gerar diferentes condições de bônus e gerar textos de comunicação.
A propósito, sobre comunicações - desde o início, fizemos com que o próprio sistema de fidelidade, no momento certo, formasse os textos de comunicação com os clientes, extraindo pontos de bônus do banco de dados e enviando-os para os próprios clientes. Como tínhamos muitos clientes, usamos na época fornecedores de terceiros para enviar SMS.
A interação com eles foi mais ou menos assim:
- o provedor entendeu que ele era um grande cliente e começou a se alegrar
- um cliente importante na forma de nós especificou se o provedor realmente lidaria com essas correspondências
- o provedor disse que vai dominar, é claro
- o provedor recebeu a tarefa de enviar uma enorme quantidade de SMS em um curto período de tempo e decidiu descansar
Então, sobre o protótipo. Em princípio, todo o sistema foi decidido a ser reprojetado, porque inicialmente era aprimorado apenas para bônus, e não para trabalho on-line, e, portanto, esperava-se que ele deixasse de lidar com retornos. Além disso, caiu, é claro, durante momentos de alta carga. Ou seja, no momento mais delicioso da loja - Ano Novo, 8 de março, 23 de fevereiro e outras datas agradáveis.
O sistema cai -> o humor dos negócios cai -> o humor de todos cai.
Juntamente com um colega, reescrevemos o sistema de acordo com o seguinte princípio.
Componente 1. Pré-processamento que fornece a resposta para as lojas o mais rápido possível.
Componente 2. Processamento, a mesma caixa mágica, bônus difíceis e habilmente creditados em verificações de mercadorias.
Componente 3. Marketing, reunindo tudo isso e formando textos de comunicação.
Além disso, resolvemos o problema de queima de bônus. O novo sistema simplesmente não os queimou. Afinal, se você não forçar o sistema a queimar bônus - você não terá problemas com a queima de bônus.
Na nova versão, o sistema simplesmente armazena os bônus de cada cliente no banco de dados, mas em algum momento deixa de considerá-los ativos. Ou seja, agora sempre há bônus, mas cada um com seu próprio período de atividade. O que, aliás, permitiu a introdução de promoções e campanhas mais precisas e mais urgentes.
O sistema antigo, na verdade, apenas mantinha registros de cartões e bônus nesses cartões. O novo sistema não prioriza um cartão, mas a conta de uma pessoa. Podemos identificá-lo por número de telefone (isso funciona para nós desde o início, fomos os primeiros a implementar a autorização por número de telefone).
Um recurso adicional do novo sistema são os chamados bônus do produto, funciona assim:
- cada produto possui atributos (nome, categoria do produto, tamanho, cor, esporte, outro, outro, outro).
- o sistema combina esses atributos, formando uma condição lógica para acumular bônus.
- quando chega uma verificação, essa condição é sempre verificada.
Mostramos esse protótipo no trabalho comercial. Os negócios deram o aval.
Começamos a escrever o sistema em 1º de março e colocamos em operação em 27 de outubro de 2013 (escrevemos juntos, sim). De fato, a data de entrega planejada era 1º de setembro, mas a principal contraparte do sistema não possuía lojas de varejo de tempo. As lojas não tiveram tempo por várias razões, e nem todos atualizaram o software da caixa registradora (e atualizar o software da caixa registradora em uma rede bastante grande ainda é um problema). Por isso, adiaram, esperaram por eles e começaram em 27 de outubro.
Ideologia do sistema
Eles criaram a idéia principal - nem a loja nem o software de caixa registradora funcionam mais com a lógica dos bônus. A loja agora apenas envia a cesta do cliente para o Centro, o Centro processa a coisa toda, fornece à loja um cálculo de bônus.
Agora os bônus são distribuídos assim:
- Em primeiro lugar, os bônus são distribuídos uniformemente por todo o cheque, para todos os itens de mercadorias. Isso é útil para análises e ajuda em caso de devolução de mercadorias.
- Introduzimos o conceito de bônus prioritários. Bônus são mercadorias, existem bônus para aniversários, que têm um curto período de validade, existem regulares (os mais tenazes). Portanto, primeiro baixamos bônus específicos. Ou seja, uma pessoa veio para esquiar - vamos deduzir principalmente os bônus que ela tem nos esquis. E acontece que ele veio esquiar, escrevemos bônus regulares. Uma semana depois, ele virá para uma jaqueta, e nós lhe daremos um homem, você só tem bônus para esquiar. Você quer esquiar? O mesmo ocorre com as compras durante os períodos de aniversário, primeiro anote-as e depois as regulares.
- Realizamos operações de back office e de frente. Agora, as lojas que vêm com solicitações não afetam o trabalho e o desempenho do serviço que calcula os bônus e vice-versa
Em geral, era possível entupir todos os problemas antigos e, em vez de novos problemas, adicionar novos recursos.
Em vez de pendências, tivemos este caderno de anotações de Alexander.
Lançando uma nova versão do sistema
Como o novo sistema era diferente do antigo, não apenas tecnicamente, mas também ideologicamente, não poderíamos lançá-lo de alguma forma parcialmente, na metade das lojas ou de alguma forma. Nós apenas tivemos que desligar o antigo e ativar o novo.
Parece bom, mas na verdade se resume a algumas limitações.
Em primeiro lugar, devido ao grande número de lojas (mais de 1200), tivemos que fazer tudo em 3 horas. Enquanto uma loja fecha à meia-noite em um fuso horário, outra tem uma hora completamente diferente e também há uma loja de conveniência. Em geral, para converter todos os dados do sistema antigo, alimente o novo, inicie em três servidores ao mesmo tempo - 3 horas.
As armadilhas eram assim:
- O sistema foi cortado imediatamente em toda a rede. Se tudo estiver bem em qualquer lugar - tudo funcionará em toda a rede. Se algo cai, sim, cai por toda a rede.
- Quando você liga o novo sistema, ele deve conter todos os dados que estavam no sistema antigo no momento em que as lojas foram fechadas e o bônus mais recente foi emitido. Lançamos em 4 países ao mesmo tempo. O banco de dados tinha mais de um terabyte e armazenava centenas de bilhões de registros.
- Às 23h00, tivemos que desligar o sistema. Converta tudo. Despeje no novo sistema. Inclua tudo. Nesse caso, tudo deve funcionar.
Nós treinamos por um longo tempo, penduramos scripts nos mais indulgentes. Após longos testes e tentativas de fazer tudo o mais rápido possível, alcançamos o melhor resultado às 9 horas.
O que era um pouco diferente da figura planejada de 3 horas.
Então decidimos primeiro fazer o pré-processamento, que mantinha os restos em nós mesmos. Levantou o servidor principal, ele entrou em contato com as lojas. Ao mesmo tempo, ele não sabia que todo o sistema ainda não havia surgido e, naquela época, estávamos bravamente lançando todo o resto.
Mas, ainda assim, esse volume de dados em máquinas padrão não pôde ser feito em tempo hábil.
E aqui deve ser observado o Oracle Exadata. Os caras da Oracle criaram um hardware especial que funciona muito bem com seu próprio banco de dados e até em drives flash. Em geral, foi tomada uma forte decisão de usar o Exadata. Com sua ajuda nos testes, nós dominamos tudo o que você precisa em 2 horas em vez de 9 e percebemos - precisamos fazer isso.
Como somos pessoas meticulosas, no processo de configuração e funcionamento, detectamos vários bugs e falhamos no suporte do Oracle com uma margem. Por exemplo, houve um bug interessante - devido a um erro no processamento interno da solicitação, o Oracle começou a consumir intensivamente o TEMP. Percebemos isso a tempo, e jogamos para ele arquivos TEMP'ovyh, foi muito interessante quando ele ficou bêbado. Mas como o pedaço de ferro mostrou-se muito sensível e conhecedor, ela usou TEMP de 3 Tb com sensação por 10 minutos, percebeu que não era mais e foi para a cama. Eu tive que propor soluções alternativas.
Por um lado, foi legal que tudo em termos de conversão fizemos em 2 horas. Por outro lado, em todo o processo de conversão limpa, 2 horas, e também planejamos:
- recarregue todos os dados dos servidores do sistema antigo para exadados, porque conta tudo rapidamente.
- Converta dados de estruturas antigas em novas.
- Despeje tudo isso convertido em três servidores diferentes.
Ao mesmo tempo, em cada banco de dados havia várias informações úteis sobre serviços, como os mesmos índices que poderiam ajudar durante a reconstrução, mas pontuamos isso e decidimos reconstruir tudo novamente nos servidores de batalha.
Preparação
Nós preparamos com poder e principal. Estávamos dormindo no trabalho. Nos penduramos não apenas com scripts, mas também com muitas métricas.
Às 23:00 todos os dias, iniciamos o processo e monitoramos as métricas. Fizemos as alterações necessárias e, como resultado, configuramos tudo para que nada pudesse dar errado.
Obviamente, no dia do lançamento, algo deu errado.
Para nossa honra, o cant não estava do nosso lado. Em algum lugar a rede piscou estupidamente. Ou seja, você se senta assim, ajusta tudo para que o mosquito não apenas prejudique seu nariz, mas nem sequer tem tempo para pensar nisso - e em algum lugar alguém puxa o cabo errado.
Enfim, conseguimos iniciar o primeiro servidor a tempo. O prazo geral era 5 da manhã; a essa altura, todos os servidores deveriam estar animados e alegres, porque as primeiras lojas do Extremo Oriente abrem às 10 da manhã.
Portanto, o último servidor começou às 11 da manhã. Mas como construímos o sistema de forma que tudo estava isolado, tudo funcionou bem.
Agora
Atualmente, 14 desenvolvedores e 8 analistas estão trabalhando no sistema do clube. Considerando todas as vantagens que encontramos, esse não é mais apenas um cartão que oferece um certo número de bônus disponíveis para gastar nas lojas.
Começamos a combinar totalmente os bônus. O principal critério para uma combinação bem-sucedida do sistema é o benefício máximo para o comprador. Pode haver muitos utilitários e promoções, por exemplo:
- o usuário acumulou um bom número de bônus regulares;
- mais agora o período em que há uma ação em uma determinada marca;
- além de agora descontos também em um grupo e subgrupo de produtos específicos;
- e também pode haver um desconto em uma cidade ou loja específica.
Escrevemos um algoritmo que recebe um cheque de uma loja, percorre os itens do produto no cheque, aplica todas as promoções e descontos possíveis em uma determinada data e em uma determinada cidade e fornece o resultado mais benéfico para o usuário. Então ele devolve tudo à loja. E ainda existem direções de desenvolvimento:
- Desenvolvimento de um mecanismo para o lançamento de complexas campanhas de marketing de várias vias, incluindo correspondência, fornecimento de bônus, descontos e personalização de ofertas para um cliente
- Conexão de novos canais de comunicação, como mensagens instantâneas, redes sociais, etc.
Nesse momento, um cliente agradecido pode se lembrar de que também queria comprar meias e pede para adicioná-las ao cheque. É claro que adicionar meias (ou o que seja) requer uma recontagem completa.
Mas também vamos lidar com isso. E em um dos próximos posts, contaremos a história da criação do site do Sportmaster.