背景

在数字化转型的过程，业务由粗放式运营演进为精细化运营，支付宝域内逐渐演进出P2C、P2B、B2C等各大运营体系。业务的发展也带来了运营平台数量的激增，截止当前，支撑各大运营体系的后台数量已达到50+，并且为了支撑运营活动快速迭代，各平台采用配置化架构，通过配置免开发的方式供业务小二直接使用。

配置化架构带来高效和便利的同时，也带来技术风险敞口扩大，原因有3点：

第一，传统代码实现需求有完善的研发与质量保障流程，配置化架构的每次操作，没有技术专职投入保障，无法通过code review，以及线下/线上的测试回归保证正确性；

第二，配置化平台大多是面向小二内部的产品， 区别于对外部客户的系统，本身产品设计上并没有很高要求，稳定性成熟度低，三板斧机制偏弱；

第三，配置平台的使用对象是内部运营小二，大多数用户不具备技术风险保障的意识和专业性，且很多新用户不清楚平台的各种概念及规则。

这些风险这几年也带来了很多问题，包括红黄色的事件，这些问题给公司造成了恶劣的影响，发生过重大资损、全站交易下跌、严重的负面社会舆情，给蚂蚁带来了恶劣的影响，对公司的收入、品牌声誉都造成了严重损失，由于配置错误导致的典型重大问题如下：

解决方案

风险演进

细化的风险分层可以更好的指导后续的解决方案设计和方向指导，在发生一次业务配置变更时，会存在如下三层风险：

• 基础通用风险：不具备业务语义，如 容量、规范、OS波动、软件一致性等基础设施维度的风险，风险与业务场景无关，对应的防御更容易具备通用性，适合通过中心化的通用防御能力来cover大部分场景；

• 业务通用风险：具备业务语义，反应业务正确性，风险与业务场景相关，适配于大部分业务域，但每次变更的准出标准是因业务的不同而差异化的，所以这一层风险适合以通用的平台能力供给业务，去中心化的方式让各个业务线来进行防御铺设来cover；

• 业务个性化风险：具备业务语义，属于垂直领域，只适配于某个业务域特色，如 物料域码值可用性、设计稿一致性等，这些风险与业务场景强关联，不适配于其它业务，需要业务域特色的能力，所以这一层的风险适合以开放集成的方式，引入个性化能力来解决。

问题定义

配置变更本质上也是属于变更，所以基于蚂蚁的变更战场，跟变更核心团队一起将变更进行了更细致的分层：

• IaaS变更：基础设施层的变更，比如startagent，阿里云底座变更；

• PaaS变更：基础平台层的变更，比如linke(蚂蚁的代码发布平台)、idb数据变更；

• SaaS变更：业务配置平台的变更，比如营销奖品变更、物料配置变更。

当前的蚂蚁变更战场，已经较好的覆盖了IaaS层和PaaS层的变更，这两层的变更语义明确，源自固定的平台，通过中心化化的标准方案解决；而SaaS层的变更，来自于各个不同的业务线，刚刚分析的风险分层中也有提到业务层的风险都是需要去中心化到各个业务线去控的，并没有被覆盖到。

明确了战场后，再看下方法，需要先明确一下技术及质量架构现状是什么，不同角色之间的生产关系应该是怎么样：

当前的配置防御架构为左图的自闭环模式，这种模式有三个不足：

第一、大家都在投入很大的精力在底下这一层工程基建上，而这些又都可以进行通用化，一定程度上来说是一种资源浪费；

第二、业务线都投入在要优先建设的工程基建上，导致没有精力聚焦在业务防御上，而对配置风险起到风控拦截作用的，其实是上面业务防御层；

第三、这些都没有把变更战场联动起来，走不到蚂蚁技术风险体系的大闭环。

全局视角来看，这里的矛盾是业务线在配置风险上有诉求，但是底下这一层的基建暂时又没有能做到通用开放的。所以我们的定位，演进成了 “联动变更战场，解决大家做配置防控的工程基建，让业务线可以少投入甚至不投入，精力释放出来更加高效便捷的投入业务防御层” ，把业务线的投入模式生产关系的转换，从而来达到配置风险防控的目的。

整体架构

有了明晰的风险分层和问题定义后，架构方案重点解决两个问题：

1、基于蚂蚁技术风险体系，站在变更战场上，在配置的领域，借力变更战场解决问题；

2、面向配置的三层风险，下沉通用防御能力，上浮业务域特色防御能力，解决业务线做基建的问题，让业务线专注case。

专题整体的架构设计如下：

跟变更核心团队对焦，基于现有的变更战场做了一层演进，现有的变更战场已经较好的收口了标准变更的风险，而且沉淀了较好的通用防御能力，这些能力刚好可以适用于配置的基础通用风险， 我们作为opscloud的业务防御执行器，重点解决业务语义转换，将业务防御结果和通用防御结果融合，解决业务配置变更的风险敞口。

明确好和变更核心的定位后，回到支付宝基于业务特性，抽象配置生命周期，沉淀全局技术架构如下：

1、复用opscloud的通用防御能力，解决通用基础风险，中心化来控这一层的风险；

2、下沉五大标准能力：事前的变更分析、规则检查、业务验收，事中的变更推进，事后问题发现，解决业务线做基建的问题，让业务线可以更加专注业务防御，低成本建设业务用例，去中心化解决业务通用风险；

3、通过提供多种开放集成方式，将业务线域特色的能力引到配置防御流程，解决业务个性化风险。

这样一套方案各层职责更加明确，将我们跟变更战场的关系、平台与业务线的关系，更加明晰，上下游紧密咬合，形成合力，共同服务好业务配置变更。

关键技术

数据引擎

所有配置变更的载体都是数据，五大标准能力均是以变更数据为起点，路由相应的能力唤起，因此，做好配置防御的基建，首要的就是供给配置数据的处理能力，并且可以原子化、组件化。

通过对各大运营平台的配置变更防御流程抽象，得到数据处理的环节如下：

• 数据补全：提供了多样的数据采集和处理底层能力 例如DB、GROOVY、http、tr、odps，通过定义不同类型组件，自定义选择编排组件，可将多种组件串联执行，实现了跨平台、跨系统的多平台级联调用。

• 数据切割：提供了数据解析功能，可适配于结构化、半结构化、非结构化数据，用户只需要选择某个节点下的数据，蓝鲸能够自动化切割出逐级的KV数据对，并智能判断数据类型。

• 前置过滤：基于数据切割，提供了一些列常用的逻辑运算，例如  是否包含、是否数组包含、正则、数组相等、数据类型等，以此来支撑同一变更模型映射到的不同业务场景，例如 在芝麻go的场景中根据“$.hermesTemplateResult.resultObj.signPage.name”是 DEVELOP_FREE/API/TAOBAO 来具体哪个模板的变更。

• 业务场景识别：基于前置过滤，用户可以定义特定规则来识别场景，在数据样本中赋予节点数据业务语义，例如 将$.comparePositionCrowdCheck[*].failedCnt 映射为 “失败节点数”，从而让用户以业务语义化的规则来理解场景

• 可视化规则：用户通过下来某个节点数据来定义规则，通过上述的语义化字段切割，平台支持常用的一些逻辑运算，做到0脚本编辑规则，后续维护成本也比较低；

沉淀数据引擎，将上述处理能力封装并产品化提供，业务方部署场景模型及检测规则全流程，都可以采用配置化的方式，提升业务方部署效能，创新式的沉淀0代码编写成本的规则部署能力，重点解决配置的业务语义识别和静态数据检测的问题。

功能验收

通过数据引擎的赋能，通过可视化规则的能力，可以从配置数据层面保障正确性，但是还无法cover一些类型的配置，比如

• url链接：alipays://platformapi/startapp?appId=201905235****124&page=/pages/index/index?source=${source}

• 小程序appid："appId":"60****4"

• 图片：

  image%2Fresize%2Cm_fill%2C***_48%2Fformat%2Cpng

• 收银台运营位：

  "NodeId":"20230322000008***0"

针对上述类型配置，无法从数据维度校验配置正确性，需要将配置模拟在端上（web & app）渲染后，提供真实的产品功能供业务验证。为此，我们跟终端环境、端质量、awatch团队合作，集成了丰富的产品验收能力，适配大部分配置数据类型的端显。

在传统端自动化的基础上，结合配置场景的特色，重点解决以下几大类问题：

• 场景管理：重点验收任务管理，通过录制回放和智能遍历提升case效率，通过用例编排支持自定义解决方案，通过执行引擎封装了调度/触发/重试等操作，让业务更加专注于case本身；

• 原子能力：封装常用验收操作步骤成api，如 图像能力解决端显内容的识别与断言、mock产品化能力解决配置数据依赖通路问题等，提升复用度；

• 业务场景通路：是验收产品的核心能力，不同业务场景链路对配置数据的渲染存在种种限制，沉淀多类型的mock和skip能力，从而实现对业务的提前验收：

• 访问（时间、空间、员工体系）限制：例如活动红包发放时间为一个月后、任务限制只有北京市可完成、限定企业员工可访问等，通过流量染色和参数篡改，模拟生效条件从而完成端显，解决配置内容渲染对时间、空间、人员等依赖；

• 概率限制：例如五福刮刮卡中某个指定奖品验收、双11玩法中某个指定任务的验收等，此类配置特性为仅有一定概率出现（有的甚至低至1/500），通过服务端mock产品化将业务配置模型直接组装转换为前端渲染模型，呈现用户，解决概率限制；

• 任务限制：例如支付后推荐、延边农商行支付运营、扫码乘车激励，此类配置特性为依赖前置任务完成的触发才可渲染，对于简单线上场景可以通过操作完成触发，对于复杂/小众线上场景和线下场景完成成本较大，通过集成不同业务的场景化mock能力解决。

沉淀通用处理原子能力，如 注入、mock、智能遍历等，解决业务通用的验收基建问题，对不同业务线个性化的问题，通过开放集成引入业务域特色解决方案。

以真机/模拟器渲染为底座，为用户封装供给原子化操作能力，如 mock、多版本/设备管理、ocr、黑白屏检测等原子能力，并为了适配业务玩法对服务端的依赖，通过注入能力的产品化，解决了部分业务配置对时间、空间、概率、人群等条件的限制，更加便于业务专注在验收的产品功能逻辑层。

业务预演

通过静态的规则检测可以从配置数据层面保障正确性，通过功能验收可以从端产品功能层面保障正确性，但是这两个维度还不足以覆盖 人群、活动、玩法、中奖概率、区域分布 等具备大流量属性的配置，在传统的单样本、单流量验证ok的前提下，面对线上真实的大流量，如何提前看到配置真实生效时的数据分布，建设业务预演的能力解决。

几个真实的例子：

在前述环节的规则检测和产品功能验收的能力基础上，仍然无法cover例如活动、应用、规则、人群类配置的正确性问题，为此，我们联动蚂蚁技术风险团队的流量海关、仿真团队，共建了业务预演的能力：

1、预演样本采集：提前准备能够命中所有活动配置可能性的历史用户流量，活动变更时，根据活动配置项，抽取符合活动配置的用户数据作为正样本（期望命中），以及不符合活动配置的用户数据作为负样本（期望不命中）发起流量，观测样本命中范围，以及预期与结果的比较。流量样本中最重要的是去沉淀业务特征标签，如 成都市、双流区、使用农行信用卡、男性，特征的覆盖度也决定了预演预测的效果准确性，在实际落地过程中，遇到了如信用卡卡号脱敏、人群准备、流量保鲜等难点问题，通过资产替换及代理转发的方式攻坚解决，可参考这里。

2、预演执行引擎：通过业务入口触发预演，创建对应的预演实体化模型并指定预演流量，创建预演任务，通过触发预演任务执行，捞取对应的流量样本进行分发触发不同业务接口进行预演，预演任务需支持流程编排，以满足不同业务预演需求（部分任务需要依赖其他前置任务预演结果），重点解决单笔流量的供给数量，提升样本回放的时效性。

3、业务回放链路：在近几年蚂蚁仿真环境大修的背景下，业务仿真升级仿真环境方案，减小业务链路的改造成本。在重点解决仿真底盘稳定性（可用率、容量）基础上，在实际落地过程中，遇到了如TPP非标应用仿真通路、策略模型线上加载、业务缓存刷新等问题，通过配置化mock等方式解决，可参考这里。

4、预演指标分析：通过对业务预演日志采集、通用人群分层数据分析，产出对应的活动预演结果报表数据，提供给运营进行业务确认。通过配置化指标能力，供给不同业务的接入，自定义规则开放能力，一次预演结果如下图：

业务预演重点解决配置上线前，通过模拟用户触发参与，下钻分析用户参与后的业务结果数据，通过效果预览，帮助业务在不消耗预算及用户无感知的情况下，发现此类配置的风险，从“上线前活动效果预估、活动设计错误拦截、配置内容错误拦截”三个维度，规避活动风险引发的线上故障、大额资损风险、活动效果不及预期的情况。

风险机器人

配置的操作人是内部的产品运营、外部的商户服务商等角色，操作的平台为不同的运营平台，需要将配置技术风险产品化的表达给配置人员，以便进行相应的决策操作。

除了域内的各渠道通知触达外，我们设计通过机器人的形式透出到运营配置平台，提供多种样式满足业务个性化诉求：

机器人重点承担了人机交互以及与配置运营平台交互这两大职责，主要解决如下问题：

• 人机交互

• 技术风险的产品化表达：在详情中，将质量风险通过业务语义字典映射，转换为业务表达，免去跨平台的操作和理解成本；

• 风险处置的交互操作：在系统产出的技术风险之上，需要人工的进一步操作，如修改配置、确认噪声、double check等；

• 与运营平台交互

• 结果透传：支持风险结果透传到运营平台前端，以便业务自定义后续处理；

• 宿主侵入：针对高风险配置，根据业务配置，支持配置错误时优先阻断运营平台的配置页面操作。

机器人的技术方案如上，核心技术能力包括：

• 风险处置：

• 阻断：业务配置需要阻断的页面操作button元素和拦截条件，机器人唤醒时进行拉取，当配置结果触发拦截条件，机器人执行相应配置脚本，定位配置操作元素(按钮)，对需要拦截或放开拦截的元素(按钮)进行新增或移除disabled属性；

• 加签：机器人拉取配置加签人、加签流程等信息，唤起antprocess创建审批工单，附上风险详情，通过蚂蚁工单的spi回调，感知加签结果，并透出到机器人上；

• 重试：支持工单整体重试和单条规则重试，并实时更新展示业务平台上的内容；

• 反馈：支持工单和规则维度反馈，触达质量owner外，支持运营直接添加规则黑名单，在后续的规则运行中做过滤，如 某次春促中，运营同学在活动过程中发现，某些行业奖品的规则比较定制化，无需校验奖品来源，或者运营定制化修改了一些奖品展示名称等信息，修改是符合预期的也是无需校验奖品名称的，运营可在配置平台直接反馈后，系统加入该规则的过滤条件，后续跳过检测。

• 前端适配：支撑业务平台使用云凤蝶、bigfish等蚂蚁主流前端框架，重点解决跨域鉴权、ssrf攻击等问题；设置多租户模式，支持路由不同的服务端，从而实现支持可适配不同的技术风险产品，除配置外，当前机器人已适配蚂蚁其它技术风险产品3个。

• 个性化组件：支持悬浮组件、嵌入式等组件样式，并支持展示样式(按钮、图标、展示条目等)配置化自定义，适配不同业务诉求。    

机器人不仅解决了域内外配置人员的触达问题，并通过业务语义字典的映射，将配置变更的技术风险产品化表达给非技术人员，更加便于理解风险，采取相应处置，减少了跨平台操作的通路和成本问题，当前已嵌入域内外十余个配置平台面向运营，并且沉淀开源组件，适配输出蚂蚁PaaS层的技术风险产品对客表达。

智能推导

当沉淀了一段时间的风险场景和防御用例后，系统也积累了相当量的配置运行数据，但是这些规则都是基于人工的专家经验，基于业务owner的业务熟练度，存在如下的问题

• 分母的完整性：基于人工圈选的分母，存在知识盲区导致的遗漏，当前可以依靠分批推进的标准能力减小问题发生时的影响面，但是需要进一步前置，辅助补充业务分母。

• 增量的分母感知：当业务owner配置完业务防御后，后续只会关注运行结果，如果业务发生变化，同一业务场景新增了规则限制，平台无法感知，owner也可能未来及时补充，导致分母的遗漏。

• 平台与其上的业务区分：有部分业务是平台类型的，并不直接面向外部客户，而是横向支撑其它不同业务，平台owner对其上业务的配置规则不清楚，例如产品合约平台上，配置了 花呗产品、贷款产品、声波付产品、小程序、芝麻等，归属于不同BU的不同业务线，产品的质量同学很难细化业务规则，导致精细化分母的遗漏。

调研了业界相关能力后，采取了设计了基于正则和统计特征的校验方案：

主要的算法模块有四部分：

• 数据定位: 通过递归解析，设计一套描述结构化数据的全路径模型，将复杂数据拆解为基本元数据。

• 检测模板: 先进行枚举的判断，再针对每一种不同的元数据，通过聚类大量的历史变更数据特征，总结得到“规律”的正则特征维度，以及置信度，并且将后续实时检测的数据，不断回流更新检测模板的训练模型。

• 实时检测特征: 根据对应的模板，制定规则生成策略，基于不同的数据模版，提取正则规范表达式特征和统计范围特征，生成对应防御规则。

• 实时校验: 实时配置数据进行参数分类，拆解成原子数据，通过防御规则的实时校验，对校验失败的数据生成拦截原因。

本方案在配置防御拦截上核心的优势点如下：

• 自动生产: 根据历史配置数据自动产出防御规则，零人工介入，并覆盖主流的配置数据格式。

• 拦截反馈: 不止输出拦截决策, 输出拦截原因, 帮助推送人定位问题，并且结合机器人的业务场景反馈功能，辅助业务方feedback优化挖掘的规则和模型。

落地实践

业务效果

【业务覆盖】

梳理支付宝全量运营后台，增量接入，存量兼容，支付宝一级域覆盖度100%，高风险应用覆盖度80%，如营销、物料、支付诸葛、数字分行、光华等高风险涉资平台，另外覆盖投放等业务，业务风险场景150+，沉淀业务规则总数500+。

【效率提升】

业务接入：与变更核心团队协同，在原有适配PaaS变更场景的标准化接入的基础上，共同演进适配业务配置的G1同步/异步接入方案，系统接入改造成本由3天提升至0.5天，通过配置化的方式部署业务场景及风险模型，新场景接入耗时小于0.5h。

用例部署：结合各业务场景的配置模型，沉淀通用数据处理能力，将原本需要通过groovy脚本编写，甚至是系统发布才能实现的规则校验，优化为全流程0代码编写的配置操作，单规则新增配置成本5min，极大提高业务方的效能成本。

开放集成：通过组件化、泛化调用、编排等形式，开放业务自定义配置防御流程，在不同节点引入集成业务域特色能力>10个，更好的支撑业务垂直解决方案；沉淀悬浮组件、嵌入式module等不同形态机器人，通过配置化的方式开放业务自定义，输出到各域总计十余个运营平台，完成质量风险对客表达的同时，实现小二在运营平台的一站式操作，提升效能成本。

【业务效果】

支撑支付宝日常的运营变更月均70W+次，节省保障成本486人日，支撑秋促、双11、双12等大促活动，有效拦截配置问题50+，包括人群口径放大/缩小、活动互斥、限核打标等问题，无运营配置导致的重大问题。

典型case

1、投放条件规则放大

背景

• 保险运营在营销平台配置碎屏险体验版活动，实际运营人群：会员冲刺准入人群 & 白名单 & 黑名单

• 整体资金量：预算X万元，活动周期6.25~7.31

问题

• 运营配置了3个条件组（如图中上半部分），误以为条件组之间是“且”的关系

• 实际平台条件组间是“或”的关系

• 真实生效，条件组3“人群id不属于有限的黑名单”生效，会导致该规则面向几乎全量支付宝用户

预计影响

• 计划投给200多万用户的活动，投给几乎全量支付宝用户

解决

• 条件组“不等于”放大风险规则：

• 高危配置加签审批；

2、人群配置错误

背景

• 双12大促活动，运营配置营销活动任务，任务只针对满足一定条件的人群可见，完成任务后进行发奖；

• 运营配置线上活动，人群具有有效期（在人群dmp平台），若失效则条件（在营销海豚平台）整体失效；

• 行业的运营通过预估配置了X天内访问阿里健康但未访问二级的医疗健康，希望增加转化漏斗率，估算了180天；

• 活动周期12.1 00:00:00 ~ 12.31 23:59:59。

问题

• 人群放大：人群有效期到12.31 00:00:00，晚于活动任务的有效期12.31 23:59:59，导致中间差值的一天内，人群失效从而条件限制失效，导致人群放大，全量人群可领取奖品；

• 人群缩小：行业配置的人群组合，180天访问阿里健康(dmp1) & 180天未访问未访问医疗健康(dmp2)，实际无人命中，导致人群缩小，配置未起到运营效果。

预计影响

• 计划投放给指定人群的奖品，活动最后一天，全量人群可获取

• 行业运营无实际效果，无人可入，预计核销为0

解决

• 配置上线前，通过预演回放样本流量，模拟配置真实生效后的业务效果发现

• 放大：混合正(满足人群规则，可准入)、负(不可入)样本，二阶段领奖转化率在最后一天为100%；

• 缩小：转化率为0，所有样本不可入，运营调整人群条件后，转化率符合预期。

3、活动快速验收

背景

• 营销的奖品一般具有时间、空间、人群限制，如 配置区域化的红包码，限定只能在特定时间段、指定城市、指定人群才可访问

• 配合上大促的玩法，在线下场景，需要完成如 单车、公交等任务，运营验收的成本非常大

问题

• 运营配置规则后，较难验证，因为存在时间、空间、人群、线下任务的限制

解决

• 基于awatch底座，在业务链路的入口注入如下两端逻辑，识别验收流量，并做参数替换；

• 流量染色：基于某些业务属性（如 触发系统、请求人员）识别验收流量，并在上下文中打入流量标；

• 参数篡改：判断如果是验收流量，则将入参中的限制参数替换为满足限制的参数；

• 开放集成：行业任务模拟，并工具化，通过组件化配置的方式集成进防御流程。

展望

在蚂蚁的技术风险体系下，补齐SaaS变更防御的标准方案，今年在“风险”的视角，已经较好的服务好支付宝的运营配置变更，保障各大运营体系快速奔跑的同时，风险敞口得以收敛，后续还需要在“效率”和“效果”层面持续推进：

• 效率：

• 接入侧：产品化持续提升，利用积累的数据，建设业务配置特征库，自动挖掘辅助分母补充；

• 运行侧：通过 风险模型、历史值diff、小二画像等资产数据，进行变更影响面分析及风险分级，制定差异化的保障策略。

• 效果：

持续领域能力纵深打磨，在配置正确和产品功能正确夯实能力深度的基础上，拓展配置生效后的业务效果保障，通过算法效果及端到端效果预估、产品评测等能力建设，给出运营配置的业务效果预估及ROI边际收益预估，覆盖如增长策略、区域活动、数字营销等场景，从业务效果层面助力运营配置对业务的增长。

如对本文有任何建议或问题，请关注我们的微信公众号，我们将私信回复 ❤️