您好！
我叫 Mikhail，是 Sportmaster 公司的 IT 副总监。 我想分享我们如何应对大流行期间出现的挑战的故事。
在新现实的第一天，Sportmaster 通常的线下交易格式冻结了，我们在线渠道的负载（主要是送货到客户地址方面）增加了 10 倍。 在短短几周内，我们将庞大的线下业务转变为线上业务，并根据客户的需求调整服务。
基本上，我们的副业变成了我们的核心业务。 每个在线订单的重要性都大大增加。 有必要节省客户给公司带来的每一卢布。
为了快速响应客户请求，我们在公司总部开设了一个额外的联络中心，现在每周可以接到约 285 个电话。 与此同时，我们将 270 家商店转移到新的非接触式安全运营模式，使顾客能够收到订单，员工也能维持工作。
在转型过程中，我们主要遇到两个问题。 首先，我们在线资源的负载显着增加（谢尔盖将告诉您我们如何处理这个问题）。 其次，罕见的（新冠疫情之前）操作的流量增加了很多倍，这反过来又需要大量的快速自动化。 为了解决这个问题，我们必须快速从原来的主力区域转移资源。 埃琳娜会告诉你我们是如何处理这个问题的。
网上服务运作
Kolesnikov Sergey，负责在线商店和微服务的运营
从我们的零售店开始对访客关闭的那一刻起，我们就开始记录用户数量、应用程序中下的订单数量以及应用程序请求数量等指标的增长。
18月31日至XNUMX月XNUMX日订单数在线支付微服务请求数量网站下的订单数量
在第一张图中，我们看到增加了大约 14 倍，在第二张图中，增加了 4 倍。 我们认为应用程序的响应时间指标最具指示性。
在这张图中，我们看到了前沿和应用程序的响应，并且我们自己确定我们没有注意到任何增长。
这主要是因为我们在2019年底就开始了准备工作。 现在我们的服务是预留的，在物理服务器、虚拟化系统、docker以及里面的服务层面保证容错。 同时，我们服务器资源的容量使我们能够承受多种负载。
在整个故事中帮助我们的主要工具是我们的监控系统。 确实，直到最近，我们还没有一个单一的系统可以让我们收集所有层面的指标，从物理设备和硬件级别到业务指标级别。
正式上，公司内部有监控，但通常是分散的，并且属于特定部门的职责范围。 事实上，当事件发生时，我们几乎从来没有对到底发生了什么达成共识，没有沟通，这常常导致绕圈寻找和隔离问题以便解决。
在某些时候，我们认为并决定我们已经受够了——我们需要一个统一的系统来全面了解整个情况。 我们的堆栈中包含的主要技术包括作为警报和指标存储中心的 Zabbix、用于收集和存储应用程序指标的 Prometheus、用于记录和存储整个监控系统数据的 Stack ELK，以及用于可视化的 Grafana、Swagger、Docker以及其他有用的和您熟悉的东西。
同时，我们不仅使用市场上现有的技术，还开发一些我们自己的技术。 例如，我们提供用于系统相互集成的服务，即某种用于收集指标的 API。 另外，我们正在开发自己的监控系统 - 在业务指标层面，我们使用 UI 测试。 Telegram 中还有一个用于通知团队的机器人。
我们还试图让团队可以访问监控系统，以便他们可以独立存储和使用他们的指标，包括为一些未广泛使用的狭窄指标设置警报。
在整个系统中，我们力求尽快主动并定位事件。 另外，我们的微服务和系统的数量最近显着增长，集成的数量也相应增长。 作为在集成层面优化事件诊断流程的一部分，我们正在开发一个系统，允许您进行跨系统检查并显示结果，这使您可以找到与导入和系统交互相关的主要问题。彼此。
当然，我们在操作系统方面还有成长和发展的空间，我们正在积极致力于这方面的工作。 您可以阅读有关我们的监控系统的更多信息 .
技术测试
Orlov Sergey，网络和移动开发能力中心负责人
自实体店关闭以来，我们从发展角度面临着各种挑战。 首先，负载激增。 显然，如果不采取适当的措施，那么当系统承受高负载时，它可能会变成南瓜，或者性能完全下降，甚至失去其功能。
第二个方面不太明显，即高负载下的系统必须非常快速地进行更改，以适应业务流程的变化。 有时一天几次。 许多公司有一个规则，如果营销活动很多，则无需对系统进行任何更改。 完全没有，只要能用就让它用。
我们基本上经历了一个无尽的黑色星期五，在此期间有必要改变系统。 系统中的任何错误、问题或故障都会给企业带来巨大的损失。
展望未来，我会说我们设法应对这些测试，所有系统都承受住了负载，很容易扩展，并且我们没有遇到任何全局技术故障。
系统承受高浪涌负载的能力取决于四个支柱。 第一个是监控，您在上面读到过。 如果没有内置的监控系统，几乎不可能发现系统瓶颈。 一个好的监控系统就像家居服；它应该舒适并且适合您。
第二个方面是测试。 我们非常重视这一点：我们为每个系统编写经典单元、集成测试、负载测试和许多其他测试。 我们也在编写测试策略，同时尝试提高测试水平，直到不再需要手动检查。
第三个支柱是 CI/CD 管道。 构建、测试和部署应用程序的过程应尽可能自动化；不应有人工干预。 CI/CD Pipeline 这个话题很深，我只简单介绍一下。 唯一值得一提的是，我们有一个 CI/CD 管道清单，每个产品团队都会在能力中心的帮助下完成该清单。
这是清单
这样，很多目标就实现了。 这是 API 版本控制和功能切换，以避免发布序列，并在测试完全自动化、无缝部署等级别实现各种测试的覆盖范围。
第四个支柱是架构原理和技术方案。 我们可以长时间谈论架构，但我想强调一些我想重点关注的原则。
首先，您需要为特定任务选择专用工具。 是的，这听起来很明显，而且很明显，钉子应该用锤子钉进去，手表应该用专用螺丝刀拆卸。 但在我们这个时代，许多工具都在努力实现通用化，以便覆盖最大的用户群体：数据库、缓存、框架等等。 例如，如果采用 MongoDB 数据库，它适用于多文档事务，而 Oracle 数据库适用于 json。 似乎一切都可以用于一切。 但如果我们代表生产力，那么我们需要清楚地了解每种工具的优点和缺点，并使用我们完成任务所需的工具。
其次，在设计系统时，复杂性的每次增加都必须合理。 我们必须时刻牢记这一点；低耦合的原则是人人都知道的。 我认为应该应用在具体服务的层面，应用在整个系统的层面，应用在建筑景观的层面。 沿着负载路径水平扩展每个系统组件的能力也很重要。 如果你有这个能力，扩展就不是什么难事。
谈到技术解决方案，我们要求产品团队准备一套新的建议、想法和解决方案，并实施这些建议、想法和解决方案，为下一波工作负载做好准备。
克什
有必要有意识地对待本地和分布式缓存的选择。 有时在同一个系统中使用两者是有意义的，例如，我们的系统中的某些数据本质上是展示缓存，也就是说，更新的源位于系统本身的后面，并且系统不会改变这个数据。 对于这种方法，我们使用本地咖啡因缓存。
并且存在系统在运行过程中主动更改的数据，这里我们已经使用 Hazelcast 的分布式缓存。 这种方法使我们能够在真正需要的地方利用分布式缓存的优势，并在不需要它的情况下最大限度地降低循环 Hazelcast 集群数据的服务成本。 我们已经写了很多关于缓存的文章。 и .
此外，在 Hazelcast 中将序列化器更改为 Kryo 也给我们带来了很好的推动。 Hazelcast 中从 ReplicatedMap 到 IMap + Near Cache 的过渡使我们能够最大限度地减少集群中的数据移动。
一点建议：在大量缓存失效的情况下，预热第二个缓存然后切换到它的策略有时是适用的。 看起来，通过这种方法，我们应该得到双倍的内存消耗，但实际上，在实践这种方法的系统中，内存消耗减少了。
反应式堆栈
我们在相当多的系统中使用反应式堆栈。 在我们的例子中，这是带有协程的 Webflux 或 Kotlin。 当我们期望输入输出操作缓慢时，反应式堆栈特别好。 例如，调用慢速服务、使用文件系统或存储系统。
最重要的原则是避免阻塞呼叫。 反应式框架有少量在后台运行的实时服务线程。 如果我们不小心允许自己进行直接的阻塞调用，例如 JDBC 驱动程序调用，系统将简单地停止运行。
尝试将错误转化为您自己的运行时异常。 程序执行的实际流程转向反应式框架，代码执行变得非线性。 因此，使用堆栈跟踪来诊断问题非常困难。 这里的解决方案是为每个错误创建清晰、客观的运行时异常。
Elasticsearch
使用Elasticsearch时，不要选择未使用的数据。 原则上，这也是非常简单的建议，但最常见的是被遗忘的内容。 如果需要一次选择10万条以上的记录，就需要使用Scroll。 打个比方，它有点像关系数据库中的游标。
除非必要，否则不要使用后置过滤器。 由于主样本数据量较大，该操作对数据库的负载很大。
在适用的情况下使用批量操作。
API
设计 API 时，请考虑尽量减少传输数据的要求。 对于前端来说尤其如此：正是在这个交汇处，我们超越了数据中心的渠道，并且已经在致力于连接我们与客户的渠道。 如果有最轻微的问题，过多的流量就会导致负面的用户体验。
最后，不要扔掉一大堆数据，要清楚消费者和供应商之间的合同。
组织变革
Eroshkina Elena，IT 副总监
在隔离发生、需要大幅加快线上发展步伐、引入全渠道服务的那一刻，我们已经处于组织转型的过程中。
我们的部分结构按照产品方法的原则和实践转移到工作中。 目前已经组建了团队，负责每个产品的运营和开发。 此类团队中的员工 100% 参与，并使用 Scrum 或看板来构建他们的工作，具体取决于他们更喜欢什么，建立部署管道，实施技术实践，质量保证实践等等。
幸运的是，我们的大部分产品团队都从事在线和全渠道服务领域。 这使我们能够在最短的时间内（认真地说，实际上是两天内）切换到远程工作模式，而不会损失效率。 定制流程使我们能够快速适应新的工作条件，并保持相当快的新功能交付速度。
另外，我们还需要加强那些处于在线业务前沿的团队。 在那一刻，我们清楚地意识到，我们只能利用内部资源来做到这一点。 大约 50 人在两周内改变了他们以前工作的领域，并参与了对他们来说是新产品的工作。
这不需要任何特殊的管理工作，因为除了组织我们自己的流程、产品的技术改进和质量保证实践之外，我们还教会我们的团队进行自组织——在不涉及行政资源的情况下管理自己的生产流程。
我们能够将管理资源准确地集中在当时需要的地方 - 与业务进行协调：现在对我们的客户来说什么是重要的，应该首先实现什么功能，需要做什么来提高我们的吞吐能力交付和处理订单。 所有这些以及明确的角色模型使得在此期间能够将真正重要和必要的内容加载到我们的生产价值流中。
显然，在远程工作和快速变化的情况下，当业务指标依赖于每个人的参与时，你不能仅仅依靠“我们一切顺利吗？”系列中的内心感受。 是的，看起来不错。” 需要生产过程的客观指标。 我们有这些，任何对产品团队指标感兴趣的人都可以使用它们。 首先是团队本身、业务、分包商和管理层。
每两周一次，每个团队都会进行一次状态评估，分析指标 10 分钟，识别生产过程中的瓶颈，并制定联合解决方案：可以采取哪些措施来消除这些瓶颈。 如果任何发现的问题超出了团队的影响范围，或者超出了可能已经遇到类似问题的同事的专业知识，您可以在这里立即向管理层寻求帮助。
然而，我们明白，为了实现倍数加速（而这正是我们为自己设定的目标），我们仍然需要学习很多东西，并将其落实到日常工作中。 目前，我们正在继续将我们的产品方法扩展到其他团队和新产品。 为此，我们必须掌握一种新的形式——方法学家在线学校。
方法学家，帮助团队建立流程、建立沟通和提高工作效率的人，本质上是变革的推动者。 目前，我们第一批毕业生正在与团队合作并帮助他们取得成功。
我认为当前的形势为我们带来了机遇和前景，也许我们自己还没有完全意识到。 但我们现在获得的经验和实践证明，我们选择了正确的发展道路，未来我们不会错过这些新的机遇，也能够有效应对Sportmaster将面临的挑战。
发现
在这个困难时期，我们制定了软件开发所依据的主要原则，我认为这对于每家从事此业务的公司都适用。
人。 这就是一切的基础。 员工必须享受他们的工作并了解公司的目标以及他们所从事的产品的目标。 当然，他们还可以在职业上得到发展。
技术。 公司有必要采取成熟的方法来使用其技术堆栈并在真正需要的地方建立能力。 听起来非常简单明了。 并且经常被忽视。
流程。 正确组织产品团队和能力中心的工作，与企业建立互动，以便作为合作伙伴与其合作，这一点非常重要。
总的来说，我们就是这样生存下来的。 我们这个时代的主要论点再次得到了证实，额头上响起了一声响亮的咔哒声
即使您是一家规模庞大的线下企业，拥有许多商店和经营所在的许多城市，也要发展您的在线业务。 这不仅仅是一个额外的销售渠道或一个漂亮的应用程序，您还可以通过它购买东西（而且因为竞争对手也有漂亮的应用程序）。 这不是一个可以帮助您度过难关的以防万一的备胎。
这是绝对必要的。 为此，不仅您的技术能力和基础设施必须做好准备，您的人员和流程也必须做好准备。 毕竟，您可以在几个小时内快速购买额外的内存、空间、部署新实例等。 但人员和流程需要提前为此做好准备。
来源： habr.com