我们的仓库大小为两个红场，高度为5层，全年无休，从不睡觉-一年24/7 364天（唯一的休息日是1月1日）。 我们已经存储和服务了8,000,000多种商品，每天有300多个操作员进行更改。 他们处理来自世界各地的商品，并为来自四个国家的用户收集订单：俄罗斯，乌克兰，白俄罗斯和哈萨克斯坦。 在这样的规模上，业务需要无可挑剔的自动化。
在削减的基础上，我，Pasha Finkelstein（仓库开发和自动化团队的负责人）将告诉您，如果您拥有一支优秀的开发团队和一项非常具体的业务任务，那么开源解决方案将会增长什么。
基本逻辑
任何仓库的三个主要过程：货物验收，存储和运输。 我们仓库的简化周期如下所示：主要标识，质量控制，放置，选择和保留订单，搜索，分类，包装，转移到交货服务。 当客户退货时，该循环重复进行。 参与这些过程的每个物理实体都有其自己的信息表示形式，例如：卡车，产品，橱柜单元，包裹，包装材料，容器等。 货物状态的所有重大变动和变化都将转换为会计系统，并且绝对会记录仓库内货物的所有操作。
WMS（仓库管理系统）控制着仓库中每种产品的生命周期，从带有供应商货物的卡车到达仓库直到货物被运送到客户的那一刻起。
时尚自动化的细节
我们公司从事时尚和生活方式领域，在仓库中承担某些任务：产品可能是易碎品（眼镜，手表），非标准尺寸（冬靴或珠宝），高档商品（采用特殊包装）-或具有其他特定特征仓库必须考虑在内。 因此，不可能完全放弃在存储区域中的体力劳动。
所有其他过程都是自动化的-收货，转移到装运区，分类，包装和装运准备。 这些过程中的每一个都需要特殊的设备和操作过程。 当所有这些过程“结合在一起”并开始协同工作时，魔术就发生了-这要归功于我们的系统。
仓库自动化中的任何监督-是导致操作员错误，流程不理想等的接口。 -这是运输延迟，整个系统的停机时间，巨大的损失。 此外，对于每个错误，我们都会带来负面的客户体验。 因此，对于我们来说重要的是仓库必须像时钟一样工作。
开源和自己发展的道路
在开放阶段，我们使用了外部仓库。 随着数量的增长，我们开始了解到我们需要对运营流程进行全面控制，并对这些流程进行高度更改，因此我们决定朝着自己的仓库和开发方向发展。
当时我们面临的主要问题是对所有细节的操作流程的详细说明。 取决于员工的去向和方式，进行的扫描次数等。 在这些流程上，已经有必要部署WMS，它可以管理操作活动并自动执行常规操作。
首先，他们采用Java的开源解决方案，然后决定组建自己的开发团队，尤其是因为已经有了合适的基础。 我们增加了功能，然后占据了系统的核心：摆脱了传统和庞大的客户端，进行了重构，开发了新的服务来支持操作流程。
自动化阶段
主要的变化是由“浪潮”进行的，同时流程也进行了重组。
迄今为止，他已经经历了现代化的九个阶段，我们不打算对此进行详细介绍。
- 在第一阶段和第二阶段，我们使订单的运输过程自动化-我们添加了传送带，货物分拣逻辑，按托盘自动分拣订单。
- 在第三和第四阶段，我们着重于验收流程：我们学习了如何按不同类型和存储区域来区分进货流。
- 第五阶段在楼层之间增加了自动电梯-这就是在存储区域开始工作的方式。
- 第六阶段是最关键的阶段，当我们关闭所有自动化区域时，我们关闭了收货区和装运区。
- 在第七和第八阶段，我们对验收区的流程进行了更改，并增加了新区，电梯和传送带：我们扩展了现有的自动化系统。
- 在第九阶段，他们将新建筑物添加到仓库中，并将其与现有的自动化系统集成。
实作
我们的核心技术：Java，Postgres，Wildfly，Redis，ActiveMQ。
WMS用Java 8编写。但是不久前，我们修复了最后一个模块，该模块阻止了向Java 11的过渡，该模块将在不久的将来进行更新。
直接在仓库中安装的服务器机架保留用于WMS。 这使我们更加有信心即使电源和/或Internet已关闭，WMS仍能正常工作。 唯一会受到影响的是，发送到记帐系统的消息将延迟。 尽管尚未使用WildFly，但仍将其用作应用程序服务器。 向后者的迁移也在计划中。 一切都已经为迁移做好了准备，但尚未进行功能和负载测试，并且在新的一年之前，负载相对较高。 还使用了经过验证的ActiveMQ。
我们存储在PostgreSQL中的数据。 我们系统中的主要要素显然是产品。 有时，仓库员工会想出一些解决方法来简化工作，例如，他们扫描相同的条形码50次，而产品本身就是不用扫描就手动扔掉的，而无需深入了解，这是牛仔裤或T恤衫，因此我们输入了标识特定单位的标签货物，在基础设施中提供支持。 有关这些单位的信息存储在2 TB的PostgreSQL数据库中。
那里的大多数地方甚至不被货物占据，而是通过对仓库工人的行为进行审计。 作为关键业务系统，仓库必须知道为什么某些东西出现在系统中或消失了-我们不能允许无法跟踪的更改。 现在，我们正在考虑将数据库的这一部分带入MongoDB中的单独实体。
仓库员工工作站是瘦Web客户端。 在自动化开始的某个地方，所有这些操作都是按照胖客户端的原理进行的，这带来了一定的困难，特别是在发行大版本（包括界面更改）方面遇到了一些困难：大约150个工作站必须手动更新。 这个事实以及没有停机时间我们就无法释放的事实为我们设置了限制-在夜班结束后的清晨，我们每周最多只能部署两次，这不能被称为方便的时间表。 现在，我们已经将WMS转移到了网络上，到今年年底，我们将完全放弃胖客户端，这将大大简化我们的用户界面更改。 在其中一个阶段添加的Web和群集消除了对发布频率和时间的限制-现在，用户只有在出现问题时才可以了解发布。
我们的仓库中还有一个有趣的“异国情调”。 例如，在
Technoradar中提到的Haskell，上面写有用于可视化项目分类器的后端（这是一台可以将一个包装中的货物组合在一起并交给组装操作员的机器）。 有一个纯粹的计算问题，可以方便地以函数形式解决。 自然，没有人将Haskell用于任何大型项目。
我们在
有关Technoradar的
文章中提到的仓库的另一个元素是一个自写的
状态机，可以“监视”每种产品的正确操作顺序。 与整个系统一样，它是从一组简单的约束开始迭代开发的。 现在，这是一件非常方便的事情，已深入集成到我们的系统中。 我们希望在不久的将来将其
公开发布 -也许不仅对我们有用。
自动化设备
没有设备什么自动化！ 整个仓库纠缠在整个输送机网络中。
上面提到的项目分类器在装运阶段起作用，使您可以为特定订单布置从库存中收集的成千上万单位的货物。 一次，分拣员使我们的操作员不必再用手推车在仓库周围旅行来收集必要的货物。 订单被拆分，每个操作员仅从其所在楼层收集货物（节省移动时间），并且分拣员确保来自不同楼层的货物自动进入正确的订单。 将操作流程更改4倍可以加快订单的组装速度，并显着减少错误数量。
所有自动化设备均由我们的合作伙伴提供。 对于特定单元的管理，他们有自己的系统，该系统位于WMS旁边的服务器机架中。 在系统之间，集成是在相当高级的协议上配置的-我们通过SOAP进行通信。 从WMS内部的操作流程中，例如，当我们需要将装有货物的容器从A点移到B点时，我们转向他们的系统。 从我们的系统的角度来看，尽管这种自动化确实存在内部复杂性，但所有这些自动化看起来都很简单。
当然，这种明显的简单性无法立即起作用。 在自动化的第一阶段，我们对技术进行了“相互磨合”。 一旦传送带真正烧毁了我们的货物-传送带的速度过高，就会“咀嚼”货物并将其烧毁，这阻碍了其他订单的组装。 也许最艰难的故事发生在自动化的开始，即我们启动的第一阶段。 昨天，仓库完全是手动的，今天，切换开关后，它应该变成自动的。 但是没有任何效果：由于系统集成中的错误，彼此的消息被错误地解释，这导致几天的仓库停机时间和数百万美元的损失。
现在，合作伙伴已在我们的仓库中，计划在进行新一轮自动化时与我们一起安排设备，帮助测试新模块。
团队和Scrumban
整个系统的开发现在由12个人组成的团队进行。 在现代化高峰期的最后阶段之一中，当将单独的自动化流程合并为一个整体时，仅多达20个开发人员参与了该阶段（该阶段需要132个工时，并包含1,500多个提交）。 但是随着大规模转型的结束，有些人决定学习Go或Python，并改用其他开发团队。
在团队中，我们有“经典”项目经理，他们将产品功能和IT部门的项目相结合（平均而言，每5-6人使用一个PM）。 他的任务包括与我们的主要客户进行沟通-以其主管和运营流程开发部门为代表的仓库。 就我们而言，我们更关注技术现代化-选择正确的堆栈，更新等。 -仓库里的人正在考虑优化流程。
有时我们自己会花时间在该领域进行研发。 从字面上看，我们来到仓库，与高级轮班，普通操作员进行沟通，并弄清他们所遇到的问题，使用上的便利和不便之处。 换句话说，我们进行用户体验研究。
例如，由于采用了这种方法，我们改变了进行收货的员工工作场所的界面。 最初，它是一个企业复杂的界面，具有许多字段，按钮和缩写，而不是文字说明。 但是我们尝试优化流程和设计，使其与Google搜索主页面更加相似-外观不那么漂亮，但功能非常强大。 界面越简单，操作员所拥有的选项越少，在哪里单击以及要扫描的内容，错误就越少（以及修复错误所需的时间）。
现在，在最详细的时刻，我们已经掌握了如何优化细节的知识：一旦我们的团队进入机构，一时之间，几乎所有参与者都在关注收银员的行动顺序。 大约40秒后，一位同事表达了总体想法：“不是非常理想，您可以简化它。”
尽管团队中角色之间的关系非常经典，但是我们为开发方法选择了scrumban。
我们对方法进行了大量实验，而“输入”数据是非标准的。 例如，我们发行的版本很少。 上述对每周两次发布的限制是该过程的一部分，但实际上，我们的部署频率要低得多-平均每两周一次。 此外，我们还有一个仓库自动化硬件，这是由外部公司开发的用于干净瀑布的软件，其中所有变更都将在两年前安排好所有必要的文档。 但是，我们自己无法遵循他们的榜样：我们需要定期对系统进行一些更改，并且强迫客户为每个客户编写详细的任务是没有意义的。
因此，scrumban是一种让所有人开心的妥协。 我们使用迭代过程，但是sprint是我们的发布。 我们每月一次与客户见面并制定发布计划：我们讨论推出的日期和时间。 在sprint内部，实现了看板-积压了任务，进度等。 没错，这个过程正在逐步改变-例如，我们没有看板。 当一个开发人员完成任务时，就会根据下一个版本的计划和开发人员的能力为他们分配下一个开发人员。
我们喜欢这种方法。 它在迭代中提供了必要的灵活性，并为业务客户提供了实现某些提交的日期的可预测性。 对我们来说，这种方法的重要性并不重要。 最主要的是，一切正常。
不同于其他所有人-以广告资源和监控为例
在开发操作流程时，我们是从行业需求出发的，因此，我们有很多独特的功能。
一个很好的例子是库存。 根据法律，必须每年在仓库执行一次，但是我们的业务需求决定了对库存的更严格监控。 首先，我们希望在网站上反映有关商品供应的相关信息，其次，我们的B2B合作伙伴时尚品牌也需要同样的相关信息。 因此，每天要进行一次库存检查，一年一次，每天364天，在几栋建筑物的整个5层建筑群中逐层进行盘点。 这个过程得到了我们WMS的完全支持-很难实施这样的解决方案。
现在，清单正处于下一个更新过程中，以提高此过程的效率。
我们自己的发展的另一个例子是监控。 它是通过Web客户端实现的，允许您显示和跟踪非常有趣的指标。 此外，这些指标的直观表示对我们很重要。 实际上，监视是按照简单的时间表进行描述的仓库，我们可以清楚地看到在什么地方一切正常，在哪里发现问题（取决于特定的操作员）。 最重要的是，通过这种观点，我们可以理解为什么会出现这些问题。
KPI仓库工人和Redis
新技术的引入，更新，重构-都很棒。 但是我们的WMS在实际业务中有效，因此在这里我们不仅要解决这些问题。 我们工作的一部分是保护内部“黑客”免受攻击-足智多谋的仓库员工发明了绕过任务执行KPI的新方法。
例如，不久前，我们被迫将Redis添加到堆栈中，以防止用户同时从多个工作站登录系统并实现会话超时。 事实是，仓库工人意识到，使用相同的登录名工作并获得超过KPI的奖金比提高自己的生产率要有利得多。
由于解决业务问题需要在系统的各个位置进行更改，因此从技术角度来看，这是一个非常有趣的挑战。
仓库工作人员的惊喜并没有就此结束。 在会话发布后几乎立即，PostgreSQL开始崩溃。 我们搜寻了几天后基地意外退化的原因，直到发现问题再次变得机智。 一个女孩经常抽烟。 当她离开工作场所时，被淘汰出局，为了再次登录，有必要找到高级轮班并扫描他的徽章。 减少了在仓库中的徘徊，她只需从其中一个推车上撕下条形码，并用胶带固定扫描仪按钮，即可将其设置为不断扫描该条形码。 如果条形码不是从载有800单位商品的购物车中发出的，那么很长一段时间都不会注意到这一点。 每次扫描时，都会生成一个巨大的SQL查询来验证商品，从而通过“内部DDoS”“杀死”数据库。 我必须注意单位时间内扫描次数和购物车中物品数量的限制。
这样的故事已经很多了，我们一直在面对新的故事。 而且，系统必须每次都适应新条件。 在这种情况下，人们不能只将自己限制在管理方法上，一旦发生的事情可以很好地重复。
我们下一步要去哪里？
似乎无法完成流程优化和仓库自动化。 它在公司中持续了5年，而且正如我上面所说，即使在第9阶段之后，我们也不会停止。 该公司继续在B2C和B2B方面进行扩展，因此在不久的将来我们正在计划另一个大项目-开设另一个仓库，这将需要对现有系统进行大规模改写，或者从头开始在新位置创建类似的系统。 这是在业务，物理设施，运营流程和技术解决方案交界处的一个新的有趣挑战。