作为亿级日活的平台，支付宝承载了大量民生服务，这些服务大都是由支付宝生态合作伙伴供给，并且深度地融入了百姓的日常生活。提升生态服务质量，帮助合作伙伴业务成功，已经从简单的交付承诺衍生成为一种社会责任。希望借此机会，分享支付宝对生态业务质量风险体系的整体设计思路，介绍平台如何理解业务质量、并通过技术特征的挖掘分析，协助生态合作伙伴发现并消除其中的质量风险与问题。

讲师介绍

顾惟祎 高级测试开发专家
现在负责支付宝生态合作伙伴的服务质量与体验。以深入一线业务的视角，提供行业质量解决方案，支撑政务、出行、餐饮、教育等多个行业的合作伙伴，挽回了潜在的用户流失风险。有数据中心基础设施、互联网广告、多行业解决方案的从业经验，擅长综合业务模型和全链路技术特征识别和解决问题。

王啸 测试开发专家
主要负责支付宝行业产品域和行业生态质量保障相关工作，2014 年加入蚂蚁金服，深耕在业务技术风险领域，先后负责过数字金融域、行业域等重点业务域的风险防控和保障体系，主导了支付宝乘车码、12306、互联互通等关键产品的质量工作，在业务质量风险防控、质量产品、及工程效能等架构设计和研发领域有着丰富的经验。

以下内容根据顾惟祎 、王啸两位老师在 TesterHome 社区与支付宝质量技术主办的测试之美《支付宝生态质量保障》主题技术沙龙直播现场所讲内容进行精简整理，大约 5500 字左右。

风险概览

其实我们会有很多种的手段去发现风险，
风险的整个生命周期的话：

• 需要对问题进行分解
• 理解到底是哪一方发生在哪里的什么问题
• 再给出对应的解决方案
• 并且最终沟通落实。 在https://testerhome.com/topics/34657 提到的巡检、验收、监控这些是由我们技术能力主动去识别到的风险。这些风险有明确的技术特征， 他们的能力都是可以复制的，对应的这样的风险特征，去提供解决方案的话，会很容易的去形成转化。

但是实际上在生产环境，在线上很多的服务现场，有很多的问题，其实是没有办法通过这一套技术能力去识别到的，就需要我们被动的通过用户客诉、舆情反馈来感知到这里面存在问题。

这些问题通常都零散的，而且由于之前我们技术能力没有覆盖到，所以他本身的问题现场也是未知的。我们需要通过理解才能够感知到这里面到底存在什么问题。
那么在整个线上实际的这个风险场底下，我们会面临的两个问题：

• 首先：现有的技术体系是看不全的，这里要求我们用一个开放和发展的视野去持续的捕获里面的风险，去完成从被动反馈中的案例现场，找到这里面的技术机会点， 然后往主动召回的技术能力上去转化。
• 另外就是：当问题不够清晰时，就算在真实在线上发生了，但也很难和合作伙伴一起去推动解决。

历时案例

• 第一个例子
  今年 3 月 14 号的时候，由于疫情变化，然后行程卡业务量有了飞速上涨，当天上午行程卡整体的用户量达到了一个非常高的水位。在这个现场，支付宝自己一部分的接口的限流，没有做动态的调整，这时候如果被限流，在用户的现场可能就会导致网络不稳定重度的情况。
  这个现场场景非常罕见，当时在现场应急也是花费了一段时间的。

• 第二个例子
  从 2021 年开始安卓的 webView 的 95 版本，其实做了一些 cookie 的策略变化（影响到了 cookie 在客户端上的保存）。当完成登录，cookie 保存后，在读取的时候变成了空，导致用户登录完成，执行后续操作时，又回跳到了首页。

虽然这个问题其实变更在底层，但是了影响到了顶层的业务，而洞察到这个问题的话，还比较困难的。因为当时 webview 95 放量是很缓慢的，线上碰到的案例是非常少的。

• 第三个例子 用户现场的表现是没有办法查询到证照，但是这个现象在线上并不是全量存在的，是有一些问题特性的。 最后定位出其实是核心的接口没有跑通，https 的请求没有发送到指定的服务器，问题发生在 DNS 的阶段，因为运营商的一个 DNS 污染。

这些案例其实说明，我们的问题、技术风险是可能发生在技术栈上的任何一个环节的。

这里面的风险特征是可以枚举的，图中用蓝色框和蓝色线条标注出来的是支付宝主要负责的链路，这条链路上面支付宝会识别到我们自己的问题，但是这个问题识别并不完整，然后也会不断的扩展。比如上面讲到的内核层面的一个机制问题，而且在业务层面来看的话，所有这个业务场景所面临的挑战，里面的风险特征是很离散的。

我们可以以 API 为界，API 以下是平台所承诺的这个行为，而 API 以上就是业务该解的问题。

在这里面我们和和生态合作伙伴之间的交互主要有这几种形态：

• 小程序客户端上的 jsapi，或是一些像扫脸的 SDK 移植到外部的 APP 上面，负责和 native 进行通讯
• 业务层面的接口，通过 https 或者 webSocket 的等等之类的，业务前端和服务端通讯 这个层面。支付宝会承接底层的网络通讯，但是只到这个 http 协议这一层，至于这个协议里面的数据，我们也是没有办法捕获和理解的。

支付宝可以提供一些基础的监控、基础的告警，但是真正涉及到业务层面的内容，还是需要业务的同学一起来去建设。

• open API 的接口，比如说常见的支付、会员、营销这些通过集成一个阿里的 SDK，
  然后去发起往支付宝网关的请求

• spi 接口
  通过在支付宝注册第三方系统服务，来去从支付宝调用合作伙伴服务端这种形态
  支付宝可以感知到的是在这个接口的边界上，我们的一个基础的监控情况

治理策略

面对上述碰到的这些困难：

• 风险是不断的发展的，不一定看得全
• 问题是很复杂，我们没有意愿去看

那我们采用什么样的策略：
-第一个当然就是问题要看全，并且要有一个开放的视野，不断的去发展的看待问题。

我们是如何不断的补充特征的？
往往关注度最高的是这类完全阻塞到用户现场的一类问题。在支付宝这边，会有基础层面埋下的这些问题特征，叫白屏错误页或者加载问题。在这里面这些问题是我们重点治理的对象。但是在疫情变化的情况下，面对场所码、健康码，我们不只看白频率，还会关注扫码体验。

真正去看待这个服务是不是好用的时候，需要站在一个完整的使用链路上来看待，比如上海核酸码，进到了随身办首页，要先完成登录人脸认证，然后最终展码。

这个过程会涉及到非常多的技术形态和技术特征，这里面的风险我们要完整的关注起来才能去更好的去识别问题。这里面要评价的风险实体可能可能包含了小程序本身、扫脸这个业务、码值 H5 页面和他的核心请求，对应的特征也进行了枚举。

更大的颗粒度的话，刚刚提到这些，也只是一个特定的剖面。
我们会面临不断扩展的技术特征，这个特征可能是，对支付宝端内的，不同技术团队提出的要求，也有可能是对我们上下游技术栈，也可能是跟 google、apple 的交互。

而横向我们会不断的去扩展我们业务的视野。

我们在业务场景关注的风险不仅是离散的，而且非常的稀疏。如果这里面我们要去识别风险，一定要从这个弹性的试图里面，去聚焦到我们所关注的那些风险特征和风险实体，才能去识别问题。这是一套发展的评价体系，要不断的去扩展特征、扩展场景。

数据和特征其实决定了机器学习的上限,而模型和算法只是逼近这个上限而已。

如果把验收、监控等等都当做一个模型，支付宝是一个大的风险发现模型，这里面我们仍然要去处理的一个命题，就是不断的去补充我们的风险特征。

第二个问题是说这些问特征这么多，我们怎么去表达他的业务价值，哪些风险该治理哪些不该治理。

这里面我们会引用一套理论，这个理论来自于这本书叫《用户体验度量》，把这个用户体验描述成为这几个可度量的指标，就是当你在平台上使用这个产品完成一个任务的时候，你一定会有在完成这个目标过程中的成功率、耗时、步长、学习成本。

学习成本意思就是第 2 次来用这个产品，相比第一次他的复杂度的收敛情况，就比如说操作的步数是不是有明显的收敛，或者成功率是不是明显的增加，以及异常体验

在这种情况下去度量这个体验的话，在工程上是有这么一个转化的：
首先一定是跟用户怎么使用这个服务是相关的，比如说点餐，或者展示核酸码，这个过程是一步步操作，通过某些页面上的一些控件触发了一些事件，并且进行了进一步的交互。

在这过程里面，我们需要有一个基础的访问数据。
在基础的访问数据里面，通过理解用户的行为会得到基础的行为链接，在这个行为链录里面可能是比较杂的，而且只有相对基础的一个数据，没有办法去清晰的理解到是什么业务语义。但是如果要真正理解业务影响，势必要把它进行业务语义化，把刚才的基础行为链路去做语义化的方法有好几种：

• 第一种是主成分
  访问量最大的，这条边的技术最大的那就是主成分，看主成分上是不是有异动、有流失

• 第二个定义的业务核心链路
  点餐：从首页到菜单-》菜品页加购购物车-》确认订单-》支付详情，就是这么一个过程

不同的行业可能会有不同的挑战，《质量验收与检测技术》讲到的智能动线，这个智能会跟用户的行为是有关联的，都是基于业务场景下一些特定的行为，操作数据层面是可以看出规律的，这是可以训练的一个模型。

• 舆情感知的现场 舆情反馈的用户现场，肯定是经过一系列的操作才碰到了困难，线上这一波用户，他的行为链路是不是有些共性？都是在经过了某些页面、某些服务后才碰到的问题？ 这是一个值得挖掘的点。

问题诊断

生态问题排查的痛点：应接不暇、无需低效、惊艳孤岛。
这里有三层意思：

• 第一层
  支付宝海量的生活服务，以及提供的这个服务能力，加上支付宝海量的用户群体以及高频的使用的一些场景，带来的是每天大量问题的这个涌入。

• 第二层
  复杂、庞大且庞杂的特征体系，离散稀疏的特征分布以及规则化、碎片化的业务特征。

比如以公交的场景为例：公交在排查问题的时候，可能有卡的问题、码的问题、行程、结算等等这样的问题，公交覆盖的百城千线，可能每一个城市，它的规则又是不一样。

比如说各个不同的城市账期就会有不同，a 城市的重复扣款跟 b 城市的重复扣款的规则也不同，很难用一套所谓的银弹把这个问题的结论直接给抛出来的，也没有一个非常理想的类似错误码的这种形式，直接能给出这个问题的定义的。

所以这个量特征的复杂以及业务规则的复杂，就带来的诊断的这个复杂性。在排查问题当中会非常的低效，在排查过程中又非常依赖人工的经验以及这个专家文档的沉淀。所以类似样像森林能量这种 日常高频的生活服务，会有特别多的这个问题，其实我们内部会有一些千人的群，最后提供的诊断服务都是通过一些文本的方式来提供。

这个就会形成一个恶性的循环，在最后一定会变成无序低效的这么一个结果，至于这些痛点，怎么来打造一个好的诊断系统来解决它呢？

• 最关键的是要去抓住，这些生态问题本质核心的特征是哪些。基于特征作为抓手去定义整个问题排查的模型，并以此模型来指导我们去把问题给排查出来。

可能大家会问：
既然有这么多的文档跟人工经验，那是不是可以把人工经验给自动化掉、工程化掉，就像写验收验用例是一样的，通过一些用例的方式，把这些问题的规则，先查什么后查什么给落下来，最后是不就能起到这样的作用了？相当于是一个啊自动化的过程？

坦诚的来说，其实一开始我们也是这样想的，并且也是这么做的。我们围绕着不同的业务去落了很多的排查规则脚本，然后这个当中打磨了非常多的编排的能力等等，但渐渐的我们发现这其实无法解决本质的问题，这里面有 3 个原因：

• 整个业务的脚本排查，非常的复杂，是没有办法通过这一套脚本来完整的回答整个百城千线，就像刚刚公交问题里面的这些个问题
• 这些业务规则脚本的铺设，是人力在这个里面的，随着这个问题越来越多，规则越来越复杂，这个规则本身的这个维护和保鲜是非常大的成本
• 这些规则的脚本可能解答的只是单 case 的这样一个问题。 今天能告诉你发生了 a 类问题，那可能这个回答的是 a 的问题；b 又来了一个反馈，那可能给的是 b 的答案。 但是其实对于生态场的排查来讲，我们其实背负了更大的一个命题。怎么通过诊断模型面对这些海量的客诉，去提供、刻画整个业务风险的一个视角，能够回答说今天到底有多少类的问题，它的原因是什么。 也就是在生态当中，常常是通过一些个例问题的排查、聚合，最后反馈出原来这个地方有一些聚合性的问题，然后给到生态的合作伙伴，推动他们去消化跟恢复。

所以我们的诊断模型是聚焦在特征的诊断模型。其核心的原理就是我们能够在有限的、不完整的、不确定的这个条件下，能够追溯到用户的业务场景，以及把用户的技术特征给刻画出来，最后来推导出一个接近真实的结果。

那么举个例子：
我们比如说每天都在发生的一些热线的客诉情况，话费充值到账的这个问题，突然之间可能有 7 条舆情过来，反馈的是一个集中性的问题，这时候就会引起我们的高度重视，为什么今天在支付宝做话费的充值，没有办法到账？那这时候应该怎么办呢？
原来的方式就是每一条都花人力去投入、去排查，然后每一个排查时候，我们要确定他是一个什么样的场景，找到什么样对应的文档，给出一个结论，最后做一个规避。

以特征的这个方式来推导的话，会提前是这样做部署，针对这个话费缴费的业务去抽取他的风险技术特征，（在这个缴费当中，会定一些关键的特征，比如说这个卖家的 pid 是哪个、这个商户运营商是哪一个、货源的类型是什么、渠道是什么、这个订单的状态是什么）那围绕这些特征，对这些特征进行数据的抽取，可以是通过日志抽取取、通过设备底层的信息进行抽取、通过数据库的一些信息进行抽取，最后拿到这些特征，并且在最右侧会针对这这特征，去编排我们的这个诊断规则。

最后这个问题诊断出来，我们不单单会给出一个定位的结论，同时会给出这一批量舆情，问题当中的 top1、2、3 共性的这个特征是什么？
比如：能知道货源类型可能是属于哪个平台的，卖家的名称可能是哪个商户的，卖家的未到帐的原因可能是什么。我们就能知道这一个客诉事件中这 7 条舆情，60% 或 70% 是一个什么样的原因。

特征的这个模型有了、诊断的模型有了我们基础的能力有了，我们在想怎么样能够更好的、更加精准的去还原用户的这个这个行为，达到更精准的定位。以此就推导，我们需要依托这些场景去进行精确的定位。

何为场景：根据用户的这些行为动线，来还原出用户在支付宝整个业务服务的过程中：

• 从哪里来的？
• 到了哪里？
• 在哪些页面做了哪些操作？
• 最后又去向了哪里？
• 可能是外部的商户？
• 可能是一些结果业等等一些场景？ 流量雷达通过对线上数据的度量，能知道这个是什么场景。

回到排查当中其实也是这样子的，根据问题的路径，进行定向的诊断，会把用户的上下文，以及他的行为场景给刻画出来，然后不同的行为场景会挂载更有效、列针对性的这个特征。
比如说在这个随身办的这个业务当中：

• 我们会从首页进来 -》授权 -》扫脸
• 授权会去关联授权相关的一些风险特征
• 扫脸会关联扫脸相关的一些信用的特征
• 然后在某一个固定的页面当中，就只查跟这个页面相关的特征以及他的一些规则。

以此能够把这个时间范围缩小、行为特点跟这个用户的这个上下文的场景关联起来，
最后得到一个相对来讲，比较精确的定位结果。

生态发展

生态质量其实我们未来一定会沿着开放共赢的方向去发展，那在这个当中，其实必须明确的是，最懂业务的一定是合作伙伴自己所以从支付宝的整个的视角来看，一定是
提供好自己平台能力的支撑，把所有的风险特征以及我们捕获到的一些种种的用户的行为，包括我们自己有的一些能力，作为一个开放的方式提供给和合作伙伴，以此来提升整体的这个质量开放后的能力。

目前在支付宝内部，已经开放了大概有 4 个这样的产品：

• 全息检测
• 质量洞察
• 监控报警
• 用户反馈

全新检测，就是在用户的现场调试时、开发小程序调试时，能够快速的帮其暴露出
在支付宝视角看到的一些问题。

那质量洞察和监控告警就是在运行态这个阶段，能揭示出线上运行的一些风险。洞察是至于一些离线的数据，消费到一些风险的特征、指标，给出一些异动的分析给到合作伙伴。

监控报警就是线上通过我们自己的监控，感知到了一些敏锐的异动，同时触达到这个商户。

那么最后其实发现，通过我们自己的洞察也好、监控也好，可能未必能完全发现所有的问题，最后就需要依赖到，用户的一些反馈。如果用户有些困难，那这个时候我们会收集他的原声和他的声音，给到我们，以帮助我们做一定的这个排查。

相关视频内容，可直接在 TesterHome 视频号进行观看