成千上万的Pyaterochka商店的不间断运营在很大程度上取决于可靠和定制的软件。 现在，网络使用GK SOFTWARE产品，该产品已从盒装版本改进到X5内的代码开发。 在我们的文章中，我们将告诉您安装发行版的过程，以确保公司的业务从新软件的单一商店发展到目前的15,000。
过去的日子，深厚的传统
现代世界中IT的十年历史是历史。 2009年，第一家Pyaterochka连锁店刚刚改用GK，出现了第一批软件更新任务。 该过程看起来像这样：完全手动工作，每个商店中都有“目光”的日志分析，启动软件时常出现的问题-结帐时，设备停止初始化，然后GK服务不在服务器上启动。
随着GK系统的稳定和更新工具的开发，我们通过GK系统的中心组件Storemanager进行了部署，每晚部署100-200家商店（每位员工）。 然后，这被认为是一项伟大的成就。 为了确保1000家商店的更新速度，已经需要一家直属店-只有每晚6人的团队才能达到要求的门店数量。 要创建更新任务，需要用手“点击”每个商店。 每个作业仅包含50个对象，因为由于内部错误，在更新后可能会丢失所有状态，因此需要进行全面的手动检查。
那时，商店的健康检查最初是根据任务的状态进行的，最后是通过连接到收银员的桌面和对收银员的屏幕进行可视化分析。
2014年，每晚更新1人的劳动强度是150家商店。
第一次突破
这种速度和更新成本都不适合我们或公司。 工作中最重要的领域是流程的改进和自动化，以确保快速，高质量地“交付”商店的更改，以帮助企业有效地解决任务。
由于GK代码不属于X5，因此我们无法独自完成Storemanager的改进，更改流程或修复错误。 因此，我们与承包商一起从头开始开发一种技术替代工具，称为“ Booster”。
我们全面地分析了更新过程，并从各个方面进行了研究。 他们对流程有了了解，这成为所有未来更改的基础。 更改的成功实施取决于我们将新版本的发行版交付给商店的速度，我们为升级准备的方式，安装过程的组织方式以及后续性能检查的进行方式。
“ Booster”具有仪表板上所有商店的单一列表，每个阶段的预检查和状态，以及更新后的第一个原始自动检查。
“ Booster”项目的实施使劳动力成本降低了6倍，并在一名员工的帮助下（到2016年底）每晚更新约1000家商店。 当时，这是前所未有的突破。
成功发展
下一阶段是巩固和发展我们的成功。 我们启动了一系列名为“ Booster2”的改进。
平台已移至新硬件，用户界面已完全重新设计，我们摆脱了制动。 引入了每个阶段的新检查和状态。
我们已为每晚更新的员工提供了所有信息，以发现问题并迅速解决。 通过基于屏幕截图的售票处可操作性的自动检查，为我们带来了预防事故的最大效果。 系统确定屏幕条件与标准条件不同的地方，而员工首先看的是这些商店。
更新后的“ Booster”允许在2017年底至2018年初每人每晚更新1,500家商店。
迈向新的高度
一晚有1,500家商店是个好习惯，我们可以轻松地管理发布时间表，进行额外的冲刺，我们准备提供错误纠正并在收银台和后台安装多达6个组件，但我们公司的任务是今天建立下一代零售。 我们业务数字化的过程，技术和技术基础尤其是开发和分发新软件版本的速度。 在2019年3月，设定了一项雄心勃勃的任务-到秋天，在一个晚上内更新3000台服务器和12000个收银台。 我们从当前现实中抽象出来，再次进行了出色的分析工作，以确定过程中的瓶颈。 确定了需要自动化，技术改进，开发新的专用软件以及重新思考的任务。 此外，我们已经形成了组织任务池。
结果，一个内部IT项目诞生了，制定了路线图，计算了预算，确定了里程碑，并明确定义了内部和外部交互的部门和承包商圈子。
路线图让我们更详细地介绍已形成的任务。 我们确定了3个领域：
- 降低风险的目标；
- 行政和组织任务；
- 每天增加更新商店的任务。
降低风险。 我们的任务-无论更新是成功还是失败，以确保现金节点的运行以及为客户提供服务的能力，即 早上开一家商店。 随着网点数量的增加，出现问题的风险会增加很多倍。
发行分发组中的员工就像是飞机驾驶员或空中交通管制员一样，承担着很大的责任。 在这种情况下，有必要开发出简单而自动化的工具，以最大程度地减少人为错误的因素。
在该区域内，制定了任务以开发新的商店检查系统，自动化准备更新的设施，创建用于记录网络基础结构上的工作并自动恢复的机制。
使用新的验证工具，您可以快速确定整个商店的运行状况，生成有关大量参数的报告，并立即向支持人员显示那些更新后早上无法打开的对象。 我们分析了软件的启动和下载步骤。 我们检查后台办公室收银员基地的形成，设备的初始化，收银软件退出到收银员注册模式等。 该过程基于我们公司最新的系统-使用现代技术堆栈（Filebeat，Kafka，ClickHouse，Grafana）的“业务监控”。
在用于全面准备更新商店的工具（系统）中，我们组合了所有分散的验证脚本，这些脚本甚至可能位于不同的服务器上。 我们连接了自动脚本来修复典型错误（空间不足，没有必要的权限等），并在问题没有自动解决的情况下以不同的方向邮寄给负责的员工。 我们添加了一个在MFSM中“毫不费力地”毫不费力地请求的机器人，并从便利店中排除了收银机来更新收银台。 这样的机器人每天可以节省三小时以上的员工时间。
用于在网络基础架构上进行会计核算的机器人工具 ：它可以分析来自提供商的完全分散的信件，在指定的SAP地址识别商店代码，并将工作日期和时间的数据加载到数据库中。 此外，基于该信息，更新循环时间表。 这逐渐消除了剩下300个商店无法通信的时刻，而我们无法获取更新或检查的状态。
自动恢复机制 ：在商店的一侧，它将允许对现金节点进行自我诊断，确定不可能启动收银台并从备份中恢复系统，从而在大多数情况下允许商店在早上开放，即使支持人员无法远程连接到问题的解决方案。
行政和组织任务。 系统的有效工作是成功的一半；要取得成功，必须确保团队的有效工作。
解决方案是增加培训，在工作日程中增加周末，设置与所有生产线的交互。 在周末部署。我们为员工进行了内部培训，以确保互换性和重新分配任务的可能性。 团队的工作时间表也进行了修改-所有员工都被转移到夜间轮班工作，这创造了确保连续更新的机会。 我们今年已实施了此选项。 现在，GK更新每周7天进行，而无需其他人员参与。
增加每晚商店数量的任务。 在这里，我们解决了快速而有保证的配送交付问题，以确保无论更改有多快，都可以更新任意数量的商店。 实际上，这还包括对系统本身的改进。
首先，我们开始尽可能高效地使用当前的“ Booster”更新工具。 负载测试揭示了最困难的操作，我们确定了可能性的极限，找到了用于水平扩展更新实例的选项。
此外，在项目框架内，我们决定应针对哪些工具进行更新，以及对哪些工具进行进一步开发。 选择Storemanager作为目标工具，因为通过获取GK源代码，我们能够独立开发和改进标准工具。
自项目启动以来，我们已经确定了在Storemanager中实现所有“ Booster”功能的步骤，并且今年对改进提出了额外要求，以确保更新所需的商店数量。
我们还设计了使用当前工具的选项，对其进行了改进，将目标基础架构专门移植到了Linux上作为下载服务器。 他们与同事一起引入了另一种新工具，大大扩展了我们的能力。
已经发生了什么
目前，我们计划中的大多数任务已经执行：
- 抽水系统的升级和改进。
- 减少GK分布的大小。
- 团队中的行政和组织任务。
- 自动化商店准备以进行更新。
- 负责网络工作。
剩下的任务是引入新的商店检查并完善目标更新工具。
接下来呢？
更进一步。 现在，我们的目标是每晚更新20,000（+）家商店，但是它将已经在具有新工具和方法的新平台上。 将来我们一定会告诉您。
作者Vasily Golubev，ITX5软件发行发行组负责人
商店解决方案支持部主管Evgeny Lapshin＃ITX5