12.4
12.4 成熟度自评
本书的每一章都以一份”成熟度模型”作为结尾，用以描述某项实践通常会如何演进。本附录把每一章的成熟度模型汇总成一份统一的参考资料，让你能够一目了然地评估一个团队、一个领域，或者整个组织。
共同的五级量表
所有章节描述的都是同一种演进过程。各章之间的具体措辞略有不同，但其内在含义都能清晰地映射到以下这五个级别：
- 第 1 级，启动级。 临时性、被动应对式、由个人性格驱动。实践只存在于个别人选择去做的地方，因此结果取决于英雄式的个人努力和运气。
- 第 2 级，发展级。 基本的实践已经存在，但在各团队之间并不一致，部分依赖人工操作，并且在压力之下常常被绕过。
- 第 3 级，标准化级。 实践在整个组织范围内被记录下来，实现标准化，并被强制执行。这是审计和合规的底线：大多数企业和政府工作都必须达到这个级别，才能做到可靠且可审计。
- 第 4 级，管理级。 实践通过数据和指标与基线进行对照，得到度量和控制。你能够以量化的方式了解每一项实践的表现，并依据这些数字采取行动。
- 第 5 级，协同级。 实践在整个组织范围内持续改进、相互整合，并具备适应能力。安全或正确的路径成为默认选择，组织有意识地学习和演进。
如何用它进行自评
- 对于与你的场景相关的每一章，阅读下面的五个级别描述，选出能够诚实反映你通常行为的那个级别（）不是你最好的团队在状态最好的那天的表现，也不是你书面政策所写的内容，而是实际发生的情况。
- 为每一章打 1 到 5 分。如果拿不准，就向下取整；一项不一致的实践应算作第 2 级，而不是第 3 级。
- 在每个部分内部对分数求平均值，以了解整个领域所处的位置，然后再看分数的分布情况：一个”平均分为 3”的部分，如果其中隐藏着一个处于第 1 级的章节，依然带有第 1 级的风险。
- 定期重新评估，并追踪变化趋势。变化的方向，比任何单次的快照都更重要。
成熟度是手段，而不是目的
更高的成熟度并不天然就更好。目标是适配：具备足够的严谨程度来应对你实际面临的风险和规模，仅此而已，不多不少。一个规模很小、风险很低的工具，并不需要第 5 级的混沌工程。把追求高级别当作一种奖杯，而不是用来解决真实问题，只会产生毫无价值的仪式感。请把下文中的每一个”第 5 级”都理解为”只有在风险足以证明其合理性时才适用”，并让风险、规模和监管暴露程度，来决定你应该向上攀登到多远。
第一部分：人员
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 工程文化与价值观 | 文化是偶然形成的，由个人性格驱动；事件发生时意味着追责；知识只存在于少数几个人的脑海中。 | 一些团队会进行事后总结并撰写文档，但实践并不一致，也没有得到领导层的强化。 | 无责学习、主人翁模式和书面文化，是整个组织范围内的规范，具有明确的期望和相应的工具支持。 | 文化健康状况会被度量（心理安全感调查、事件学习率、留任率），与基线进行对照追踪，并据此采取行动。 | 文化持续改进，实践在各团队之间传播；领导层随着组织的成长和学习不断调整规范。 |
| 团队拓扑 | 团队的组建是偶然的，或者仅仅依据人头数；结构反映的是遗留的层级关系；依赖关系无处不在。 | 一些流对齐团队已经存在，但共享的瓶颈和职能孤岛依然存在。 | 四种团队类型和明确的互动模式被有意识地加以运用；平台和 InnerSource（内源）模式减少了依赖关系。 | 认知负荷、流动情况和依赖数量，会针对每个团队与目标进行对照度量；当数字出现下滑时，团队边界会被相应调整。 | 随着产品和平台的演进，组织持续重塑团队和互动模式，以维持流动性。 |
| 角色、职业阶梯与成长 | 没有书面的职级体系；晋升和薪酬都是临时性的，由个人性格驱动。 | 一套基本的职级体系已经存在，但执行并不一致；没有校准机制；招聘缺乏结构化流程。 | 双通道职业发展路径、清晰的能力矩阵、校准机制和结构化招聘，都已成为标准做法。 | 晋升速度、薪酬公平性和在职级停留时间，会与基线进行对照度量；校准结果会被分析以排查偏见。 | 这套框架随着工作内容持续演进；随着岗位的变化，赞助式指导和学徒制在整个组织范围内被有意识地推行。 |
| 工作方式 | 流程是临时性的，或者只是照搬形式而不明就里；沟通以会议为主，且不留文档；估算被当作承诺来对待。 | 一种方法论被始终如一地遵循，但各种仪式流于形式，跨团队协调负担沉重。 | 实践的选择依据具体场景而定；异步的、以文档为先的沟通方式是常态；估算用于提供参考，而不是用于控制。 | 流指标（前置时间、在制品数量、吞吐量）会与基线进行对照追踪，并在每个周期加以审查。 | 团队根据这些指标持续调整自己的工作方式；协调需求从源头上被降到最低，好的实践在整个组织范围内传播开来。 |
| 决策与治理 | 决策是临时性的，且未被记录；治理要么缺失，要么成为一刀切式的瓶颈；债务不可见。 | 一些决策被记录了下来，也存在一定的评审机制，但流程并不一致，也与决策的重要程度不相匹配。 | 架构决策记录、铺好的路（paved road）、基于可逆性的授权，以及债务清单，都已成为标准做法，且保持透明。 | 决策周期时长、逆转率和债务水平会被度量；审查的严格程度会依据这些数字，按决策的重要程度进行校准。 | 治理在整个组织范围内持续调整；审查的重点聚焦于不可逆的决策；债务和外部采购则作为不断演进的组合加以管理。 |
第二部分：软件编程
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 编码标准与风格 | 代码风格因作者而异；没有共享的配置；格式问题在评审中反复争论。 | 每个团队都有自己的格式化工具和代码检查工具，但配置和规则在各团队之间各不相同。 | 按编程语言设立集中共享的配置；由 CI 强制执行；新仓库通过模板自动继承相关标准。 | 标准的采纳程度、违规率，以及对评审耗时的影响，会与基线进行对照度量；配置本身也受到版本管理和治理。 | 标准根据这些数据持续精炼，并在整个组织范围内共享；执行过程几乎没有摩擦，并能适应新的编程语言。 |
| 软件设计原则 | 设计是临时性的；耦合不断累积；设计原则要么无人知晓，要么只是被当作口号来引用。 | 团队了解这些原则并加以运用，但运用得并不一致，还常常教条化。 | 共享的设计词汇、有意识的耦合/内聚分析，以及与团队相对齐的限界上下文。 | 耦合度、内聚度和变更失败率等指标，为设计评审提供依据，并与基线进行对照；决策会被记录下来。 | 随着证据的积累，设计决策会被重新审视；原则的运用更加细致入微，范式的选择也会随着领域的演进，在整个组织范围内加以调整。 |
| API 与接口设计 | API 是从实现中自然产生的；没有共享的约定；破坏性变更司空见惯，且事先不通知。 | 团队遵循基本的 REST 约定，并以非正式的方式进行版本管理，但一致性和文档质量参差不齐。 | 契约先行的设计方式、机器可读的规范、明确的弃用策略，以及一致的错误处理和分页约定。 | 每个 API 的采纳程度、延迟、错误率和破坏性变更的频率，都会与目标进行对照度量。 | API 作为受治理的产品被收录在目录中，并具备出色的开发者体验；这项实践持续调整适应，破坏性变更在整个组织范围内都很少见，且能得到妥善管理。 |
| 测试策略 | 测试是人工进行的、临时性的；自动化覆盖率极低；回归问题频繁发生。 | 存在自动化单元测试和一些集成测试，但测试套件运行缓慢或不稳定，人们对它缺乏信任。 | 一套均衡、快速、可靠的测试套件为每一次变更把关；不稳定的测试问题得到管理；非功能性测试也被纳入其中。 | 覆盖率、测试不稳定率、缺陷逃逸率和套件运行时长等指标，会与基线进行对照追踪，以确定投入精力的方向。 | 高级测试技术（属性测试、变异测试、模糊测试）被用于高价值代码；测试策略持续改进，并在各团队之间推广。 |
| 代码评审与协作 | 评审并不一致，或者干脆被跳过；机械性的问题占据了评审的主要内容；反馈规范尚未确立。 | 评审是强制要求的，但速度慢、也不稳定；自动化程度有限；PR 的规模和质量参差不齐。 | 小规模的 PR、自动化的机械性检查、明确的标准和反馈规范，以及受到监测的评审延迟。 | 评审延迟、PR 规模和缺陷逃逸率，会与目标进行对照追踪；评审的深度会依据已度量的风险来匹配。 | 组织根据这些数据持续改进评审工作；结对编程和 AI 辅助被有意识地采用，好的实践在各团队之间传播。 |
| 版本控制与源码管理 | 临时性的分支策略；长期存在的分支；提交信息质量低劣；没有密钥扫描；合并经常带来痛苦。 | 存在一致的分支模型和提交信息约定，但分支存活时间过长，执行力度也不完全。 | 主干开发、受保护的主干分支、强制执行的提交约定、密钥扫描，以及经过精心设计的仓库结构。 | 分支存活时长、合并频率和回退率，会与交付指标和基线进行对照度量。 | 自动化端到端地保障各项卫生标准的执行；随着交付需求的变化，仓库结构和工作流在整个组织范围内持续演进。 |
| 文档 | 文档稀少、零散且过时；知识只存在于人们的脑海中。 | 关键文档确实存在（README、一些操作手册），但维护得并不一致，也很难找到。 | 文档即代码，具有清晰的结构、自动生成的 API 文档和变更日志、决策记录，以及明确的更新预期。 | 文档的覆盖率、新鲜度和准确性，会与基线进行对照度量；过时的内容会被自动标记出来。 | 文档是”活”的，大部分是自动生成的，或者会针对系统进行测试验证，有明确的所有者，也易于被发现；这项实践在整个组织范围内持续改进。 |
第三部分：系统
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 架构基础 | 架构是隐性的，只存在于人们的脑海中；没有质量属性，也没有架构决策记录；决策往往是在事件发生时才浮出水面。 | 关键图表已经存在，重大决策有时会被记录下来；质量属性被提及，但很少被量化；文档逐渐与现实脱节。 | 质量属性场景和具有架构意义的需求得到明确规定；架构决策记录成为常规做法；C4/arc42 文档与代码放在一起并持续维护；权衡评审得以开展。 | 适应度函数在 CI 中强制执行各项质量属性，并将度量结果与基线进行对照记录；各种权衡取舍被量化。 | 架构根据这些数据在整个组织范围内持续演进；随着系统的调整，文档始终保持足够可信，能够经得起审计人员的检验。 |
| 架构风格与模式 | 一个纠缠不清的单体系统，或者一团意外形成的分布式混乱；边界依循分层结构或历史沿革而定；架构风格的选择追随潮流。 | 有意识划定的模块边界，或几个粗粒度的服务；一些横切关注点保持一致；拆分方式仍然是临时性的。 | 服务与限界上下文对齐，各自拥有自己的数据；在合适的地方使用网关/BFF（前端专属后端）模式；整洁架构/六边形架构式的分层成为标准做法。 | 架构风格的决策以证据为依据，使用已度量的耦合度、延迟和变更成本数据，与基线进行对照。 | 一个成熟的平台让分布式变得成本低廉；当某次拆分不再划算时，组织会重新整合，并根据证据的变化调整架构风格。 |
| 分布式系统 | 远程调用被当作本地调用来对待；没有重试机制，或者重试机制过于天真；故障会级联扩散；调试意味着逐台机器地翻找日志。 | 超时和基本的重试机制已经存在，但并不一致；有一定的幂等性；日志已经集中化，但彼此之间缺乏关联。 | 通过共享库实现幂等性、退避重试、断路器和舱壁隔离；Saga 模式；分布式追踪；针对每条流程都有文档记录的一致性保证。 | 弹性会与 SLO（服务水平目标）进行对照度量；故障注入的结果和故障率会与基线进行对照追踪。 | 弹性是平台的默认属性，并通过故障注入持续接受测试；优雅降级被设计进系统之中，并在整个组织范围内不断演进。 |
| 数据架构与存储 | 一个数据库承担所有用途；没有迁移纪律；缓存的使用是偶然的；靠升级更大的机器来扩展规模。 | 存储方式的选择大多是经过深思熟虑的；有一个缓存，也许还有一个数据仓库；有版本管理的迁移有时需要停机。 | 多语言持久化与工作负载相匹配，每种存储都有明确的所有者；自动化的零停机迁移；明确的缓存和副本策略。 | 存储方式的选择会依据访问模式、延迟和成本基线进行对照度量；分片和缓存决策以数据为依据。 | 数据架构在整个组织范围内持续接受审查并不断演进；随着工作负载的变化，迁移过程实现自动化并接受审计。 |
| 可扩展性、性能与弹性 | 单实例运行，或仅靠垂直扩展；状态保存在服务器端；没有负载测试，也没有性能预算；故障会导致全面中断。 | 无状态层实现水平扩展；具备基本的自动扩缩容；上线前进行一些负载测试；灾难恢复方案已有文档记录，但很少被真正测试。 | 容量规划留有余量；性能预算被纳入 CI；弹性模式成为标准做法；RTO/RPO（恢复时间目标/恢复点目标）已明确定义，且灾难恢复方案经过测试。 | 容量根据已度量的负载进行预测；性能预算与 RTO/RPO 会与基线进行对照追踪。 | 跨区域的自动化故障切换、持续的混沌工程，以及演练日活动，随着系统在整个组织范围内的演进，不断验证和改进恢复目标。 |
| 遗留系统现代化 | 遗留系统令人畏惧并被冻结；没有清单；现代化改造意味着要么全部重写、要么什么都不做；相关知识存在于即将退休的人的脑海中。 | 清单已经存在，对风险也有一定理解；遗留系统被用 API 包装起来；思维方式仍然是一次性大改造；迁移的难度被低估。 | 系统依据风险和价值排定优先级；绞杀者模式和抽象分支模式成为标准做法；迁移过程通过双运行来加以协调。 | 现代化改造以组合的方式加以管理，风险、价值和进度都会与基线进行对照度量。 | 现代化改造在整个组织范围内持续进行；渐进式替换成为常规做法，具备可逆性，并随着优先级的变化而调整。 |
第四部分：安全
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 安全基础与文化 | 安全工作是被动应对式的，且高度集中；评审姗姗来迟，甚至根本不存在；没有威胁建模；安全被视为”别人的问题”。 | 安全团队制定标准；一些重大项目会进行威胁建模；具备基本的培训；安全被视为一道关卡。 | 安全倡导者被嵌入到各团队之中；威胁建模成为常规做法；安全软件开发生命周期得到文档记录；基于风险确定优先级；评审秉持无责原则。 | 安全指标（威胁建模覆盖率、从发现问题到修复的耗时、控制措施的采纳率）会与基线进行对照追踪。 | 安全真正成为每个人的职责；威胁建模成为习惯性做法；零信任在很大程度上得以实现，这项实践在整个组织范围内持续改进。 |
| 应用安全 | 安全依赖于个人的知识水平；没有标准的控制措施；密钥硬编码在代码中；依赖项过时；身份验证是临时拼凑的。 | 对 OWASP Top 10 有一定的认知；框架自带一些防护机制；密钥管理器的使用并不均衡；偶尔会进行依赖项扫描。 | 按等级采用基于 ASVS 的要求；使用参数化查询；集中式身份系统并配备多因素认证；密钥受到统一管理；具备 SBOM（软件物料清单）和流水线扫描。 | 漏洞密度、平均修复时间和控制措施覆盖率，会在各个服务之间与基线进行对照度量。 | 安全的默认配置直接内置于”铺好的路”框架之中；短期有效凭证和完整的供应链保证（SLSA）在整个组织范围内持续接受验证。 |
| 基础设施与云安全 | 基础设施靠人工配置；权限范围过宽，且使用静态密钥；网络结构是扁平的；加密应用不一致；没有安全态势管理。 | 具备一些 IAM 角色和多因素认证；基本的网络分层；主要存储实现静态加密；定期进行人工评审；部分实现基础设施即代码。 | 采用最小权限原则的 RBAC/ABAC，并配合短期有效凭证；默认拒绝的网络分段策略；默认启用加密并配合密钥管理服务（KMS）；具备策略支持的云安全态势管理（CSPM）。 | 安全态势、配置漂移和策略违规等指标，会与基线进行对照追踪；护栏机制的有效性会被度量。 | 安全的默认配置直接内置于着陆区和基础设施即代码之中；微分段和预防性护栏持续演进，配置漂移在整个组织范围内实现自动修复。 |
| 安全运营 | 安全测试是人工进行的，而且很少开展；没有集中式日志记录或 SIEM（安全信息和事件管理）系统；没有事件应对计划；补丁应用是临时性的；从未接受过对抗性测试。 | 流水线中集成了一些扫描工具；具备集中式日志记录；有一份基本的事件应对计划；补丁应用的时间表比较松散；每年进行一次渗透测试。 | 完整的 DevSecOps 扫描，配合基于风险的关卡；具备 SIEM 系统，并搭配一定的 SOAR（安全编排、自动化与响应）能力；通过桌面推演演练过事件响应流程；具备补救工作的 SLA；开展红队演练。 | 平均检测时间（MTTD）和平均修复时间（MTTR）会与基线进行对照度量；检测覆盖率会与对手所使用的技术手段相对应，并加以追踪。 | 测试和响应高度自动化；紫队演练和检测工程持续改进，并在整个组织范围内适应新出现的威胁。 |
| 隐私与数据保护 | 个人数据被随意收集；没有清单、最小化原则或保留策略；同意机制是事后才想起来加上的；没有权利请求处理流程。 | 存在隐私政策和基本的同意机制；对数据保留有一定的意识；权利请求靠人工处理，速度较慢。 | 隐私设计理念贯穿始终，并配合数据保护影响评估（DPIA）；数据经过梳理和分类；保留策略得到强制执行；合法处理依据被记录在案；权利请求能按期得到满足。 | 隐私态势会被度量：数据清单覆盖率、保留合规性，以及权利请求的处理周期，都会与基线进行对照。 | 隐私成为默认的工程约束条件；数据最小化和自动化的保留策略成为标准做法；权利请求实现自助服务，这项实践在整个组织范围内不断调整适应。 |
| 合规与治理 | 合规工作是被动应对式的；没有控制框架；证据是在截止日期压力下靠人工拼凑出来的；审计发现问题频繁出现。 | 关键框架已被识别出来；一些控制措施有文档记录；审计能够通过，但要靠大量人工投入；无障碍性直到后期才被考虑。 | 一套统一的控制框架把各项标准交叉映射起来；证据收集部分实现自动化；无障碍性经过测试；相关记录和授权已经建立。 | 控制措施的有效性和证据覆盖率，会持续与基线进行对照度量；审计发现的问题会被追踪趋势。 | 合规工作是持续性的，证据始终可用，并采用”合规即代码”的方式；新的认证成本低廉，这套框架在整个组织范围内不断调整适应，随时都能应对审计。 |
第五部分：UI/UX 设计
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| UX 基础 | 没有专门的 UX 实践；决策依靠主观意见；研究是临时性的；流程和术语不一致。 | 有一些设计师，偶尔会进行可用性测试；用户画像缺乏维护；UX 只是一个阶段，还常常被跳过。 | 持续的混合方法研究为优先级排序提供依据；共享的用户画像、用户旅程图和信息架构；UX 质量关卡被纳入完成标准（DoD）。 | UX 指标（任务成功率、满意度、可用性评分）与业务指标一并，与基线进行对照追踪。 | 研究是持续性的，并与业务成果相关联；受控实验形成闭环，洞察随着产品的演进在各团队之间传播。 |
| UI 设计与设计系统 | 每个团队都各自构建自己的界面；没有共享组件；外观不一致；颜色和间距被硬编码。 | 存在部分风格指南或组件库，但使用与否是可选的，设计和代码之间也常常不同步。 | 一套基于设计令牌（token）的设计系统，配备持续维护的代码组件库、文档和治理机制，在各团队之间通用；无障碍性被内建其中。 | 设计与代码的一致性、组件的采纳程度和偏差，会与基线进行对照度量；版本变化会被追踪。 | 这套设计系统作为一个受治理的产品，拥有自己的路线图；它在整个组织范围内持续改进，品牌重塑变成了只需修改设计令牌即可完成的事情。 |
| 无障碍性 | 没有无障碍性实践；问题只有通过投诉或诉讼才会被发现；标记语言缺乏语义，也未经测试。 | 已经具备一定的意识；有一些自动化扫描和上线前审计；无障碍性只是一份后期才用到的检查清单，还常常被降低优先级。 | WCAG 2.2 AA 成为标准；无障碍性被内建到设计系统之中，经过测试，并被纳入完成标准（DoD）；团队接受过培训，并有明确的负责人。 | 无障碍性合规情况会在 CI 中与 WCAG 基线进行对照度量；缺陷率和审计结果会被追踪。 | 无障碍性是持续性的；残障人士参与到研究工作之中；它被嵌入到采购流程、设计令牌和 CI 之中，并在整个组织范围内持续改进。 |
| 内容与沟通设计 | 没有内容实践；文案是临时写就的；术语和语气不一致；错误提示和空状态毫无帮助。 | 可能存在一份风格指南；对简明语言有一定的意识；内容工作仍然处于后期阶段，各团队各自为政，复用程度很低。 | 一套内容策略、语气与风格指南和术语表，在各团队之间通用；简明语言成为标准；共享的内容模式。 | 内容效果会依据实际成果（理解程度、任务完成率、出错率）与基线进行对照度量。 | 内容根据这些证据持续改进；暗黑模式被明令禁止，并接受审计；各种内容模式在整个组织范围内默认实现本地化和无障碍化。 |
| 国际化与本地化 | 只支持单一语言；字符串被硬编码；对 Unicode 的支持存在错误假设；新增语言区域需要修改代码。 | 字符串已经外部化，并使用了 Unicode，但本地化工作是上线前手工批量完成的；格式化和复数形式处理不一致。 | 共享的国际化架构和支持语言区域感知的格式化；具备翻译管理系统（TMS）和持续流水线；伪本地化和多语言区域的 CI。 | 本地化覆盖率、字符串更新的及时性和语言区域相关缺陷率，会与基线进行对照度量。 | 国际化通过工具和代码检查在各团队之间强制执行；本地化是持续性的，文化适配是系统化的，新语言区域能够快速上线。 |
| 前端工程 | 前端开发各团队各自为政、临时拼凑；客户端代码臃肿；没有性能预算；只在团队自己的设备上测试；框架的选择追随炒作热点。 | 具备一些共享工具和组件库；性能会被偶尔度量，但没有预算约束；跨设备测试有限。 | 框架和渲染方式会针对每个界面场景有意识地进行选择；预算在 CI 中借助真实用户监测（RUM）强制执行；渐进增强成为标准做法。 | 性能、健壮性和覆盖面，会与真实用户基线和预算进行对照度量；出现性能回退会导致构建失败。 | 随着前端及其用户的演进，这些信号与业务成果相关联，并在各个界面场景中持续改进。 |
第六部分：人工智能
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| AI 战略与就绪度 | 临时性的实验；没有共享的战略；决策由炒作热点和个人热情驱动。 | 一些项目对问题进行了界定；已经具备初步的平台基线；关于自建还是购买有所讨论，但并不一致。 | 一套用例组合，具有明确的指标、决策树、就绪度评估，以及锁定风险/总拥有成本分析。 | 用例的价值、采纳程度和就绪度，会与基线进行对照度量；整个组合的投资回报率会被追踪。 | AI 战略与业务规划和风险规划相互整合；就绪度得到持续维护，系统会在整个组织范围内依据证据不断重新界定范围。 |
| MLOps | 模型是在 notebook 中临时构建的；部署靠人工完成；没有数据/模型版本管理；没有监控。 | 具备一些实验追踪能力和模型注册表；部署实现半自动化；少数模型具备基本的监控。 | 共享平台配备特征存储、注册表、可复现的流水线和血缘追踪；具备漂移/质量监控；晋升流程受到治理。 | 模型质量、漂移程度和业务影响，会与基线进行对照度量；重新训练由阈值触发，并配合关卡机制。 | 整个生命周期完全自动化，且可审计；随着数据的变化，自助式的”铺好的路”和持续评估在整个组织范围内不断改进模型。 |
| 生成式 AI 与 LLM 应用 | 在孤立的项目中临时编写提示词；没有事实依据、护栏机制或评估；幻觉问题在生产环境中才被发现。 | 具备一些检索增强生成（RAG）和提示词版本管理；具备基本的输出验证；有一个小规模的人工评估集。 | 针对 RAG、护栏机制和工具调用的共享模式；每次变更都进行自动化的离线评估；具备线上指标和人工评审。 | 离线和线上的评估分数、幻觉率和注入攻击成功率，会与基线进行对照度量。 | 评估与业务成果相关联，并持续改进；注入攻击防御、受治理且可观测的智能体，以及缓解措施，在整个组织范围内不断调整适应。 |
| AI 辅助软件开发 | 个人临时性地使用 AI 助手；没有相关政策；没有度量；密钥和知识产权面临风险。 | 具备基本的使用指导和数据规则；有一些安全扫描；对生产力提升的说法多为轶事性质。 | 按风险级别制定明确的规范；强制要求评审和扫描；诚实的成果指标；安全的部署方式和信息披露。 | AI 辅助对交付效率和质量的影响，会与基线进行对照度量；验证覆盖率会被追踪。 | 流水线中的验证机制十分健全；技能培养是有意识进行的，相关政策随着工具和证据的变化，在整个组织范围内持续调整适应。 |
| 负责任与可信赖的 AI | 没有公平性测试、可解释性机制或治理；责任归属不明确；问题只有在造成伤害之后才会被发现。 | 具备一些偏见测试和文档记录；监督是临时性的；对相关框架有所了解，但采纳程度有限。 | 治理与公认的框架相对应；系统性地开展公平性/安全性/隐私性测试；监督机制和申诉渠道均有文档记录；开展红队演练。 | 公平性、安全性和隐私性指标，在生产环境中与基线和阈值进行对照监测。 | 治理被整合进交付流程之中；责任成为每个人的职责，这套方法在整个组织范围内持续改进。 |
| AI 基础设施与运营 | GPU 分配是临时性的；没有批处理或缓存机制；成本缺乏可见性；提示词没有版本管理；监控程度极低。 | 具备一些共享的调度和缓存机制；具备基本的成本追踪；提示词纳入版本控制；评估工作是临时性的。 | 共享平台具备调度、配额、批处理、缓存和资源适配能力；具备向量基础设施；自动化评估；成本归因。 | 利用率、单位成果成本和延迟，会与基线进行对照度量；预算和配额得到强制执行。 | 路由和扩缩容实现自动化，LLMOps 可观测性全面覆盖，利用率和成本得到持续优化，同时在整个组织范围内保持可移植性。 |
第七部分：数据、分析与洞察
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 数据战略与治理 | 数据没有文档记录，也没有所有者；各种定义相互冲突；数据质量问题只有在报表出错时才会被发现；没有数据目录或血缘追踪。 | 一些数据集有所有者和文档；具备部分数据目录；质量检查靠人工进行，且是被动应对式的；政策已经写好，但执行力度较弱。 | 关键数据产品拥有所有者、契约和 SLA；数据目录具备自动化的血缘追踪；质量检查是持续性的；治理采用联邦式模式。 | 数据质量、契约合规性和数据新鲜度，会与 SLA 和基线进行对照度量。 | “数据即产品”成为常态；契约得到自动化执行，自助式护栏机制不断调整适应，各项定义在整个企业范围内都得到信任。 |
| 数据工程 | 临时性的脚本、人工运行、没有测试或监控；故障是由使用者发现的；成本缺乏管理。 | 具备一些编排和调度机制；基本的数据转换纳入版本控制；偶尔进行测试；以被动救火的方式应对问题。 | 采用 ELT 模式，模型分层、经过测试且有版本管理；依赖关系通过编排实现，配合重试/回填机制；具备可观测性；成本受到追踪。 | 流水线的可靠性、数据新鲜度和成本，会与 SLA 进行对照度量；异常情况会与基线进行对照检测。 | 数据流水线本身被当作软件来对待，具备 CI/CD、契约和测试；这个平台持续改进，新的数据产品能够在整个组织范围内快速上线。 |
| 分析与商业智能 | 报表是在电子表格中临时构建的；指标不一致；图表具有误导性；没有治理。 | 使用了一款 BI 工具，具备一些共享仪表盘；指标定义仍然存在分歧；不受控的自助式分析开始蔓延。 | 一个语义层统一定义核心指标；内容区分为已认证内容和实验性内容；自助式分析在护栏范围内进行；生命周期受到管理。 | 指标的使用情况、新鲜度和定义变更，会与基线进行对照追踪；已认证的内容会受到监测。 | 指标像 API 一样受到治理，拥有明确的所有者和变更日志；分析工作涵盖从描述性到规范性的全谱系，并嵌入到整个组织的各个决策节点之中。 |
| 产品分析与实验 | 埋点极少且不一致；决策依靠主观意见；没有实验；只关注虚荣指标；对用户同意处理草率。 | 追踪了一些事件，但分类体系不一致；偶尔进行 A/B 测试，却没有进行统计功效分析；“北极星指标”已被提出，但尚未真正落地。 | 一份受治理、经过验证的埋点方案；漏斗分析/队列分析/留存分析成为常规做法；实验在共享平台上进行；用户同意得到妥善处理。 | 实验数量、统计功效和成功率，会与基线进行对照度量；埋点覆盖率会被追踪。 | 实验成为默认做法；一个共享的结果知识库和明确归属的埋点体系，让组织能够持续积累经验并不断调整适应。 |
| 决策科学与数据文化 | 决策依靠层级和直觉；相关性被当作因果关系对待；不确定性被忽视；指标被用于监控，也因此被博弈。 | 数据被有选择性地用来为决策提供依据；对因果陷阱有一定的意识；不确定性很少被传达出来。 | 分析与决策相绑定，并有预先设定的标准；相关性与因果关系得到区分；不确定性被传达出来；聚焦于结果。 | 决策质量和预测的校准程度，会与实际结果和基线进行对照追踪。 | “什么会改变我们的想法？“成为常规做法；因果严谨性和诚实面对不确定性成为规范，领导者在整个组织范围内根据证据明显地更新看法。 |
第八部分：自动化
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| CI/CD 与交付 | 构建和部署在很大程度上依靠人工，且不一致；集成滞后；发布频率低、压力大；回滚靠人工完成。 | 每次提交都会触发自动化构建和单元测试；部署已经脚本化，但仍需人工监督；构建产物可能在每个阶段被重新构建。 | 一套标准化的流水线，让同一个不可变的构建产物依次通过各个环境，并配合自动化关卡；金丝雀发布/蓝绿部署；自动生成变更记录。 | DORA 指标（前置时间、部署频率、变更失败率、平均恢复时间）会与基线进行对照追踪，并用于把关是否需要回滚。 | 渐进式交付通过功能开关将发布与部署解耦；流水线能够自我改进，合规证据在整个组织范围内自动生成。 |
| 基础设施即代码与配置 | 基础设施靠人工配置；各环境不一致，也没有文档记录；恢复速度慢，且结果不确定。 | 一些基础设施已经脚本化，但实践各不相同；状态不一致；配置漂移常见；策略靠人工评审来执行。 | 声明式的基础设施即代码成为标准做法，使用共享的、有版本管理的模块和远程状态；策略即代码式的护栏机制；定期进行配置漂移检测。 | 配置漂移、配置耗时和策略违规率，会与基线进行对照度量；合规证据自动生成。 | 基础设施具备不可变性，由 GitOps 驱动，并能自我修复；模块库和策略库持续改进，并在整个组织范围内不断调整适应。 |
| 容器、编排与云原生 | 容器的使用是临时性的；镜像手工构建，且未经扫描；部署靠人工完成；没有共享平台或隔离模型。 | 各团队实现了容器化，并使用编排工具，但实践各不相同；扫描和资源限制不一致；成本和租户管理缺乏治理。 | 一个标准化的平台，具备经过加固的镜像、签名/扫描关卡、带配额和网络策略的命名空间级租户隔离，以及成本分摊机制。 | 利用率、部署密度和单位工作负载的成本，会与基线进行对照度量；FinOps（云财务运营）优化以数据为依据。 | 一个自助式、可自我修复、具备强大多租户能力的平台，保持可移植性，并具备混合云/主权云就绪能力，在整个组织范围内持续改进。 |
| 平台工程与开发者体验 | 没有平台；每个团队各自拼凑自己的工具链，方式各不相同；交接依靠工单驱动；认知负荷很高。 | 具备一些共享工具和模板，但比较零散，且部分依赖人工；自助服务能力有限；开发者体验（DevEx）未被度量。 | 一个平台团队负责运营黄金路径、自助式资源配置、开发者门户和评分卡；护栏机制被内置于”铺好的路”之中；开发者体验受到度量。 | 采纳程度、开发者体验评分和认知负荷信号，会与基线进行对照度量，并接受审查。 | 一个成熟的平台产品根据这些反馈持续改进；自愿采纳率很高，治理机制在整个组织范围内的工作流中保持”隐形”。 |
| 测试与流程自动化 | 测试和运维工作在很大程度上依靠人工；覆盖率不一致；操作流程存在于人们的脑海中，或写在过时的文档里；合规证据靠人工收集。 | 存在自动化测试，但运行缓慢或不稳定，且运行也不一致；具备一些运维脚本；补救工作靠人工完成；治理依靠定期审查。 | 快速、并行、可靠的测试基础设施；操作手册被代码化；ChatOps；自动生成合规证据；治理以自动化检查的形式实现。 | 自动化覆盖率、误报率和补救耗时，会与基线进行对照度量。 | 常规事件在具备安全防护的前提下实现自动补救；合规工作是持续性的，随时可供审计，在整个组织范围内，人力则聚焦于需要判断力的工作。 |
第九部分：运维、可靠性与可观测性
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 站点可靠性工程 | 运维工作依靠人工，且是被动应对式的；没有 SLO；可靠性只是主观看法；同样的事件反复发生；救火式工作占据主导。 | 关键服务具备基本的 SLI/SLO；有一些监控和告警；重复性劳动（toil）已被认识到，但未被度量；事后总结不一致。 | 错误预算影响优先级排序；重复性劳动受到度量并设有上限；常规性的容量规划；自动化工作获得资金支持；具备生产就绪评审（PRR）和参与模型。 | 错误预算、重复性劳动和 SLO 达成率，会与基线进行对照度量，并据此驱动优先级排序。 | 错误预算政策实现自动化，并得到切实遵守；自助式运维和前瞻性的容量管理，让组织能够依据数据在速度与稳定性之间做出权衡，并不断调整适应。 |
| 可观测性与监控 | 基本的运行时长检查和逐台机器的非结构化日志；调试意味着要通过 SSH 登录排查；告警噪声大，且常被忽略。 | 指标集中收集，日志实现聚合；有一些仪表盘和阈值告警；追踪链路部分缺失或完全没有；关联分析靠人工完成。 | 使用 OpenTelemetry 埋点，并传播追踪 ID；结构化日志、链路追踪、精心设计的仪表盘，以及基于 SLO 症状的告警；值班安排具有可持续性。 | 告警质量、平均检测时间和遥测成本，会与基线进行对照度量；告警的燃烧速率会依据 SLO 进行调优。 | 高基数、事件丰富的可观测性能够支持临时性的调查排查；数据保留策略在成本上得到优化，遥测数据在整个组织范围内为决策提供支持。 |
| 事件管理 | 事件由碰巧注意到的人临时处理；没有明确角色、严重程度分级或事后总结；值班安排是非正式的；故障反复发生。 | 具备基本的值班轮换和严重程度分级；有一些事后总结，但角色不明确，纠正措施的追踪也不一致。 | 一套正式的事件指挥系统，具有明确的角色和判定标准；无责事后总结成为标准做法；行动项受到追踪；值班能获得相应报酬。 | 事件发生频率、平均恢复时间和值班负荷，会与基线进行对照度量；反复出现的原因会被追踪趋势。 | 响应能力通过演练日进行演练；值班工作保持可持续且相对清闲，随着组织不断学习，汇总分析推动着结构性投入。 |
| 成本、可持续性与绿色软件 | 云成本每个月都是一个”惊喜”；没有标签、分摊机制或碳排放意识；资源配置十分慷慨，也从未被重新审视。 | 具备基本的成本可见性和标签体系；有一些被动应对式的资源调优和闲置资源清理；可持续性已被认识到，但未被度量。 | 一套 FinOps 实践，具备成本归因、预算、预测、异常告警、承诺型采购和资源调优；主要服务的碳排放受到度量。 | 成本和碳排放会按团队与预算和基线进行对照度量；异常情况会被标记出来。 | 成本和碳排放成为由团队持续负责的信号；高效的默认配置、自动化优化和具备碳排放意识的调度机制，在整个组织范围内持续改进。 |
第十部分：项目/产品/项目集管理
| 主题 | 第 1 级 启动级 | 第 2 级 发展级 | 第 3 级 标准化级 | 第 4 级 管理级 | 第 5 级 协同级 |
|---|---|---|---|---|---|
| 组合与项目集管理 | 优先级由声音最大的人临时决定；没有组合层面的全局视图；依赖关系以危机的形式浮出水面；年度资金分配一片混乱。 | 一份定期审查的组合清单；已发布的目标与实际工作之间的关联较弱；有一份依赖关系登记表；预算按项目分配。 | 战略通过 OKR 层层传导；具备一致的优先级排序框架；跨团队规划用于管理依赖关系；团队资金采取持续性拨付方式。 | 组合层面的成果、交付的可预测性和依赖数量，会与基线进行对照度量。 | 组合根据成果证据持续再平衡；依赖关系通过设计从源头上被消除，在整个组织范围内，资金拨付的节奏与学习的节奏相匹配。 |
| 风险、审计与保证 | 风险只有在事件发生之后才被动地加以处理；没有框架或登记表；控制措施没有文档记录；人工审计痛苦不堪。 | 主要系统具备风险登记表；已采用某种控制框架，审计能够通过，但依靠人工且只是某个时间点的快照；供应商在准入时接受评估。 | 在整个组织范围内采用三道防线模型和统一框架；许多控制措施实现自动化；持续监测；具备供应商/SBOM 清单；灾难恢复按计划进行演练。 | 控制措施的有效性、未关闭风险的数量和审计发现的问题，会与风险偏好和基线进行对照度量。 | 保证工作是持续性的，且在很大程度上实现自动化；审计人员抽样检查实时证据，随着风险在整个组织范围内的演变，供应链的完整性也得到持续验证。 |
| 采购、开源与许可 | 开源组件被随意引入；没有政策或清单；许可证未经审查；生命周期终止情况只是偶然被发现；没有所有者。 | 具备基本的政策和许可证白名单；有一些人工的、滞后的扫描；主要系统具备清单；对外贡献是临时性的。 | 一个开源项目办公室（OSPO）负责战略和工具；许可证/漏洞扫描和归因实现自动化；具备 SBOM；对外贡献流程明确；生命周期终止情况受到追踪。 | 许可证合规性、依赖项的更新程度和漏洞暴露面，会与基线进行对照度量。 | 开源被当作一项受管理的战略资产，合规工作完全自动化；对上游项目的投入是有意识进行的，依赖项的更新和生命周期终止情况在整个组织范围内得到持续管理。 |
| 维系大型与长期运行的系统 | 系统依赖于”英雄式人物”；所有权靠记忆维系；知识没有文档记录；系统被冻结，直到出故障为止；退役工作永远无法完成。 | 主要系统的所有权被指派并记录了下来；有一些文档和操作手册；明显的关键职能具备候补人员；维护工作是被动应对式的。 | 团队层面的所有权被记录在目录之中，并能在重组之后延续下去；巴士系数受到度量并加以缓解；具备决策记录和操作手册；现代化改造以渐进方式进行。 | 巴士系数、所有权覆盖率和知识转移的进展，会与基线进行对照度量。 | 守护工作成为一门获得资金支持的学科；没有任何关键系统是单一的人为故障点，知识转移和有计划的系统终结工作在整个组织范围内持续进行。 |
| 伦理、问责与公共利益 | 伦理问题无人问津，或只有在丑闻曝光之后才被动应对；无障碍性被忽视；自动化决策不透明，且没有申诉渠道；偏见未经测试。 | 具备一份行为准则，以及一些（滞后的）无障碍性考量；备受关注的自动化决策会受到一定的监督；偶尔进行偏见检查。 | 伦理评审成为流程的一部分；无障碍性被纳入设计并经过用户测试；具有重大影响的决策附带解释说明和申诉渠道。 | 公平性、无障碍性和算法问责方面的成果，会与基线进行对照监测。 | 责任被嵌入到组织的建设方式之中；公平性成为不容商量的默认标准，算法问责成为标准做法，并在整个组织范围内持续改进。 |
整体成熟度自评
使用上面的矩阵，得出一个轻量级的、诚实的评分。
评分细则
- 为每一章打 1 到 5 分，使用与你通常的实际情况最匹配的那个级别的描述。当行为表现不一致时，打较低的那个分数。
- 按部分求平均值。 将一个部分内各章的分数相加，再除以章节数量。这样就能得出每个部分的成熟度（例如，“第四部分平均分为 2.5”）。
- 记录最低分，而不仅仅是平均分。 一个平均分为 3.0 的部分，如果其中包含一个处于第 1 级的章节，无论平均分是多少，都依然带有那个章节的风险。
- 绘制趋势图。 每一两个季度重新打分一次，观察变化的方向。一个从 2 分提升到 3 分的领域，要比一个始终停滞在 3 分的领域更健康。
每个部分都可以使用一份简单的工作表：
| 部分 | 已打分章节数 | 平均分（均值） | 最低分章节 | 备注/优先级 |
|---|---|---|---|---|
| 第一至第十部分 | 数量 | 均值 | 最低级别 | … |
确定改进的优先级
不要试图一次性提升所有方面，也不要一味追求最高的平均分。要依据风险加权的成熟度差距来确定优先级：优先攻克那些成熟度低、后果又严重的领域。
- 首先： 处理你们风险最高的领域中成熟度最低的章节。对于大多数组织而言，这意味着安全、隐私、可靠性、合规，以及任何一旦出故障就会伤害他人或违反法律的系统。这些领域中出现第 1 级，是紧急情况。
- 其次： 那些能够提升其他所有领域上限的基础性支撑因素（文化、工作方式、CI/CD、基础设施即代码、可观测性）。改进这些方面，会让后续的提升变得更容易实现。
- 最后： 那些已经处于第 3 级、有可能提升到第 4 级或第 5 级的领域。只有当风险和规模确实能够证明额外投入是合理的时候，才去超越这个底线继续攀升。
企业与政府的基准线
在企业和政府场景中，通常不能止步于”能用就行”。要通过审计、维持授权，并满足监管和公共问责方面的义务，大多数领域都必须达到至少第 3 级（标准化级），也就是实践在各团队之间实现标准化、有文档记录、得到强制执行，并能产生证据的那个级别。第 2 级通常无法通过审计，因为它不一致，而且是在截止日期压力下靠人工拼凑出来的；第 1 级则会彻底无法通过。
对于任何需要接受审计或涉及安全的事项，都应把第 3 级视为底线，而更高的级别（第 4 级和第 5 级），只有在持续保证、规模，或公众信任的需要证明这份额外的严谨性物有所值时，才应作为目标。成熟度终究只是一种手段：目标是针对你实际承担的风险，建立一种站得住脚、与之相称的控制水平，而不是追求一个完美的分数。