少年，MTBF 和 MTTR 了解下！
pshu 最近接了两个新项目，每个都是采用接锅的姿势。接的过程有痛苦，也有收货，这里和大家分享下自己的思考。
什么是 MTBF 和 MTTR
先上两个概念，MTBF ：Mean Time Between Fail，粗暴的翻译下，平均出错间隔。拿软件来举例，MTBF 就是出 bug 的平均时间间隔；MTBF 越大，说明你的软件的质量越好，因为很久才出一个 bug。再来第二个概念，MTTR：Mean Time To Repair, 平均修复的时间。这个在软件行业最好理解，出了一个 bug 平均的修复时间，这个值越小越好，侧面也体现了软件的质量好。小结下: 一个产品它的 MTBF 越大越好，MTTR 越小越好。
那接盘了一个新项目，想让项目好好的过渡下去，自然是想办法来提高 MTBF，减少 MTTR。但是如果项目时间紧急，项目管理者要求又快又好，你该如何选择？我们从另外的一个角度可用性 availability 来看这个问题。软件的可用性是指正常提供服务的时间和总运行时间的比例，我们常说的 “5 个 9 ”，就是可用性 99.999%，折算成具体时间就是一年服务的故障时间要小于 5 分半 （365 * 24 * 60 * (1-0.99999)=5.25）。结合 MTBF 和 MTTR 这两个概念的话，可用性可以写成如下的公式。
通过这个公式，我们代入一些参数，可以做出下面两个表。
| AVAIL/MTTR | 1h | 4h | 24h |
|---|---|---|---|
| 90% | 9h | 1d12h | 9d |
| 95 % | 19h | 3d4h | 19d |
| 99 % | 4d3h | 2w | 3.5mo |
| 99.9 % | 6w | 6mo | 2.8y |
| 99.99 % | 1y10d | 4.5y | 28y |
| 99.999 % | 11.5y | 45y | 280y |
这个表的意思是，MTTR 为 1 小时，4 小时和 24 小时，为达到对应的可用性需要的 MTBF。例如当 MTTR 为 1 小时，可用性要求为 90%时，MTBF 需要达到 9 小时; 在这种条件下, 即使每 9 个小时出一个 bug 也能满足服务要求（SLA：service level agreement）。
| AVAIL/MTBF | 7d | 1mo | 3mo | 6mo |
|---|---|---|---|---|
| 90 % | 19h | 3d | 1w2d | 2w6d |
| 95 % | 9h | 1d12h | 4d10h | 1w2d |
| 99 % | 1.5h | 7h | 20h | 1d 20h |
| 99.9 % | 10m | 40m | 2h | 4.5h |
| 99.99 % | 1m | 4m | 12m | 26m |
| 99.999 % | 7s | 24s | 1m | 2m |
再看这个表，即使我们做到了 MTBF 是一个月，要满足 4 个 9 的可用性要求，来了一个 bug 需要在 4 分钟就修复。可能吗，如果是你新接手的项目可能吗？
可以看到在一般情况下，在资源有限的情况下，我们尽快的减小 MTTR 是比较合理选择，因为 MTTR 的改善会在 MTBF 上有放大作用。那面对新接手的项目你如何快速的减小 MTTR 呢？
建立监控，少量发布，快速回滚
建立监控体系的目的就是第一时间知道项目出错了。第一时间知道项目出错有什么好处呢？你可以尽快的做一个 quick fix。最简单的就是回滚 roll back 咯。但是如果你有灰度发布系统，第一时间停止灰度就安全了，业务的影响面也非常的小。
而在实际的工程实践中建立一套监控体系相对于建立一套完整的测试会容易的多。日志方面有完整的 ELK（Elasticsearch, Logstash, Kibana），性能方面有各种免费收费的 APM（Application Performance Management），错误收集也有 Sentry 这样的社区免费解决方案。
绕不开的 MTBF
建立一套这样的监控体系，自然是你接手项目的第一步。可是如果在实践的过程中你三天两头就回滚回滚，项目需要的功能迟迟上不去，项目管理自然就会天天催着你了。那这个时候我们就需要重新回头来看看 MTBF 了。
那如何提高项目的 MTBF 呢？pshu 作为 TDD 和单元测试的爱好者，自然就是求助单元测试，给接手的项目增加原本缺失的测试；如果项目原来就有完备的测试那是再好不过的事情了。可是现实总是有点偏差的，pshu 最近接手的那两个项目没有任何测试，完全没有质量保证体系。再回忆下更久以前接手的项目，有些确实写了一些单元测试，但是测试的内容太过 trivial (来来来：记个单词，trivial 琐碎的，不重要的)，都是些类似 expect(1+1).to.equal(2) 的测试用例，这样的测试对提高产品质量，验证业务逻辑方面的作用几乎是没有。
单元测试（包括其他层面的测试）能给我们带来质量保证。而团队的现实情况更多的是
开发的同学根本就不认同开发还需要写测试
开发的认同测试的重要性，可惜测试用例写的不好，对项目的保护作用很小。
不管是上述的那种情况，想通过测试来保证质量就需要付出大量的时间。让团队认同测试需要时间做观念上的转变；让团队写出坚实的测试用例更需要大量的实践和踩坑。一个需要长时间才能出结果的方案，项目的 owner 肯定会有迟疑要不要采纳，就会因为产出的延迟而放弃提高 MTBF 的目标。
那如何让 MTBF 继续在项目实践中发挥作用呢？我们先来分析下构建一套完善的测试用例的困难在哪里。需要时间投入的这个困难真的没有太多的方法。种一棵树的最好时间是 10 年前和现在，写测试用例也是一样。在实践中最大的困难在于，写出各种场景的测试用例。如果测试测试覆盖所有的业务场景，那自然 MTBF 就是无穷大了；当然这个假设不是可能的。那针对新项目的话，短时间也不可能积累大量的测试用例，首先时间也不允许，最重要的是业务也不理解。困难总是有的，那怎么破呢？
结合减少 MTTR 时完善的监控系统，在每次回滚的时候我就会得到一个真实的场景，那个场景是测试用例非常好的输入。通过这样真实的例子，我们知道业务上期望的行为，目前错误的行为还有引起这部分错误代码的大致范围。这样明确的输入转化成的测试用例对质量的保证就能为了下一次发布提高 MTBF。
总结
接盘一个项目，总是有些被勉强的地方。但是为了项目的正常运营，我们也必须让项目尽快进入到自己的控制范围之内。定下可用性的目标，通过建立监控和回滚高效的利用 MTTR，同时利用线上的真实例子来丰富测试用例，逐步保障项目质量，提高 MTBF。总之两条腿走路，虽然要分先后但是最终的目的是为了走起来。
-EOF-
欢迎大家,转发,评论和点赞~