3. 规则的生命周期：从提出、评审、上线、监控到废弃的全流程
很多团队把规则库当成一个静态的文档集，写完就扔在那。说实话，这跟把种子撒地里就不管了没啥区别。规则库必须像软件产品一样，有完整的生命周期管理。我经历过好几个项目，规则库从几百条膨胀到几千条，最后没人敢碰——因为不知道哪些规则还活着，哪些已经死了。
这一章，我就把规则的生命周期拆开来讲。一共五个阶段：提出 → 评审 → 上线 → 监控 → 废弃。每个阶段都有坑，也有最佳实践。
3.1 提出阶段：别让规则从脑子里直接蹦到文档里
规则是怎么来的？最常见的场景是：线上出了故障，复盘时有人说「加条规则吧，以后不许这么干」。然后运维同学就写了一条规则，扔进库里。嗯，这其实是最糟糕的提出方式。
我个人习惯把规则提出分为三个来源：
- 事故驱动：线上故障复盘后提炼的规则。这类规则往往最紧急，但也最容易过度设计。
- 评审驱动：代码评审或架构评审中发现的共性问题。比如「好几个人都在同一个地方踩坑」，那就值得抽象成规则。
- 数据驱动：从监控数据中发现的趋势。比如「最近一周 CPU 使用率超过 80% 的实例增加了 30%」，这背后可能缺一条资源使用规范。
我曾经见过一个团队，一个月提了 200 条规则，结果上线后 80% 都没触发过。为什么？因为提出的人根本没想清楚这条规则在什么情况下会生效。说白了，就是拍脑袋。
3.2 评审阶段：两条命，一条给技术，一条给业务
规则评审是我最看重的环节。很多团队只做技术评审，看看语法对不对、逻辑通不通。但我觉得，规则评审需要两条命：技术评审和业务评审。
| 评审维度 | 评审内容 | 参与角色 | 常见问题 |
|---|---|---|---|
| 技术评审 | 规则逻辑是否正确、性能是否可接受、是否与其他规则冲突 | 开发工程师、QA、运维 | 规则嵌套过深导致执行超时 |
| 业务评审 | 规则是否覆盖真实场景、阈值是否合理、误报率预估 | 业务负责人、产品经理 | 阈值设得太严，一天告警几百次 |
| 安全评审 | 规则本身是否存在安全漏洞、是否可能被绕过 | 安全工程师 | 规则暴露了内部敏感信息 |
评审时我建议用「三票制」：技术、业务、安全各有一票否决权。任何一票反对，规则就不能上线。你想想看，如果一条规则技术上完美，但业务上天天误报，那还不如没有。
3.3 上线阶段：灰度是底线，没有例外
规则上线，我坚持一个原则：先灰度，后全量。不管这条规则看起来多简单、多安全，都必须走灰度流程。
为什么？因为规则的影响面往往比你想的大。一条看起来无害的规则，可能因为触发条件过于宽泛，导致大量请求被拦截或告警。我在项目中遇到过，一条「禁止使用 root 用户启动应用」的规则，灰度时只覆盖了 5% 的实例，结果那 5% 的实例全部告警——因为很多遗留系统确实在用 root 跑。
灰度策略一般分三步：
- 金丝雀发布：先覆盖 1%-5% 的实例，观察 24 小时。重点关注误报率和性能影响。
- 小范围全量：覆盖 20%-30% 的实例，观察 48 小时。这时候可以开始看业务影响。
- 全量上线：覆盖 100% 实例。但保留回滚能力，至少 72 小时内不删除灰度分支。
- 规则是否已通过技术+业务+安全评审？
- 灰度策略是否已配置？回滚方案是否就绪？
- 监控告警是否已对接？
- 规则文档是否已更新？
- 是否已通知相关方？
3.4 监控阶段：规则上线只是开始
规则上线后，很多人就觉得完事了。其实恰恰相反，监控阶段才是真正考验规则质量的时候。
我一般会监控三个核心指标：
- 触发率：规则被触发的频率。如果一条规则上线一周触发率为 0，那要么是场景没覆盖到，要么是规则根本没用。
- 误报率：规则触发但实际不是问题的比例。误报率超过 10% 的规则，需要立即回退评审。
- 执行耗时：规则每次执行消耗的时间。如果超过 100ms，就要考虑优化规则逻辑了。
举个例子，我之前维护过一个规则库，里面有条规则叫「检查数据库连接数是否超过阈值」。上线后触发率很高，但误报率也高得离谱。后来一查，发现是阈值设得太低，而且没有区分读写实例。说白了，这条规则在监控阶段暴露了评审时没发现的问题。
3.5 废弃阶段：学会给规则办葬礼
这是最容易被忽视的阶段。很多团队的规则库越积越多，最后变成一座「规则坟场」——没人知道哪些规则还活着，哪些已经失效了。
我个人认为，规则废弃应该有一个明确的流程：
- 标记为「待废弃」：当一条规则连续 30 天触发率为 0，或者业务场景已经不存在时，先标记为待废弃。
- 公示期：标记后公示 7 天，通知所有相关方。如果有人提出异议，可以重新评审。
- 正式废弃：公示期结束后，将规则从活跃库中移除，但保留到历史库中。
- 归档：废弃的规则不能直接删除，要归档到历史库，并注明废弃原因和废弃时间。
废弃阶段还有一个容易被忽略的点：规则依赖。有些规则之间是有依赖关系的，比如规则 A 触发了才会检查规则 B。如果废弃了规则 A，规则 B 就会变成孤岛。所以废弃前一定要做依赖分析。
3.6 全流程的闭环思维
五个阶段不是线性的，而是一个闭环。监控阶段发现的问题，可以驱动新规则的提出；废弃阶段的经验，可以指导下一轮评审的改进。
我习惯在每个季度做一次规则库的「健康度检查」，把五个阶段的数据拉出来看看：
- 这个季度提了多少条规则？评审通过率是多少？
- 上线的规则中，有多少条触发率正常？多少条误报率高？
- 废弃了多少条规则？废弃原因是什么？
这些数据能帮你判断规则库是在变好还是在变差。如果发现废弃率越来越高，那就要反思是不是提出阶段太随意了。如果发现误报率居高不下，那就要加强评审阶段的阈值验证。