活动场景是当前质量领域的重要保障对象，活动场景重要、高频、复杂，甚至上千个活动的集合，用户量级大、资金量级大、协同复杂度高，活动全链路的复杂度和风险如何控制住并逐渐走向无人值守？

支付宝高级测试开发专家唐寅老师的这篇干货分享，一起来看看！

唐寅 高级测试开发专家

主负责支付宝中心化大促相关业务和平台的质量保障工作。擅长领域：质量平台架构设计、风险防控解决方案设计、金融高可靠系统测试、服务端仿真自动化、运营配置风险保障等。2014 年加入蚂蚁，先后在金融核心、人工智能、商家开放等领域从事测试与开发工作，以及专业质量人才的培养工作。

以下内容根据唐寅老师在 TesterHome 社区与支付宝质量技术主办的测试之美系列《支付宝活动保障 - 质量保障》主题技术沙龙直播现场所讲内容进行精简整理，大约 1.3 万字左右。

支付宝中心化大促的特点与挑战

√大促的活动特点

节日型大促
在每年的春季夏季秋天以及我们的双 12，都会有一次比较大型的这种大促，差不多每年会有五次这样规模的活动。除此之外，像跟集团联动的 618 和双 11，也是类似的一种形态，只是有些是跟阿里一起联合运作的。

我们的这种大促，是全部由支付宝进行独立研发而形成的我们的支付宝大促。

在这样的大促里面，我们每次会有一些比较个性化的玩法。比如 “摇一摇”，会跟附近的人单对单以及几十个人一起进行多人摇的玩法，可以在这样的匹配过程中去跟不同的朋友匹配到，不同的红包以及更好的权益。然后我们也会在每天的 8 点或者 12 点的这种整点活动，会在不同的城市，让大家去抢到更加优质的红包或者消费券，这样的一些高价值的权益。

除此之外，我们还会有通过让用户去完成任务赚取金币，再兑换红包或者卡券等各种不一样的玩法，可以看出我们在不同的大促里玩法功能也是不断变化，内容也是比较丰富。

在这样的大促形态中，每次也会给上亿的用户以及几百万上千万的商家一起去联动去供给这样的一场大促，资金规模也是比较庞大的。

常态化大促

常态化大促活动会针对每个比较特性的行业，比如说比较大规模的餐饮行业、快销行业等等，会联动这些行业各类比较优质的商家，这些商家包含大商家、中小型商家，也包含比较大型的服务商，由他们去供给不同类型的代表了商家特点的一些权益。

政府合作活动

这类活动是我们比较高频的一种大促形态，比如各地政府的消费券。

它会由政府出资或者政府跟我们蚂蚁集团一起出资的方式，给这一区域的用户提供更加优质的消费券的权益。这类大促更加具备区域的个性化，并且在每个区域类型，有更多的用户来广泛的参与。

总的来说，支付宝大促的活动特点包含：功能复用性低、活动频次高、准备周期短、故障率高、外部商家风险高等特点。

√大促架构简介

首先会有我们的研发工程师去针对整个大促的链路所设计的系统进行相关的功能升级，大概包含招选品、搭建、投放、营销等数十个对应的研发构建的系统。

然后在这些系统的代码基本上完成和上线之后，第二步就会有我们的运营，在我们的比较重要的大促里面，可能会有来自十几个部门的上百位运营对这些平台进行各种不一样的配置操作。比如会包含不同类型的活动属性、奖品金额规则以及一些搭建出来的会场的组件的 LOGO 还包括文字等等，都是由运营去制作、配置和搭建出来的。

第三步就是在这个链路刚好发布对外之后，就会先由商家和服务商来进行配置和报名，他们就会把外部商家的一些权益或者是小程序等内容配置进来，再通过我们的整个链路去供给上来。

第四步就是我们的测试开发工程师对整个链路所涉及到的各类风险进行测试和保障，最终我们会生成一次大促活动的举办的会场作为载体，然后把整个大促的内容集合在一起，去供给触达给我们的用户，用户就会在这样的会场里去参加到不同的玩法，去领取到权益，去使用对应的权益。

√大促的质量挑战

从这些大促的特点可以看出，我们大概会面临以下几个比较有代表性的质量挑战。

——代码类风险

从前面的背景也可以看到，其实我们的代码的复用性相对来说是比较低的。不管是前端每次搭出的展示样式会完全的不一样，包括组件有哪些功能，也有可能是千差万别的；那同时我们后端的一些逻辑也很可能是会发生很多改变，在我们大促进行过程中，可能每天也会有比较频繁的代码升级，去优化新的业务诉求，并且在我们的这种大促的形态里面，其实前端对应的稳定性风险和各种功能不可用的风险也相对来说会比后端更不容易去枚举。

——运营配置风险

在前面我也讲过，我们运营在这里面有非常多，可能去操作的一些空间尤其是所配置的奖品，什么情况下可以去发奖，什么情况下可以去核销，这种配置稍有不慎都有可能会导致比较严重的资金类故障。

同时，因为运营涉及的人也很多，他们也经常轮换，所以他们犯错的可能性其实也是非常高的。然后同时我们的配置流程不像研发那样有相对完整的一个流程去严格约束，运营相对来说会更随意一点。

——商家生态风险

第三类风险就是商家生态风险，因为商家自己独立所供给的内容，可能会导致所配置的优惠券金额不对，或者说无法核销，以及商家小程序有可能在大促运行过程中面临用户量级大或者自身的问题，可能随时也会挂掉。

——项目协同复杂

此外，质量挑战方面还有一个非常显著的特点，就是我们的项目协同比较复杂。因为一次大促，基本上都会涉及几十个部门、几百位同学的协同，并且这种协同的同学的责任也是非常丰富的，就远远不止是简单的产品研发和测试自己的角色，还有非常多的包括运营、BD 以及法务安全等很多同学的介入，同时我们的新人占比也比较高，每次大促里也有比较多的轮换，经验也比较难以传承。

支付宝中心化质量保障策略

面对这样的质量挑战，我们的质量策略是怎么去落地和支持的呢，下面就重点给大家介绍一下支付宝大促的业务质量团队在保障大促所走过的三个比较关键的阶段。

√大促质量保障策略演进史

2019-2020
1.0：保障白皮书

第一个阶段是从 2019 年的时候开始，我们这类大促差不多是从 2019 年的双 12 开始以这样的形式对外供给，并一直以这样的方式沉淀下来。

在我们的保障初期，1.0 阶段我们重点是通过保障白皮书的方式来进行保障，而这个阶段最大的特点是我们制定的一个非常全的，能够去约束各个模块各个人员在每个环节都需要做什么的一个流程，策略的一个规范。

然后对于我们的横向的一号位等同学，会在这个过程中去做好对应的项目管理，我们会看全局保障的东西有没有遗漏，然后在重点容易出故障的环节，我们要加大精力去进行分析，总体来说这个阶段大体是靠我们的人工经验来进行保障。

2020-2022
2.0：保障工具化/平台化

在 2020 年到 2022 年，这两年多的时间我们走向了一个 2.0 的时代。在这个阶段，我们重点是通过保障工具化和平台化的方式，来真正通过技术化的手段保障大促。

这里有 4 个关键词，首先我们是做一个保障平台，让跟保障相关的角色都可以通过这个平台来进行一站式的保障。

第二是保障生态，我们联动了支付宝来自蚂蚁集团的各个质量技术团队，去供给各种差异化的质量能力，通过丰富整个生态系统，来保障各个领域的保障能力，都尽可能地自动化和技术化。

第三我们再做一个保障流水线，针对每一种场景我们都可以集成和用什么样的方式去集成各种保障能力，来支持当前所要保障的大促。

最后一个关键词是架构内置，在这个过程中，我们把质量架构跟研发的系统架构完全植入到一起，使研发在发生对应的技术变更和运营在使用研发系统发生配置变更的时候，都能够无缝地去使用到我们的保障能力。

2022-未来
3.0：保障智能化/无人值守

然后到今年，我们是处于 2.0 向 3.0 的一个转化期，面向未来是希望把保障做得更加智能化和更加的无人值守。

同时我们也在部分的一些场景里面，已经开始无人值守，这方面的探索和尝试也都取得一些比较好的效果。

√各阶段具体做法分享

接下来，我把我们在数据化和智能化的一些展望和现阶段的一些做法给大家进行一个分享。

大促质量保障 1.0:保障白皮书

先来看一下我们的 1.0 阶段，保障白皮书大概的样式，是从我们的大促启动到评审研发测试，之后我们要经历一个非常复杂和涉及人也非常多的包括运营准备、大促演练和专项保证的一个阶段。这也是一个大促区别于常规业务功能模块去测试的最关键的差异点。

因为常规的模块可能就是在前期的研发和测试阶段能够做好就行了，而大促的话，我们重点是在测试完成之后到整个活动对外之前，会有非常多需要去保障的东西，这些都做完就会进入到真正的活动上线。活动上线因为每天都有可能会有我们的人员分组需要去保障，也有可能我们有一些需要动态去调整业务的策略，也有可能我们要去优化了一些功能。

其实每天都可能会处理非常多的一些事情，那同时在用户量级比较大的时候，对线上舆情，还有客群问题的吸收和反馈，也是我们要重处理的一个重点。

然后直到活动下线之后更新的一个常规化内容切换，也是我们要保证一个重点。

但是在实际的实操层面，就会有我们的质量负责人联动大促的项目经理以及对应的产品还有开发同学，去协同各个会场和模块的测试人员以及专项的保障人员，共同使这个机制可以落地。从而能够尽可能解决刚才所提到的包括代码类等风险。

可以看到，其实这种模式下，大多数都会依赖于我们人工的经验和人工执行的能力，因而还是会存在一些问题。首先是整个人工成本比较高，其次是问题还是可能会遗漏，因为每个人的经验和能力水平都有局限性，都有犯错的可能性。

大促质量保障 2.0:保障工具化/平台化

【大促质量保障 2.0:会场保障】

那基于此，我们就开始走向了质量保障 2.0 的阶段。在 2.0 阶段，我们首先是针对刚才所提到的几个问题，分别去打造一些集成得比较好的技术化的解决方案，最终形成一个平台能力去解决。

首先在会场保障方面，针对代码复用性比较低、代码变更频繁、前端风险高的一些风险，我们的减法思路是希望在这个过程中，尽可能去形成一种更通用的代码验证能力，并且重点去解决端到端的全链路的验证能力，同时使整个流程尽可能不依赖于人工而可以全自动化解决。

我们大概是这样做到的，首先是在每次大促里可能每一天后端开发和前端开发都会去研发对应的前端和后端代码，从而组成这么一个会场。

然后在大促会场真正对外之前，会采用这样一个核心的技术链路保障整个会场。第一步会大致对这次的变更场景进行分析，大概会知道这次大促活动相关的哪些核心功能改变了，然后再去自动调度我们对应的在前端和后端核心的一些功能自动化。我在这里需要强调一下，因为我们的代码复用性比较低，如果每次大促都去建一个覆盖比较全的自动化，其实这样的 ROL 是很不合适的，所以我们只会去建去抽象在一年的几次大促里面，最有可能会被复用的那些核心功能并且有可能会引发线上故障的功能才做自动化，而它的覆盖率就不会达到非常齐全的一种功能覆盖率的要求，这样的话我们自动化成本才不会很高。

然后当这部分已经执行完之后，我们重点会去执行核心元素智能便利的一个能力，简单来说是会通过我们一些检验的标注，会知道在这次大促会场里有哪些比较核心的组元素，比如说有一个点击摇一摇，就可以进行摇一摇这个功能，然后点击我的红包可以去查看红包以及兑换红包等等大概的这种主要的场景，它会完全不依赖人在每次去进行智能便利的时候，会通过更自动化的技术和智能技术自动去找到可以在这里面去点击什么，下一个页面又可以去进入到什么，然后在下一个页面里面又可以去点击什么，这样子无序的任意组合的去执行人有可能在这个页面里去进行的一些比较主要的操作。

在这个操作过程中，我们会对一些通用的兜底的质量风险元素进行检测，包括有没有白屏、卡死闪退，有没有一些关键的报错词等，然后等这个功能执行完之后，我们会有一个视觉图片 diff 的功能，就比如如果因为一个前端开发出现一个问题，他把一个核心的我们第二天要去进行抢红包的一个组件给下掉了，我们会通过当前新的页面跟昨天的页面进行对比，就知道有一个关键的元素缺失了，我们也会通过这个方式去进行风险的识别，然后才会进行性能测试，就会把整个会场的耗时有没有比以前变得更差，然后有没有一些大图的一些资源等等也做一个智能化检测，同时在必要的时候，我们再对核心的功能和智能便利的主要用例再通过智能化兼容性测试去完成，最终生成一个完整报告，然后会有测试开发工程师去判断对应的变更是不是可以对外的，大概这样的一种技术和方式，去解决我们代码指定风险的问题。

【大促质量保障 2.0:运营配置保障】

然后针对刚才所提的运营配置的风险，其实运营配置的风险还是非常多的，影响也是非常大的。我们核心的减法思路是需要把以前人工去 review 运营的配置和每个配置都通过人工去验证的这种方式，尽可能用技术化的方式去替代。同时我们也通过流程化去规划每一个运营的配置的验收流程和发布流程都是有序的、符合我们规范的。

比如说在一次大促里我们几百位运营同学就会在 5 个以上的平台，去配置会场展示出来的各个组件，还有我们的投放的一个排期，比如说在第二天的 8 点展示什么、12 点展示什么等等，然后还包括活动的一些属性以及发奖的规则、奖品的配置以及核销规则等等。

其实这里面很多元素都配错的情况下，都是有可能产生比较影响大的故障风险，然后我们现在是针对运营去配置这些内容，一旦配置完成，在生效之前我们会先启动一个规则制定的流程，这是针对每次大促可能的业务特点我们梳理出来的，并且会对风险进行人工梳理和分析，然后把这种风险转化为一个轻量级的脚本化的质检规则，进行自动化质检和拦截，并且整个流程也是植入在整个配置平台中的，让运营配置同学在配置的过程中实时看到自己的配置内容有没有什么样的问题的一种反馈，然后等质检完成之后，我们进入到整个活动配置的一个 review 阶段。

因为前面所提到的配置，其实还有一个特点，就是每个配置都不是单一存在的，而是环环相扣的，一个平台的配置跟另外一个平台配置可能是一对多的关系，但第二个平台跟第三个平台也有可能是一对多的关系，而这个组合关系如果出现了问题的话，是有可能会带来很大的风险，这个组合关系如果通过人去 review，它起始的成本会更高，要到专业性也更高，所以我们重点是针对整个活动的不太容易去枚举一个数模型，通过技术化的手段去抽象出了一个配置模型，然后基于这个配置模型就能够把配置的变更以及这一次活动相比于上一次类似的活动，它的核心的元素有没有发生一些变化。就比如说上次大促的时候，是限制黑灰产用户不能使用的，而这次如果有运营忘掉了，把这个规则配上去了，我们就能够知道在什么样的比较重要的规则变更，我们就能够把这个 diff 能够更好展示出来，能够把风险预测出来提示给大家。

然后第三步就是我们的配置验收，当配置完成后，每个内容的展示还有后面交付的流程，包括用户的动线还有核销等等，每个环节也都可能出现问题，然后我们通过时空穿越的技术可以提前去模拟到，通过自动验收的能力可以去进行验收。再同时如果是机器能够去判别的验收结果，我们也会全自动化去进行结果的校验，如果是机器无法做到全自动化验收结果的话就会通过人工验收的手段进行辅助，当这个流程完成之后，我们就会进行一个效果预演的环节。

前面也提到，我们很多时候都是以红包去作为最主要的营销载体去触达给用户，红包的金额价值分布还是非常大的，如何在整个营销费用有限的有效的情况下，让不同类别的用户都能得到最合适的红包权益，我们背后是有运营的逻辑，也有算法的逻辑。

我们在这个环节是通过一个效果预演的能力，提前对这次活动可能会涉及到的上亿用户的特征，跟当前的活动对应的算法模型和运营配置的规则进行一个效果预演，我们就能够提前知道大概有多少用户、什么特点的用户，能够得到什么样些奖品，能够得到什么样些金额，就可以供我们提前去识别整个诉求是否符合我们的运营业务预期，然后最终在上线之前还会对配置类型进行权益质检，这个内容的配置要跟另外的配置是需要一个一次性的关系还是需要一个互斥的关系，在这个时候会进行一个整体性的校验，然后这种做完之后我们就会就能够去真正上线了。

【大促质量保障 2.0:外部商家保障】

关于外部商家的保障，我们这里面主要的一个减法思路，是在商家配置过程中的事前准入的环节，还有整个活动运行中的事中监控的环节，以及商店内容出现问题之后事后快速应急的环节，都分别去建了一些非常关键的能力，可以一起组合从而达到对商家更好的保障。

简单来说，商家经过我们平台以及运营的一些配置和选品的关联操作之后，就会进入到真正的会场，然后我们是在商家的配置环节有一些跟运营配置比较类似技术，我们会进行配置的一种防御，包括金额的区间和链接有效性，会进行一个质检，然后去反馈给商家，如果有问题的话就不能够向下进行推进。如果是商家配置的优惠券，我们也会通过一个模拟商家以前的一些交易额的入参数据，去核销这个券是否有商品可以核销，那这种自动化能力去进行自动的验收。如果是一个新的交易参数，我们会提供一个验收工具，让商家可以半自动化去进行验收，如果准入已经过的话，我们的内容就可以去上会场的。

在会场环节，我们通过小程序巡检和小程序监控这两个比较核心的能力，通过主动的方式去识别每次搭选比较核心的几百个小程序，会不会有一些关键的白屏问题和打不开的问题，也会有在小程序的运行日志监控关键报错日志和报警，去识别有没有比较高风险的异常出现。

然后就是事后应急，其实事后应急这个环节相对来说还是比较关键的，因为在监控的时候，首先就是这个出现的概率会很大，其次在每次大促里面差不多都还是有一些问题需要我们去响应的，但如果响应的速度很慢的话，会对用户的体验造成很大的影响。

但这里面有一个关键的技术难点就是在前面的监控环节，我们都是针对小程序去知道它有问题的，但是实际上在我们会场里面真正我们全链路的组成元素里面，小程序不是作为一个核心的元素载体，而我们的核心元素可能就只是一个 LOGO，也有可能是一个权益。我们在事后应急的时候，其实是需要能够快速去做到问题定位：当我们知道某一个小程序的 ID 有问题的，我们怎么找到，到底在我们会场里面的，选品的什么样的 ID，投放了什么样的 ID，什么样的展位，到底跟他才是有关系的。我们要在这么一个复杂情况下去找到这么一个数据或者有可能是好几个数据，然后同时进行操作，从而去实现自动下线。

【大促质量保障 2.0:平台化流水线保障】

前面讲了 3 个在每个专项里比较极致的一些能力，我们把这些合成到一起，最终做成了这样的一个平台化保障的能力。

下面这张大图其实就代表着我们现在 2.0 阶段已经做好的比较核心的平台化技术产出，就是我们已经跟各个研发平台去进行中控设备等内容打通，当这些平台有对应的前端代码、会场配置和奖励配置等各类变更的时候，都会触发我们的整个保障平台的运作，这个运作会通过我们的总控程以及我们的数据智能中心去大致判别：这是一种什么类型的变更，大概需要一些什么类型的保障能力。

我们就能够把这些保障能力进行有效集合，然后在底层去调度，前面也提到，我们其实是整个支付宝的质量团队以及整个蚂蚁的质量团队去分别供给的一些原子能力，我们会有效的去调度，包括有问题的时候我们也会有比较好的一些重试的机制，还有一些人工的机制最终去保障每个流水线的各个环节，都能够有序推动，然后保障结果会通过我们的保障决策程，反馈给对应的要变更的平台，从而把所有能力做到集成以及跟研发系统的集成，通过这个机制同时把刚才所提得到 3 个比较纵向的风险以及项目协同的风险都能够一起解决。

同时，也把 1.0 阶段所提高的 “人工成本高” 以及 “问题易遗漏” 的问题也都能够一起解决，因为在这里面所提到的这个机制，都是尽可能通过我们的保障平台以及数据智能中心积累的经验和沉淀，来进行自动化的生成和尽可能自动化的保障。

【大促质量保障 2.0 总结 - 质量架构内置】

现在我们的大促的质量保障平台以及在每个专项领域做到了深度和比较极致的保障能力的调度和集成，跟我们的研发平台已经形成了一种架构类似的保障。

所以在这样的一种模式下，我们的测试开发工程师就不再像以前那样主要是通过人工测试和保障的手段去完成对大促的支持，而是尽可能的有更大量的时间是在开发和维护各大保障平台以及各个原子能力，从而去保障我们的大促。

【大促质量保障 2.0 总结 - 新的挑战】

当 2.0 阶段已经发展到现在这个程度，我们其实也在看未来的活动会有什么样的走向，以及我们目前还有什么样关键的不足，从而去看我们面向未来还需要去做什么样前瞻性支持，我这里就主要是总结两个方面：

一是面向未来我们的活动更加的高频和多元化，尤其是我们平台目前还有还处在一个关键的需要让我们的所赋能的业务，通过中心化大促去支持更多类型的活动，就基本上是希望能够把支付宝和蚂蚁各个类型的活动都能够去支持。

同时包括我们自己支付宝的活动，活动形态也已经从前几年的非常重到目前的越来越轻的形态在进行转变。我们的活动量级也基本上每年差不多是上一年的 10 倍乃至 100 倍这样的规模在进行发展。

可以看到，因为我们的活动量级越来越大，但是准备过程又越来越短，就意味着可能会越仓促，这些人的经验就有可能会更不足，其实给我们质量所带来的风险和成本的挑战是相比以前越来越大的。

二是大促保障的 2.0 阶段我们的能力提效方面还是有比较大的空间，首先我们的保障能力的广度其实是已覆盖到了从会场保障到运营配置等等，但我们的人还是需要在每次大促中去做一些需要分析的事情，深度还是有些不足的。比如说某某的技术配置，如果配上一个什么词，就有可能是错的之类的这种毛细血管的问题，还不太能够通过以前比较通用的能力去保障，我们还是希望要把我们的保障能力，从广度往深度走，有更深层次的发展，才能够抓住任何一个细微的变更。

另外，因为我们大促数量越来越多，我们的人力会更加紧缺，更加多的去轮换，而以前的专业经验其实是有但是不够具体，不同的人去面对这个领域的时候他的经验会完全的不一样。我们需要在每个专业类型里面变得更加具体，更加不容易遗漏，同时也需要去彻底去解决人工成本。

大促质量保障 3.0 展望

【大促质量保障 3.0 展望 - 智能化与无人值守】

面向未来，我们目前是处在大促质量保证的 3.0 展望关键的雏形期，面向这个阶段，我定义的一个关键词：是希望能够实现真正的在我们的大促的关键环节，实现智能化和无人值守。

这里我先说一下我自己对无人值守的一个简要的理解，传统的保障方式对于我们测试工程师是通过跟研发的沟通，能够主动去知晓研发要提测什么东西，就知道我这是要保证什么对象。然后通过我的测试分析，去决定到底在功能测试里面要怎么去测，用不用自动化，测试用例怎么写，以及是否会需要做压测等等。之后再结合自己的所制造一些质量的一些能力和工具，去判断哪些是通过自动化能力可以去解决，哪些通过人工去解决的，然后再通知开发去进行保障，通知开发我的保障是通过还是没有通过，这是一个比较传统的保障方式。

而无人值守的思想其实是对以前的关键环节有一个颠覆，首先我们是真正去减弱了测试工程师在这里面的主导性地位，当变更发生的时候，我们都希望通过机器去自动知晓保障对象，然后基于每个保障对象要进行真正深度的和确定性的理解，从而去决定我们的自动保障策略。这里面自动保障也是需要我们的各个保障原子有更多的一些技术化和自动化率能够尽可能达到百分之百的水平。

如果有些自动化能力无法达到百分之百，就比如说像兼容性测试等等，它自己可能会识别到这个机型跟另外一个机型会有些差异，但是这种差异究竟是对的还是不对的，它尽可能的去给一个疑似问题率，然后再把真正它觉得有可能还需要人去确认的以及人不得不确认的一些事情，再通知别人。然后测试工程师通过我们的经验，去进行非常简单的，一定需要确认的一个环节进行最终的确认，自动化去跟我们的研发平台进行打通，就告诉它这个变更拦截了，原因是什么。然后开发基于这个问题，就重新再提交代码。

这样的一种趋势可以看到这样的一个变化，就是人的角色已经完全由主动变成了被动了，去减少人和人的这种能力的差异性，同时也希望通过机器把人要做的事情尽可能去利用到极致，最大化减少人工成本。

【大促质量保障 3.0 展望 - 无人值守方案雏形】

然后基于这个，讲一下我们现在的无人值守方案雏形。

左边是我们的各个环节，包括大促的活动各个阶段推进环节，然后第二个是包括个人的变更，有可能是各种细微的配置、细微的技术的运营配置，以及技术的一些代码发生变更的时候，同时还包括在线上运行的时候，我们会接受到客服那边报过来的用户的问题，还有我们通过监控所发现的用户问题，我们都通过自动化的机制，对于我们是否需要进入保障的进行一个全部的百分之百的一个收口，那同时他会在这个时候会基于我们的一些数据化和智能化的技术，去决定我们当前的我们要保障的内容具体元素是什么，需要去启动什么样的保障能力，尤其是更细节的一些保障能力，从而去进行自动化保障和人工保障，而这里面人工保障就完全会因为自动化保障的一个结果，去决定到底是否还需要去做人工保障。

然后在保障结果完成之后,我们的保障决策会通过对这个保障能力所识别的风险,它到底是一个准确率非常高的风险还是有可能有误报的一个风险,会基于历史经验进行自动的决策和判断，然后再判断是否需要去把这个变更打回。

如果是机器实在判别不了的情况下，我们才要人在里面去参与进行打标，再把这个变更是否拦截以及是当前的线上问题是否应急去反馈到对应的当前的处理环境里面去。

同时我们会通过一个保障演进去不断在每次大促准备阶段，评估到底人打标对我们的保障经验又贡献了什么样的数据，以及我们在运行过程中什么样的保障能力对解决什么样变更是最为有效的，也最为准确的，以及我们还有哪些问题是我们的保障能力没有解决好的等等这样的数据，我们把它进行一个经验化的一种传承，进而不断地去让它去影响整个个性化深度保障流程去生成的一个过程，然后最终希望通过这个机制，能够真正去实现智能化和无人值守的保障，去减少人在这里面犯错的可能性，也是我们用同样的机制在未来能够保障更多类别和更多量级的活动。

Q&A 问答时间

01 运营配置的稳定性等是怎么做的？

回答：我所认为的运营的稳定性，它其实还是处于风险的一个角度去保障运营配置的风险，这个是可以去有效拦截的。

在实际层面，就包括我这个流程可以看到其实是比如说第一个规则字典，我们还是要通过人工专家经验积累的一些沉淀，然后就知道什么样的配置一定是需要在什么区间才是对的。

除此之外，我们在活动配置模型和效果预演这两个环节，尽可能通过一些数据的技术和新活动的配置跟以前的配置进行一个对比，这种大批量的数据对比和数据分布计算模式，去预测运营配置的效果，大体是通过这种方式其实是基本上能够百分之百的去解决我们运营配置的一些确定性能够出问题的那种可能性。

然后在一些实际的效果里面的话，我们现在的运营配置的问题基本上通过我们这个能力的拦截率已经达到了 99% 了，基本上在每次大促里面遗漏问题都差不多是以前我们的经验还不具备的，大概还会有一些少量的接近 1% 的遗漏，这个是我们目前运营配置保障稳定性保障所做到的一种技术和水平。

02 面对这么长的链路，这么复杂的配置以及不同的活动，那我们的自动化是怎么做的呢？

回答：可能问这个问题的同学，他们应该还是更关注我们的技术代码的自动化，那我就针对代码的自动化去讲一下。

比如我们前几天刚刚结束的一个夏季大促，它的会场和玩法的形态和我们在端午大促有一个类似的会场，但是可能还是有百分之二三十的元素是不一样的；然后在之前我们 5 月份五一的大促也有百分之三四十是不一样的，而这几个大促相对于去年就有可能会有百分之八九十是不一样的。这就是我们大促的一个特点。

在实际的研发投入当中，相对于后端研发，我们前端研发在每次的代码的变更量相对大很多，平均来说，前端研发的代码量应该是后端变化代码量的四五倍这么一个量级。

因为每次的大促的一些元素，其实是完全长得不一样的，只是有些功能看起来是一样的。针对这样的情况，每个月完成一次大促，其实整体的链路又比较长，如果我们去写自动化用例的话，很有可能写不好的话要写一周的时间，然后运行可能运行一周，但下次大促又有可能这 5 天写的自动化用例就用不了了，所以我们基本上就不采用通过测试人员去写自动化用例的方式去解决。

所以如果需要去写自动化用例的话，我们就只会去抽象我们有可能在一年里面都不会变化的一些元素，比如核心的一些抽奖的接口，还有我们的那个每天 8 点和 12 点去抢消费券这样的一些核心的功能，会对它的预期是什么，什么场景下的入参是怎么去进行一个自动化沉淀，这个是跟自动化用例相关的。

除此之外，我们重点是核心抽象到底在我们人力有限的情况下，我们底线是不能去犯什么样的风险。如果这个风险一旦出现的话，又有可能会给我们线上带来故障，就基于这个点我们又进行了一种端到端的抽象的总结。

还是拿我们以前那个红包雨获得消费券举例吧，就是每天的 8 点还有 12 点要抢券，其实每天应该是有几百万几千万的用户会在那个时间去抢，但是那个功能如果一旦发生问题的话，很有可能产生一种微博上的热搜事件，我们针对这种功能的话，主要是还是因为这个功能他其实每天都会变，只要我们的活动持续一个月，这一个月每天晚上都会有对于技术变更和运营变更都会影响到第二天红包雨抢的对不对。

所以我们就基于这种东西的话就会把自动化做到极致，当每天有针对这个红包雨的配置发生的时候，我们在配置的每个城市的预算，还包括领取时间等这些规则会有一个非常强的自动化校验，第 2 天时间到了之后，我们还做一个自动化模拟第二天去抢券，通过端自动化的技术把会场渲染出来，然后点击按钮自动模拟去抢到了，然后再去检查对应的预算有没有减少，就这种情况下我们会把对应的自动化做到极致，同时也抽象了就刚才所提到的一些核心的风险类别，比如说出现白屏或者某个页面报错打不开了，这种通用的东西我们也会进行一个自动化的校验。

在结果方面，我们这些能力叠加之后，其实在端上和全链路的关键技术风险的提前全自动化拦截率，在我们最新的一次大促里是已经有 90% 以上的效果了。这代表着我们用比较低的成本去写自动化用例，但是用比较高的成本去建一些通用的技术保障的手段，这在真正的问题难解的效果里面收益还是非常明显的，大概是这样的。

03 支付宝做了这么多自动化，包括智能便利、核心链路的自动化，那我们测试充分性是怎么做的？

回答：这个问题我可以回答一下，但是有可能问题的答案和大家的预期会不太一样，所以我这里就需要再重点去讲一下我们支付宝的活动和大促，它其实是跟平常的业务项目的迭代确实是有一个本质的区别的。

平时的一个日常项目，它其实是有更为严格的一个风险规范，在做开发工作量还有测试工作量以及测试充分的评估的时候，都会有非常成熟的一个代码覆盖度模型，从而尽可能避免所有的线上问题不要遗漏和出现，日常项目是这样子的。

但是我们的大促，是有一定的特点和有它自己的特性在，比如说，有的大促只有两周的时间，而在这两周的时间里面，其实我们的开发工作量和测试工作量还包括保障的工作量，其实是远远不够的，这个时候我们自己公司的战略目标会更加的关键。

比如在某段时间我们觉得在那个阶段去做一些活动，会对公司非常重要，一定要把我们的活动上上去，时间就会非常有限，在这种情况下我们的主要思维逻辑就是一定要在有限的时间内把最关键的风险和问题给防住，一些比较细小的问题因为时间有限，我们还是要在这个地方进行一个容忍，在这种情况下，我们就把这种问题可以通过一种事后的经验沉淀的方式，再把它补充到我们的整个保障能力的一种建设中去，就大概是这样的思路。

所以说我们是不会在事前对充分度进行非常多的那种比较细致的考量，但是我们自己在梳理跟故障相关的底线性的风险的时候，会基于故障的模型去进行梳理，然后反推到我们到底在运营配置以及商家以及代码类都一定要去防什么，使我们的技术能力更加完善和丰富，以这样的方式去完善覆盖度的保障。

04 在整个活动保障里，涉及到研发、测试、运营、产品等等很多角色，那协作分工是怎样的？

回答：其实可以看到我们的大促和活动的环节是非常多的，从最开始的大促启动到测试阶段，除了常规项目所面临的产品开发和测试之外，其实运营这一个角色从头到尾基本上都会非常大力度的去参与，在实际的人力规模里面，我们的每次大促应该是运营的人数是明显是最多的。

一般一次大促，差不多有几百位运营同学，然后产品的话可能有几位产品，然后研发和测试差不多都会有几十个同学。

在测试具体的角色里面，我们其实也还是有比较细致的分工，比如说一个大促因为协同是比较复杂的，我刚才其实所举例都是讲了主会场的一个形态。但其实在主会场的背后，还有很多二级层级，比如说这下面就有一个直播也是一个比较独立的一个功能模块。其实除了主会场之外，就代表着有非常多模块的测试同学他们也都很有可能是来自不同部门不同团队，测试大概就会有这么丰富的一些业务测试的角色。

除此之外，我们的专项保障角色也非常多，也是有专门的同学去完成的。此外我们的三方保障，就是跟外部的商家和机构对接也会有行业那边的保障同学进行保障除。另外，我们在安全领域、数据领域、算法领域和客户端的运营配置也都是有专业的做这个领域的横向的保障同学来进行保障。

然后像刚才有提到的运维的同学以及 dba 的这种跟数据库相关的同学，其实我们公司在大促里面就这方面的人介入的不多。比如说，如果是涉及到那个机器调配的事情，就基本上还是有稳定性的接口的同学会负责总体的，会有他们进行统一的收口。