作者：肖刚毅、张俊、李晶磊（全球化业务平台团队）

全球化电商中的业务、技术及架构和国内技术都有一定差异，从安全生产保障和质量保障角度，这些差异带来了更多的挑战，本文将为大家分享安全生产和质量保障相关的经验。

一、前言

作为有丰富国内电商技术沉淀的团队，在服务全球化电商业务中，一方面会自然传承国内电商技术体系去解决电商业务通用问题。另一方面，面对业务、技术、组织、文化、政策等维度差异，促使我们演进新的或更合适的技术体系。比如，国际电商业务发展的阶段特征、海外基础设施特征、国际业务区别国内业务的特征、用户和文化特征、以及更不可控的政策和合规等。在我们摸索多年形成的技术体系中，我们上一篇分享讲解了开发技术和架构相关经验，在本文中，我们想分享技术领域不可或缺的另一大块，安全生产和质量保障相关的经验。

分享技术经验以前，我们先把所服务的全球化电商这个对象，在一些关键维度稍作拆解，也是多年经验对全球化电商的一些关键特征的理解，而这些理解对我们的技术构建是至关重要的。

1.1 业务差异

在业务上，全球化电商主要有本对本和跨境两种最基本的类型。

东南亚电商品牌 Lazada 就是典型的海外本对本业务，主要实现在国外某国或地区，敏捷的构建一套支持本地买卖家交易的电商系统。这样的模式，决定了商家大部分在海外国本地，币种会相对单一，运营能力需要更加本地化等等。

跨境电商品牌 AliExpress 就是典型的跨境模式业务，主要实现中国商家能在中国货品优势下通过我们的系统将货物销售给跨境的买家，这里涉及的问题会大不相同。从语言、币种、时差、品类、活动、汇率差、物流、供应链等方面，我们需要有种种差异的技术解决差异的问题。电商业务，主要由电商系统、支付系统、物流系统组成，这三大系统的国际技术实现和国内技术实现都有一定差异。

1.2 技术架构差异

在技术和架构方面，也有显著区别：

• 基础架构差异：海外电商服务的对象大部分场景是跨国家的，同时海外的硬件设施和国内是有差异的。所以我们的系统要在考虑稳定的前提下，更低成本的实现数据同步、系统可复用、合规等等。这里我们的技术关键词是多单元部署、多机房部署、云原生。这些点对我们构建的质量体系的差异，十分关键。

• 应用架构差异：在电商技术领域，我们常常是通过不同的应用或微服务，构建出一套大的技术系统网，各个应用依据各自的领域拆分而来。区别国内电商的是，我们的应用或服务需要考虑站点，也就是国家站，甚至一个服务器同时通过多个域名服务多个国家站。除此之外，在应用架构上，敏捷中台如何支持好业务的问题中，我们设计了教堂 &集市的应用架构，让应用的灵活度和研发生产关系实现了质的提升。同时，也对如何保障好系统质量和稳定性提高了要求。

• 研发过程差异：中台需要尽可能抽象和合并电商逻辑，但国家差异化的本质一定会推演出大量国别定制需求，也因此而形成更复杂的组织架构，无论是本对本的业务，还是跨级业务中的本地化运营。所以我们的系统会同时有更多的、更接近电商用户的工程师一起开发。我们需要实现更灵活的应用编排、代码并行编写、隔离发布、流量调度等能力。在更灵活、更大型的研发过程中，质量把控的难度自然上了一个阶梯。

• 运行态差异：考虑到 QPS 特征等，在运行态，从成本和效能的角度，我们实现了多租户并行和架构隔离。这也决定了我们系统在复杂度、可测性、问题排查、测试环境、自动化、数据构造等方面的工作会更加复杂。

• 数据同步差异：即便我们的系统在运行态可能是租户复用的，但在数据上，考虑隐私、安全、合规、性能、可扩展等，我们是按站点进行物理或逻辑隔离的。在跨境场景中，要实现中国的商品在全球可以快速访问，必然需要实现秒级的数据同步能力。这对系统的稳定性带来了难度，也提高了测试用例的复杂性。

这些差异，有的天然由业务属性决定。有的是我们从技术上解决业务或架构问题时带来的新问题。从安全生产保障和质量保障角度，这些差异给我们带来了更多挑战，也是技术创新的机会，这也正是整个全球化技术体系的内核。

二、安全生产体系

2.1 全球化高可用架构概述

系统可用性(Availability) 最早在 Patrick O‘Connor 的 Practical Reliability Engineering 一书被提出。

其中，MTTR 为 Mean Time To Repair，即系统故障后平均修复时间，表示系统可维护性。MTBF 为 Mean Time Between Failure，即平均非故障时间，表示系统可靠性。

因此，保障系统实现日常态高可用主要分为两个方向：提升 MTBF，增加系统非故障时间，通过保持稳定性模式、系统冗余等手段，提升整体系统可靠性 &容错性。以及，降低 MTTR，缩短故障恢复所需时间，从事故、变更、监控运维等方便，增加系统可维护性。

除了上述两个日常态高可用建设方向，对于大型电商系统，大促时如何在洪峰冲击下保持服务高稳态，大促前又如何在相对短暂的备战阶段摸清系统瓶颈，掌握全局核心链路，也是高可用体系构建中不可忽视的一环。

因此，本文将分为三个领域对全球化高可用架构展开论述：

• 高可用体系建设

• 大促稳定性保障建设

• 应用高可用架构

2.2 高可用体系建设

目前业界通用衡量高可用的标准是 1-5-10。1 分钟发现，5 分钟响应/定位，10 分钟恢复。在过往的实践中，1-5-10 的达成，非常依赖 SRE 团队，团队的业务熟悉程度、问题排查手段，实操的熟练程度。不过随着系统的复杂度越来越高，链路依赖关系越来越复杂，1-5-10 对 SRE 团队的要求越来越高。

高可用故障跟业务故障是有一定的区别，高可用故障是有通用性的。围绕着故障，我们可以做有针对性的布防。接下来我们介绍的是在国际化板块，我们围绕着故障定义建设的一套高可用故障体系。

下面我们将从一个交易下单成功率下跌的故障来分析整个高可用体系处理的过程。先假设存在一个故障定义：下单成功率下跌 5%持续 10 分钟。

2.2.1 一分钟发现

在故障发现的场景，过往是等待下跌了 5%持续 10 分钟才会发出故障通告。SRE 团队开始介入问题的处理。

下单成功率下降了 1%、2%的时候，或者下跌了 5%持续了 5 分钟的时候，大家是缺少感知的。我们希望将故障响应的时间提前。提前到系统指标发生异常的时候就开始介入。

我们在系统指标异常发现之后，在故障发生之前，加入了风险预警的机制（图 1 实线所示）。风险预警由 GOC 触发，触发后 SRE 团队开始介入问题的处理。这样问题很有可能在故障发生时，完成风险的解除。

图 1 风险预警流程与原故障应急流程对比

2.2.2 五分钟定位

当问题发现后，我们需要尽快的定位原因。高可用故障，分为两类：变更类与运行类。

这两类故障的定位，都需要知道几个信息：

• 故障关联的系统有哪些，及其依赖关系？

• 当前报错是哪个系统导致的，哪个是表象哪个是根因？

• 故障是否存在相关的变更：时间相关、范围相关？

图 2 五分钟定位产品

在全球化业务中，针对核心应用，通过了一套统一的日志框架，进行应用信息的收集。收集的信息包括所有的 RPC 调用链路、核心的出参（错误码、是否成功）、中间件信息。通过该日志框架收集的日志信息，我们能够还原所有核心应用的链路拓扑信息，与其接口的成功率、错误码、RT 等实时信息。

当风险预警发生时，可以得知两个核心的信息

• 入口应用

• 问题场景

通过入口应用与问题场景，及链路拓扑信息，我们能够定位到链路下游可能出问题的节点。

除了链路信息的收集，我们还做了变更信息的收集，包括发布变更、配置变更、运营操作变更。通过变更大脑中相关度的算法，计算出与当前故障场景最相关的变更。

通过上述的方式，对于高可用的发生，能做到 90%以上的 2 分钟定位准确率。当定位后，接下来就要考虑如何恢复了。

2.2.3 十分钟恢复

在 1-5-10 三项中，10 分钟恢复往往是最难的。

针对变更类故障，其中配置变更的回滚速度比较快，能够在 10 分钟内完成回滚。针对发布类的变更，由于涉及应用启动时间，10 分钟恢复很难做到。针对发布过程中的情况，建立精细化切流的能力，能够切走有问题的机器的流量（已发布的机器）。但针对已经发布完的情况，还是基于应用完整的回滚。

2.3 大促稳定性保障建设

大促是每年投入人力最大的项目，光是大促稳定性保障，往往需要上千人日的投入。其中包括各种梳理的专项、多次全链路压测。另外机器资源也到了每年的峰值。在确保大促稳定的情况下，怎么降低人和硬件成本，成为了大促保障的主要命题。

2.3.1 保障大促稳定，打造大促确定性

在备战过程中，最关键的是压测。而压测又分为几个关键的步骤：流量评估、施压、压测复盘。

流量评估，我们将流量评估的过程和数据全部上翻到了系统，大促确认了关键指标后，将关键指标输入系统，将会得出各个核心链路的流量值，后续的保障我们会基于该流量值进行硬件资源的准备。各个业务域的开发同学只需要持续的维护关键指标与系统入口流量的计算公式即可。

在过往的压测中，时常会出现少压漏压而导致大促峰值出现异常流量的问题，这些异常流量还曾引起过 P1 的故障。为此，在施压过程中，我们通过关键系统流量、性能指标的收集，与上述的流量评估结果进行对比，发现流量不符合预期的链路。通过增加流量或者补压消除风险。另外通过链路的拓扑引擎，进行日常流量与施压流量的对比，发现可能漏压的链路。

通过这个方式，我们发现了多起的少压漏压的情况，确保了压测的真实性，保障了大促的稳定性。

2.3.2 降本提效

2.3.2.1 硬件成本

大促往往具有一个特点，周期短，流量大。在非压测、非大促峰值的情况，硬件资源并不需要那么多。因此，我们考虑从施压到链路，都具备自动扩缩容的能力，从而大大缩小我们使用的容器资源。

压测：在压测开始之前，进行施压机、业务容器的扩容。在压测结束后，对施压机、业务容器进行缩容。

大促日：大促周期进行扩容，非大促周期缩容。通过这个方式，我们能降低 50%容器资源。

图 3 自动化压测

2.3.2.2 人力时效

全球化大促备战，涉及多个国家、多个时区，我们为了每个大促备战的专项，基本都把备战内容进行了系统上翻。除了 review 的工作，大部分都能在系统上完成。这样大大的减少了大家协同、数据整合的工作。大促的负责人也能从系统上，了解到当前大促备战的进展与风险。结合着自动化压测、无人守值等自动化工具，大大的减少了人员的投入。

过往几次大促看，施压人员减少 80%，大促保障项目组投入减少了 30%人次。

图 4 大促工作台

2.4 系统高可用架构

上述章节讲述了面向故障发生、大促备战的高可用的考虑。接下来主要是系统高可用架构。每个系统都具备高可用是整个业务高可用的基础。SRE 团队做不到对每个系统十分了解，怎么做到所有的系统都具备相同的、较高的水准是我们要考虑的方向。

这里我们引入了一套高可用的度量体系。针对系统的可靠性、高吞吐、可监管、容错性进行了定量的评估。针对每项的分数，我们提供了建议的优化策略与方法。每个业务系统的同学，就可以有针对性的对系统进行优化。而 SRE 团队也有了一个运营的阵地。通过不断的完善度量体系，增添指标，可以不断的驱使系统负责人进行优化治理工作。

图 5 高可用度量体系

这些指标的统计往往都是根据线上的数据进行事后的统计。每次的变更质量，还是需要技术质量团队保障。安全生产体系是构建在技术质量体系上的二次防护，安全生产是质量体系的右移，质量体系是安全生产的底座。要确保系统和业务的稳定，我们在质量保障体系上也做出同样的努力和探索。

三、质量保障体系

全球化电商系统的质量保障，首先要解决电商业务的质量问题，需要在不同的电商链路构建不同的质量体系，解决各个领域最关键的问题。同时，考虑到国际电商和国内电商的业务、技术差异，质量体系或实现手段，也会有差异。比如：

• 因为多站点而出现的站点应用，应用数相对更加膨胀，业务中台负责的内核代码需要在各个业务各个站点应用同时运行，如何高效测试和覆盖，如何能准确的度量覆盖率。

• 因为线上 qps 相对较低，测试环境/正式环境的比例会显著变高，测试成本大幅提升。同时多个业务因为并行运营会有更多的并行迭代，更加显著提高了所需测试环境数量，加剧了被测对象的测试资源耗费过高问题。如何构建一套测试环境体系可以在更高效支撑业务并行迭代的同时，让环境成本大幅降低。

通过多年技术迭代，历经全球电商系统的各项大型技术重构战役，在支持好业务和技术升级的同时，解决了许多难题，不断迭代着质量保障体系。我们构建了高效的自动化和持续集成能力、建设了更高效的测试环境技术和运营体系，把资损防控从单点变为可左移和可右移的长周期可覆盖体系，在实践中推行了标准研发流程及配套工具度量和运营能力。这些努力，在技术和效能提升上有明显体现，同时通过质量平台将各领域测试能力产品化，友好的服务其他业务团队。

3.1 自动化体系

自动化建设的挑战

全球部署 &法律合规

在上一篇文章里面介绍国际化基础设施方面的挑战，自动化测试也面临着同样的挑战。由于被测对象的全球部署特点，再加上各国法律合规上数据不准出境、不准入境等规定的限制，测试用例与测试数据的展示、测试用例的运行与维护这些原本非常基本的诉求都面临着很大的挑战。

开源架构

国际化最新一代的架构实现了业务（集市层）和中台（教堂层）各自闭环、独立迭代，这就意味着需要能够独立测试，传统的接口测试只针对完整的应用进行测试，集市层和教堂层的独立测试需要自动化测试粒度更细，也要求自动化测试的重点从黑盒自动化转向灰盒自动化。

3.1.1 自动化实践

我们按照经典分层测试理论设计自动化体系，并将流量回放技术应用于分层测试中的多个环节中，包括单元测试生成、模块测试生成、接口测试、链路测试用例，并为其提供测试数据支撑。

图 6 分层测试金字塔

3.1.1.1 单元测试

单元测试作为开发工程师保障质量的首选方法，但仍有几个问题需要解决。

• 存量的老应用缺乏单元测试基础，需要快速补齐；

• 复杂系统的测试数据构造难，需要配套工具；

• 系统重构会导致单元测试大批量失效，需要低成本的快速修复。

对于旧系统的存量代码，通过流量直接构建完整的单元测试用例，快速补齐存量代码的单元测试用例。

对于新增函数，我们通过静态分析快速生成单元测试用例的基本“骨架”，开发工程师补充测试数据后即可快速完成一个单元测试用例。

对于系统重构场景，通过静态分析、流量重采集方式批量重新生成单元测试用例，让单元测试成为可持续汰换资产，避免成为开发工程师的负担。

3.1.1.2 接口测试

国际化业务涉及到多租户、多站点的特性，用例维护管理的成本会随着业务的水平扩展而显著增加，因此需要更高效的进行用例收集、用例维护管理。

在用例收集上，采用了自动特征分析及去重的策略，在无人参与的情况下，就可以自动沉淀用例集，然后有人工输入专家经验，提升特征丰富度和用例覆盖率。

在用例管理上，弱化了传统相对复杂的用例集管理功能，使用系统托管的方式进行用例维护，并且用例运行时自动根据多租户、合规等条件进行调度，保证准确性同时降低人工介入成本。

在回放结果上，通过对错位、断言等聚合分析，有效减少失败分类数量，降低人工排查的成本，并在运行后提供代码覆盖率和业务覆盖率度量结果。

图 8 接口测试原理示意图

3.1.1.3 模块测试

对于开发工程师来说，除单元测试外，对于单一业务场景的小范围集成测试有很强的诉求。因此，我们提出了一种新的测试方法——模块测试。模块测试的测试粒度介于单元测试和接口测试之间，主要对逻辑相对比较内聚的模块进行测试。

图 9 模块测试与单元测试、接口测试的测试范围比较

模块测试的思想是将用例直接运行在应用中，可以在测试用例运行的过程中访问到应用中的资源、实例，更加简单、真实，但是测试用例仍就为一个 JUnit 用例，与单元测试一致。

整个方案利用 JavaAgent 技术，实现了测试用例与被测应用实时通信，保证了测试用例修改即时生效，实现了即改即测。

表 1 模块测试与单元测试、接口测试的特点对比

模块测试不仅解决开发工程师小范围集成测试的问题，同时也能够满足国际化开源架构下对于集市层、教堂层独立测试诉求。

3.1.1.4 研发辅助

在分层测试之外，为了提升研发自测效率和将质量保证前置，我们为开发工程师提供了自测辅助工具，包括提测前的本地接口测试能力和本地独立联调能力。

接口自测

接口自测一般在单元测试和模块功能测试完成之后进行，策略是复用接口测试能力，在 IDE 中为研发提供一套完整的自测流程和相关功能，并与当前代码分支（变更）绑定，使开发工程师在其编码环境中即可快速完成测试。

图 10 接口自测流程

本地联调

联调是研发自测最后一个环节，也是上下游高度耦合、相互依赖和效率较低的环节。为了提高联调效率，我们实现了一套本地自测联调的方案。其思想是参与联调的上下游共用同一条链路用例，并按照接口约定为其依赖方修改对应的数据，使得所有参与联调的开发工程师仅依靠链路用例即可完成联调，实现彻底解耦。

图 11 本地联调原理

3.1.2 度量体系

3.1.2.1 代码覆盖率

代码覆盖率是测试度量的有效手段之一，但是全量代码覆盖率往往基数庞大，不利于精细化管理。在日常迭代过程中，增量代码覆盖率更加直观，可以对每次代码变更做精细化的覆盖率管理，持续提升代码覆盖率。

图 12 增量代码覆盖率原理

3.1.2.2 影响面分析

在度量体系中，度量风险也是重要一环，影响面分析可以帮助研发工程师更加准确的评估每个函数改动对全局的影响。通过对生产环境采集流量中的函数调用关系进行建模，形成一张包含全部函数间关系的“图”，通过这张“图”可以分析出每个函数上游的调用方，即受影响的函数。

影响面分析不仅可以评估函数变更对分布式系统的影响，在国际化的开源架构体系中，还可以帮助教堂层的开发工程师准确评估教堂层变更对集市层的影响。

图 13 影响面分析原理示意图

3.1.3 自动化用例持续集成

3.1.3.1 什么是自动化用例持续集成？

区别传统的持续集成是面向被测对象的概念，自动化用例持续集成是为解决自动化用例腐化问题而进行的创新。以主干预发部署单元为最小回放单位进行持续回放，降低了运行噪音和精细了用例运行态粒度，并提供更友好的量化能力，包括用例通过率，接口覆盖率，代码覆盖率，业务覆盖率等，帮助用例持续迭代。

3.1.3.2 方案 &实现

为了提高通用和可扩展能力，我们通过产品功能实现用例的生产、消费、防腐，替代人工维护。持续集成平台支持应用接入、用例集合管理、定时执行配置。

图 14 自动化持续集成

持续集成平台主要分为 4 个模块：

• 用例管理：支持集团内多种自动化用例平台

• 精准回放：定义用例源，提高用例的管理精度

• 用例防腐：通过规则可配置、环境管控、实时告警，实现用例及时防腐

• 结果度量：提供多维度的覆盖率报告，更有效便捷的帮助用例迭代

3.1.3.3 效果

可以便捷清晰的观测到核心被测对象最近 20 天的用例运行结果、各类覆盖率，也会给出其他优化建议。

图 15 持续集成效果

3.2 测试环境

3.2.1 测试环境问题

• 测试效率问题：测试环境的稳定性，会严重影响上下游测试效率；

• 测试环境资源问题：需求高峰期并发，涉及测试环境抢占；需求低峰期，多余测试环境被闲置；

• 测试环境隔离问题：子域内需求需要相互隔离；子域之间快速支撑联调；

• 测试环境使用成本：测试环境答疑成本，以及构建成本；

3.2.2 测试环境难点

• 测试环境隔离支持同步接口/HTTP 服务和异步消息隔离；

• 测试环境资源根据需求情况，弹性占用，同时也要控制预发环境膨胀的问题；

• 测试环境问题答疑：往往业务问题、系统问题都会被上报为环境问题，导致排查耗时，如何快速定位问题？

3.2.3 测试环境方案

3.2.3.1 测试环境管控方案

方案：主干、项目预发建设；环境防腐与管控；环境问题排查工具建设

• 线下环境：针对 DB、Tair 以及资金相关的变更进行管控，其他需求不在管控范围内；

• 预发环境：引入项目预发环境支持日常需求变更，项目预发环境无管控，即用即建，变更发布或者关闭之后释放资源。项目预发环境用环境标签隔离，对其他应用的依赖，且不在变更列表中，路由主干预发环境。

• 发布阶段：发布阶段包含两类情况，一是测试完成之后，生产部署，在预发主干环境部署之后，进行功能回归验证。二是业务 UAT 验收，主干预发环境基于 UAT 变更进行部署；主干预发：增加功能回归和测试用例门禁(主干预发是指和生产环境代码版本一一致的环境，用于提供稳定的上下游依赖环境)

图 16 一个变更在测试环境中的扭转 

3.2.3.2 项目预发环境隔离方案

• 流量转发流程：

1）用户 HTTP 请求进入接入层，集团网络层将流量路由到主干预发环境；

2）主干预发环境将流量标组装项目预发环境的流量路由标识；

3）通过流量调度服务返回目标项目预发环境，由主干预发环境转发到目标项目预发环境。

• 流量隔离方案：

1）子域项目隔离：通过流量环境标进行隔离，需求之间互不影响，包含消息、接口服务；

2）多域联调需求：项目预发环境一键加入联调，将涉及变更的应用归属于一个预发联调环境中，相同隔离标识的应用相互调用，支持联调测试。

图 17 项目预发环境隔离

3.2.3.3 环境防腐 &问题排查

目的：对预发、项目预发、线下主干环境采取监控等手段，保障环境可用，发现环境腐化现象并治理。

策略：通过服务可用性及业务正确性监测，主动发现环境异常。

图 18 环境稳定性

目前已累计产出治理项如“hsf 服务异常”和“业务健康度不达标”若干，监测衡量环境是否腐化。

上文所说，目前业务中台流量隔离方案采取集团通用流量隔离方案，该隔离方案存在如下好处：

• 保障不同需求同一时间提测不互相干扰；

• 开发自测修复 bug 和测试环境之间的隔离，保障高效率的开发和测试。

但是使用过程中可能会遇到以下问题：

• 隔离环境服务异常，导致流量路由至主干预发；

• 云上云下没有对等部署，用户流量被路由到主干预发。

隔离失败带来的危害包括测试分支错误等导致的漏测，因此测试过程中需确认环境隔离生效正确。对于长链路应用来说，排查较麻烦。基于此，我们也提供了链路排查工具，可根据请求 ID 查询并分析经过的所有应用环境与机器信息，帮助业务测试同学能快速的排查出环境问题，在实战中效果很好。

3.3 质量工具平台

3.3.1 问题

为了降低重复工作量和提升测试专家经验的可传承度，很多测试团队都会建设效能工具门户，比如数据构造工具、度量工具等。但工具建设更深层次的问题是如何持续运营，如何持续正确迭代。

• 业务庞大团队历史悠久，导致工具分散，前后端链路复杂，也没有统一品牌心智。

• 工具之间没有整体规划，有工具能力缺失和重叠，重复轮子泛滥。

• 各领域新增测试工具开发 &维护有成本，对新手不友好。

• 在 devops 研发体系、云原生等架构升级中，质量工具难以整合同步升级。

• 工具效果没有统一度量指标，难以运营迭代。

3.3.2 架构和设计

图 19 质量工具平台设计

图 20 质量工具平台方案

3.3.3 效果

• 统一了多个分散的领域测试工具的产品和技术架构，提高可持续运营能力；

• 对外提供 10+种平台测试能力，并且进行了 2.0 升级，包括自动化、环境、资金安全、测试账号、开放工具等；

• 平台服务超过 8 个不同业务部门，日均 UV>100，日均 PV>1000。

3.3.4 质量平台孵化的一个案例：特征识别 &业务度量

质量平台的升级不但实现了对提升已有工具能力的目标，借助对各产品关系的厘清、对新问题的重新定义，也促成了不少新的工具产生。其中借助标签系统升级而实现的业务度量工具就是一个典例。对资深的测试而言，测试用例覆盖全不全是一定会面对的难题，区别代码覆盖率，我们打磨业务度量工具的目标是从更客观真实的视角去度量用力的有效覆盖度。

业务痛点

用例多：国际化电商各应用自动化主要基于流量采集沉淀用例，单应用的用例从几千~几十万不等。

• 场景多：消费者链路业务场景复杂，场景梳理困难，各域的场景梳理方式各不相同。

• 存量场景覆盖不足：用例虽多，但场景覆盖率不足，以交易为例只能覆盖到主干链路，一些特殊场景易遗漏。

• 场景覆盖更新不及时：新增功能新增场景，用例更新不及时，往往会遗漏对应场景的覆盖。

• 无法度量：项目交付时无覆盖率计算口径，难以评估覆盖结果，发布标准只能依赖人的经验

设计思路

图 21 测试用例特征识别与业务度量方案

对线上流量的更全面采集，通过算法分析以及少量的人工参与，实现对单应用业务标签可自动化获取，提高获取的准确度和降低标签维护成本。通过流量染色和其他数据分析能力，对标签链关系进行分析和在线管理，实现全量业务场景可分析。当然，这个过程需要多次的迭代，降低部分特殊参数的噪音，以及被测对象在不断迭代的同时需要对已经产出的全量业务场景同步维护。目前我们已经在部分核心应用落地，有效的补充了大量未覆盖测试用例。

3.4 资损防控

资金安全故障是指因技术原因（包括编码缺陷、变更执行、系统设计类漏洞、安全漏洞等）导致的线上产生资金损失的故障。根据产生资损的对象将资损场景分为以下两类

• 平台多出：买家、卖家、平台、供应商、合作伙伴等蒙受直接资金损失，或未获得相应的优惠折扣（例如红包、购物津贴无法使用等），且最终均需由平台赔偿或平台多出流量/权益/钱等。

• 平台少收：平台佣金、运费等应收款少收或收入减少。

国际电商技术服务多个业务和国家站，部署架构、运营模式都给资损防控加大了难度，如多单元部署架构下的数据同步延迟风险、跨境模式下多币种计算涉及复杂的汇率转换、财税合规问题、多时区、多语言等。我们主要通过持续在资损场景分析、监控降噪、智能监控规则三个方面投入，确保整体资损风险可控。

3.4.1 资损场景分析

• 业务拆分：对有资损风险的业务模块，比如交易下单、库存扣减、营销冻结等，针对业务模块的特性，开展接近白盒测试的内部一致性梳理和对账核对补充。一般会涉及业务梳理、技术风险梳理、强弱依赖梳理等。

• 与上游一致性：对调到本应用的请求，或者本应用需要消费的消息，做一致性核对。

• 与下游一致性：对本应用调到的应用，或者本应用发出消息的消费方，做一致性核对。

3.4.2 资损监控降噪

如果监控有大量噪音，那么监控本身就是无效的。特别在资损监控领域，如果不加治理，告警量往往在 10W/天的级别。目前我们已经将电商中台、LAZADA、AE 等所有站点的监控核对规则统一收拢到资金安全大盘，对已有的大量对账脚本进行逻辑持续防腐和脚本告警的持续防腐。

图 22 资金安全监控大盘

3.4.3 智能监控规则

目前主流的资损监控工具都需要人工参与脚本的编写和调试工作，在站点和业务扩展很常态的国际电商中，边际成本很高，因此需要一种低成本且完善的资金安全核对脚本生成方式来降低技术投入成本。我们基于流量的字段级别进行算法分析关联度，自动化生成资金安全规则。

产品架构图：

图 23 资金安全监控规则生成

其中，算法模块使用流量解析模块生成的数据集进行算法的分析，包括数据处理、字段关系分析、条件关系分析、结果处理，整体流程图如下：

图 24 字段相关性判断

通过以上分析和数据聚合，算法模块的产出物为字段间关系 + 可靠度，供监控规则生成模块自动或者手动生成监控项。

3.5 研发过程 SOP

3.5.1 研发过程中已有的痛点

根据调研，在没有 SOP 前，研发过程的痛点很多，其中 Top 痛点如下：

• 需求评审/技术评审/提测都是线下操作，线上数据缺失；

• 预发环境不稳定，研发环境和测试环境互相干扰；

• CR 时机过晚，未发挥出 CR 最佳的效果；

• 单元测试和持续集成测试覆盖不足，未发挥完整作用；

• 业务覆盖率难衡量，无卡点约束。 

3.5.2 逐步建设研发过程 SOP

构建整个研发 SOP 的推导过程如下：

1）观察：现有研发流程不规范影响了研发效能和研发质量。

2）调研：通过调研不同的干系人（PD、开发、测试等），获取不同视角的诉求或痛点。

3）筛选：筛选出 TOP-N 亟待解决的诉求或痛点。

4）分析：分析这些节点的现状，推导出解决方案。

5）落地：分析哪些痛点是可以复用或定制现有工具就可以解决，不需要重复造轮子，哪些痛点是需要开发新产品来支持的。

6）度量：SOP 度量采用的是差异化运营方式，基础度量指标可以直接复用现有研发效能产品来分析和下钻数据，新增指标需要单独维护一套可视化报表来差异化运营。

7）生长：通过分析数据或干系人反馈会生成新的 Top-N 的痛点，进而形成持续迭代泛化的研发流程 SOP 体系。

图 25 研发流程 SOP

研发流程 SOP 体系终态结果如下：

SOP 覆盖了整个研发过程，采用“筛选关键节点+线下会议对焦+线上流程管控”的方式来规范研发过程，对在此过程中获取到的关键节点数据统计、分析和下钻，定位出研发流程中瓶颈问题，进而提升工程质量和研发效能。

图 26 研发流程 SOP 管控

3.5.3 SOP 数字化运营

研发 SOP 目标是将研发流程数字化产品化，提高研发交付过程顺畅度，规范研发流程，提升工程质量。

SOP 实施路径主要将部门内的商家和交易两个团队作为试点，根据不同团队的习惯和研发流程现状采用不同的策略因地制宜地实施：

1）交易团队采用绑定技术架构升级项目的方式，推进研发效率升级，落地关键数据获取。

2）商家团队采用绑定卓越工程项目及 OKR，分应用地推进 SOP 的落地和效能提升，重点关注过程增量指标。

获得关键指标数据后便可以用来做 SOP 的深度运营，SOP 度量采用的是差异化运营方式，即基础度量指标直接复用现有集团研发效能产品的数据可度量方式，新增指标需要重新维护一套定制化度量报表，收集并分析研发流程关键节点信息 ( 需求评审、技术评审、创建变更、部署、提测、发布 )，助力研发效能治理。

图 27 研发过程 SOP 运营目标

图 28 研发过程 SOP 数字化运营结果

3.6 全球化中台质量保障体系

以上各领域的质量建设，汇为质量体系，即质量工作开展侧重点和关键路径。这是构建在质量基础设施的、可度量的、和业务关键指标绑定的体系，通过 SOP 建设和运营，贯穿和落地在全球化电商中台质量保障过程中。我们也通过质量月报持续的运营各维度质量数据，对体系迭代升级。

四、未来展望

跨境电商、海外电商、全球化电商，是近年互联网的热点，越来越多的公司开始构建各个维度的跨境电商技术能力或产品。在国际形式、政策不可预测的大背景中，我们面对的机会和挑战也很不确定。但从技术的角度看，被测对象、稳定性保障对象，一定有确定性。我们需要用经验和功底去摸索积累，支持好全球化电商技术的演进。未来我们会在安全生产高可用治理、质量保障的可度量可托管、自动化测试更接近智能化等方面继续探索，更高效、清晰、低成本的支持好全球化技术和产品快速迭代，能灵活的应对更多的变化。