2. 治理模型设计：成熟度模型、维度划分与策略制定
好，我们进入第二章。上一章聊了为什么要做治理，这一章咱们来点实在的——怎么设计治理模型。
说白了，治理模型就是一套框架。它告诉你：你现在在哪个阶段、该管哪些事、具体怎么管。我见过不少团队，一上来就搞全量治理，结果三个月后连日志都没人看了。为什么？因为没有模型指导，步子迈太大了。
2.1 治理成熟度模型：先搞清楚你在哪
我个人习惯把治理成熟度分成五个等级。你想想看，就像打游戏，你得先知道自己几级，才能决定去打哪个副本。
| 等级 | 名称 | 典型特征 | 我见过的真实案例 |
|---|---|---|---|
| L0 | 混沌期 | 无治理、无规范、全靠人肉运维 | 某创业公司，API 文档靠口头传 |
| L1 | 感知期 | 有监控告警，但无主动治理 | 出问题了才去看日志，事后补救 |
| L2 | 规范期 | 制定了规范，但执行靠自觉 | 有 API 设计规范，但没人检查 |
| L3 | 自动化期 | 工具自动检查、自动拦截 | CI/CD 流水线中集成治理检查 |
| L4 | 自适应期 | 系统能根据流量自动调整策略 | 动态限流、自动降级、智能路由 |
我的建议：大多数团队处于 L1 到 L2 之间。别急着跳级，先稳定在 L2，再往 L3 走。我曾经见过一个团队，直接从 L0 跳到 L3，结果工具上了，人不会用，最后工具成了摆设。
2.2 治理维度划分：管哪些事？
成熟度模型告诉你「做到什么程度」，接下来要回答「管哪些方面」。我把治理维度分成四个核心域，每个域下面还有子维度。
嗯，这里要注意：维度不是越多越好。我见过有人列了 20 个维度，结果每个都管不深。我个人习惯控制在 4-6 个核心维度，每个维度再拆 2-3 个子项。
2.2.1 四个核心治理域
- 安全治理：认证、授权、数据脱敏、防篡改
- 质量治理：响应时间、错误率、可用性、数据一致性
- 成本治理：调用量配额、资源消耗、计费审计
- 合规治理：版本管理、变更审批、审计日志、数据主权
你可能会问：这四个域够用吗？其实大部分场景都覆盖了。如果你们有特殊需求，比如金融行业需要额外的反洗钱检查，可以在合规治理下面加子维度。
避坑指南：我曾经在一个项目中，把「性能治理」和「质量治理」分成了两个独立域。结果发现大量重叠——响应时间既是性能指标，也是质量指标。后来我学乖了，把性能归到质量治理的子维度里，清晰多了。
2.3 治理策略制定：具体怎么干？
有了维度，接下来就是策略。策略说白了就是「规则 + 动作」。规则是判断条件，动作是触发后的处理方式。
2.3.1 策略的三要素
我习惯用这个公式来定义策略：
策略 = 触发条件 + 评估逻辑 + 执行动作举个例子：
触发条件：每秒调用量 > 1000
评估逻辑：检查调用方 APP ID 是否在白名单
执行动作：返回 429 限流响应，并记录审计日志2.3.2 策略的分类
根据执行时机，我把策略分成三类：
| 类型 | 执行时机 | 典型场景 |
|---|---|---|
| 静态策略 | API 发布时 | 参数校验、格式检查、版本号检查 |
| 动态策略 | 运行时 | 限流、熔断、动态路由、灰度发布 |
| 审计策略 | 事后 | 调用链分析、异常检测、成本核算 |
注意：静态策略和动态策略不要混在一起配置。我曾经见过一个团队，把限流阈值写死在代码里，结果每次调整都要重新发布。正确的做法是：静态策略走配置中心，动态策略走规则引擎。
2.4 治理模型的核心逻辑图
下面这张图，是我自己总结的治理模型核心逻辑。它把成熟度、维度、策略串在了一起。
2.5 策略制定的实操步骤
光有理论不行，咱们来点实操的。我总结了一个五步法：
- 定目标：先问自己，这个策略要解决什么问题？是防刷单？还是保稳定性？
- 选维度：根据目标，选择对应的治理维度。比如防刷单，走安全治理。
- 设阈值：阈值不是拍脑袋定的。我习惯先跑一周基线数据，看 P99 和平均值，再定阈值。
- 定动作：触发后怎么办？是告警、限流、还是直接拒绝？
- 加观测：策略上线后，必须能观测到效果。没有观测的策略，就是盲人摸象。
一个小技巧：阈值设置可以分阶段。比如第一周只告警不拦截，第二周拦截 10% 的流量，第三周全量拦截。这样即使阈值设错了，影响也可控。我每次上线新策略都这么干，从来没出过事故。
2.6 一个完整的策略示例
最后，给你看一个我在项目中实际用过的策略配置。它用 YAML 描述，清晰明了：
策略名称: 订单接口防刷单
治理维度: 安全治理
成熟度等级: L3（自动化期）
触发条件:
接口: /api/v1/order/create
调用频率: > 50次/秒
来源IP: 不在白名单
评估逻辑:
- 检查调用方 APP ID 是否有效
- 检查请求体中用户 ID 是否在黑名单
- 检查设备指纹是否异常
执行动作:
- 返回 429 Too Many Requests
- 记录审计日志到 Elasticsearch
- 发送告警到钉钉群
- 自动将 IP 加入临时黑名单（有效期 30 分钟）
观测指标:
- 策略触发次数
- 误杀率（正常请求被拦截的比例）
- 接口整体成功率变化嗯，这个配置看起来简单，但背后其实做了很多权衡。比如临时黑名单设 30 分钟，是我根据历史数据算出来的——太短防不住刷单，太长容易误伤正常用户。