可靠性” 与 “可用性，可靠性实验的必要性

来源：东莞市一品仪器设备有限公司 2022年11月16日 09:35

相信点开这篇文章的读者，一定或多或少接触过“高可靠”“高可用”这些字眼，但是往往或语焉不详，或罗列术语（MTBF、MTTR ...），那么我们到底应该如何定量描述系统的可靠性和可用性指标呢，这些看着很上流的术语到底意味着什么呢？也许，看完这篇文章，您从此也可以和小伙伴们愉快地拽术语了！

1) 软件过程（代码评审、单元测试等）

2) 软件复杂度

3) 软件规模

4) 开发团队经验

5) 可复用代码比例（久经考验的代码）

6) 产品交付前的测试

比如正在运行中的100只硬盘，1年之内出了2次故障，则故障率为0.02次/年。

上文提到的关于MTBF和Failure Rate关系值得细细体会，在现实生活中，硬件厂商也的确更热衷于在产品上标注MTBF（个人猜测是因为MTBF往往高达十万小时甚至百万小时，容易吸引眼球）。Failure Rate伴随着产品生命周期会产生变化，因此，只有在前述“浴盆曲线”的平坦底部（通俗点说就是产品的“青壮年时期”）才存在如下关系：

MTBF = 1/λ

一般来说，服务器的主要部件MTBF，厂商标称值都在百万小时以上。比如：主板、CPU、硬盘为100wh，内存为400wh（4根内存约为100wh），从而可以推算出服务器整体MTBF约25wh（约30年），年故障约3%，也就是说，100台服务器每年总要坏那么几台。

上面的理论计算看着貌似也没啥问题，感觉还挺靠谱。但如果换个角度想想，总觉得哪里不太对劲：MTBF约30年，难道说可以期望它服役30年？先看看希捷的工程师如何解释

比如应用升级或者程序CORE掉，往往借助所谓“秒起”来完成服务恢复，有些更的甚至拦截”段错误”一类信号。其实，无论如何秒起，总归会有部分用户受影响，另外，如果是由于程序错误导致的意外重启，谁能保证共享内存的数据仍然处于正确状态呢？

此外，如果出现机房搬迁、空调故障、供电故障等意外，所谓的共享内存+秒起也只能干瞪眼。

因此，正如上文所说的，通过容灾备份+路由切换实现优雅无缝重启才是好的设计。一般来说，“可重启”进程具备如下特征：

无论exit还是kill，都可以正确重启
不使用生命期大于进程的IPC（共享内存、跨进程的mutex等）
不使用难以重建的IPC（父子进程共享FD通信等）

那么又该如何优雅重启呢？一般分为两种场景：

有计划的重启（如版本升级）

首先将节点从服务列表中摘除，等待节点流量跌零，发起重启过程（更新文件等），确认服务启动正常后，重新将节点添加至服务列表，逐步引流进行正确性验证（若发现异常，及时摘除）。服务节点依次分批处理，真正实现无缝重启

意外故障发生

服务访问方支持Failover，自动切换备用节点，或者通过Name Service一类设施自动摘除故障节点，人工介入恢复。

当然，前面一些看法并非“放之四海而皆准”，在实际设计系统的时候，还是应该因地制宜，选择当时环境的方案。

免责声明

凡本网注明“来源：仪表网”的所有作品，均为浙江兴旺宝明通网络有限公司-仪表网合法拥有版权或有权使用的作品，未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的，应在授权范围内使用，并注明“来源：仪表网”。违反上述声明者，本网将追究其相关法律责任。
本网转载并注明自其它来源（非仪表网）的作品，目的在于传递更多信息，并不代表本网赞同其观点或和对其真实性负责，不承担此类作品侵权行为的直接责任及连带责任。其他媒体、网站或个人从本网转载时，必须保留本网注明的作品第一来源，并自负版权等法律责任。
如涉及作品内容、版权等问题，请在作品发表之日起一周内与本网联系，否则视为放弃相关权利。