14、关键指标：软件开发与运维的度量之道

关键指标：软件开发与运维的度量之道

在软件开发和运维的领域中，准确的度量是确保项目成功、提升软件质量的关键。以下将为您详细介绍一些重要的度量指标和方法。

简单质量指标

有几个简单却强大的质量指标，与持续交付（CD）和DevOps密切相关，它们分别是：
- 平均故障间隔时间（MTBF） ：用于衡量终端用户发现问题（或故障）的频率。故障间隔时间越长，整体平台的稳定性和质量就越高。
- 平均修复时间（MTTR） ：帮助测量从发现问题到解决问题所花费的时间。
- 缺陷逃逸距离 ：用于测量问题是何时被发现的。

测量这些数据能很好地反映项目的进展。例如，如果CD和DevOps实施得很好，MTBF应该会随着时间上升，而MTTR会下降。

代码复杂度

复杂代码有时是必要的，特别是在资源有限的高度优化代码或实时用户界面的场景中。但对于在线商店、登录页面或财务模块等，过于复杂的代码可能弊大于利。一些工程师认为能编写复杂代码很厉害，但为了复杂而复杂其实是在炫耀。

过于复杂的代码会带来很多问题，尤其在调试或扩展代码以满足更多用例时，会直接影响实现哪怕最小更改的速度。CD的前提是进行小的增量更改，如果代码过于复杂，后续就会出现问题。因此，在实施任何流程或工具之前，应该花时间深入研究这个复杂的主题，理解其底层原理和科学依据。

单元测试覆盖率

在软件开发过程中纳入单元测试是公认的最佳实践。它能在开发早期以更细粒度和底层的方式执行代码路径和逻辑，有助于尽早发现和消除缺陷。如果一小段代码有良好的测试覆盖率，那么就可以更有信心地频繁发布该代码，风险也更小，这符合CD小而频繁的交付方式。

需要注意的是，度量的指标主要基于代码库被测试覆盖的百分比。如果企业过于关注这个数值，可能会认为低覆盖率意味着重大风险，但事实并非总是如此，特别是在对没有测试覆盖的现有代码库开始实施单元测试时。应该设定好背景，确保查看数据的人都理解其含义，比如解释少量测试（甚至一个测试）也比没有测试要好且风险更小。

提交率

定期向源代码控制进行提交应该被广泛鼓励，并融入工作方式中。源代码长时间留在个人工作站或笔记本电脑上是非常危险的，有时会导致工作重复，甚至可能阻碍其他工程师的进度。

有人担心工程师提交过于频繁会增加产生缺陷的几率，担心未完成的代码会被合并到主代码分支。但这种担心是错误的，没有工程师会真的这么做。真正的风险在于提交间隔时间越长，需要合并的代码就越多，这会导致更多问题、延迟和潜在的缺陷。

CD方法基于小而频繁地交付更改，这不仅适用于软件二进制文件，小而频繁地交付源代码的增量部分也是一种好的实践。如果能够测量提交率，就可以知道谁在遵守规则，谁没有。但要注意，不要用这些数据来奖励或惩罚工程师，以免引发不良行为。

遵守编码规则和标准

软件开发团队可能已经有自己的编码标准，或者试图遵循外部记录和认可的最佳实践。分析代码库以确定哪些部分符合标准，哪些部分不符合是非常有用的，因为这有助于突出潜在风险区域。

有很多工具可以帮助进行这种分析，这种分析通常基于一组预定义的规则和阈值（如信息、次要、主要、关键和阻止），需要与工程团队合作，在工具中达成一致并设置这些规则。虽然这看起来很麻烦，但却是值得的。

从何处开始以及为何要关注这些指标

有许多可以且应该测量、分析并生成指标的内容，也有很多工具可以提供帮助。需要确定最重要的指标并从这里开始。设置所需工具的工作和努力应该被视为一个很好的机会，可以引入一些想要嵌入的良好行为，如协作、开放和诚实的对话、信任等。

尽早实施这些工具，以便从一开始就跟踪进展。虽然一开始情况可能不太乐观，而且这样做的有效性可能会受到质疑，但它能带来一些有价值的好处：
- 有额外的数据证明软件质量，会建立起对代码可以快速安全发布的信任。
- 对整个代码库有清晰的了解，有助于将平台重新设计为组件化。
- 如果工程师对代码库更有信心，他们就可以专注于新功能开发，而不用担心每次更改都会引发问题。

还可以将这种测量和工具纳入持续集成（CI）过程。例如，在CI作业中加入代码质量分析步骤，这样未通过测试的软件就不会被发布。这样不仅能测量软件质量，还能设置一个质量关卡，确保代码符合要求。

测量现实世界

分析和测量代码及工程专业知识固然重要，但为了让CD和DevOps有效运作，还需要关注整个平台、运行中的软件以及CD和DevOps的有效性进展。下面从环境稳定性的测量开始介绍。

测量环境的稳定性

在产品交付过程中，可能会有多个不同用途的环境。随着发布周期加快，对这些环境的依赖会增加。如果是两到三个月的发布周期，某个环境出现半天左右的问题对发布影响不大；但如果每天发布10次，半天的停机时间就是重大影响。

在IT行业中，“环境问题”这个术语经常出现，当遇到诸如夜间测试失败、构建服务器掉线、无法提交更改、用户无法登录、实时平台无法工作等情况时，人们常常将其归咎于环境问题。但这种说法并不总是有根据的，从长远来看，这不利于开发和运维部门建立良好的工作关系。

为了克服这种态度并培养良好的行为，需要做到以下两点之一：
- 确凿证明软件平台按预期运行，那么遇到的任何问题都一定是基础设施的问题。
- 确凿证明基础设施按预期运行，那么遇到的任何问题都一定是软件的问题。

纳入自动化测试

可以将自动化测试组合在一起，对给定环境持续运行。这样可以不断测试平台的大部分内容，如果捕获测试结果，就能快速了解环境的健康状况，或者更准确地说，能知道软件是否按预期运行。如果测试开始失败，可以查看自上次成功运行以来发生了哪些变化，尝试找出根本原因。

不过，这种方法有很多注意事项：
- 需要有良好的测试覆盖率才能建立高度的信心。
- 可能有不同方式和技术编写的测试，它们可能无法很好地协同工作。
- 一些测试可能会相互冲突，特别是依赖某些预定义测试数据时。
- 测试本身可能并不完美，特别是包含模拟或存根时，可能无法显示问题。
- 有些测试可能不稳定，会时不时失败。
- 按顺序运行所有测试可能需要很多时间。

如果能接受这些注意事项，或者有资源来加强测试，使其能够持续一致地作为一组运行，就能对软件平台更有信心，相对容易地发现给定环境中的不稳定问题。

结合自动化测试和系统监控

仅运行测试只能了解部分情况。将自动化测试结果与监控解决方案的输出结合起来，可以更全面地了解环境的稳定性。更重要的是，当出现问题时，能更好地找出根本原因。

但这种方法也有一个注意事项：在生产环境中运行一些自动化测试可能会有重大问题。除非运维团队愿意接受每小时/每天多次在生产数据库中生成和删除测试数据，并且能接受额外的负载和可能的安全影响，否则这种方法可能仅限于非生产环境。

软件本身的实时监控

结合自动化测试和系统监控能提供有用的数据，但只能证明平台正常运行且测试通过，无法深入了解软件平台的行为，特别是在被数百万真实用户使用的生产环境中的行为。

可以借鉴一级方程式赛车的开发方式。赛车中有各种传感器和电子设备，能提供深入的指标和数据，这对了解赛车的运行情况更有价值。同样，软件平台也需要从其内部获取数据和指标，才能全面了解其运行情况。

有很多工具可以帮助处理软件生成的日志文件，将其编译成有用的报告和图表，但很难实时生成这些内容，特别是在产生大量数据时。更简洁的方法是在软件中内置一些功能，以小而简洁、一致的格式提供底层数据，主要有以下两种方式：
- 在软件API中纳入健康检查功能，当中央数据收集解决方案定期调用时，提供底层指标数据。
- 扩展软件平台，定期将底层指标数据推送到中央数据收集解决方案。

当然，需要一个中央数据收集解决方案，可以通过DevOps的方式选择和实施最合适的工具。

无论采用哪种方法，最终都应该能获得丰富而深入的信息。关键是要将所有数据整合为连贯且易于理解的形式，这也是鼓励DevOps行为的一个挑战，因为要捕获和呈现的数据最好由双方工程师共同确定。

以下是一个简单的流程图，展示了从代码开发到环境监控的主要流程：

graph LR
    A[代码开发] --> B[单元测试]
    B --> C[代码提交]
    C --> D[代码分析]
    D --> E[环境部署]
    E --> F[自动化测试]
    F --> G[系统监控]
    G --> H[实时数据收集]

同时，为了更清晰地对比不同测量方法的优缺点，我们列出以下表格：
| 测量方法 | 优点 | 缺点 |
| ---- | ---- | ---- |
| 自动化测试 | 能快速发现软件问题，持续测试平台大部分内容 | 有诸多注意事项，如测试覆盖率、协同工作等问题 |
| 结合自动化测试和系统监控 | 全面了解环境稳定性，更好找出根本原因 | 在生产环境运行自动化测试可能有问题 |
| 软件本身的实时监控 | 深入了解软件在生产环境的行为 | 实时生成数据困难，需内置特定功能 |

关键指标：软件开发与运维的度量之道

监控的理想状态

无论你采用何种方法（或多种方法的组合），最终都应能获取到丰富且深入的信息。实际上，你所拥有的数据量可能堪比一级方程式赛车技师所掌握的海量数据。而你要做的，就是将这些数据整合为连贯且易于理解的形式。这一挑战也为促进DevOps行为提供了契机，因为你想要捕获和呈现的数据，最好由开发和运维双方的工程师共同探讨并达成一致。

为了更好地理解不同测量指标之间的关系，我们可以通过以下的流程图来展示：

graph LR
    A[MTBF] --> B[系统稳定性]
    C[MTTR] --> B
    D[代码复杂度] --> E[开发效率]
    F[单元测试覆盖率] --> G[代码质量]
    H[提交率] --> I[协作效率]
    J[遵守编码规则] --> G
    K[环境稳定性测量] --> L[整体可靠性]
    M[自动化测试] --> L
    N[系统监控] --> L
    O[实时监控] --> L

下面我们通过一个表格来总结各个测量指标的作用和意义：
| 测量指标 | 作用 | 意义 |
| ---- | ---- | ---- |
| MTBF | 衡量终端用户发现问题的频率 | 反映系统的稳定性和质量 |
| MTTR | 测量从发现问题到解决问题的时间 | 体现问题解决的效率 |
| 代码复杂度 | 评估代码的复杂程度 | 影响开发和维护的效率 |
| 单元测试覆盖率 | 测量代码被测试覆盖的比例 | 保障代码质量，降低发布风险 |
| 提交率 | 统计代码提交的频率 | 促进团队协作，减少合并冲突 |
| 遵守编码规则 | 检查代码是否符合标准 | 提高代码的可读性和可维护性 |
| 环境稳定性测量 | 监测环境的运行状况 | 确保软件在不同环境中的可靠性 |
| 自动化测试 | 持续测试软件功能 | 快速发现软件问题 |
| 系统监控 | 收集系统运行数据 | 全面了解环境稳定性 |
| 实时监控 | 获取软件内部的详细数据 | 深入了解软件在生产环境的行为 |

实际应用中的注意事项

在实际应用这些测量指标和方法时，还需要注意以下几点：

数据的准确性和可靠性

确保所收集的数据准确无误是至关重要的。不准确的数据可能会导致错误的决策，从而影响项目的进展。为了保证数据的准确性，需要对数据收集的过程进行严格的监控和验证。例如，在进行自动化测试时，要确保测试用例的设计合理，测试环境的配置正确，以避免因测试过程中的误差而导致数据不准确。

指标的关联性和综合性

各个测量指标之间并不是孤立存在的，它们相互关联、相互影响。在分析和评估软件项目时，不能仅仅关注某一个指标，而应该综合考虑多个指标。例如，代码复杂度可能会影响单元测试覆盖率和MTTR，如果代码过于复杂，可能会导致测试用例难以编写，问题解决的时间也会相应延长。因此，需要建立一个综合的指标体系，全面评估软件项目的质量和性能。

团队的协作和沟通

实施这些测量指标和方法需要开发和运维团队的密切协作和沟通。开发团队负责编写代码、进行单元测试和提交代码，运维团队负责环境的部署、监控和维护。双方需要共同制定测量指标和规则，确保数据的收集和分析符合项目的需求。同时，团队成员之间要保持开放和诚实的沟通，及时分享问题和解决方案，共同推动项目的进展。

持续改进

测量指标和方法并不是一成不变的，随着项目的进展和技术的发展，需要不断地对其进行优化和改进。通过对数据的分析和总结，发现存在的问题和不足之处，及时调整测量指标和方法，以提高软件项目的质量和性能。例如，如果发现某个指标的变化趋势异常，需要深入分析原因，采取相应的措施进行改进。

总结

在软件开发和运维的过程中，准确的度量是确保项目成功的关键。通过对MTBF、MTTR、代码复杂度、单元测试覆盖率、提交率、遵守编码规则等指标的测量和分析，可以全面了解软件项目的质量和性能。同时，结合自动化测试、系统监控和实时监控等方法，可以及时发现和解决问题，提高软件的可靠性和稳定性。

在实际应用中，要注意数据的准确性和可靠性、指标的关联性和综合性、团队的协作和沟通以及持续改进。通过不断地优化和完善测量指标和方法，促进开发和运维团队的协作，实现软件项目的高效交付和持续改进。

希望以上内容能够帮助你更好地理解和应用这些测量指标和方法，提升软件开发和运维的水平。如果你在实际操作中遇到任何问题，欢迎随时交流和探讨。