规则分类与分层：业务规则、技术规则、安全规则，如何分层管理？

规则库建好了，接下来最头疼的问题来了——规则怎么放？

我见过不少团队，一开始把所有规则往一个文件夹里堆。结果呢？三个月后，没人找得到想要的规则。半年后，规则库变成了「规则坟场」。

说白了，规则分类不是搞学术，是为了让不同角色的人，能快速找到自己关心的规则。今天我就聊聊我自己的分层实践。

为什么必须分层？

先讲个真实案例。我之前带的一个项目，QA 同学想加一条「接口响应时间超过 3 秒告警」的规则。他找了一圈，发现规则库里既有「登录接口超时 5 秒告警」，又有「支付接口超时 2 秒告警」，还有「数据库连接超时 10 秒告警」。

这些规则混在一起，没人知道哪些是重复的，哪些是冲突的。最后他干脆自己又加了一条——规则库膨胀到 2000 多条，有效覆盖率不到 40%。

为什么会这样？因为没有分层。不同维度的规则搅在一起，就像把衣服、袜子、鞋子全塞进一个抽屉。

三层模型：业务、技术、安全

我个人习惯把规则分成三层。每层解决不同的问题，对应不同的责任人。

层级	关注点	典型规则示例	责任人
业务规则层	业务流程、数据完整性、业务合规	订单金额必须大于 0；用户实名认证后才能下单	业务方 / 产品经理
技术规则层	性能、可用性、代码质量、架构规范	接口 P99 延迟 < 500ms；核心链路不允许单点故障	开发 / QA
安全规则层	数据安全、访问控制、漏洞防护	密码必须加密存储；API 必须鉴权	安全工程师 / 运维

你想想看，这三层规则的生命周期也不一样。业务规则变化最快——产品改个逻辑，规则就得跟着改。技术规则相对稳定，但版本迭代时会调整阈值。安全规则最「死」，一旦定下来，基本不动。

业务规则层：贴近真实世界

业务规则，说白了就是「业务方说了算」的规则。它们描述的是「业务应该怎么做」，而不是「系统应该怎么跑」。

• 数据完整性规则：比如「订单必须有收货地址」「商品价格不能为负数」。
• 业务流程规则：比如「退款金额不能超过原订单金额」「优惠券不能叠加使用」。
• 业务合规规则：比如「跨境订单必须上传身份证信息」「金融产品必须做风险测评」。

技术规则层：关注系统质量

技术规则是 QA 和开发的主战场。这一层我习惯再拆成三个子类：

1. 性能规则：响应时间、吞吐量、资源利用率。比如「数据库连接池使用率超过 80% 告警」。
2. 可用性规则：错误率、健康检查、容灾策略。比如「核心接口错误率超过 1% 自动熔断」。
3. 代码质量规则：静态扫描、测试覆盖率、代码规范。比如「新增代码的单元测试覆盖率不低于 80%」。

嗯，这里要注意。技术规则的阈值不是拍脑袋定的。我见过有人把「接口超时时间」设成 100ms，结果线上天天告警——因为网络抖动一下就到了 120ms。阈值要基于历史数据 + 业务容忍度来定。

安全规则层：底线思维

安全规则是「红线」。碰了就出事，没得商量。

• 数据安全规则：敏感字段必须脱敏、日志不能打印密码、数据传输必须加密。
• 访问控制规则：接口鉴权、权限最小化、操作审计。
• 漏洞防护规则：SQL 注入检测、XSS 过滤、依赖库漏洞扫描。

安全规则有个特点——一旦触发，必须阻断。不像业务规则可以「告警后人工处理」，安全规则往往是「直接拒绝请求」。所以安全规则的优先级最高，执行引擎里要单独开一条快车道。

分层管理的落地方法

光说理论没用，我分享一个我在项目中实际用过的分层方案。

1. 物理隔离

三层规则放在不同的目录或数据库中。比如：

rules/
├── business/          # 业务规则
│   ├── order.yaml
│   ├── payment.yaml
│   └── user.yaml
├── technical/         # 技术规则
│   ├── performance.yaml
│   ├── availability.yaml
│   └── code_quality.yaml
└── security/          # 安全规则
    ├── data_security.yaml
    ├── access_control.yaml
    └── vulnerability.yaml

2. 标签化

每条规则打上标签，方便跨层检索。比如：

标签	含义	示例
layer:business	业务规则	订单金额校验
layer:technical	技术规则	接口超时告警
layer:security	安全规则	密码加密校验
severity:critical	严重级别	安全规则默认 critical
scope:payment	作用域	支付相关规则

3. 生命周期管理

不同层的规则，审核流程不同：

• 业务规则：产品经理提，QA 审核，周维度更新。
• 技术规则：开发提，架构师审核，版本发布时更新。
• 安全规则：安全工程师提，CTO 或安全负责人审核，月维度更新。

一张图看懂规则分层

下面这张图是我自己画的规则分层结构。你可以看到，三层规则从下往上，关注点从「系统」逐渐过渡到「业务」。

分层之后，怎么协同？

分层不是「各玩各的」。三层规则之间会有交叉。比如一个业务规则「用户实名认证后才能下单」，它背后可能依赖技术规则「认证接口可用性 > 99.9%」和安全规则「用户身份证信息必须加密存储」。

我的做法是：在规则元数据里加一个「依赖规则」字段。业务规则可以引用技术规则和安全规则。这样，当底层规则变更时，上层规则能自动感知。