?可靠性” 與 “可用性，可靠性實驗的必要性
相信點開這篇文章的讀者，一定或多或少接觸過“高可靠”“高可用”這些字眼，但是往往或語焉不詳，或羅列術語（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一類設施自動摘除故障節點，人工介入恢復。當然，前面一些看法并非“放之四海而皆準”，在實際設計系統的時候，還是應該因地制宜，選擇最適合當時環境的方案。?
