IT公司经验研发质量度量
2010-11-22 10:33:48 
阿炯
9 个研发质量度量指标
研发质量管理中的 MTTR、MTBF、MTTF、MTTD 都是什么？这里从生产事件的全生命周期出发，认识研发质量管理的 9 个度量指标 ——「MT 家族」。
1、Mean Time To ALL
「MT」是 Mean Time 的缩写，意为平均时间，「MT 家族」则是 LigaAI 对「MT」开头的一系列量化指标的戏称。
最常用于跟踪研发质量的两个 MT 指标分别是 MTTR 和 MTBF。近几年，随着精细化研发管理需求的攀升，行业也出现了 MTTD、MTTA、MTRS、MTTI 等细分管理指标，旨在帮助技术团队更好地了解生产事件发生的频率以及团队的恢复速度。
2、共识在前，度量在后
在使用「MT 家族」度量质量水平之前，研发团队需要先就两个基础问题达成共识。
如何计算系统的总服务时长？
如何定义系统的可用时间（Uptime）和不可用时间（Downtime）？
明确第一个问题有助于规范讨论对象。系统的服务周期是多长？系统维护升级或提前告知的主动停机等特殊事件应否计入服务时长？研发团队应就以上问题达成一致，才能辅助更准确的度量和管理。
讨论第二个问题的意义在于建立内部一致的判断标准。什么样的事件属于完全中断事件？在部分中断事件中，多大程度的阻碍或多大影响范围的故障可以被定义为「系统不可用」？可正常运行但不符合预期水平的系统是否处在可用状态？
如果能将事件的具体量值和标准讨论并确定下来，研发效能管理或许会有一个更加清晰的视图。
03「MT 家族」全员辨析
下面是单个生产事件从故障发生到修复完成的简要示意图，根据起止时间点的不同，将获得若干个 MT 指标。
温馨提示：研发效能管理下的「MT 指标」或与其他领域的定义有所不同。
1.Mean Time To Detect（MTTD）
平均故障检测时间（MTTD）是系统出现故障到问题首次被发现的平均时间，用来衡量问题在被发现前存在的平均时长，可以用一定周期内的事件总检测时间除以事件总个数计算得出。
系统出现故障后，生产事件可能会被监控工具或观测平台快速识别并自动提醒，也可能被用户率先发现。因此，对问题识别得越慢，MTTD 越大，用户可能遭受中断的时间也会越长。
2.Mean Time To Acknowledge（MTTA）
平均应答时间（MTTA）衡量了系统不可用被首次发现后，研发团队平均需要多久能够着手修复问题，反映了团队的响应能力和警报系统的效率。定期监控 MTTA 对减少警报噪音，提高工作效率也有显著作用，因为居高不下的 MTTA 可能说明研发团队正在被「警报疲劳」所困扰。
MTTA = 故障首次被发现到开始修复的总间隔时间/事件总数。
3.Mean Time To Repair（MTTR）
根据「R」的不同释义，MTTR 可以表示为平均修复时间、平均恢复时间、平均响应时间和平均解决时间。四者在含义上皆有不同，因此在日常工作和沟通中，要小心上下文缺失导致的「鸡同鸭讲」哦！
平均修复时间衡量了研发团队排除和修复故障的效率，是指开发团队从开始修复到系统恢复正常运行的平均时间，包含修复、测试、部署等多个环节。可以用一定周期内的系统总修复时长除以事件总个数得出。MTTR 越小，说明系统的可维护性越强，易恢复性越好。此外，由于系统复杂情况或故障严重程度各不相同，技术管理者在实际管理中也要避免掉入「数字管理陷阱」。
MTTR = 开始修复到恢复可用状态的总间隔时间/事件总数。
4.Mean Time To Recover（MTTR）
平均恢复时间也称平均服务恢复时长（Mean Time To Restore Service, 即 MTRS），也是 DORA 指标中的「服务恢复时间」。
它衡量了系统从不可用状态恢复到正常可用状态的平均耗时，在数值上与系统的平均不可用时长相等，包含研发团队监控、定位、识别和解决故障等多个过程。经验法则指出，优秀的研发团队每年的平均恢复时间一般不超过 5 个小时。
MTTR 或 MTRS = 系统总不可用时间/事件总数。
5.Mean TimeTo Respond（MTTR）
平均响应时间是指系统不可用状态从被发现到被解决的平均时间，反映了研发团队响应需求和变化的效率以及系统可维护性的高低。平均响应时间不考虑事件通知的延迟性，常在网络安全中用来衡量团队缓解系统攻击的效率。
MTTR = 故障被发现到系统恢复可用的总间隔时间/事件总数。
6.Mean Time To Resolve（MTTR）
平均解决时间衡量了故障出现到被彻底解决所花费的平均时间。「彻底解决」意味着该故障在未来的运行中不会再现，因此平均解决时间需要统计研发团队发现问题、检测故障、修复故障以及确保故障不会再发生等环节的总时间。
MTTR = 故障出现到彻底解决的总间隔时间/事件总数。
7.Mean Time Between Failure（MTBF）
平均无故障时间（MTBF）是衡量系统可靠性和可用性的关键指标之一，指可修复系统在运行期间从前一个故障（结束）到下一个故障（出现）所经历的平均时间，代表了系统的平均可用时间。
MTBF 越大，说明系统持续提供正确服务的时间越长，可靠性越强。通过计算一定周期内的 MTBF，研发团队还可以对未来故障的发生时间展开预测，以便更好地管理。
MTBF = 连续两次事件的总间隔时间/事件总数。
8. Mean Time To Failure（MTTF）
与 MTBF 相似，平均失效时间（MTTF）也是衡量系统可靠性的关键指标；二者的区别在于，MTTF 用于衡量不可修复的系统，而 MTBF 的管理对象是可修复的系统。
MTTF 是指不可修复的系统或产品从开始运行到发生故障而终止服务的平均时间，可以简单理解为平均使用寿命。相比软件研发行业，MTTF 更常用来描述硬件、组件或基础设施等等。
其管理价值在于通过对大量相同类型的系统或产品进行更长周期的观察和统计，团队可以了解该类型系统/产品的失效时间，并率先为淘汰和更换旧系统/产品做好准备。
小结
速率、质量和价值是研发效能管理的三驾马车。而相较速率而言，研发质量管理对团队共识的要求更高，因为我们需要通过集思广益，描绘一个线条干净、指标区隔清晰的质量评估视图，以进一步支持无歧义的指标量化管理；否则，研发效能管理最终又会回到让人头疼的「定义讨论会」。所提到的 9 个「MT 指标」可以从系统可靠性、可用性和可维护性等多个维度，衡量研发质量水平并辅助技术管理者展开更精确、更精准的研发质量监控和管理，进而有效提升组织效能，赋能业务增长。
高级开发人员要了解的高并发性能指标
QPS
QPS(Queries Per Second)即每秒查询率，是指一台服务器每秒钟能够支持的查询操作次数，为什么要定义这样一个标准呢？这个标准可以用来衡量服务器在规定的时间内的流量处理能力，而这里的流量其实就是指系统能够支持用户请求访问。在互联网环境下，QPS经常被用来定义域名服务器的机器性能，通俗来讲就是系统能够处理用户请求的能力。
TPS
TPS(Transaction Per Second)即每秒处理事务率，也就是每秒能够处理事务的个数。它是测试应用软件性能的标准之一。所谓的事务，其实就是指计算机所要完成的业务操作，例如转账、添加订单、扣减库存等等。也就是说当用户向服务器发送请求之后，服务器做出反应并且反馈到用户的整个过程，其实就可以被称为是一个事务操作。通过对TPS的统计可以有效的反映出业务系统处理事务的能力。
其实当我们的业务系统在处理用户请求的时候，QPS与TPS应该是相当的，也就是有多少个用户请求，就有多少个用户业务处理。但是有所不同的是，当用户点击了下单按钮之后，在用户看来只是单纯的下单也就是一个TPS操作，但是对于后台处理来说的话就有可能会调用订单系统、调用库存系统、调用其他一些业务判断系统例如减扣、优惠券等等。而这些处理就可以计入到QPS中。也就是说一个TPS中有可能会包含多个QPS。
RT
RT(Response Time)即响应时间，所谓的响应时间其实就是用户从发出一个请求到接受到请求响应的总时长。也就是说用户在浏览器中请求了一个商品详情信息，经历多少时间之后这个商品信息才渲染到用户页面上。这个指标主要用来反应系统的快慢，如果响应时间小的话，就说明系统反应较快，反之，则表示系统中存在了耗时操作，这个时候就需要对系统性能进行优化了。
并发数
并发数其实对大家来说是不是一个陌生的概念，并发数是指系统在同一时间能够处理多少个请求。侧面反映的就是系统的负载能力，举个简单的例子，很多人可能都经历过春运，我们知道在春运期间，火车站不但挤满了人，而且还挤满了火车，如果将火车站看做一个能够处理火车停靠的应用的话，并发数就相当于车站能够用来停靠火车的站台有多少，也就是说同时能够允许多少列火车停靠。这也就是这个车站最大的能够负载的能力。超过这个负载能力肯定火车是没地方停靠的。软件系统并发数的概念与之类似，如果超过了并发数，系统肯定会崩溃的。
吞吐量
系统的吞吐量是用来反映系统能够承载多少的用户请求压力。与用户请求、CPU处理能力、IO操作等等都有关系。简单的举个例子，在春运期间，一个车站的吞吐量就是指这个车站能够收发多少人员。如果我们将一个旅客看做一个用户请求的话，能够体现其吞吐量的因素应该有如下的几个：
1、能够处理请求的效率，也就是上面提到的QPS。
2、同时能够处理多少的请求，也就是上面提到的并发数。
3、就是系统的处理时间，也就是上面提到的响应时间。
这三个因素应该是共同影响这个系统的吞吐量的因素。如果是一个系统的QPS是100的话，也就是说它一秒之内能够处理100个请求。就可以理解为这个系统的并发数就是100。也就是说如果一个系统在一分钟之内处理了6000个请求，那么它一秒钟所处理的请求数就是100个。根据这个关系，我们就可以明确的感觉到系统吞吐量其实就是系统的整体性能的体现，包含了QPS、TPS、RT等一系列的参数。
PV
PV(Page Views)一般是指页面访问量，包含了用户对应用系统任意页面的访问量。例如当浏览了一个商品详情页的时候，就可以被记为一次PV。
线程数
线程数，也可以理解为并发数，也可以理解为QPS数，为什么这么说呢？了解Request请求原理，或者是了解过I/O模型的可能都清楚，我们的线程是不可能一直被无限创建的，并且一个系统所能创建的线程数是有限制的，超过限制就会导致系统异常。这里我们为什么说可以理解为QPS也可以理解为并发数呢？是因为当用户请求发送到服务器之后，会有一个线程来处理相应的请求。在多线程场景中，影响并发、影响QPS就是线程数的多少，在可控范围内一个系统所能创建的线程越多，就说明系统处理能力就越强。
简单的例子，当春运的时候我们的购票窗口往往都是排着长队的，那么这个时候，我们需要增加购票窗口，增加窗口之后，明显就感觉到买票的时间会缩短，并且窗口越多服务能力就越强。但凡事都有个限度，当我们超过了限度之后，就会适得其反。当然系统也是一样的。
有了上面的参数分析，我们可以得到如下的几个结论。
QPS/TPS = 并发数/RT
并发数=QPS*RT
QPS=PV/总时间
根据这些公式，结合上面的理论支持，就可以有效的进行计算机资源的分配，也可以根据上面的这些参数，来计算出系统的整体综合性能了。
研发质量管理中的 MTTR、MTBF、MTTF、MTTD 都是什么？这里从生产事件的全生命周期出发，认识研发质量管理的 9 个度量指标 ——「MT 家族」。
1、Mean Time To ALL
「MT」是 Mean Time 的缩写，意为平均时间，「MT 家族」则是 LigaAI 对「MT」开头的一系列量化指标的戏称。
最常用于跟踪研发质量的两个 MT 指标分别是 MTTR 和 MTBF。近几年，随着精细化研发管理需求的攀升，行业也出现了 MTTD、MTTA、MTRS、MTTI 等细分管理指标，旨在帮助技术团队更好地了解生产事件发生的频率以及团队的恢复速度。
2、共识在前，度量在后
在使用「MT 家族」度量质量水平之前，研发团队需要先就两个基础问题达成共识。
如何计算系统的总服务时长？
如何定义系统的可用时间（Uptime）和不可用时间（Downtime）？
明确第一个问题有助于规范讨论对象。系统的服务周期是多长？系统维护升级或提前告知的主动停机等特殊事件应否计入服务时长？研发团队应就以上问题达成一致，才能辅助更准确的度量和管理。
讨论第二个问题的意义在于建立内部一致的判断标准。什么样的事件属于完全中断事件？在部分中断事件中，多大程度的阻碍或多大影响范围的故障可以被定义为「系统不可用」？可正常运行但不符合预期水平的系统是否处在可用状态？
如果能将事件的具体量值和标准讨论并确定下来，研发效能管理或许会有一个更加清晰的视图。
03「MT 家族」全员辨析
下面是单个生产事件从故障发生到修复完成的简要示意图，根据起止时间点的不同，将获得若干个 MT 指标。
温馨提示：研发效能管理下的「MT 指标」或与其他领域的定义有所不同。
1.Mean Time To Detect（MTTD）
平均故障检测时间（MTTD）是系统出现故障到问题首次被发现的平均时间，用来衡量问题在被发现前存在的平均时长，可以用一定周期内的事件总检测时间除以事件总个数计算得出。
系统出现故障后，生产事件可能会被监控工具或观测平台快速识别并自动提醒，也可能被用户率先发现。因此，对问题识别得越慢，MTTD 越大，用户可能遭受中断的时间也会越长。
2.Mean Time To Acknowledge（MTTA）
平均应答时间（MTTA）衡量了系统不可用被首次发现后，研发团队平均需要多久能够着手修复问题，反映了团队的响应能力和警报系统的效率。定期监控 MTTA 对减少警报噪音，提高工作效率也有显著作用，因为居高不下的 MTTA 可能说明研发团队正在被「警报疲劳」所困扰。
MTTA = 故障首次被发现到开始修复的总间隔时间/事件总数。
3.Mean Time To Repair（MTTR）
根据「R」的不同释义，MTTR 可以表示为平均修复时间、平均恢复时间、平均响应时间和平均解决时间。四者在含义上皆有不同，因此在日常工作和沟通中，要小心上下文缺失导致的「鸡同鸭讲」哦！
平均修复时间衡量了研发团队排除和修复故障的效率，是指开发团队从开始修复到系统恢复正常运行的平均时间，包含修复、测试、部署等多个环节。可以用一定周期内的系统总修复时长除以事件总个数得出。MTTR 越小，说明系统的可维护性越强，易恢复性越好。此外，由于系统复杂情况或故障严重程度各不相同，技术管理者在实际管理中也要避免掉入「数字管理陷阱」。
MTTR = 开始修复到恢复可用状态的总间隔时间/事件总数。
4.Mean Time To Recover（MTTR）
平均恢复时间也称平均服务恢复时长（Mean Time To Restore Service, 即 MTRS），也是 DORA 指标中的「服务恢复时间」。
它衡量了系统从不可用状态恢复到正常可用状态的平均耗时，在数值上与系统的平均不可用时长相等，包含研发团队监控、定位、识别和解决故障等多个过程。经验法则指出，优秀的研发团队每年的平均恢复时间一般不超过 5 个小时。
MTTR 或 MTRS = 系统总不可用时间/事件总数。
5.Mean TimeTo Respond（MTTR）
平均响应时间是指系统不可用状态从被发现到被解决的平均时间，反映了研发团队响应需求和变化的效率以及系统可维护性的高低。平均响应时间不考虑事件通知的延迟性，常在网络安全中用来衡量团队缓解系统攻击的效率。
MTTR = 故障被发现到系统恢复可用的总间隔时间/事件总数。
6.Mean Time To Resolve（MTTR）
平均解决时间衡量了故障出现到被彻底解决所花费的平均时间。「彻底解决」意味着该故障在未来的运行中不会再现，因此平均解决时间需要统计研发团队发现问题、检测故障、修复故障以及确保故障不会再发生等环节的总时间。
MTTR = 故障出现到彻底解决的总间隔时间/事件总数。
7.Mean Time Between Failure（MTBF）
平均无故障时间（MTBF）是衡量系统可靠性和可用性的关键指标之一，指可修复系统在运行期间从前一个故障（结束）到下一个故障（出现）所经历的平均时间，代表了系统的平均可用时间。
MTBF 越大，说明系统持续提供正确服务的时间越长，可靠性越强。通过计算一定周期内的 MTBF，研发团队还可以对未来故障的发生时间展开预测，以便更好地管理。
MTBF = 连续两次事件的总间隔时间/事件总数。
8. Mean Time To Failure（MTTF）
与 MTBF 相似，平均失效时间（MTTF）也是衡量系统可靠性的关键指标；二者的区别在于，MTTF 用于衡量不可修复的系统，而 MTBF 的管理对象是可修复的系统。
MTTF 是指不可修复的系统或产品从开始运行到发生故障而终止服务的平均时间，可以简单理解为平均使用寿命。相比软件研发行业，MTTF 更常用来描述硬件、组件或基础设施等等。
其管理价值在于通过对大量相同类型的系统或产品进行更长周期的观察和统计，团队可以了解该类型系统/产品的失效时间，并率先为淘汰和更换旧系统/产品做好准备。
小结
速率、质量和价值是研发效能管理的三驾马车。而相较速率而言，研发质量管理对团队共识的要求更高，因为我们需要通过集思广益，描绘一个线条干净、指标区隔清晰的质量评估视图，以进一步支持无歧义的指标量化管理；否则，研发效能管理最终又会回到让人头疼的「定义讨论会」。所提到的 9 个「MT 指标」可以从系统可靠性、可用性和可维护性等多个维度，衡量研发质量水平并辅助技术管理者展开更精确、更精准的研发质量监控和管理，进而有效提升组织效能，赋能业务增长。
高级开发人员要了解的高并发性能指标
QPS
QPS(Queries Per Second)即每秒查询率，是指一台服务器每秒钟能够支持的查询操作次数，为什么要定义这样一个标准呢？这个标准可以用来衡量服务器在规定的时间内的流量处理能力，而这里的流量其实就是指系统能够支持用户请求访问。在互联网环境下，QPS经常被用来定义域名服务器的机器性能，通俗来讲就是系统能够处理用户请求的能力。
TPS
TPS(Transaction Per Second)即每秒处理事务率，也就是每秒能够处理事务的个数。它是测试应用软件性能的标准之一。所谓的事务，其实就是指计算机所要完成的业务操作，例如转账、添加订单、扣减库存等等。也就是说当用户向服务器发送请求之后，服务器做出反应并且反馈到用户的整个过程，其实就可以被称为是一个事务操作。通过对TPS的统计可以有效的反映出业务系统处理事务的能力。
其实当我们的业务系统在处理用户请求的时候，QPS与TPS应该是相当的，也就是有多少个用户请求，就有多少个用户业务处理。但是有所不同的是，当用户点击了下单按钮之后，在用户看来只是单纯的下单也就是一个TPS操作，但是对于后台处理来说的话就有可能会调用订单系统、调用库存系统、调用其他一些业务判断系统例如减扣、优惠券等等。而这些处理就可以计入到QPS中。也就是说一个TPS中有可能会包含多个QPS。
RT
RT(Response Time)即响应时间，所谓的响应时间其实就是用户从发出一个请求到接受到请求响应的总时长。也就是说用户在浏览器中请求了一个商品详情信息，经历多少时间之后这个商品信息才渲染到用户页面上。这个指标主要用来反应系统的快慢，如果响应时间小的话，就说明系统反应较快，反之，则表示系统中存在了耗时操作，这个时候就需要对系统性能进行优化了。
并发数
并发数其实对大家来说是不是一个陌生的概念，并发数是指系统在同一时间能够处理多少个请求。侧面反映的就是系统的负载能力，举个简单的例子，很多人可能都经历过春运，我们知道在春运期间，火车站不但挤满了人，而且还挤满了火车，如果将火车站看做一个能够处理火车停靠的应用的话，并发数就相当于车站能够用来停靠火车的站台有多少，也就是说同时能够允许多少列火车停靠。这也就是这个车站最大的能够负载的能力。超过这个负载能力肯定火车是没地方停靠的。软件系统并发数的概念与之类似，如果超过了并发数，系统肯定会崩溃的。
吞吐量
系统的吞吐量是用来反映系统能够承载多少的用户请求压力。与用户请求、CPU处理能力、IO操作等等都有关系。简单的举个例子，在春运期间，一个车站的吞吐量就是指这个车站能够收发多少人员。如果我们将一个旅客看做一个用户请求的话，能够体现其吞吐量的因素应该有如下的几个：
1、能够处理请求的效率，也就是上面提到的QPS。
2、同时能够处理多少的请求，也就是上面提到的并发数。
3、就是系统的处理时间，也就是上面提到的响应时间。
这三个因素应该是共同影响这个系统的吞吐量的因素。如果是一个系统的QPS是100的话，也就是说它一秒之内能够处理100个请求。就可以理解为这个系统的并发数就是100。也就是说如果一个系统在一分钟之内处理了6000个请求，那么它一秒钟所处理的请求数就是100个。根据这个关系，我们就可以明确的感觉到系统吞吐量其实就是系统的整体性能的体现，包含了QPS、TPS、RT等一系列的参数。
PV
PV(Page Views)一般是指页面访问量，包含了用户对应用系统任意页面的访问量。例如当浏览了一个商品详情页的时候，就可以被记为一次PV。
线程数
线程数，也可以理解为并发数，也可以理解为QPS数，为什么这么说呢？了解Request请求原理，或者是了解过I/O模型的可能都清楚，我们的线程是不可能一直被无限创建的，并且一个系统所能创建的线程数是有限制的，超过限制就会导致系统异常。这里我们为什么说可以理解为QPS也可以理解为并发数呢？是因为当用户请求发送到服务器之后，会有一个线程来处理相应的请求。在多线程场景中，影响并发、影响QPS就是线程数的多少，在可控范围内一个系统所能创建的线程越多，就说明系统处理能力就越强。
简单的例子，当春运的时候我们的购票窗口往往都是排着长队的，那么这个时候，我们需要增加购票窗口，增加窗口之后，明显就感觉到买票的时间会缩短，并且窗口越多服务能力就越强。但凡事都有个限度，当我们超过了限度之后，就会适得其反。当然系统也是一样的。
有了上面的参数分析，我们可以得到如下的几个结论。
QPS/TPS = 并发数/RT
并发数=QPS*RT
QPS=PV/总时间
根据这些公式，结合上面的理论支持，就可以有效的进行计算机资源的分配，也可以根据上面的这些参数，来计算出系统的整体综合性能了。
该文章最后由 阿炯 于 2023-09-09 20:54:33 更新，目前是第 4 版。