第三章：平台工程成熟度模型与审计等级归纳总结
说到成熟度模型，我脑子里第一反应其实是 CMMI，但平台工程这个东西吧，跟传统软件开发的成熟度还真不太一样。你想想看，平台工程的核心是「面向内部客户提供自服务能力」，这跟写一款内部产品其实更像。我刚开始做平台时，团队连个统一的 CI/CD 都没有，每个项目组各玩各的——那会儿连 Level 0 都算不上。
所以，到底怎么衡量我们的平台建得够不够好？审计时怎么评级？这就是这章要聊透的事。
平台工程成熟度模型是什么
成熟度模型，说白了就是把平台的演进过程切分成几个阶段。每个阶段都有明确的特征和度量指标。我个人习惯用五级模型，因为五级够细，又不至于让团队失去耐心。
下面这张图展示的就是我常用的五级成熟度模型。你把它当成一张地图，看看自己团队现在站在哪一级。
五个级别的详细特征
下面我把每个级别拆开讲，顺便说说我在项目中遇到的坑。
Level 0：初始级
这个阶段的特点是「啥都没有」。开发自己搭 Jenkins，运维自己写脚本，环境之间靠拷贝文件。
- 审批流程：纯人工，负责人拍脑袋
- 环境一致性：开发说「在我机器上能跑」
- 安全合规：基本没有，出了事才补
Level 1：标准化级
这个级别开始统一工具链。比如全公司都用 GitLab + Jenkins + Docker。但标准化不等于自动化，很多步骤还是靠人。
| 维度 | 达标标准 | 常见缺失 |
|---|---|---|
| CI/CD | 有统一的流水线模板 | 模板版本没人管 |
| 镜像管理 | 使用私有 Registry | 镜像标签不规范 |
| 配置管理 | 配置与代码分离 | 密钥还写在代码里 |
Level 2：可度量级
这个级别我们开始讲数据了。关键的指标都要能自动采集和展示。比如部署频率、失败率、恢复时间。嗯，这里要特别注意，指标不是越多越好，选 5 个核心指标就够了。
我自己的经验是，先盯住这 4 个：
- 部署频率：每天部署次数
- 变更失败率：回滚或修复的比例
- 恢复时间：从出问题到恢复的时间
- 黄金信号：延迟、流量、错误、饱和度
说白了，可度量级的核心是「不再靠感觉做决策」。你想想看，如果没有数据，你怎么证明平台在变好？
Level 3：优化级
这个级别开始做自动化闭环。比如基于失败率自动触发回滚，或者根据流量自动扩缩容。这要求你有稳定的可观测性基础。
关键差异：Level 2 是「知道哪里慢了」，Level 3 是「慢了能自动修」。
在审计层面，Level 3 要求平台有自治能力，而不是依赖值班人员熬夜。
Level 4：个性化级
这是最高级。平台能根据不同角色提供不同的「黄金路径」。比如前端团队看到的是封装好的 API，数据团队看到的是自助的 Notebook 环境。
但说实话，我在实际项目中很少看到团队真正需要 Level 4。很多时候大家把 Level 2 做好了，效率已经翻倍了。比起追求 Level 4，我更建议先把 Level 2 和 Level 3 做扎实。
审计等级如何与成熟度对应
审计不是只看你墙上的流程图，而是看你的实际表现。我把审计等级也整理成了一张表，跟成熟度模型挂钩。
| 审计等级 | 对应成熟度 | 审计重点关注 |
|---|---|---|
| 缺失级 | Level 0 | 安全漏洞、环境差异、无记录 |
| 流程级 | Level 1 | 流程是否定义并执行 |
| 验证级 | Level 2 | 指标数据可追溯 |
| 自动化级 | Level 3 | 自动化覆盖率和可靠性 |
| 智能级 | Level 4 | 自适应和自服务能力 |
审计时，检查员会随机抽一个项目的全流程，从代码提交一直看到生产运行。如果任何环节需要人工干预，那对应的审计等级就要降一级。这招很狠，但确实能逼出真问题。
怎么评估当前处于哪一级
评估方法其实不复杂。我一般用三步：
- 做一次全流程扫描：画出现有发布流程的每一步，标出是自动还是手动
- 收集关键指标：至少收集两周的部署数据
- 跟团队做一次复盘：找几个实际案例，看看出了问题怎么处理的
举个例子。我参与过一家金融科技公司的审计。他们自认为在 Level 2，但实际上一查，配置变更还是靠运维手动改文件。单单这一个点，审计等级就被打回了 Level 1。所以别急着给自己戴高帽子。
总结
平台工程的成熟度不是往上堆功能，而是让团队能持续、稳定、高效地交付价值。审计等级也不是为了打分，而是帮你找到最值得改进的地方。
记住一句话：做完 Level 1 能活下去，做完 Level 2 能睡好觉，Level 3 和 Level 4 是锦上添花。先把基本功打牢，其他的慢慢来。