本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 分散式系統可用
<a name="distributed-system-availability"></a>

 分佈式系統由軟件組件和硬件組件組成。某些軟體元件本身可能是另一個分散式系統。基礎硬體和軟體元件的可用性會影響工作負載產生的可用性。

 使用 MTBF 和 MTTR 的可用性的計算有其根源於硬件系統。但是，分散式系統失敗的原因與一個硬體完全不同。如果製造商可以持續計算硬體元件耗盡之前的平均時間，則相同的測試無法套用至分散式系統的軟體元件。硬體通常遵循故障率的「浴缸」曲線，而軟體則遵循由每個新版本引入的額外缺陷所產生的交錯曲線 (請參閱[軟體可靠性](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability))。

![\[顯示硬體和軟體故障率的圖表\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)


 此外，分散式系統中的軟體通常會以比硬體更高的速率變更。例如，標準磁性硬碟的平均年故障率 (AFR) 可能為 0.93%，在實際情況下，硬碟的使用壽命可能至少為 3-5 年，可能會延長 (請參閱 2020 年 [Backblaze](https://www.backblaze.com/b2/hard-drive-test-data.html) 硬碟資料與統計資料)。硬碟在該生命週期內不會發生重大變化，例如，在 3 到 5 年內，Amazon 可能會在其軟體系統上部署超過 450 至 7.5 億項變更。請參閱 [Amazon Builders' Library — 自動執行安全、免提](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)部署。) 

 硬件也受到計劃過時的概念，即具有內置的壽命，在一段時間後需要更換。（見[偉大的燈泡陰謀](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy)。） 從理論上講，軟件不受這種限制，它沒有磨損期，可以無限期地操作。

 所有這些都意味著用於生成 MTBF 和 MTTR 號碼的硬件的相同測試和預測模型不適用於軟件。自 1970 年代以來，已經有數百次嘗試構建模型來解決此問題，但它們通常分為兩類，即預測模型和估計建模。(請參閱[軟體可靠性型號清單](https://en.wikipedia.org/wiki/List_of_software_reliability_models)。) 

 因此，計算分佈式系統的前瞻性 MTBF 和 MTTR，從而具有前瞻性的可用性，將始終從某種類型的預測或預測衍生出來。它們可以通過預測建模，隨機模擬，歷史分析或嚴格的測試生成，但這些計算並不保證正常運行時間或停機時間。

 分散式系統過去失敗的原因可能永遠不會再次發生。future 失敗的原因很可能會有所不同，並且可能不知道。future 失敗所需的復原機制也可能與過去使用的復原機制不同，因此需要大幅不同的時間。

 此外，MTBF 和 MTTR 是平均值。從平均值到看到的實際值會有一些變化（標準差 σ，測量此變化）。因此，在實際生產使用中，工作負載可能會在故障和復原時間之間經歷較短或更長的時間 

 話雖如此，構成分佈式系統的軟件組件的可用性仍然很重要。軟體失敗的原因有許多 (在下一節中詳細討論)，並會影響工作負載的可用性。因此，對於高可用性的分散式系統而言，應該關注軟體元件的計算、測量和改善軟體元件的可用性等於硬體和外部軟體子系統。

**規則 2**  
 工作負載中軟體的可用性是工作負載整體可用性的重要因素，而且應該與其他元件相同。

 重要的是要注意，儘管 MTBF 和 MTTR 難以預測分散式系統，但它們仍然提供有關如何提高可用性的關鍵見解。降低故障頻率 (更高的 MTBF) 並減少故障發生後的復原時間 (降低 MTTR)，都會導致更高的實證可用性。

## 分散式系統中的故障類型
<a name="types-of-failures-in-distributed-systems"></a>

 在影響可用性的分佈式系統中通常有兩類錯誤，親切地命名為*博爾錯誤*和*海森*堡（見 [「與布魯斯·林賽的對話」，ACM 隊列第 2 卷，第 8-2004 年 11 月）。](http://queue.acm.org/detail.cfm?id=1036486)

 Bohrbug 是一個可重複的功能軟件問題。給定相同的輸入，該錯誤將始終產生相同的不正確輸出（如確定性的 Bohr 原子模型，它是固體且易於檢測的）。當工作負載進入生產環境時，這些類型的錯誤很少見。

 海森錯誤是一個暫時性的錯誤，這意味著它只發生在特定和不常見的情況下。這些條件通常與硬體 (例如暫時性裝置錯誤或硬體實作細節 (如暫存器大小)、編譯器最佳化和語言實作、限制條件 (例如暫時不在儲存空間) 或競爭條件 (例如，不使用信號量進行多執行緒作業)。

 Heiisenbugs 構成了生產中的大多數錯誤，並且很難找到，因為它們難以捉摸，並且在您嘗試觀察或調試它們時似乎會改變行為或消失。但是，如果您重新啟動程式，失敗的作業可能會成功，因為作業環境略有不同，從而消除了引入 Heiisenbug 的條件。

 因此，生產中的大多數故障都是暫時的，當重試操作時，不太可能再次失敗。為了保持彈性，分佈式系統必須對海森蟲具有容錯能力。我們將探討如何實現這一部[分增加分佈式系統 MTBF](increasing-mtbf.md#increasing-mtbf.title)。