高可用性架構和最佳實踐
關於高可用性的 13 個鮮為人知的事實
1. Hypervisor HA 與應用程序 HA 不同
一個關鍵的誤解是，我之所以具有高可用性，是因為我的硬件或虛擬機管理程序中有冗餘。 但是，硬件和管理程序冗餘並不能保證高可用性用於應用程序。 也不能保證應用程序的編排將在失敗時正確執行。
2. 在高可用性中，更大並不等於更好
如果你是一名力量舉運動員，更大的重量更好，更小的代表更好。 或者，如果我們談論擁抱。 （你還記得擁抱是我們見到來自不同城鎮的朋友時經常做的事情，我們有一段時間沒見過了。）但是，更大並不總是意味著更好。 例如，更大的腎結石肯定不是更好。 在更高的可用性中，創建更大、更複雜的解決方案並不總是意味著您將提高您的高可用性。 這可能意味著您的可用性相同或更少。 這也可能意味著您有一個更大、更複雜的系統，其中包含許多移動部件，需要在停機時進行分類。
3. 一切都失敗了……有時
應用程序編程語言可以追溯到 1950 年代。 雖然語言、處理器、IDE 和代碼質量有所提高，但現實是“所有應用程序都會在某個時候失敗”。由於異常、錯誤、未處理的終止、意外終止、資源耗盡等導致的失敗時有發生。 仍然需要一個主動/主動或主動/被動應用程序可用性策略。
4. 關注“為什麼”和“如何”一樣多
我們跳入任務完成模式的自然傾向是一種必要的資產，但需要通過我們對為什麼的問題的回答來加以調節和引導。 在不了解業務、應用程序、數據庫和利益相關者要求的情況下向環境添加解決方案將導致：
- 失敗
- 超支
- 表現不佳
- 混亂和過度架構
- 上述所有的
與其只關注實現可用性，不如花費必要的資源和精力來了解業務需求和“為什麼”的答案
5. 未修補的問題是常見的遺憾來源
做或不做，後果自負。 所有未修補的問題的後果是後悔。 作為客戶體驗副總裁，我親眼目睹了由於客戶未能及時解決已知問題而導致的停機。
6. 未記錄的問題也會導致停機
描繪場景。 一位新管理員正在調查網絡上的服務器。 使用情況報告表明服務器未處於活動狀態，並且沒有連接任何客戶端。 新管理員無法識別服務器，也沒有發現“標籤”、文檔或其他標識符，因此認為應該關閉它。 不幸的是，未記錄和未通信的實例實際上是一個備用服務器，當主服務器意外崩潰時，刪除它會導致停機。 這不是虛構的故事，而是一個新管理員的真實故事，他錯誤地將服務器識別為空閒 QA 系統並在修補練習之前將其關閉。
7、自滿也是敵人
如果內部或云中或介於兩者之間的任何地方的可用性是我們可以“設置並忘記”的，我們都會喜歡它。但是，生活中很少有事情真的像“設置並忘記它”那樣簡單。未來可用性的最大敵人之一是您現在的高可用性成功。 當災難很少發生並且團隊確信他們已經實現了持續穩定時，自滿情緒就會介入。 成功誘使我們認為什麼都不會改變，因此對高可用性的自滿是高可用性的敵人。 企業周圍和企業內部的事物正在發生變化。 雲在變化，您的業務需求在變化，應用程序和操作系統也在變化。
8.改變很難
改變很難。 問問那些一直試圖在睡前放棄第二塊蛋糕的愛吃甜食的人吧。 即使在高可用性中也會出現類似的阻力。 團隊，即使是那些經歷過災難的團隊，即使改變是好的，也往往不願意改變。 他們需要遠見、對原因的理解和支持。 其他擁有解決方案的團隊不願意提高高可用性，因為害怕引入不穩定或將自己暴露在新的風險中。
9.所有的改變都不是好的改變
改變是好的，當改變是好的。 在考慮對更高可用性解決方案和架構進行更改時，根據目標、要求以及在提高可用性的範圍內分析更改至關重要。 提高穩定性、增加對關鍵組件的保護、消除變通方法、優化服務可用性並經過全面測試的更改都是很好的更改。
10. 便宜並不總是更好
便宜並不總是更好。 雖然更便宜的解決方案通常具有較低的價格標籤，但它們也可能帶有許多限制，使其不太理想。 當價格標籤較低時，請注意缺少的功能，例如缺乏應用程序意識、有限的編排、隱藏的複雜性、手動恢復和故障轉移，並且僅限於沒有用戶驗證。 更便宜的解決方案也可能不包括客戶支持。 請務必了解您的更便宜的解決方案是否包含支持，或者支持是否是額外的、大量的附加成本。
這同樣適用於減少計算、磁盤或存儲的更便宜的部署。 雖然價格標籤和每月成本可能較低，但您的解決方案也可能以不太理想的容量運行。
11.響亮不等於有效
聽說過那個叫狼來了的男孩的故事。 產生警報風暴的應用程序監控解決方案遲早會被忽略。 擁有提供警報的解決方案固然很棒，但如果該解決方案錯誤地或過多地觸發了關鍵警報，則它是無效的。
12. 高可用性是一種文化和心態，而不僅僅是產品或硬件解決方案
軟件、硬件、流程、解決方案和服務都是高可用性的一部分。 但是，如果沒有跨 IT 職能和業務部門的支持，它將充滿挫敗感並不斷成為預算討論的來源，而不是關於價值、業務穩定性、提高客戶滿意度和降低風險的討論。
13.現在還不晚
希望不是實現高可用性的策略，希望您不會遇到嚴重災難或應用程序故障也不需要成為策略。 即使距離上次災難已經過去數週或數月，現在也可以設計和構建高度可用的企業架構。
聯繫 SIOS了解更多高可用性解決方案為您的應用程序。
– 客戶體驗副總裁 Cassius Rhue 轉載自SIOS
