通过变化传递信号来衡量系统可靠性

系统变更是导致生产问题的最主要原因。行业研究及实际事后分析通常认为，60%到80%的生产问题都与代码、配置、数据或实验方面的变更有关。因此，对变更进行有效监测与其他可靠性指标（如成功率、每秒查询量、延迟时间等）同样重要。

这一观点也与行业标准软件交付绩效评估框架高度契合。例如，DORA指标定义了四个关键的软件交付绩效指标：部署频率、变更前置时间、变更失败率以及服务恢复时间。实践证明，在DORA指标上表现优异的团队，其系统稳定性往往更高，恢复速度也更快，业务成果也更佳。

基于这一行业基础，本文提出了一套更加注重可观测变更的指标体系，并设计这套体系以便在异构且分布式的变更管理系统中统一应用。

此外，本文还会介绍一种可扩展的架构模式，用于构建专门用于收集和展示这些指标的数据仓库。

变更的特性

要有效设计这样的指标体系，首先必须了解系统变更的基本特性，因为这些特性直接决定了变更带来的风险、所需的监测要求以及其在生产环境中的运行行为。

异构性

不同类型的变更往往遵循不同的工作流程、验证步骤和风险控制机制。例如，代码变更通常需要经过单元测试、集成测试、回归测试以及渐进式部署等环节才能正式投入生产使用；而配置变更则可能需要更严格的审批流程、审计机制以及变更审查节点，因为它们一旦实施就会立即影响正在运行的系统，而无需重新进行部署。

分布式特性

现代系统都是建立在分布式计算基础之上的；变更过程在范围、执行方式以及影响程度上也同样具有分布式特征。变更往往会在多个微服务、数据中心以及不同的地理区域中被触发并应用，有时这些变更还会由那些采用不同发布周期的团队来执行。

高频率更新

在现代科技企业中，系统变更会持续不断地发生，并且规模也会不断扩大。由于采用了持续集成/持续部署流程、自动化部署平台以及实验系统，这些变更能够全天候地在不同的时区以及由不同的工程团队来推进并最终应用到生产环境中。

评估机制

业务指标

为了全面评估变更交付过程的效果，我们定义了以下一些与具体技术实现无关的业务级指标，以便根据系统变更的特性来评价其可靠性和效率。

变更部署周期

这个指标用于衡量一项变更成功应用于生产环境所需的时间，它反映了你的交付流程的效率。

变更成功率

这个指标表示某项变更成功应用到生产环境的比率。只有当变更顺利完成部署且没有引发回滚或立即需要采取补救措施时，才能被视为成功的变更。这一指标既体现了交付流程的效率，也反映了其可靠性。

问题发生率

这个指标用于衡量那些在部署后导致了生产故障或警报出现的变更所占的比例。与专注于回滚结果的变更成功率不同，问题发生率能够揭示那些在部署之后才被发现的潜在缺陷、功能退化以及运行性能下降的情况。

与DORA指标的关系

这些指标在概念上与DORA提出的四个关键评估指标是一致的：部署频率、变更部署周期、变更失败率以及服务恢复时间。然而，我们有意对这一框架进行了调整和重新诠释，以便使其更适用于大规模、多平台的变更管理场景。

我们没有将部署频率作为一级评估指标。实际上，部署频率的高低本身并不能直接说明交付流程的好坏。例如，不同团队提交的多个代码变更可能会被集中安排在一次性部署中，这样做虽然会降低部署频率，但有可能提高系统的可靠性，同时也不会延迟产品的迭代进程。因此，仅凭部署频率这一指标，是很难准确评估变更质量或效率的。

我们也将“服务恢复时间”从变更交付指标体系中剔除。平均响应时间主要反映的是问题处理的效率，而非变更交付过程本身的质量。虽然平均响应时间对于系统的整体可靠性来说非常重要，但它实际上反映的是下游的运营成熟度，而不是上游的变更风险预防机制。

我们将交货周期作为核心效率指标，并采用“CLT”这一概念作为其直接对应指标。CLT依然是衡量流程处理能力及运行效率的最可靠依据。我们并非通过测量失败率来评估系统性能，而是将其倒数定义为“CSR”。对于监控界面而言，“CSR”这个指标更为直观，也更容易被理解为“数值越高代表效果越好”的信号。重要的是，“CSR”同时体现了效率与可靠性的双重标准：频繁发生的故障会增加运营负担、延缓交付进度，并说明系统的验证机制存在缺陷。

然而，仅凭“CSR”这一指标是无法区分那些在部署过程中就被及时发现并被阻止的变更，以及那些成功部署但却隐藏了潜在问题的变更的。这两种情况所伴随的风险本质上是不同的。一个经常拒绝高风险变更的流程可能会显示出较低的“CSR”值，但这样反而能有效保护生产系统的正常运行；相反，如果一个“CSR”值较高的流程中总有一些有缺陷的变更能够通过验证机制，那么这个系统依然可能存在安全隐患。

“ILR”这一指标正是针对这一问题而设计的，它通过检测部署后的问题发生情况来反映这一现象。这个指标试图回答这样一个问题：在所有被实际应用的变更中，有多少最终会引发问题？因此，“ILR”有效地补充了“CSR”的不足，它将变更执行的正确性与风险控制的效果区分开来。一个健康的系统应该具备较低的“CLT”值（即高效的交付能力）、较高的“CSR”值（也就是较少的部署失败情况），以及较低的“ILR”值（也就是较少的缺陷漏网情况）。

技术指标

基于这些业务目标，我们制定了以下技术层面的控制指标，以便在实际操作中规范变更交付流程：

变更审批率

所有涉及生产环境的变更在正式部署之前都必须经过审批流程，包括质量检测、风险评估以及合规性审查等。这一审批环节是确保变更符合安全、合规及质量要求的第一道关卡。

渐进式部署比例

渐进式部署是一种被广泛采用的最佳实践方式，它能够让潜在问题在全面部署之前就被及时发现。不同类别的变更应该按照渐进式的顺序进行测试和部署，从而将对生产系统的负面影响降到最低。

变更监控窗口期

如果不在渐进式部署过程中安排足够的监控时间，变更带来的影响可能不会立即显现出来。实际上，设置15到30分钟的监控窗口期，可以在保障运营可靠性的同时，确保交付效率不受影响。

综上所述，这些指标共同构成了一个系统化的评估框架，用于衡量变更交付流程的健康状况和成熟度，从而使各组织能够不断优化变更管理的安全性和效率。

数据采集与处理

现在我们已经建立了一个全面的指标体系来评估变更交付流程的效果。接下来需要考虑的问题是如何获取这些数据。一种直接的方法是从现有的交付平台中收集数据，因为许多系统已经提供了包含变更相关信息的日志或数据库记录。然而，在实际操作中，这种方法的可扩展性较差，因此我们选择了其他方案。原因在于之前已经提到过，变更本身具有异构性和分布式特征，因此传统的数据采集方式并不适用于这种情况。

不同的交付平台通常支持不同类型的变化处理机制，遵循不同的工作流程，并且会随着时间的推移而独立发展。因此，如果试图通过汇总来自多个特定平台的数据来源来构建评估指标，就会导致语义不一致、覆盖范围碎片化、逻辑重复以及集成效果脆弱，而这些问题都会在平台发生变化时需要持续进行维护。

此外，在分布式环境中，变化并不会源自某个单一的流程或系统。它们可能会在多个服务、地区和组织部门中被发起，而每个部分都使用自己的工具和操作规范。在这种情况下，依赖特定平台的评估指标体系就会与具体的实现方式紧密绑定在一起，从而无法提供关于交付性能的统一、系统级的视图。

因此，一个可扩展且可靠的解决方案需要采用一种与具体平台无关的、基于事件驱动机制的评估体系，这种体系能够跨不同的平台和地区一致地观察变化行为。这样的设计可以确保评估指标具有可比性、可扩展性，并且能够在底层平台发生变化时依然保持稳定，同时真正反映变化交付过程的端到端特性。

以事件为中心的架构

图1：基于事件驱动的架构。

上图展示了一种基于事件驱动机制的架构，该架构能够以可靠、可扩展的方式从多个平台收集、标准化并分析变化交付相关的数据。与那些依赖碎片化日志或特定平台数据库的方法不同，每一个变化事件都会被发布到一个统一的事件处理管道中，从而在整个生态系统中实现一致的语义表达和端到端的监控能力。由不同变化交付平台生成的事件首先会被转化为结构化的消息格式，然后这些消息会被送入中央事件中心消息队列中。这种设计使得事件生成者与下游处理者相互解耦，同时提供了数据持久性、缓冲机制以及防压力溢出保护功能。这样一来，各个平台就可以独立发展，同时又能够为共同的分析工作提供基础支持。

随后，这些事件会以批量处理的方式被送入事件中心的数据仓库中保存。原始的事件数据会被保留下来，以便用于追溯分析、历史回放以及满足审计要求。之后，批量分析流程会对这些数据进行处理和优化，包括规范数据结构、提取变化属性、关联跨平台的标识信息以及应用验证规则，最后将这些处理后的数据以结构化表格的形式存储到变化交付数据仓库中。

最后，实时聚合与可视化服务会从分析数据仓库中提取数据，从而为变更交付仪表板提供支持，这些服务能够实现跨平台的统一报告、运营洞察以及变更风险监控。这种分层设计将事件的采集、存储、处理和展示等功能分开，既保证了系统的可靠性，同时也支持历史数据分析及近乎实时的运营监控需求。

除了具有可扩展性之外，这种架构还具有较高的成本效益。通过将事件采集与分析功能集中到同一个处理流程中，而不是在多个交付平台上重复进行存储和计算操作，该架构有效地避免了冗余的数据处理工作，降低了集成开销，并使得基础设施资源能够被统一管理和调整规模。对于历史数据分析而言，采用批处理方式进一步降低了存储和计算成本；而对于那些需要实时处理的业务场景，该架构依然能够确保及时提供运营洞察。

虽然这种架构在大规模应用中才体现出其真正价值，但它的优势并不局限于大型组织。当变更量增加、多种部署机制同时存在，或者理解变更带来的影响变得至关重要时，各类团队都应该考虑采用这种架构。对于规模较小的系统来说，采用较为轻量级的实现方案可能就已经足够了；但只要在设计之初就考虑到这种分层处理的理念，就能避免日后进行昂贵的重新架构工作。

以数据驱动的方式优化您的变更交付流程

一旦建立了相应的测量体系，各组织就可以每天或每周跟踪与变更相关的各项指标，从而持续提升系统的可靠性和运营效率。在实际操作中，可以根据变更对象的业务重要性、影响范围以及运营风险将其划分为不同的等级，然后为不同等级的变更设定不同的指标目标及可靠性要求^{服务水平目标}，而不是对所有变更都采用统一的评估标准。

例如，支付或金融结算类系统通常会被归为第一级（L1）。对于这类系统，会设定更为严格的目标，比如接近零的变更失败率、更严格的审批流程、更完善的部署保障措施以及更低的可观测性阈值，因为哪怕是微小的故障也可能带来严重的业务、财务或合规问题。相比之下，非关键性的系统或处于测试阶段的系统，如内部工具、分析仪表板或产品初期功能，可能会被归为第三级（L3）。这类系统可以承受更高的变更频率，其可靠性目标也可以更加灵活，这样就能支持快速的迭代和创新发展，而不会增加不必要的管理负担。

这种基于风险的指标框架将可靠性目标与业务实际需求相结合：对那些影响较大的系统，会采取更严格的控制措施；而对于风险较低的领域，则保留其灵活性。随着时间的推移，企业可以利用这些分层化的指标来识别可靠性方面的不足之处，确定工程改进的优先级，并根据收集到的数据优化自身的变更管理流程。基于这一指标框架设计的变更管理仪表盘，其展示效果如下图所示。

图2：变更管理仪表盘。

假设这个仪表盘反映的是年终绩效总结，那么我们就可以从这些指标中提取出一些关于可靠性和流程质量的见解。

从可靠性的角度来看，整体表现相当不错。对于那两项面向外部用户的服务（L1和L2），整个年度内因变更而引发的在线故障总数约为：

2000×0.5%+3000×1%≈40

考虑到变更操作的数量规模，这个数字其实已经相当低了。我们特意没有将L3纳入这一统计范围，因为它是一项内部服务，其故障通常不会对外部业务产生太大影响。

L1和L2都采用了逐步推进的变更部署方式，并设置了合理的监控周期，这说明大多数变更都得到了有效的管控。如此高的采用率说明这种部署管理机制在及时发现问题、防止大规模故障蔓延方面确实非常有效。

虽然故障发生的绝对数量不多，但不同服务层级之间的风险分布情况却存在差异：

• L1拥有最高的审批通过率和最严格的管控措施，因此其漏报率也是最低的。
• L2处理的变更操作数量更多，但其管控措施相对较弱，因此故障泄漏率略高一些。

这种做法体现了一种有针对性的风险控制策略：对于核心关键服务来说，安全性是首要考虑的因素；而对于中等重要程度的服务而言，则可以在保证一定效率的前提下，允许存在一定的风险。

尽管整体的可靠性和交付性能都表现良好，但这些指标也指出了进一步优化的方向：

加强L2和L3的监控力度

L2和L3的漏报率比L1要高，这说明在逐步推进变更部署的过程中，确实存在一些问题未能被及时发现。延长监控周期或提升自动化异常检测机制的效果（例如通过监测成功率、延迟时间以及错误峰值等指标），有助于减少故障泄漏现象，而不会对交付效率产生实质性影响。

加强在高变更频率领域中的治理措施

L3流程处理的变更量最大，但目前其审批与控制机制的覆盖范围相对较低。虽然其故障不会直接影响外部用户，但服务中断仍可能降低内部运营效率，导致工作效率下降，并增加工程团队的恢复工作负担。通过引入一些轻量级但系统化的治理措施，例如针对敏感变更类型实施有针对性的同行评审、开展自动化的部署前验证，以及为高风险场景制定更严格的发布保障机制，可以在不显著影响交付速度的情况下提升系统的稳定性。

结论

系统变更是导致生产问题的主要因素之一，因此应将变更的可观测性视为可靠性工程的核心组成部分，而不仅仅是事后才需要考虑的因素。我建议采用一种实用的指标体系，将业务层面的评估指标（如变更生命周期时间、变更成功率、变更影响程度）与技术层面的控制指标（如审批流程、分阶段部署机制、监控机制）结合起来。这种指标应用方式能够帮助组织以一致且具有操作性的方式来衡量其变更交付过程的可靠性和效率。

我还建议采用以事件为中心的数据架构，该架构能够提供可扩展的、与具体平台无关的变更分析功能，并说明如何通过基于风险的分层指标模型将运营保障措施与实际业务影响联系起来。这些实践共同将变更管理从一种被动应对的过程转变为一种可衡量、可优化的工程能力，从而帮助团队在保持高效交付的同时降低风险。

虽然这种框架在变更频率高、所有权分散且部署平台多样的环境中效果尤为显著，但对于那些部署频率较低、服务依赖关系简单或运营风险较小的小型系统来说，可能并无必要采用。在这种情况下，轻量级的指标或基于平台的可观测性机制或许就能提供足够的洞察力，而无需增加额外的架构复杂性。

这种模型是对现有的交付与可靠性框架的补充，而非替代。例如DORA指标、站点可靠性工程的金色信号指标，以及传统的事件管理关键绩效指标等，组织应根据系统的规模、风险状况及治理需求来调整变更可观测性的实施深度。