4. 混沌工程成熟度模型：从Ad-hoc到平台化
混沌工程并非一蹴而就的实践，而是随着组织技术能力与基础设施成熟度逐步演进的。理解成熟度模型，有助于团队定位当前阶段、规划演进路径，并明确基线核验在整体能力建设中的锚点作用。
4.1 成熟度模型总览：四个关键阶段
基于CNCF混沌工程兴趣组及行业实践，我们将混沌工程成熟度划分为四个阶段：Ad-hoc（临时手动）、标准化（脚本驱动）、自动化（平台集成）、平台化（智能自治）。每个阶段在工具、流程、覆盖范围及风险控制上均有显著差异。
核心观点： 基线核验是衡量混沌工程从“手动实验”走向“平台化运营”的关键质量门禁。没有基线，混沌实验就是盲目的破坏；没有基线核验的自动化，平台化就无从谈起。
4.2 各阶段特征对比
| 维度 | Ad-hoc 阶段 | 标准化阶段 | 自动化阶段 | 平台化阶段 |
|---|---|---|---|---|
| 实验方式 | 手动SSH、随意注入故障 | 脚本化、可重复执行 | CI/CD流水线触发、定时执行 | 自适应、基于风险评分自动编排 |
| 覆盖范围 | 单节点、单服务 | 核心服务、有限场景 | 全链路、多故障组合 | 全业务域、跨集群、跨区域 |
| 基线核验 | 无基线，凭经验判断 | 手动定义静态阈值 | 动态基线、自动比对 | AI驱动基线、预测性核验 |
| 风险控制 | 无防护，极易引发生产事故 | 人工审批、最小爆炸半径 | 自动熔断、回滚机制 | 智能熔断、自适应限流 |
| 平台依赖 | 无平台，依赖个人工具 | 独立工具链（如Chaos Monkey） | 集成到内部开发者平台（IDP） | 平台原生能力，对用户透明 |
4.3 基线核验在成熟度模型中的位置
基线核验并非一个独立阶段，而是贯穿成熟度模型各阶段的核心能力。其角色随阶段演进发生质变：
- Ad-hoc 阶段： 基线核验缺失。实验后依赖人工观察日志和监控面板，无法量化系统是否“正常”。风险极高，常导致误判。
- 标准化阶段： 基线核验以静态阈值形式出现。例如“P99延迟 < 200ms”、“错误率 < 0.1%”。核验过程手动或半自动，维护成本高。
- 自动化阶段： 基线核验实现动态化。平台自动采集历史数据，生成动态基线窗口。实验结束后自动比对，输出通过/失败结论。这是平台工程介入的关键节点。
- 平台化阶段： 基线核验走向智能化。利用机器学习预测系统行为，在实验前即可评估风险，实验过程中实时调整基线，实现“自适应核验”。
平台工程视角： 在自动化阶段，平台团队需要将基线核验封装为平台能力（如：Chaos Service API中的 /validate 端点），使应用团队无需关心核验算法，只需声明SLO目标。这是混沌工程从“专家行为”转变为“自助服务”的关键。
4.4 成熟度演进与基线核验关系图
下图展示了混沌工程成熟度各阶段与基线核验能力的对应关系，以及平台工程在其中扮演的赋能角色。
4.5 平台工程视角下的演进路径建议
作为平台工程团队，推动混沌工程成熟度提升的核心策略是：将基线核验作为平台服务能力进行抽象和封装。具体建议如下：
- 评估现状： 使用上述成熟度模型对团队当前阶段进行自评，重点关注基线核验的自动化程度。
- 定义平台API： 在自动化阶段，设计统一的基线核验接口（如
POST /api/v1/chaos/validate），输入为实验ID和SLO定义，输出为核验结果。 - 封装动态基线引擎： 平台底层集成时序数据库和统计模型，自动计算动态基线，对上层应用透明。
- 提供自助服务目录： 在内部开发者平台（IDP）中，将“混沌实验 + 基线核验”打包为自助服务项，降低使用门槛。
避坑提示： 不要试图跳过标准化阶段直接进入自动化。没有静态阈值和手动核验的经验积累，动态基线的阈值范围和敏感度将难以确定，导致大量误报或漏报。基线核验的成熟度必须与组织整体运维能力同步演进。