快速溫變濕熱試驗箱 技術(shù)規(guī)格：

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

 •應用程序表現(xiàn)出用戶所期望的功能。

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

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

•系統(tǒng)能防止未經(jīng)授權(quán)的訪問和濫用。

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

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

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

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

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

硬件故障

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

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

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

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

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

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

軟件錯誤

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

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

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

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

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

•級聯(lián)故障，一個組件中的小故障觸發(fā)另一個組件中的故障，進而觸發(fā)更多的故障。

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

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

人為錯誤

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

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

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

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

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

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

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

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

可靠性有多重要？

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

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

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