如果您每年不止一次访问我们的商店以购买体育用品或服装，则很可能拥有我们的俱乐部卡（蓝色，银色或金色）。 我叫马克西姆（Maxim），我是软件开发，实施和维护部门的副主任，在这篇文章中，我们将与同事讨论Sportmaster俱乐部计划的建立，我们在此过程中收集的佣金收集以及我们的俱乐部计划与其他普通折扣卡有何不同交易网络。
然后
2004年在院子里。 发生的是Sportmaster的俱乐部计划和每个27卢布。 什么不是-现场正常的互联网和商店稳定的沟通渠道。
在那些年里，我们自己编写了一个忠诚度系统，该系统通常可以跟踪每个用户的奖励积分。 但是由于与数据处理设施相比，那时我们已经有很多商店，所以我们的整个奖金数据库都位于一个文件中，该文件被简单地发送到商店并在本地提供服务，并返回当天的更改。 顺便说一句，这是奖金只能在购买后的第二天才花掉的原因，而不是业务要求和确保客户回头的原因-在一天之内，所有这些根本没有时间进行适当地更新和重新计算。
换句话说，那时奖金可以开始使用，并且通常在第五天开始工作，直到带有新计算的奖金的表格到达所有商店为止。
这些卡本身的工作非常简单-每张卡仅累积了一定数量的奖金，其所有者可以快乐地使用它们并感觉得到。 也就是说，对于基数来说，看起来很简单，大概是一张卡-一位数字。 对于金卡，情况要复杂一些-除了带奖金的数字外，还有服务点。 这是当您购买自行车时，六个月后您想拧紧链条，检查刹车，铃铛开始温暖您的灵魂，吓跑过路人等等（或为新季节磨冰鞋并固定滑雪板）。
同时，奖金是使用基于自然智能的解决方案的力量来计算的-我们有一名特殊的员工来撰写选择和做出选择，然后将奖金添加到特殊的标牌中，然后系统将该标牌拉高。 是的，如果这个人突然决定加油或别的什么-在这些困难的日子里，有些客户可能会失去奖金。
当然，这种情况对于企业来说是相当昂贵的，并且确实是危险且不可预测的，并且企业希望将系统转移到正常（自动）导轨上。
首先，我们决定研究市场。 我们意识到，有几种出色的系统，具有出色的功能和价格优势，优于这些功能。 而且，在这样的许可系统中，据认为，该系统不仅仅为了使用容量或软件本身而收取贿赂，而且还为这种奖励系统中的每个活跃用户收取贿赂。 什么让该系统的作者感到高兴。 但是我们的生意很糟糕。
第二个问题是，随着客户群的增长和商店数量的增加，有一种情况是必须将越来越庞大的客户群发送到越来越多的商店。 有一天，这个基地只是停止了通过现有通信渠道的爬网。 在短时间内，所有商店都对它进行了审查，并发出巨大的吱吱声。
基地没有时间购物，有时正因为如此，商店忘了更新它们，所以他们得到了稀饭-在商店A中某人购买了有用的东西并获得了奖金，而商店B在几天后仍然不知道一个人可以并从新购买中扣除奖金。
然后，亚历山大·阿凡纳西耶夫
（ Alexander Afanasyev
，现为另一家公司的IT主管）想出了如何自己完成所有这些而无需购买第三方软件的方法。 我从企业方面收集了对该系统的一些要求，并注册了新的机会。 起初它只是令人愉悦的功能形式-例如，现在奖金不仅是一个数字，而是整个复杂的系统。 您可以为一个人的生日提供奖金，您可以单独为滑雪板和相关产品提供奖金，也可以仅在某些时间段为哥伦比亚品牌产品提供奖金-所有这些都结合起来，结合起来，结合起来。
幸运的是，网络的发展已经达到互联网几乎无处不在的地步，并且可以将解决方案在线。 就是说，工作方案已经变成这样-一家商店拥有稳定的网络渠道，它与数据库联系以获取其余部分（现在数据库是最新鲜和最美味的），从数据库中获取剩余的奖金并已经可以使用它。 而所有这些，在买家愉快地与友好的卖家进行沟通的同时。
第三个问题是奖金燃烧操作的性能。 我们有同样的想法-您可以全年狂热地赚取积分，但是如果您没有设法花掉积分，那么3月1日，积分总是会变得疯狂。
该系统的第一个版本（称为CARDS）通常可以将它们考虑在内，但是当切换到奖励焚烧厂模式时，就会出现问题。 毕竟，随着变化，燃烧奖金是整个基础的完整通道。 给定基地的规模，这可能需要3-4天。 在此过程中，她极力地放慢脚步，哑口无言，因此有时花红被打断了。结果发现，在一些商店里，去买新乒乓球的彼得罗夫同志仍然有花红，而西多罗夫则去了不幸的是，没有新的伟大的。
系统的新版本
我们在3-4天的时间里制作了一个原型，然后几天就通过实时检查对其进行了测试。 事实证明，该系统本身具有相当的功能，您可以使用它来生成不同的奖励条件并生成通讯文本。
顺便说一下，关于通讯-从一开始我们就做到了，以便忠诚度系统本身在正确的时间形成与客户进行通讯的文本，从数据库中提取奖励积分，然后将其发送给我们自己。 我们有很多客户，因此我们当时使用第三方提供商来发送SMS。
与他们的互动像这样：
- 提供者知道他是主要客户，因此开始感到高兴
- 我们形式的主要客户指定提供商是否会实际处理此类邮件
- 提供者说，它将掌握
- 提供商接受了在短时间内发送大量短信的任务，因此决定躺下休息
因此，关于原型。 原则上，决定对整个系统进行重新设计，因为最初它仅针对奖金而不是用于在线工作而进行了优化，因此预期它将停止应对收益。 而且，当然，在高负载的时候，它会掉下来。 也就是说，在商店中最美味的时间-新年，3月8日，2月23日和其他宜人的日子。
系统下降->企业情绪下降->每个人的情绪下降。
我们与同事一起根据以下原则重写了该系统。
组件1.预处理，可以尽快给出存储答案。
组成部分2。处理相同的魔盒，困难而巧妙地将商品支票的奖金记入贷方。
组成部分3.营销，将所有这些收集在一起并形成沟通文本。
另外，我们解决了烧掉奖金的问题。 新系统根本没有烧掉它们。 毕竟，如果您不强迫系统刻录奖金-刻录奖金就没有问题。
在新版本中，系统仅将每个客户的奖金存储在数据库中，但是在某个时间点，它将不再认为它们处于活动状态。 也就是说，现在总有奖金，但每个奖金都有自己的活动期限。 顺便说一句，这允许引入更准确，更紧急的促销和运动。
旧系统实际上只是保留了卡和这些卡上的奖金的记录。 新系统不会优先考虑卡，而是优先考虑一个人的帐户。 我们可以通过电话号码识别它（这件事从一开始就对我们有用，我们是第一个通过电话号码实施授权的人）。
新系统的另一个功能是所谓的产品奖金，它的工作方式如下：
- 每个产品都有属性（名称，产品类别，尺寸，颜色，运动，其他，其他，其他）。
- 该系统结合了这些属性，形成了累积奖金的逻辑条件。
- 当支票到达时，将始终检查此条件。
我们在业务工作中展示了该原型。 业务批准了。
我们从3月1日开始编写系统，并于2013年10月27日投入运行（我们共同编写，是的）。 实际上，计划的交付日期是9月1日，但是系统的主要交易对手没有时间-零售商店。 商店由于多种原因没有时间，而且并非每个人都更新了收银机软件（并且在相当大的网络上更新收银机软件仍然很痛苦）。 因此，他们推迟了等待的时间，并于10月27日开始。
系统思想
他们提出了主要思想-商店和收银软件都不再符合奖金的逻辑。 现在，商店只是将客户的购物篮发送到中心，中心会处理整个事情，并给商店计算奖金。
现在奖金是这样分配的：
- 首先，对于所有商品，奖金平均分配到支票上。 这对于分析很有用，并在退货时有所帮助。
- 我们介绍了优先奖金的概念。 红利是商品，生日有红利，有效期短，有定期红利（最顽强）。 因此，我们首先注销特定的奖金。 也就是说，一个人来滑雪-我们将主要核销他在滑雪上获得的奖金。 事实证明，他是来滑雪的，我们注销了定期奖金。 一周后，他将来一件夹克，我们将给他一个男人，您只有滑雪奖金。 你想滑雪吗？ 在生日期间购买商品时，请先注销，然后再定期购买。
- 我们进行后台办公和前台。 现在，随请求而来的商店不会影响计算奖金的服务的工作和性能，反之亦然
通常，可以堵塞所有旧问题，并且可以代替新问题而添加新功能。
而不是积压，我们有了亚历山大的笔记本。
启动新版本的系统
由于新系统不仅在技术上而且在意识形态上都与旧系统不同，因此我们无法将其部分地，半数地存储到商店中。 我们只需要关闭旧的，然后打开新的。
听起来不错，但实际上有两个限制。
首先，由于商店数量众多（1200多家），我们不得不在3小时内完成所有工作。 一个商店在某个时区的午夜关闭，而另一商店的时间则完全不同，因此还有一家便利店。 通常，要转换旧系统中的所有数据，请输入新数据，然后一次在3台服务器上-3小时启动。
陷阱如下：
- 该系统立即在整个网络上被切断。 如果所有地方的情况都很好-则整个网络都可以正常工作。 如果出现问题，是的，它将遍及整个网络。
- 当您打开新系统时，它必须包含商店关闭和发放最新奖金时旧系统中的所有数据。 我们立刻进入了四个国家。 该数据库超过了TB，并存储了数千亿条记录。
- 在23.00，我们必须关闭系统。 转换一切。 倒入新系统。 包括一切。 在这种情况下，一切都会正常。
我们培训了很长时间，最沉迷于剧本。 经过长时间的测试并尝试尽快完成所有工作，我们在9点钟取得了最佳结果。
与3小时的计划数字略有不同。
然后，我们决定首先进行预处理，从而将遗骸保存在我们自己的手中。 举起主服务器，他联系了商店。 同时，他不知道整个系统还没有建立起来，那时我们正勇敢地进行其他所有工作。
但是，仍然无法及时在标准计算机上完成如此大量的数据。
在这里应该注意Oracle Exadata。 甲骨文公司的员工制造了一种特殊的硬件，可以与自己的数据库甚至闪存驱动器完美配合。 总的来说，人们决定使用Exadata。 在测试的帮助下，我们精通了2小时而不是9小时内所需的一切，并意识到-我们需要接受它。
由于我们都是一丝不苟的人，因此在设置和工作过程中，我们挖出了许多错误，并为Oracle提供了一定的支持。 例如，有一个有趣的错误-由于请求内部处理中的错误，Oracle开始大量消耗TEMP。 我们及时注意到了这一点，并将其丢给TEMP'ovyh档案，当他喝醉时，这非常有趣。 但是，由于这块铁非常明智和博学，她用3 Tb TEMP感觉了10分钟，意识到自己已经没有了，就退休了。 我不得不想出解决方法。
一方面，很酷，我们在2小时内完成的所有转换工作。 另一方面，在干净转换的整个过程中，需要2个小时，我们还计划：
- 将所有数据从旧系统的服务器重新加载到数据库云服务器，因为它可以快速计数所有内容。
- 将数据从旧结构转换为新结构。
- 将所有已转换的货物倒入三个不同的服务器中。
同时，在每个数据库中，都有大量有用的服务信息，例如在重建过程中可能会有所帮助的相同索引，但是我们对它进行了评分，并决定再次在战斗服务器上重建所有内容。
准备工作
我们准备了强大和主要。 我们在上班睡觉。 我们不仅将自己挂在脚本上，而且还挂在许多指标上。
每天23:00，我们开始流程并监控指标。 我们进行了必要的更改，结果，我们对所有内容进行了设置，以使一切都不会出错。
当然，在发布当天，出现了问题。
令我们感到荣幸的是，这种倾斜并不在我们这一边。 网络在某个地方愚蠢地闪烁。 也就是说，您要像这样坐着，调整一切，使蚊子不仅不会破坏鼻子，甚至没有时间去考虑它-在某个地方，有人只是拉错了电缆。
无论如何，我们设法按时启动了第一台服务器。 一般截止时间是早上5点，所以此时所有服务器都应该欢快开朗，因为远东的第一家商店在他们的时间10点开门。
因此，最后一台服务器从上午11点开始。 但是由于我们以隔离所有事物的方式构建系统，所以一切正常。
现在
目前，有14位开发人员和8位分析师正在研究Club系统。 考虑到我们所拥有的所有好东西，这不再只是一张可以为您提供一定数量的奖金以供在商店消费的卡。
我们开始充分结合奖金。 系统成功组合的主要标准是购买者获得最大利益。 可能有许多实用程序和促销，例如：
- 用户积累了很多定期奖金；
- 现在加上对特定品牌采取行动的时期；
- 加上特定产品组和子组的折扣；
- 并且在特定城市或特定商店中也可能有折扣。
我们编写了一种算法，该算法从商店接收支票，处理支票中的产品，在给定日期和给定城市中对其应用所有可能的促销和折扣，并给出对用户最有利的结果。 然后，他将全部退还给商店。 而且还有发展方向：
- 开发一种机制来启动复杂的多方营销活动，包括邮寄，为客户提供奖金，折扣和个性化报价
- 连接新的通讯渠道，例如即时通讯程序，社交网络等。
感激的客户现在可以回忆起他也想购买袜子，并要求将它们添加到支票中。 当然，添加袜子（或其他任何袜子）需要完整地重新计数。
但是我们也会处理这个问题。 在以后的一篇文章中，我们将向您介绍Sportmaster网站创建的故事。