共计 2421 个字符，预计需要花费 7 分钟才能阅读完成。
在研发品质治理中，「进步代码 / 测试品质」更重要，还是「晋升故障响应能力」更重要？
LigaAI 最近和一些敌人探讨了这个问题。一种观点认为晋升研发品质应该从代码品质抓起——擒贼先擒王，从源头缩小故障产生才是基本之道；
另一种声音则指出，生产故障简直不可能通过预防完全避免，因为「未知」是无奈预测的，因而增强监测与反馈机制，疾速辨认、疾速修复才是真正的无效之治。
从治理指标的角度来看，「晋升代码品质」意味着研发团队要尽可能进步 MTBF（均匀无故障工夫），缩短零碎可继续运行工夫，而「晋升响应能力」要求尽可能减少 MTTR（均匀复原工夫），将零碎不可用工夫降到最短以最小化故障影响。
舒适提醒：研发团队该当先全面探讨零碎「服务工夫」「可用工夫」和「不可用工夫」的定义、事件覆盖范围以及故障等级，并在组织外部建设对立的了解，以确保资源和精力花在最重要的事件上。
只管在理论工作中，「进步 MTBF」和「缩小 MTTR」总是齐驱并进，但在不同倒退阶段明确二者的优先级，将有助于研发团队高效专一、对症下药地实现研发效力治理指标。
MTBF 和 MTTR 将如何影响研发效力？咱们先从研发品质治理的三个维度说起。
01 研发品质治理的「RAM」
在治理实际中，咱们罕用「RAM」评估软件交付性能。这里的「RAM」当然不是 Random Access Memory，而是三个用于形容零碎服务质量高下的要害维度——可靠性、可用性和可维护性。
1. 可靠性 Reliability
可靠性是指零碎无故障运行的能力——哪怕呈现软硬件故障、人为谬误等问题，零碎仍能失常提供正确服务而不产生服务中断的概率。
它与故障率、容错率、避错力、冗余度等严密相干。常见的软件可靠性度量指标包含牢靠度、失效率、MTBF 和 MTTF 等等。
2. 可用性 Availability
可用性是指在肯定工夫内，零碎可能继续且正确提供合乎冀望水准的服务而不产生故障和中断的概率，通常用 SLA（Service Level Agreement，服务级别协定）来示意。
零碎可用性（或称可用度）能够用零碎可用工夫占总服务工夫的百分比计算得出，即
3. 可维护性 Maintainability
可维护性蕴含可修复性和可改良性两个方面。前者是指在零碎产生故障后，不同人员高效修复故障，使之恢复正常运行状态的难易水平，而后者示意当需要或环境变动时，零碎承受性能改良或减少新性能的可能性。
可靠性和可用性都能够展现零碎的继续服务能力。区别在于，可用性更加关注零碎服务的总体持续时间，而可靠性侧重于形容零碎的抗故障能力。《分布式系统原理与范型》为辨别可靠性和可用性提供了一个十分直观的例子：
如果零碎在每小时解体 1 ms，那么它的可用性就超过 99.9999%，然而它还是高度不牢靠。与之相似，如果一个零碎从来不解体，然而每年要停机两星期，那么它是高度牢靠的，然而可用性只有 96%。
02 如何确定 MTBF 和 MTTR 的优先级？
对于不同组织或者同一组织的不同倒退阶段，晋升研发品质的无效伎俩很可能截然不同。那么，是否存在某种范式，能够帮忙研发团队迷信精准地确定 MTBF 和 MTTR 的治理优先级？
后面提到，可用性的计算公式可示意为零碎可用工夫占总服务工夫的比重，即 MTBF / (MTBF + MTTR)。简略变形后，便能够取得以下关系式：
① MTBF = 可用性 * MTTR / (1 – 可用性)
② MTTR = MTBF / 可用性 – MTBF
对于已知的 MTBF 或 MTTR 值，研发团队能够联合零碎可用性增长指标，计算出团队故障恢复能力或零碎均匀无故障工夫的所处程度，并理解量化指标的预期增量。
举个例子。已知研发团队复原一个故障的均匀耗时为一个小时，如果零碎每 9 小时呈现一次故障，其可用性就为 90%。如果想将零碎的可用性进步至 99%，那么故障频率应升高至每 99 小时（即 4.13 天）一次。
同样的，对于故障频率为每周一次的零碎而言，如果研发团队能在 1.7 个小时（等价于 102 分钟）内让零碎恢复正常工作，则其可用性便能达到 99%。
依据零碎的故障频率以及研发团队的故障复原程度，管理者能够将可用性晋升指标翻译成 MTBF 或 MTTR 的优化指标，将形象指标具象化，并综合指标实现难度、资源可用状况等明确首要优化对象，精准晋升效力。
03 MTTR vs MTBF，谁更胜一筹？
Chad Fowler 认为，对大多数组织或零碎而言，优化 MTTR 比减少 MTBF 更加无效。DORA 指标同样将 MTTR 视为影响研发效力和软件交付性能的四大要害指标之一。
一部分起因是软件系统不同于物理设施，其故障偶发性强，因此 MTBF 治理的不可控性较高。而复原故障的工作流程清晰，操作步骤明确，可干涉水平高；研发团队能够对各环节开展精细化治理，轻松、高效地达成 MTTR 优化指标。
研发团队能够应用麻利开发方法、自动化监测和预警工具、自动化部署工具、灰度公布、A/B 测试等，缩短 MTTD、MTTA、MTTI、MTTR（Mean Time To Repair）等工夫，以疾速辨认、定位和修复故障，疾速上线。
不仅如此，Sidu Ponnappa 还指出，MTTR 是弥合业务与技术了解鸿沟的要害。它能够帮忙企业更好地了解技术团队与研发工作，还能够帮忙技术领导者识别系统的薄弱环节以及须要关注的对象，是掂量组织弹性、团队构造和整体健康情况的无力指标。想要改良 MTTR，研发团队必须构建正确的常识，改良品质管制实际，并器重内外部的沟通。
LigaAI 总结
可靠性、可用性和可维护性是评估研发品质的三大维度，其中可用性能够用 MTBF / (MTBF + MTTR) 计算得出。
在研发治理实际中，优化 MTTR，进步故障响应能力更具指导意义。研发团队能够联合麻利开发方法、自动化工具等，建设高度自动化的监测、反馈、测试、部署流程，实现高速提效。
LigaAI@SegmentFault 还将分享更多研发效力度量、研发治理实际等干货内容，欢送关注咱们。
LigaAI 助力开发者扬帆远航，点击体验新一代智能研发合作，一起变大变强！