📚 课程目录第2章合规规则基础

2. 合规规则基础

在讨论灰度发布与回退之前，必须先建立对“合规规则”本身的清晰认知。合规规则是合规系统的最小可执行单元，它把法律法规、监管要求、内部制度翻译成机器可判断的逻辑表达式。理解规则的定义边界、分类方式、生命周期以及承载它的引擎与平台，是后续设计灰度策略和回退机制的前提。

一、合规规则的定义与构成要素

合规规则（Compliance Rule）是对某一业务行为是否满足合规约束的形式化描述。它通常由四个要素构成：适用范围（对谁生效，如某地区、某产品线、某客户等级）、触发条件（在什么场景下评估，如交易提交、内容发布）、判断逻辑（阈值、集合、正则、决策表等）、处置动作（放行、拦截、告警、转人工）。

例如一条反洗钱规则可以表达为：当单笔转账金额大于5万元且收款方位于高风险地区时，触发人工复核。这条规则中，适用范围是“境内个人账户”，触发条件是“转账提交”，判断逻辑是金额与地区的组合条件，处置动作是“转人工”。

规则不是代码，而是可被引擎解释的声明式资产。规则与代码分离，才能支持业务人员配置、灰度验证和快速回退。

二、合规规则的常见分类

不同维度下规则分类方式不同，实践中常按以下方式划分，便于在规则管理平台中打标签和检索。

分类维度	类型	典型示例	灰度特点
按业务域	反洗钱、内容安全、数据隐私、交易风控	大额交易上报、敏感词拦截	域内规则常需联动发布
按判断方式	阈值型、集合型、正则型、决策表型、模型型	金额>5万、命中黑名单	模型型规则回退成本最高
按生效范围	全局规则、区域规则、租户规则	GDPR仅欧盟生效	区域规则适合按地域灰度
按处置强度	阻断型、告警型、记录型	拦截支付、发送预警	阻断型必须优先回退
按变更频率	稳定型、高频调整型	监管报送、营销话术	高频规则需更细灰度粒度

分类的价值在于：它决定了灰度发布的维度选择。例如区域规则适合按地域灰度，租户规则适合按客户灰度，而阻断型规则必须配置更严格的回退阈值和更快的回退通道。

三、合规规则的生命周期

一条规则从产生到退役，通常经历六个阶段，每个阶段都有对应的管理动作和风险点。

需求识别：由监管变化、业务变更或风险事件触发，形成规则需求。
规则设计：将需求翻译为条件与动作，确定优先级和冲突处理策略。
开发与测试：在规则引擎中编写、单元测试、回归测试，验证误杀与漏杀。
发布上线：通过灰度发布逐步放量，观察指标，这正是本课程的核心环节。
运行监控：持续采集命中率、误判率、性能耗时，发现规则漂移。
退役归档：规则失效后下线并归档，保留审计痕迹。

生命周期中，发布上线与运行监控是灰度回退机制直接作用的阶段。规则在灰度期间处于“部分生效”状态，需要引擎支持按流量比例或标签路由到不同规则版本。

四、常见合规规则引擎与规则管理平台

规则引擎负责解释和执行规则，规则管理平台负责规则的存储、版本、审批和发布。两者配合，才能支撑灰度发布与回退。

主流规则引擎可分为三类。第一类是表达式引擎，如 Drools、Easy Rules，适合阈值和条件组合，性能高但复杂决策表达能力有限。第二类是决策表与决策模型引擎，如 DMN 标准实现，适合业务人员维护的表格化规则。第三类是规则编排与流式引擎，如 Flink CEP、规则链平台，适合实时风控和事件序列判断。

规则管理平台通常提供以下能力：规则版本管理、灰度发布配置、回退按钮、审批流、审计日志、指标看板。一个典型的规则发布配置如下：

rule:
  id: AML-2024-017
  name: 大额转账人工复核
  version: v3
  gray:
    enabled: true
    strategy: percentage
    percentage: 10
    targetTags: ["region:CN", "channel:APP"]
  rollback:
    auto: true
    metric: falsePositiveRate
    threshold: 0.05
    window: 5m
    fallbackVersion: v2

这段配置表达了：规则 v3 以 10% 流量灰度，仅对境内 APP 渠道生效；当 5 分钟窗口内误判率超过 5% 时，自动回退到 v2。这正是灰度发布与回退机制在规则层面的落地形态。

选择规则引擎时，优先确认它是否支持规则版本并行加载和按标签路由。如果引擎只支持全量替换，灰度发布将无法实现，回退也只能靠重启。

五、常见误区与复盘要点

在规则基础阶段，团队常陷入以下误区。

把规则当代码管理：规则写在代码里，每次变更都要发版，灰度粒度只能到服务级别，无法按规则维度控制。
忽视规则优先级与冲突：多条规则同时命中时，若没有明确的优先级和冲突消解策略，灰度期间会出现不可预期的拦截结果。
回退只回滚规则内容，不回滚配置：灰度比例、标签路由等配置若未纳入版本管理，回退后仍可能残留异常配置。
缺少基线版本：没有上一稳定版本作为回退目标，回退时只能紧急下线规则，造成合规空窗。

规则回退不等于规则删除。回退应保留灰度期间的命中数据和审计日志，否则无法复盘误判原因，也无法向监管说明处置过程。

复盘时建议围绕三个问题展开：灰度期间规则命中分布是否符合预期？回退触发是自动还是手动，响应时间多长？回退后业务指标是否恢复到基线？把这三个问题的答案沉淀为规则发布检查清单，后续每次灰度都可复用。