一、背景

目前我们为了保障生产稳定性，主要运用了如下手段：线上异常日志监控（异常场景抛出 error 关键词，无法对不符合预定标准的数据进行过滤，误报较高）、数据核对（针对底层数据，缺乏接口维度的数据核对）、前端巡检（重点巡检前端页面的基本展示 &交互，但无法精确到数据层面）、流量回放（只在发布前回放只读接口，缺乏写接口的校验，且误报较高）、接口自动化（只能作用于当前自动化产生的流量，且无法在生产环境执行）等。

流量回放天然优势是可以采集到全环境（线上、预发、线下）流量，包括流量的各种子调用、入参和响应，所以借助流量采集能力，通过只需要简单编写一些校验业务规则，利用流量触发与测试结果验证分离思想，完成全环境全流量的业务逻辑巡检校验，完成巡检能力支持，拦截各流量的异常。

二、投入 &收益

投入

Q3 增长梳理了 51 条接口规则，其中 30 条完成配置。熟悉平台操作后，平均每条规则大概投入 5-10 分钟。

发现的问题

砍价成功，券金额为 0

• 业务逻辑：用户可以选择商品进行砍价，砍价成功则发放优惠券。砍价接口会从商品聚合中心获取商品的出价、到手价，再计算出优惠金额。正常情况下，发券成功，商品优惠金额一定大于 0。

• 规则校验：条件：砍的次数>0 并且砍价接口 code=200 断言：对单个 jsonPath 进行校验即可，判断优惠金额是否大于 0

• 异常原因：砍价的商品是从算法获取的，算法推荐了虚拟商品，而砍价券的优惠资产配置中适用渠道未勾选「线下服务」，导致虽然发券成功，但该商品不可用券，商品聚合中心返回的出价和到手价相等，从而计算出的 couponAmount=0。

• 解决措施：算法侧推荐商品时过滤虚拟商品

520 膨胀后金额等于膨胀前金额

• 业务逻辑：新客首页券包模块，当用户命中 520 券 &单一膨胀，且当前为待膨胀时，首页会显示最高可膨胀的金额，膨胀金额会实时从算法侧获取。正常情况下，最高可膨胀金额一定大于膨胀前金额。

• 规则校验：条件：存在膨胀券数据断言：利用对比 jsonPath 的方式，对比最高可膨胀金额是否大于膨胀前券金额。

• 异常原因：领券成功时，算法第一次返回的膨胀前金额为 10 元，膨胀后金额为 20 元，再次查券时，算法返回的膨胀前金额为 6 元，膨胀后金额为 10 元。业务侧未针对这类情况做兜底。

• 解决措施：若查券时，算法返回的膨胀后金额小于等于已领的膨胀前券金额，处理为不可膨胀，不对用户透出膨胀信息。

商详页 520 领券失败

• 业务逻辑：新客用户可以在商详领取 520 券包。520 领券一直以来都有一些通用的拦截，比如设备领取限制、非新人、被风控等，但在商详场景比较特殊，若查券时返回了 520 券，试算会在用户未领券时做虚拟试算，即商品到手价已经包含券金额，并且给用户透出领券入口，因此在商详需尽量保证用户看到券即可领。

• 规则校验：条件：领券来源为商详断言：对单个 jsonPath 进行校验即可，判断领券结果是否成功

• 异常原因：520 发券拦截只在领券接口处理了，未考虑到商详场景的特殊性，需在查券接口也同时补上。

• 解决措施：商详查券接口，命中领券设备限制时不返回券信息。

三、实践过程

前置工作

开启自动录制

新接入的应用，首先在「流量回放平台-引流管理」，针对全部接口开启自动录制。

接口规则场景梳理

为了更有方向性地配置规则，可以事先梳理好业务需要巡检的接口以及场景。

接口配置录制方式

在「流量规则平台-接口管理」，可根据自己的需要，录制接口的请求、响应、子调用接口的请求、响应。

写接口写接口默认会录制入口的请求和响应及子调用的请求和响应。

只读接口只读接口默认只录制入口的请求及子调用的关键信息。

• 录制入口的请求：

• 入口的响应：没有录制

• 录制的子调用：

如果需要对只读接口的响应进行录制，只需要将下拉框选择红色框中的内容即可，在这种情况下，会对入口的响应进行录制。

如果需要对只读接口的响应及子调用的请求和响应进行录制，只需要将下拉框选择红色框中的内容即可，在这种情况下，会对入口的响应进行录制及子调用请求和响应进行录制。

添加流量到场景样例

场景样例数据就是配置规则时的数据源，平台根据子调用集合生成的 md5，如果一个迭代中没有这个 md5，就会自动沉淀到场景样例中，如果没有，也可以手动在流量池中将数据添加到场景样例。

规则配置

一个规则可以分为两个部分：条件和断言，这两者组合在一起就是一个规则，简单理解一个规则代表一个业务场景。其中只有条件命中，才会对规则进行断言。

创建规则

在场景样例中，通过预览请求 &响应数据，找到符合要求的数据源，创建规则。

新增 jsonPath

选择请求、响应或子调用中的数据，提取 jsonPath，作为下一步配置条件或断言的数据源。

配置条件

当流量命中条件时，才会走到后面的断言。

有多个条件时，可以选择运算符 and 或 or，也可以配置条件组。

配置断言

• 普通模式下对单个字段进行断言

• 普通模式下对比字段进行断言。

• 编写脚本进行断言。

验证规则

规则配置成功后，验证规则是否有效，可以对源数据进行修改，从而验证符合或不符合预期的 case。

特征管理

如果想对某个接口配置不同场景的规则，可以提取特征字段，平台会通过录制到的流量提取出特征字段的枚举值，从而自动生成规则，这些特征字段就会作为规则的条件，只需在此基础上添加其他条件和断言即可。

异常告警

• 平台监控到有不符合预期的流量时会有机器人通知。

• 可以针对接口、环境等筛选命中规则失败的流量。

四、总结

流量规则巡检的优势

• 线上巡检：通过配置业务校验规则，在预发 &生产上持续采集流量并触发巡检规则，出现问题及时告警召回线上存在问题，弥补线上巡检能力空白。同时有效地筛选了不合格的数据，减少了误报。

• 研发自测：可针对新需求提前编写验证规则，规则自动作用于全环境，测试触发的流量经过规则验证，结合集成流水线卡点，规则断言问题解决 100%方可确认可上线，为研发提供自测验证的有效工具手段。

• 需求右移：过往经常会出现新需求线下测试验证没问题，但因线上配置不准确或遗漏，导致实际上线后业务受损。后续可以同时线下编写验收规则在上线过程中直接转变为线上流量巡检规则，在需求上线/放量阶段对线上业务监控监测，减少人工投入成本。

• 发布验证：通过已配置好的规则手段用于生产发布后的服务端逻辑验证，服务发布切流 1%后即可开始验证，既能延长规则验证时长，又能缩短测试手工回归验证时间，支撑后续快速按需发布。

• 线下拦截：线下可以借助自动化、流量回放、造数工厂、手工等多方来源发起的流量，将流量与验证分离，验证规则分布到每个流量中，大大降低手工验证成本和问题遗漏概率。

易发现问题总结

通过分析增长目前发现的问题，总结出以下可着重巡检的场景：

• 活动相关接口，重度依赖活动运营，需要运营提前一天进行活动或任务配置，防止运营漏配导致的页面空白；

• C 端一定会展示的数据，但数据依赖下游，防止下游数据变更或异常导致的 C 端数据显示异常，例如：必须展示的商品但未展示，可能是商品被下架，未从下游获取到有效数据；

• 用户操作成功后能明显感知到变化的数据，需做数据对比，例如：领券成功，商品到手价一定会变低、券膨胀成功，金额一定会变大；

• 算法链路，由于算法无测试环境，相关业务验证都只能在预发进行，又因为环境受限，只能覆盖预期内的场景，无法更好地预判预期外的 case，防止业务侧兜底方案不够完善，可以根据业务特性在算法链路场景上做一些监控，遇到预期外的 case，可进行优化。

*文/二鬼

本文属得物技术原创，更多精彩文章请看：得物技术

未经得物技术许可严禁转载，否则依法追究法律责任！