快速溫變濕熱試驗箱分布式系統的可靠性指的是什么？

快速溫變濕熱試驗箱 技術規格：

 人們對于一個東西是否可靠，都有一個直觀的想法。人們對可靠軟件的典型期望包括：

 •應用程序表現出用戶所期望的功能。

•允許用戶犯錯，允許用戶以出乎意料的方式使用軟件。

•在預期的負載和數據量下，性能滿足要求。

•系統能防止未經授權的訪問和濫用。

如果所有這些在一起意味著“正確工作”，那么可以把可靠性粗略理解為“即使出現問題，也能繼續正確工作”。

造成錯誤的原因叫做故障（fault），能預料并應對故障的系統特性可稱為容錯（fault-tolerant）或韌性（resilient）。“容錯”一詞可能會產生誤導，因為它暗示著系統可以容忍所有可能的錯誤，但在實際中這是不可能的。比方說，如果整個地球（及其上的所有服務器）都被黑洞吞噬了，想要容忍這種錯誤，需要把網絡托管到太空中——這種預算能不能批準就祝你好運了。所以在討論容錯時，只有談論特定類型的錯誤才有意義。

注意故障（fault）不同于失效（failure）。故障通常定義為系統的一部分狀態偏離其標準，而失效則是系統作為一個整體停止向用戶提供服務。故障的概率不可能降到零，因此*好設計容錯機制以防因故障而導致失效。本書中我們將介紹幾種用不可靠的部件構建可靠系統的技術。

反直覺的是，在這類容錯系統中，通過故意觸發來提高故障率是有意義的，例如：在沒有警告的情況下隨機地殺死單個進程。許多高危漏洞實際上是由糟糕的錯誤處理導致的，因此我們可以通過故意引發故障來確保容錯機制不斷運行并接受考驗，從而提高故障自然發生時系統能正確處理的信心。Netflix公司的Chaos Monkey 就是這種方法的一個例子。

盡管比起阻止錯誤（prevent error），我們通常更傾向于容忍錯誤。但也有預防勝于**的情況（比如不存在**方法時）。安全問題就屬于這種情況。例如，如果攻擊者破壞了系統，并獲取了敏感數據，這種事是撤銷不了的。但本書主要討論的是可以恢復的故障種類，正如下面幾節所述。

硬件故障

當想到系統失效的原因時，硬件故障（hardware faults）總會**個進入腦海。硬盤崩潰、內存出錯、機房斷電、有人拔錯網線……任何與大型數據中心打過交道的人都會告訴你：一旦你擁有很多機器，這些事情總會發生！

據報道稱，硬盤的平均*時間（MTTF, mean time to failure）約為10到50年。因此從數學期望上講，在擁有10000個磁盤的存儲集群上，平均每天會有1個磁盤出故障。

為了減少系統的故障率，**反應通常都是增加單個硬件的冗余度，例如：磁盤可以組建RAID，服務器可能有雙路電源和熱插拔CPU，數據中心可能有電池和柴油發電機作為后備電源，某個組件掛掉時冗余組件可以立刻接管。這種方法雖然不能*防止由硬件問題導致的系統失效，但它簡單易懂，通常也足以讓機器不間斷運行很多年。

直到*近，硬件冗余對于大多數應用來說已經足夠了，它使單臺機器*失效變得相當罕見。只要你能快速地把備份恢復到新機器上，故障停機時間對大多數應用而言都算不上災難性的。只有少量高可用性至關重要的應用才會要求有多套硬件冗余。

但是隨著數據量和應用計算需求的增加，越來越多的應用開始大量使用機器，這會相應地增加硬件故障率。此外在一些云平臺（如亞馬遜網絡服務（AWS, Amazon Web Services））中，虛擬機實例不可用卻沒有任何警告也是很常見的，因為云平臺的設計就是優先考慮靈活性（flexibility）和彈性（elasticity），而不是單機可靠性。

如果在硬件冗余的基礎上進一步引入軟件容錯機制，那么系統在容忍整個（單臺）機器故障的道路上就更進一步了。這樣的系統也有運維上的便利，例如：如果需要重啟機器（例如應用操作系統安全補丁），單服務器系統就需要計劃停機。而允許機器失效的系統則可以一次修復一個節點，無需整個系統停機。

軟件錯誤

我們通常認為硬件故障是隨機的、相互獨立的：一臺機器的磁盤失效并不意味著另一臺機器的磁盤也會失效。大量硬件組件不可能同時發生故障，除非它們存在比較弱的相關性（同樣的原因導致關聯性錯誤，例如服務器機架的溫度）。

另一類錯誤是內部的系統性錯誤（systematic error）。這類錯誤難以預料，而且因為是跨節點相關的，所以比起不相關的硬件故障往往可能造成更多的系統失效。例子包括：

•接受特定的錯誤輸入，便導致所有應用服務器實例崩潰的BUG。例如2012年6月30日的閏秒，由于Linux內核中的一個錯誤，許多應用同時掛掉了。

•失控進程會占用一些共享資源，包括CPU時間、內存、磁盤空間或網絡帶寬。

•系統依賴的服務變慢，沒有響應，或者開始返回錯誤的響應。

•級聯故障，一個組件中的小故障觸發另一個組件中的故障，進而觸發更多的故障。

導致這類軟件故障的BUG通常會潛伏很長時間，直到被異常情況觸發為止。這種情況意味著軟件對其環境做出了某種假設——雖然這種假設通常來說是正確的，但由于某種原因*后不再成立了。

雖然軟件中的系統性故障沒有*藥，但我們還是有很多小辦法，例如：仔細考慮系統中的假設和交互；*的測試；進程隔離；允許進程崩潰并重啟；測量、監控并分析生產環境中的系統行為。如果系統能夠提供一些保證（例如在一個消息隊列中，進入與發出的消息數量相等），那么系統就可以在運行時不斷自檢，并在出現差異（discrepancy）時報警。

人為錯誤

設計并構建了軟件系統的工程師是人類，維持系統運行的運維也是人類。即使他們懷有*大的善意，人類也是不可靠的。舉個例子，一項關于大型互聯網服務的研究發現，運維配置錯誤是導致服務中斷的首要原因，而硬件故障（服務器或網絡）僅導致了10-25％的服務中斷。

盡管人類不可靠，但怎么做才能讓系統變得可靠？*好的系統會組合使用以下幾種辦法：

•以*小化犯錯機會的方式設計系統。例如，精心設計的抽象、API和管理后臺使做對事情更容易，搞砸事情更困難。但如果接口限制太多，人們就會忽略它們的好處而想辦法繞開。很難正確把握這種微妙的平衡。

•將人們*容易犯錯的地方與可能導致失效的地方解耦（decouple）。特別是提供一個功能齊全的非生產環境沙箱（sandbox），使人們可以在不影響真實用戶的情況下，使用真實數據安全地探索和實驗。

•在各個層次進行*的測試，從單元測試、全系統集成測試到手動測試。自動化測試易于理解，已經被廣泛使用，特別適合用來覆蓋正常情況中少見的邊緣場景（corner case）。

•允許從人為錯誤中簡單快速地恢復，以*大限度地減少失效情況帶來的影響。 例如，快速回滾配置變更，分批發布新代碼（以便任何意外錯誤只影響一小部分用戶），并提供數據重算工具（以備舊的計算出錯）。

•配置詳細和明確的監控，比如性能指標和錯誤率。 在其他工程學科中這指的是遙測（telemetry）。 （一旦火箭離開了地面，遙測技術對于跟蹤發生的事情和理解失敗是至關重要的。）監控可以向我們發出預警信號，并允許我們檢查是否有任何地方違反了假設和約束。當出現問題時，指標數據對于問題診斷是非常寶貴的。

•良好的管理實踐與充分的培訓——一個復雜而重要的方面，但超出了本書的范圍。

可靠性有多重要？

可靠性不僅僅是針對核電站和空中交通管制軟件而言，我們也期望更多平凡的應用能可靠地運行。商務應用中的錯誤會導致生產力損失（也許數據報告不完整還會有法律風險），而電商網站的中斷則可能會導致收入和聲譽的巨大損失。

即使在“非關鍵”應用中，我們也對用戶負有責任。試想一位家長把所有的照片和孩子的視頻儲存在你的照片應用里。如果數據庫突然損壞，他們會感覺如何？他們可能會知道如何從備份恢復嗎？

在某些情況下，我們可能會選擇犧牲可靠性來降低開發成本（例如為未經證實的市場開發產品原型）或運營成本（例如利潤率極低的服務），但我們偷工減料時，應該清楚意識到自己在做什么。