作者：王文华(连墨)

千牛是阿里巴巴商家的多端开放式工作平台，每天服务数百万的活跃商家在移动和桌面端操作业务，包含店铺管理、客服接待、资讯消息等多项功能。

同时，千牛本身是一个开放的端体系架构，二三方能通过开放体系（我们称为插件体系）为商家提供服务。之所以叫做插件，是因为我们在商家的经营链路中，定义了若干个开放节点和标准，由业务方根据标准实现，并完成相应的功能。正是因为这些标准和规范的存在，使得不同的插件之间可以串联起经营链路，从而规避因商家选择不同插件所导致的功能闭环被打破问题。

下面是千牛定义的开放节点：

开放促进了业务与三方 ISV 的入驻，使得千牛能更加充分地利用外部资源服务，比如加快开发进度，满足商家的定制化需求等。一款三方插件需要经历 4 个阶段：ISV 开发，服务市场上架，商家购买，在千牛上使用。在商家未选择默认经营插件的情况下，千牛也有一套规则引导用户优先试用插件的免费版本，ISV 则可在商家试用过程中引导升级订购来盈利。但是开放也会带来相应的问题 —— 商家体验问题。

为了提升商家体验，我们发起了开放体验升级项目。经过持续的治理，千牛月均开放舆情数量实现了减少 50%。那么，千牛有哪些舆情，防治整体方案又是如何设计的呢？

问题和产生原因

千牛开放舆情的特点

由于开放的特点，千牛开放舆情比较分散，且成因复杂。千牛上的工具数量众多，由二三方团队提供，部分二方工具历史悠久，维护投入不足，而 ISV 间的技术能力参差不齐。开放技术栈多，有早期的 H5，中期的 QAP（weex 封装的开放框架），以及小程序。插件启动链路长，从前端到 ISV 服务端涉及 7 个以上技术链路，容易受网络和各个服务抖动影响。众多的不稳定因素给开放舆情治理带来了挑战。

开放体验的核心问题是什么？

开放类体验问题多样，主要包含以下三类核心体验问题：

1. 插件打开整体链路较长，在投放，商业化订购，容器运行加载各个环节都会影响插件启动；

2. 千牛端因为有主子账号的权限管控的设计，主账号可以在各功能限制子账号权限，子账号在使用时会出现权限不足的阻断性问题；

3. ISV 或二方业务自身逻辑问题多，千牛作为平台目前缺少足够线上问题感知能力和有效的推进治理的抓手。

防治整体方案

• 优化插件启动链路: 提升启动链路技术产品的容错能力，优化打开成功率到 99.7%以上。

• 建设权限申请闭环: 提升权限申请和审批效率，优化子账号使用插件的体验。

• 建立数据衡量体系: 沉淀驱动业务优化的抓手。

千牛上业务多，舆情原因复杂且变化快，只以舆情问题切入单个解决是不够的。开放业务的的治理是循序渐进的，需要一方面解决已知问题，另一方面对插件启动和运行阶段的核心节点建立衡量标准和稳定性监控，巩固治理成果。以治理-监控-预防-优化的思路驱动舆情下降。

启动链路优化

启动流程介绍

• 协议路由: 千牛官方定义了一组开放节点(坑位)和对应的标准协议(e.g.tradeDetail 查看订单详情)，由 ISV 根据协议实现承接的功能。这个阶段需要解析配置的协议，路由到用户设置或运营配置的默认插件 appkey；

• 插件元信息查找: 从服务端下发的插件列表中，找到目标 appkey 对应的插件元信息；

• 权限校验: 校验子账号是否有权限打开此插件；

• 商业化保障: 为新用户或订购关系过期的用户，完成免费版本的订购；

• 前置授权 QAP：对于三方插件，需要用户显式授权来允许三方 ISV 访问数据；

• 容器路由和渲染: 根据插件元信息, 组装业务参数并交给对应的容器渲染。

全链路监控

首先需要定位插件启动失败的原因和分布，并以此确定后续治理和优化方案。虽然理论上可以对每舆个情分析日志，但实际操作中，由于工作量大，而且缺少全局统计视角。因此，首先建立插件启动全链路监控，保留错误上下文信息，统计准确的启动成功率和失败原因分布，为优化提供衡量基础。

埋点维度包括目标插件 appkey, 技术类型（H5, QAP, 小程序)，出错阶段，错误描述，打开插件来源或入口信息，每个阶段启动和结束的时间。

这些维度有几个作用：

1. 配置不同维度的告警，比如 H5 的插件成功率突然下降或者某个阶段出错的次数明显增加；

2. 在整体成功率变化时，方便比较不同维度的趋势，快速定位是哪个级别的问题；

3. 出错阶段信息方便按阶段来看出错分布，分阶段优化成功率；

4. 打开来源和入口信息提供了更多问题出现的场景信息。

插件启动优化专项

通过全链路监控可以看到有两类错误，一类是插件打开的前置链路失败，另一类是订购关系未建立；

前置链路容错能力提升

启动前置链路错误的主要原因是弱网或服务端抖动造成的启动链路关键信息缺失，比如插件元信息和小程序包，通过异常补偿优化。千牛通过梳理了核心经营链路的头部插件，内置元信息，利用订阅关系和场景化信息预下载小程序包, 优化后小程序包命中率从 85%升高到 97%，整体失败次数下降 55% 。

商业化保障方案升级

在千牛端，商家必须和插件建立订购关系后才能使用插件，是周期订购的商业化模式。在使用前千牛为商家续订免费版保证主要功能可用。通过 Review 旧方案，发现原来的产品链路不能覆盖订购失败等场景。升级商业化保障方案后相关错误次数下降 56.7%，前置链路耗时下降 170ms。策略如下：

• 异常补偿：协调服务端增加订购状态信息，如果在建立订购中，则延时重试查询，等待关系建立后再打开 (订购流程涉及汇金等外部系统，生效时间波动大)；如果订购无法成功 (e.g.ISV 被处罚，订购冻结)，引导更换同类插件 (并用质量分加权影响排序，驱动 ISV 优化)

• 性能优化：给前置订购链路增加频控策略，降低前置调用频率。增加后置续订延长有效期，避免进入前置流程，同时也能覆盖那些没有通过插件流程打开小程序的场景。对于最常用的默认插件，增加闲时静默续订。

启动优化专项结果：成功率从 99%升到 99.7% ，前置链路从 350ms 到 130ms；

权限申请链路建设

卖家端以主子账号来做团队协同，子账号会遇到权限不足的开放体验问题。今年千牛建设了移动端的权限申请链路，来优化商家的子账号使用体验和权限审批效率。

申请链路：

1. 拓展客户端 API 给二方，由二方主动调用触发申请引导，满足通用需求；因为二方校验方式灵活，缺少统一收口。

2. 切面检测三方链路上的权限不足，自动触发申请提示。由于历史原因，三方小程序分两类 (权限粒度维度)，有不同的检测方式。a. 从 QAP 升级的小程序: 打精细化授权标，授权粒度是权限包(匹配 TOP 响应的错误码) b. 直接以小程序身份入驻：没有精细化授权标，授权粒度是小程序应用级别 (匹配 getAuthUserInfo API 错误码）。通过监听小程序 API 调用，触发申请流程；前者还需用 TOP API 名去服务端换权限包和权限点信息后，再创建工单通知到主账号审批。

审批链路： 主账号收到待审批消息，点开直达对应权限审批详情页。

优化后，子账号权限不足的错误次数下降 57% ，相关舆情下降 52% 。

数据衡量体系建设

开放工具的功能和质量主要取决于业务逻辑和服务可用性和稳定性，因此要定义核心指标，监控线上异常，及时处理。数据衡量体系建设主要包括体感指标建设、舆情 SOP 优化、以及开放体验大盘搭建。

体感指标建设

通过小程序的事件机制建设了 TOP 和云应用的业务成功率，自建了体感白屏率（H5，weex 和小程序），拓展小程序白屏率检测方案，多次监控到业务方线上问题，推动回滚和修复。

插件核心运行质量指标

下图千牛插件运行期间的核心节点，可以通过建立对应指标全面监控线上插件运行的稳定性。除了常见的纯技术指标：接口业务成功率，bridge API 成功率，JS error 率等，千牛还建设了体感白屏率来反应插件线上运行质量。

体感白屏率

虽然有了核心节点的技术指标，但这些技术指标并不能完全覆盖功能不可用的场景：某日云应用扩容，新机器配置问题导致订单数据为空，但接口是成功的；某些技术指标错误，并不代表一定会功能不可用，比如部分 JS 错误。所以需要建立指标，从体感上直接度量可用行。其中，千牛插件功能不可用最常见的问题是白屏。

白屏率定义：在一定时间内，页面元素得不到及时的展现，导致页面布局出不来，或者出现错误的打底页面，或者部分的图片出不来的页面，定义为白屏。

检测方案：在千牛端小程序场景下，主要分为噪点场景过滤，白屏检测，和结果上报三个阶段。其中结果上报主要使用魔兔埋点平台上报和告警，不再赘述。

噪点场景过滤：

• 存在打开某个小程序页面 A 后，ISV 代码自动跳转/切换到其他页面 B，当用户访问页面 A 才会触发真正的渲染。因此如果在 A 不可见的时候检测，会被认为是白屏。这种技术实现差异造成的伪白屏并不影响用户体感，并不是我们的检测目标；

• 千牛大量的小程序是三方提供的，在访问用户数据前强制要求授权，因此如果检测时，还卡在授权流程中，小程序页面是白屏的，可检测授权弹框避免误判。

• 部分小程序页面使用了同层渲染的能力，比如使用了视频，地图等组件的小程序页面。这些元素不是正常的 html 元素，无法被 JS 探测到，但并不是白屏，需要通过配置页面白名单的方式过滤。

检测策略：

白屏检测主要策略是统计有效元素个数，有效元素指的是文本，图片等有效信息载体。在小程序和 H5 插件上，通过注入 JS 到 webview, 获取界面元素的统计信息。千牛端和大多数 C 端应用不同，千牛存在不少重输入的页面，比如问答插件的回答页面有大片面积的输入框，这种情况下认为不是白屏，通过检测是否存在输入框相关组件判断。在千牛端，如果商家没有订单，页面可能出现较大面积的空白，所以需要过滤存在"还没有", "暂时没有"等白名单文案，避免误判为白屏。

经典案例

二方业务白屏

4 月某二方业务线上用 4g 网络访问情况下，出现白屏。白屏率指标及时告警，白屏率可以看到分钟级别的明显变化，修复后回落，避免了舆情飙升。

三方业务改版触发限流

3 月收到某头部三方插件调用物流接口告警，主要错误是被限流，成功率只有 80%，明显低于平均水平。原因是该 ISV 新版本在订单列表查询物流信息，导致调用物流接口量太大触发被限流。通知 ISV 从产品层面进行了调整后成功率明显上升。

舆情 SOP 方案

千牛上用户反馈很多是从全局反馈入口进行反馈，缺少插件上下文；而且用户对插件心智不足，反馈问题的时候指向性弱，舆情分析和问题驱动难。千牛的方案是记录插件使用动线，在用户反馈插件类舆情时，展示最近使用工具，引导选择反馈目标插件，给舆情信息增加目标插件信息和问题分类，便于统计和告警。上线后，带有插件 appkey 的开放舆情占比从 11.95%升到 95% 。

开放体验大盘

通过整合舆情、技术指标和体感数据，千牛建立了开放体验大盘，做到了插件体验可跟踪、可衡量。依据插件舆情数，技术指标，体感指标建立插件质量大盘，对千牛插件质量一目了然，成为推进二三方优化的重要抓手。

总结

千牛优化了插件启动容错能力、建设了子账号权限申请产品链路，提升了自身链路的可用性。也通过建设体感指标，提升舆情反馈和分析能力，搭建开放体验大盘，对线上插件运行质量建立了上帝视角，既能及时发现线上问题，也能通过数据有的放矢地驱动二三方业务优化，系统的提升了商家在千牛端使用开放工具的体验。

关注我们，每周 3 篇移动技术实践 &干货给你思考！