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

分散式系統可用

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

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

此外，分散式系統中的軟體通常會以比硬體更高的速率變更。例如，標準磁性硬碟的平均年故障率 (AFR) 可能為 0.93%，在實際情況下，硬碟的使用壽命可能至少為 3-5 年，可能會延長 (請參閱 2020 年 Backblaze 硬碟資料與統計資料)。硬碟在該生命週期內不會發生重大變化，例如，在 3 到 5 年內，Amazon 可能會在其軟體系統上部署超過 450 至 7.5 億項變更。請參閱 Amazon Builders' Library — 自動執行安全、免提部署。)

硬件也受到計劃過時的概念，即具有內置的壽命，在一段時間後需要更換。（見偉大的燈泡陰謀。） 從理論上講，軟件不受這種限制，它沒有磨損期，可以無限期地操作。

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

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

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

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

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

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

分散式系統中的故障類型

在影響可用性的分佈式系統中通常有兩類錯誤，親切地命名為博爾錯誤和海森堡（見 「與布魯斯·林賽的對話」，ACM 隊列第 2 卷，第 8-2004 年 11 月）。

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

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

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

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