Date: 21 8 月, 2026
為什麼 99.99% 的正常運作時間並不代表 100% 的正常運作時間
你有沒有仔細觀察過洗手液的包裝？ 「殺死99.99%的細菌」通常會醒目地印在包裝的某個位置。如果你跟我一樣，可能會產生一個很合理的疑問：「那剩下的0.01%呢？」究竟是什麼讓這最後的0.01%如此難以殺滅？我們在高可用性（HA）軟體方面也會遇到同樣的問題。在討論HA正常運作時間時，你很可能已經看過99.99%這個數字。問題依然存在：為什麼我們無法實現100%的正常運作時間？
首先，我們來談談 99.99% 正常運作時間究竟意味著什麼。正常運行時間指的是應用程式運行並可供最終用戶使用的時間。通常，這是以年為單位進行衡量的。要達到 99.99% 的正常運作時間，停機時間不得超過 52.60 分鐘。平均而言，這意味著：
每年52分36秒
每月 4 分 23 秒
每週 1 分 0 秒
每天 0 分鐘 8 秒
那隻是很短的時間，但算不了什麼，那麼它究竟是從哪裡來的呢？
有意造成的停機時間
讓我們先來看看一些最基本的停機原因。事實上，無論你的高可用性軟體多麼出色，執行諸如切換之類的常見操作總是需要一些時間。每次你主動發起切換時，都會產生極短的停機時間。根據層級結構的大小，這可能需要幾秒鐘到幾分鐘不等。為了理解其中的原因，我們需要了解切換發生時的具體情況。在資源層面，我們必須先將資源從目前活動節點上完全移除，然後再將資源完全啟用到新的活動節點上。根據應用程式的不同，這可能意味著運行幾個簡單的命令，也可能意味著運行冗長而複雜的優雅關閉操作，然後在另一台伺服器上進行緩慢的冷啟動。在層級層面，在許多情況下，我們必須一次執行一個操作。如果一個資源有任何子資源，那麼在開始移除初始資源之前，必須先將所有子資源完全移除；然後，在另一台伺服器上，我們必須先讓所有子服務完全投入運行，才能開始啟動主服務。對於多層級架構和複雜的切換流程，這會造成相當大的時間損失。這是一種固有的、不可避免的停機時間，但幸運的是，在大多數情況下，最終用戶除了感覺到加載時間略微延長或需要短暫重新連接之外，不會察覺到任何異常。然而，這確實會增加停機時間的計算。
另一種固有的停機形式是維護。幸運的是，大多數維護工作都可以以高可用性的方式進行。這意味著先在備份節點上執行維護，進行切換，然後在先前執行的系統上執行維護。如上所述，這會造成一定程度的停機，但停機時間應該很短。然而，有些維護工作無法以高可用性的方式進行。在這種情況下，可能會出現相當長的停機時間，從而增加全年的總停機時間。
無意造成的停機時間
一旦我們開始關注高可用性軟體的主要用途：災難恢復，就會發現其中的利害關係。即使一切都按計劃完美進行，任何故障都會造成一定程度的停機時間。我們首先來看看在成功故障轉移過程中停機時間是如何產生的。為了從故障中正確恢復，我們必須先檢測並驗證故障。這是一個需要權衡的難題。如果故障偵測過於激進，可能會偵測到實際上並未發生的故障（誤報故障）。如果偵測不夠激進，故障偵測速度可能會過慢。大多數故障首先會被定期運行的進程偵測到。對於單一資源故障，通常是檢查腳本失敗；對於整個伺服器故障，通常是心跳遺失。在這兩種情況下，我們都不會在發生一次故障後立即啟動恢復。相反，我們會進行重試，並等待多次故障以驗證真正的故障。例如，執行更複雜的資源狀態測試的深度檢查腳本預設每五分鐘執行一次。這意味著檢測某些故障可能需要長達五分鐘的時間，而根據故障類型的不同，驗證故障可能需要更長時間。在檢測並驗證故障後，根據故障類型，我們可能會嘗試多次本地恢復。如果恢復成功，可以節省一些停機時間；但如果恢復失敗，則會略微增加故障切換的停機時間。在檢測故障、驗證故障並嘗試本地恢復後，我們將執行故障切換。根據故障的具體類型，故障切換所需的時間可能與先前描述的切換停機時間類似。所有這些潛在的延遲因素加起來，可能會顯著增加停機時間。幸運的是，大多數故障都能快速偵測到，並且與上述切換類似，最終使用者幾乎不會察覺到故障的發生。
第二個導致意外停機的原因是故障轉移失敗。一旦發生故障轉移，停機時間會顯著增加，因為故障轉移需要合格的技術人員介入並正確地恢復系統。雖然這種情況比較少見，但確實會發生。幸運的是，故障轉移幾乎總是可以預防的。確保故障轉移按計劃進行的最佳方法是提前進行測試。配置錯誤很容易發生，但只需執行一次故障轉移測試即可發現任何此類問題。確保故障轉移成功的另一種方法是確保叢集盡可能頻繁地做好故障轉移準備。這意味著要確保備份系統正常運行，並且資源處於 ISP（服務保護）狀態。例如，未處於鏡像狀態的 DataKeeper 映像不會處於 ISP 狀態，因此發生故障時將無法進行故障轉移。為確保資源能夠順利切換，應採取措施確保 DataKeeper 盡可能頻繁地進行鏡像，並且其他資源也保持最新狀態，隨時準備進行故障轉移。
導致意外停機的最後一個原因是 LifeKeeper 無法控制的問題。網路問題可能導致故障轉移成功或失敗，但也可能使看似健康的叢集無法訪問，具體取決於系統的設定方式。同樣，底層雲端或虛擬化軟體的問題也可能導致 LifeKeeper 無法處理的問題。為了避免這些問題，盡可能地將系統隔離，可以讓 LifeKeeper 免受這些問題的影響。所有系統都位於同一可用區或同一網路上的叢集比包含分散系統的叢集更容易出現問題。 LifeKeeper 無法控制的另一個問題是內部應用程式問題和人為錯誤。例如，意外刪除關鍵資料可能會為最終用戶帶來問題，而這些問題很可能無法被 LifeKeeper 偵測到或修復。使用備份軟體可以幫助從這類問題中恢復，但無法彌補損失的正常運行時間。最後，高可用性不一定能抵禦惡意行為者和網路安全威脅。某些攻擊可能會導致正常運作時間損失。為防止此類問題，建議使用可信賴的防毒/反惡意軟體套件。
可避免的停機原因
正如上文多節所述，許多停機原因完全可以避免。我不會在此一一列舉所有可避免的停機類型，但會重點介紹幾種最常見的類型。
在初始設計叢集拓樸結構時，需要考慮以下幾點。腦裂是指兩個節點都認為自己是主節點的情況，可以透過某種形式的仲裁機制來避免。如果您正在開發一個通用應用程序，請務必編寫並使用快速檢查和深度檢查腳本，以便能夠真正檢測到故障。最後，請確保設定多條通訊路徑，這些路徑跨越多個網路卡和網路。
系統配置不當也會導致停機。前面已經提到了一些例子。首先，確保受保護的應用程式、底層作業系統和高可用性軟體都已更新至最新版本。許多停機是由於一些原本可以完全避免的、但已被修復的漏洞所造成的。其次，在叢集配置完成後以及之後定期進行切換和故障轉移測試。透過這些測試，可以提前發現並預防許多可能導致故障轉移失敗的問題。第三，確保始終有一個備用節點處於運作狀態並隨時準備接手。
配置不當的系統會導致停機。為避免這種情況，LifeKeeper 和 DataKeeper 提供了可調參數，用於最佳化效能、心跳間隔、資源檢查和重試設定。雖然預設設定通常足夠，但任何更改都應在充分了解其影響和必要性後進行。務必優先考慮 SIOS 支援團隊的指導，因為他們的建議是基於豐富的專業知識，應嚴格遵循以確保系統可靠性。
作者：Carter Chandler，SIOS公司副軟體工程師
經許可轉載SIOS