没有"官方"的模型

业界几个常见的参照：

  • CNCF Platform Engineering Maturity Model：偏平台工程层面，分 4 阶
  • DORA Four Keys：用 4 个量化指标（Deployment Frequency / Lead Time for Changes / Change Failure Rate / Time to Restore Service）划档
  • 各云厂商也有自家白皮书（如 AWS Well-Architected、Cloud Adoption Framework）涉及类似话题

下面给的是一个整合常识版——不要把它当标准，当对照。

五阶图（自总）

阶 1 · 雪花服务器（Snowflake）

  • 每台机器都是手点出来的
  • 改配置 = ssh 上去 vi
  • 没人确切知道这台机器装了啥
  • "我们有一台关键机器但没人敢动它"

风险：bus-factor 1，数据重建几乎不可能。

阶 2 · 脚本化

  • 有 shell 脚本 / Makefile 包装常用操作
  • 大概知道生产环境长啥样
  • 改动靠"小心 + 经验"
  • 部署还是手动 SSH

风险：脚本失修、各环境之间漂移。

阶 3 · 配置管理

  • Ansible / Puppet / Chef 一类工具
  • 描述"机器应该长成什么样"
  • 重建一台机器有信心
  • 但云资源还是手点的

风险：基础设施层（VPC / RDS / 网络）不可重建。

阶 4 · IaC + CI/CD

  • Terraform / Pulumi 管基础设施
  • 代码改动走 PR → CI → 自动部署
  • 监控 / 告警基本到位
  • 大概率有 staging 环境

这是绝大多数中等团队的目标。继续往上是边际收益递减的话题。

阶 5 · GitOps + Self-Service

  • 一切声明式（K8s + ArgoCD/Flux）
  • 开发者通过内部平台自助
  • SLO / Error Budget 驱动发布节奏
  • 有 SRE 文化（不是只 SRE 团队）

这是大公司的目标——对小团队过度成熟反而是负担。

怎么判断自己处在哪

老实回答下面几个问题：

问题 回答
关键服务器今晚被人不小心 rm -rf / 了，多久能恢复？ 几小时 = 阶 4+；一天 = 阶 3；几天 = 阶 2；几周 = 阶 1
新员工第 1 天能部署一次代码到 staging 吗？ 能 = 阶 4+
上一次生产事故的根因报告，你 6 个月后还能找到吗？ 能 = 阶 4+
改一行代码到生产环境，平均要多久？ 30 分钟 = 阶 4+；半天 = 阶 3；几天 = 阶 2
多少改动是直接 ssh 改的而不是 git？ < 5% = 阶 4+

不要跳级

  • 阶 1 直接上 K8s = 灾难
  • 阶 2 直接上 Service Mesh = 解决了你没有的问题
  • 每升一阶，团队心智 / 工具链 / 流程都要适配

早期最高效的优化常常是 "退一阶把基础打稳"，而不是 "再上一阶"。

推荐阅读

下一篇：进入 IaC 主题，为什么不再手点控制台。