可靠性” 与 “可用性，可靠性实验的必要性
相信点开这篇文章的读者，一定或多或少接触过“高可靠”“高可用”这些字眼，但是往往或语焉不详，或罗列术语（MTBF、MTTR ...），那么我们到底应该如何定量描述系统的可靠性和可用性指标呢，这些看着很上流的术语到底意味着什么呢？也许，看完这篇文章，您从此也可以和小伙伴们愉快地拽术语了！
比如正在运行中的100只硬盘，1年之内出了2次故障，则故障率为0.02次/年。上文提到的关于MTBF和Failure Rate关系值得细细体会，在现实生活中，硬件厂商也的确更热衷于在产品上标注MTBF（个人猜测是因为MTBF往往高达十万小时甚至百万小时，容易吸引眼球）。Failure Rate伴随着产品生命周期会产生变化，因此，只有在前述“浴盆曲线”的平坦底部（通俗点说就是产品的“青壮年时期”）才存在如下关系：一般来说，服务器的主要部件MTBF，厂商标称值都在百万小时以上。比如：主板、CPU、硬盘为100wh，内存为400wh（4根内存约为100wh），从而可以推算出服务器整体MTBF约25wh（约30年），年故障约3%，也就是说，100台服务器每年总要坏那么几台。上面的理论计算看着貌似也没啥问题，感觉还挺靠谱。但如果换个角度想想，总觉得哪里不太对劲：MTBF约30年，难道说可以期望它服役30年？先看看希捷的工程师如何解释比如应用升级或者程序CORE掉，往往借助所谓“秒起”来完成服务恢复，有些更极端的甚至拦截”段错误”一类信号。其实，无论如何秒起，总归会有部分用户受影响，另外，如果是由于程序错误导致的意外重启，谁能保证共享内存的数据仍然处于正确状态呢？此外，如果出现机房搬迁、空调故障、供电故障等意外，所谓的共享内存+秒起也只能干瞪眼。因此，正如上文所说的，通过容灾备份+路由切换实现优雅无缝重启才是好的设计。一般来说，“可重启”进程具备如下特征：
- 不使用生命期大于进程的IPC（共享内存、跨进程的mutex等）
首先将节点从服务列表中摘除，等待节点流量跌零，发起重启过程（更新文件等），确认服务启动正常后，重新将节点添加至服务列表，逐步引流进行正确性验证（若发现异常，及时摘除）。服务节点依次分批处理，真正实现无缝重启服务访问方支持Failover，自动切换备用节点，或者通过Name Service一类设施自动摘除故障节点，人工介入恢复。当然，前面一些看法并非“放之四海而皆准”，在实际设计系统的时候，还是应该因地制宜，选择最适合当时环境的方案。
