5個跡象表明，要修復高可用性，需要花費比博客文章更多的時間
標誌在那裡。 警告燈閃爍。在您的直覺中，您可以感覺到它。 也許你睡不著您的高可用性問題很深。 但是，也許您不太確定。
1.如果您認為雲SLA是高可用性所需的全部
雲解決方案在提高硬件可用性和彈性方面取得了巨大進步。 但是，應用程序高可用性不僅需要選擇正確的管理程序或云提供商，還需要更多。 雲或虛擬化提供商提供的SLA不能阻止您的高可用性策略。 正如Wired所引用的那樣，“ 2011年4月近四天的Amazon中斷並未違反Amazon的EC2 SLA，正如FAQ所解釋的那樣，“保證了在365年內某個區域內99.95％的服務可用性。”在這篇DZone文章中，我們自己的David Bermingham詳細細分了雲SLA和應用程序可用性之間的差異。 如果您想要一個高度可用的基礎架構，則它還必須包括在數據和應用程序層的監視，恢復和彈性。
2.如果您僅使用開源操作系統隨附的高可用性群集
如果是這樣，那麼您很可能沒有根據與操作系統捆綁在一起的數據庫來選擇數據庫，那麼為什麼僅根據該標準選擇HA解決方案。 捆綁的工具在提供額外的保證，可能性和功能方面大有幫助。 但是，儘管易於訪問，捆綁的工具和OS群集軟件並不總是能夠滿足您的SLA，RPO，RTO和可用性要求。 如果您的企業具有操作系統的組合，則您的團隊可能需要導航不同工具並了解它們如何集成在一起的幫助。 這就好比選擇樹籬修剪器，然後將路left割草機推到路緣石上，在13洞5杆洞（奧古斯塔）上塑造“杜鵑花”形狀。 兩台割草機都旨在割草，但是您有多少時間？ 您將如何處理複雜性？ 您會信任哪個？ 您的高可用性策略所需要的不只是考慮與操作系統捆綁在一起的便利性，否則，您將運行MySQL而不是SAP HANA。
3.如果您認為企業應用程序許可（例如SQL Enterprise或Oracle Enterprise）與企業高可用性相同
除了增加成本外，許多企業應用程序許可證還提高了應用程序在某些高可用性方案中恢復的能力。 但是，整個企業極不可能基於單個應用程序。 您的高可用性不僅需要高可用性的數據庫解決方案。 您將需要一個企業級應用程序監視和恢復解決方案，該解決方案需要對所有應用程序和數據庫的廣泛支持。 此外，您不僅需要管理和復制數據庫數據的能力，還需要管理和復制關鍵應用程序和配置數據的能力。 單個數據庫或簡單應用程序的可用性是一回事，但是複雜，多部分應用程序和支持數據庫的HA卻大不相同。 在故障轉移/切換之前，期間和之後，需要提供更多的服務，需要協調的更多部分，要協調的更複雜的體系結構，要遵循的更具體的最佳實踐。 超出您企業許可證所支付的價格。
4.如果您的停機時間在增加，而停機時間在減少
在許多領域，生活的節奏都在不斷增加。 您的團隊最後一次從備份中恢復，手動重新啟動被認為是關鍵的應用程序或重新啟動一組故障的虛擬機或節點是什麼時候？ 中斷事件的速度不能繼續超過可持續性，或者您的團隊有能力從消防轉向防火和防火。 “你只能跑那麼久這麼久（Carey Nieuwhof）。”對於某些人來說，您交火已經太久了，而且停機時間比正常運行時間更為普遍。
5.如果您的第一個故障轉移測試是在生產服務器上
最近的一位客戶指出，不可能針對每種可能的災難情況進行測試。 隨著新軟件的創建，部署，更新和修補，更高可用性方面的挑戰越來越大。 但是，您的實時生產數據不是找出不能一起很好發揮作用的地方。 儘管Go-Live和Post-Go-Live總是會帶來很多驚喜，但是無法真正進行故障轉移和在備份節點上運行不應是其中之一。
精練博客可以為您提供有用的提示和見解，以定義，重新定義和提高您的更高可用性。 但是，如果警告信號消失了，您已經用某種“足夠”來換取了真正的可用性，那麼修復該問題所需要的不僅僅是博客文章，或者是在可用性世界中搜尋每篇博客文章來解決的問題。您的醫管局。
–客戶體驗副總裁Cassius Rhue
經SIOS許可轉載