哈Ha！ 我的名字叫情人（Valentine），我是拉莫达（Lamoda）的首席技术官，自公司成立以来我就一直在这里工作。 这些年来，我们整个团队前进非常快，以至于无法停下来谈论自己。 我认为时机已到。
拉莫达（Lamoda）似乎是俄罗斯互联网的先驱之一，但我们才七岁。 自2011年成立至今，我们的公司已从11名员工发展到5000多名员工。 每个月，有超过一千万的人访问我们的网站。 实际上，我们是成熟的俄罗斯IT领域的新兴公司，因此，在很短的时间内，我们就赶上了许多杰出人士。
我希望我们能告诉您一些有关我们最有用，最有趣的成就，失败，经验以及我们团队每天面临的任务。 我们将把这个职位视为我们的熟人。
在2011年，我们仅独立开发了内容准备和购买待售股票，其他一切都外包了。 现在我们自己做一切。 我们负责监督我们自己的五层仓库（一个足球场大小），三个联络中心以及向客户交付货物的运作。 尽管俄罗斯拥有很高的IT文化，但是大公司才刚刚开始沉迷于如何构建这样的基础架构，在拉莫达，他们已经成功地遵循了这条道路多年。
那么Lamoda技术后台由什么制成？ 实际上，这些是五个大单元：
- 开发部（业务流程自动化部和网上商店开发部）
- IT支持部门（基础结构和安全性）
- ERP系统实施与支持部门
- 服务支持部
- 数据和分析部门
GO中的一切
这个故事是关于正在开发电子商务平台的家伙，他们在空闲时间驾驶摩托车，并参加精酿啤酒吧的导览游。
平台是在电子商务开发部门中创建Lamoda客户每天使用的一切的：网站的桌面和移动版本以及iOS和Android的应用程序。 工作的复杂性不在于为用户实现功能，团队需要尽快推出新功能，而又不损失质量和稳定性，并支持四个国家的项目：俄罗斯，哈萨克斯坦，乌克兰和白俄罗斯。 迄今为止，该部门的员工能够在必要时每周运行该服务，并以“ GO中的一切”为座右铭。
这些团队主要按平台（桌面，移动网站，移动应用程序）细分，还有四个后端服务团队。 每个团队都包括前后开发人员，分析师，测试人员和产品经理。
为了尽可能频繁地交付更改，我们采用这种方法进行开发迭代：在sprint的开始阶段，我们提出了一个假设，并发布了生产中的新功能，然后对其进行了测试，从而了解了创新是否对产品有利以及Lamoda用户的生活是否变得更好。 例如，不久前我们学会了显示一个人最近所购买的人的数量。 为此，我们承担了产品任务，在其中找到了MVP，并确定了最快的实施策略。 在将所有产品投入生产之前，我们确定转换的增加将是成功的标准。 根据A / B测试的结果，在引入该功能的组中，转换率更高。
不久前，Lamoda开始大规模向微服务过渡。 这给了我们什么？ 首先是其他团队的新开发人员或专家的入门门槛低。 第二个是微服务系统的轻松支持和更改，因此工作流程充满了趣味，而不仅仅是痛苦。 但是仍然有少量的整体（例如负责订单分配的系统）与我们一起生活，目前摆脱这些整体是困难且不便的。
我们无需短信和注册即可从零开始收集Lamoda
人人都知道，没有失败是没有工作的。 每次解决问题并启动代码时，我们都希望这里幸福，然后没有经历。 说到经验，值得注意的是，电子商务平台开发部门的员工像真正的战士一样，能够从头开始组装Lamoda。 碰巧的是，由于网络设置不正确，我们的集群决定它不再是集群，并拒绝存在。 幸运的是到了晚上，在四个小时内我们为Lamoda注入了生命。 我们还有其他故事。
电子商务平台开发负责人Timur Nurutdinov：在开始使用新功能之前，我们像往常一样坐下来评估所需的资源。 有四个团队参与了该项目。 我们考虑了其他任务的优先级，同事的休假时间表和人工成本。 结果，我们有32周的时间。八个月实施一项功能。 听起来很疯狂。 通过简单的更改，我们就能将上市时间缩短到4周，这就是我们所做的。平台团队的诀窍是他们既可以做正面又可以做背面。 这就是他们在我们部门工作的方式。 但是在后端，需要对许多集成系统进行更改，并且平台团队的能力不允许这样做。 我们启动了Sizes项目，该项目与为客户提供最详细的尺寸网格有关，并且不想等待。 首先，我必须弄清楚哪些系统需要更改，然后我们组成一个具有适当能力的小型团队。 因此，我们删除了该块以等待其他平台团队的资源，并建立了一个产品团队。 至于任务，我们以经过验证的方式采取行动-将大型任务分解为较小的任务，将它们制成，然后将其推出产品中，并在用户身上测试了我们的假设，以了解我们是否朝着正确的方向发展。 在建立产品团队的成功尝试之后，我们计划在员工组成一个单位的区域组织团队，并制定特定的方向，例如交付。仓库自动化和15分钟的交货间隔
自动化人员没有时间要感到无聊，这里的任务并非易事。 例如，如何将数百万具有相同高质量内容的商品（照相馆的自动化）上载到站点，如何处理和考虑站点上的所有订单，并考虑到数百个市场合作伙伴和四个CIS国家，如何在三个小时内在五层楼的仓库中收集订单，仅在俄罗斯600个城市中，如何以他选择的15分钟间隔第二天实现向客户的交付。 对于甜点，他们将整个农场出售给B2B合作伙伴和Marketplace部门。
该工作主要在PHP中完成，对于仓库自动化，我们使用Java加上Docker / Kubernetes，Atlassian堆栈，PostgreSQL，RabbitMQ。
我们部门中有一个用于计划sprint的存储桶系统：60％是项目存储桶，20％是技术债务，10％的sprint被分配给优先级的bug，10％的东西是从外部飞来的。 除其他事项外，积压整理，在线计划扑克，站立，复古，代码审查360，基本指标的收集和分析，监控（Prometheus，Grafana，Icinga，Kibana），总的来说，一切都像
巴黎开发团队中最好的
房子一样。
以下是业务流程自动化部门负责人Pavel Savelyev的几个有趣的故事。测试和考虑所有内容都是不可能的，因为人们在每个业务流程中都以一种或另一种方式参与。 正如您所知，人是理性的生物，总是想出一些狡猾的手法，使他们的生活更轻松。 但是，当这些相同的概念违背所描述的业务流程时，就会发生有趣的故事。一旦我们注意到负责仓库中货物分配的系统在一分钟内收到的扫描量比平时多一百倍。 事实证明，仓库工作人员发现了一个黑客系统，并决定为他们的工作提供便利。 离开午餐时，他们将扫描仪上的按钮固定住，以免被扔出用户会话。 这个工作技巧将继续有效，但是在其中一个小物品（仓库中用于存放货物的专用盒子）中，有很多小物品。 像Maxim的机枪一样，该扫描仪处理了命运多gun的机枪手的货物，这导致负载急剧上升，系统故障并检测到开发人员的明显漏洞。 当然，我们修复了一个错误，但是我认为仓库工作人员不会让我们感到无聊，而是会提出一些新的建议。第二种情况也发生在仓库。 这个故事叫做“ 43 Fun T恤”。 并非总是可以立即认识到算法的复杂性，尤其是当您解决背包问题并且需要以特定体积最佳放置N个对象时（三维包装问题）。 事实证明，如果有43件完全相同的T恤衫到达我们的仓库，负责包装货物的系统就会针对这种情况产生大量的分销组合，以至于足以存储这些信息。 我们审查了算法，不再担心相同的T恤-但是，如果数百双袜子套在包装上，那么哪家制造商决定一次出售一件袜子，会发生什么呢？ 值得考虑...在任何无法理解的情况下，请专注于数据
Lamoda中有关分析的更改早就应该进行了，今年，我们开始将分散的分析部门与我们的分析基础架构和习惯合并为一个大部门。 怎么了 主要原因是，位于不同分析团队中的员工通常以不同的方式完成相同的工作，因此不清楚要关注哪些数据。 不同的数据-这通常是正常的，因为团队来自不同的任务和先决条件，但是您需要花费大量时间来理解它们。
该部门的员工是真正的福音传教士，公司中的所有决定都必须基于数据做出，因此，他们每天都在这里热情地研究数据中的业务现象，分析并从数据中提取价值，评估其应用方式。 主要工具是SQL，以及用于数据分析的Spark，Hadoop，Python，Excel，用于报表的SAP BusinessObjects和用于可视化的Tableau。
团队的一项重要任务是个性化客户体验：我们创建一个解决方案，向每个用户显示最相关的商品和报价清单，并且我们的所有服务将针对每个单独的客户而不是针对团队进行调整，就像现在这样。
数据和分析部主管Sergey Gilev：分析部门当前面临两项重大任务：第一项是合并之前我们所拥有的多样化经济的整合。 为了进一步开展有效的工作，我们需要通用的指标，分析基础架构和流程。 第二个目标是一个创建分析仪表盘的项目，该仪表盘描述特定过程或整个公司的“运行状况”。 因此，我们努力为决策者显着提高数据的可用性，并向所有人灌输我们的工作方法：将注意力集中在任何无法理解的情况下。重大举措的故事：我们如何推出自己的仓库而未被客户注意
逐渐放弃外包使我们意识到，现在是时候调试我们自己的仓库了。 除了为新仓库中的操作流程自动化做所有准备工作外，我们还设定了自己的目标：不缩小范围，在任何情况下都不要停止销售。 我们的专家基于创建额外的“虚拟”仓库开发了一种解决方案。 因此，在整个搬迁过程中，我们拥有三种类型的仓库：旧仓库，新仓库和在途仓库。 由于货物是由卡车集团逐步运输的，因此下一批的库存已转移到“虚拟”仓库中。 我们有一个装货和卸货时间表，因此我们确切地知道库存将要运送多长时间，并可以将客户定向到该订单的正确交货日期。
我们还提出并实施了一个棘手的算法，该算法使我们能够平衡移动速度并在一次交付中组织所有订单货物的接收：当某人订购了几本实际上可能在不同仓库中的货物时，我们试图在一个仓库中组织订单的完整组装，而且，由于那里的组装过程已经在此处调试，因此给合作伙伴的仓库带来了好处。
启动我们自己的仓库的工作进行了三个月，在此期间没有客户受伤。
为黑色星期五做准备或在购物成瘾期间我们如何生存
几年前，我们担心黑色星期五这个可怕的怪物。 我们不知道我们的系统将如何响应这样的订单流。 但是，在重构和基础架构开发方面的不懈努力使我们的系统稳定下来，并使它们尽可能地可预测。 最后一个黑色星期五是一年中最无聊的一天。 关键系统和DevOps的专家只是坐在桌旁，玩视频游戏或看电影，并且只用一只眼睛就可以看到我们基础设施的状态。 但是，这一天的准备工作有所不同。
我们根据业务预测安排压力测试，然后开发人员和管理员都将系统配置为通过测试。 经过几个月的测试，崩溃，更正，直到此后，我们相信我们已经准备好迎接一波用户和订单。
作战室-黑色星期五我们的行动中心我们为生存黑色星期五而做出的决定取决于我们在测试过程中遇到的瓶颈。 几年前，我们物理上更换了网络交换机以消除带宽问题。 我们通常为减少负载而执行的另一项操作是禁用非关键子系统。
总结
这些年来，我们一直在努力不断改进和简化我们的工作流程，从公司员工那里收集反馈，建立自下而上的渠道并完全支持新的想法和概念。
有人会说Lamoda是技术和系统的绝对动物园。 我们经常开玩笑说这个话题，说：“最好问一下我们不使用什么。” 但是，就此而言，一个重要的事实是，我们在不断发展堆栈和技术，与此同时，没有没有深思熟虑的选择。 这有助于我们对每个新服务和项目进行体系结构审查，提供员工现有专业知识的指南，以及
Technology Radar的维护，我们将很乐意在下一篇文章中介绍其详细信息和论点。 我们也很高兴在这个问题上庆祝。