應用程式韌性：保持 Windows 應用程式可用

介紹

Windows 應用程式通常依賴於遠比承載它們的伺服器更多的東西。資料庫、身份服務、儲存、網關、網絡和用戶端點都可能影響應用程式在中斷期間是否仍然可用。本文解釋了 IT 團隊如何評估這些依賴性，圍繞現有的 Windows 應用程式設計彈性，監控正確的層級並測試恢復計劃是否實際保護用戶所依賴的業務功能。

應用程式彈性是什麼？

應用程序的韌性是指應用程序及其周圍基礎設施在中斷期間繼續提供重要功能的能力，以及在故障後可預測地恢復的能力。

中斷可以是小的或大的，原因可能包括硬體或操作系統故障、應用程式崩潰、更新失敗、資料庫中斷、網路中斷、身份驗證失敗、資源耗盡、不可用的依賴項或安全事件。

一個具有彈性的架構承認故障是不可避免的，而不是旨在防止每一個事件，IT 組織尋求限制每個事件的影響，並建立受控的恢復程序以維持或恢復服務。

應用程序彈性不僅僅是伺服器正常運行時間

一個常見的錯誤是將伺服器的可用性視為應用程式可用性的代理，而該應用程式運行在伺服器上。

為了讓商業應用程序真正可用，必須同時具備多個組件：

基礎設施 → 作業系統 → 應用程式 → 依賴項 → 存取路徑 → 使用者會話 → 商業流程

此鏈中的任何元素出現問題都可能導致應用程序實際上無法使用。

例如，應用伺服器可能運行正常，但其資料庫無法訪問。已發佈的應用程式可能運行正常，但閘道故障使遠端員工無法訪問它。用戶甚至可能成功啟動應用程式，但因為授權、檔案或後端服務不可用而無法完成交易。

應用程序的韌性應根據用戶執行必要業務任務的能力來衡量，而不是根據伺服器是否能夠響應可用性或健康檢查。

為什麼應用程式彈性對於 Windows 應用程式來說是不同的？

現代的韌性實踐越來越專注於雲原生應用程式、容器、微服務和自動化編排。雖然這些是有價值的方法，但並不總是適用於每個組織。

許多組織擁有在雲原生架構普遍之前開發的舊版 Windows 業務應用程式。ERP 軟體、會計應用程式、製造應用程式、醫療應用程式、工程應用程式以及內部開發的應用程式都可能對組織的運營至關重要。

重新架構這些應用程式為微服務可能會非常昂貴、技術上具有挑戰性，或者如果組織不控制源代碼，甚至完全無法實現。

在這種情況下，圍繞應用程序的操作變得更具韌性可能會有重要價值，而不是試圖使應用程序本身更具韌性。 應用程式發佈 可以透過保持現有的 Windows 應用程式在集中式基礎設施上，同時改變用戶訪問它們的方式來成為這種方法的一部分。這可以包括對承載應用程式的基礎設施進行更改，例如消除基礎設施限制、創建冗餘的應用程式主機、啟用替代訪問方法以及為應用程式主機實施更靈活的恢復程序。

在什麼情況下 Windows 應用程式的可用性可能會失敗？

建立應用程序的韌性始於發現成功將應用程序從其主機交付給用戶所需的組件。這個過程突顯了可能導致整個應用程序失效的潛在故障點。

應用主機

在單一 Windows 伺服器上運行的應用程式有明確的單一故障點。

硬體問題、Windows 更新、操作系統損壞、資源耗盡或應用程式故障可能會影響每個依賴該機器的使用者。如果可用性需求需要，可以設置多個應用程式主機，以減少對任何一台機器的依賴，並在伺服器無法使用時提供容量。

資料庫、儲存和其他依賴項

許多 Windows 應用程式依賴於應用程式主機外部的服務。這些服務可以包括：

• SQL 資料庫
• 檔案共享
• 授權伺服器
• Active Directory
• 域名系統 (DNS)
• 證書
• API
• 中介軟體
• 網絡存儲
• 列印基礎設施

引入第二個應用伺服器提供的彈性有限，如果它們共享一個不可用的共同數據庫或存儲依賴。顯然，依賴映射需要超越可見的應用基礎設施。

身份驗證與身份

用戶無法訪問健康的應用程序，如果必要的身份驗證基礎設施不可用。

IT 團隊需要識別其關鍵應用程序所依賴的身份服務，並確保在這些資源無法訪問時有故障轉移計劃。Active Directory、雲身份平台、多因素身份驗證 (MFA) 服務和身份驗證網關都可以依賴，以提供應用程序的可用性鏈。

網絡和遠程訪問路徑

對於集中式 Windows 應用程式，使用者與應用程式環境之間的連接代表另一個可能的故障範圍。

讓我們想像完整的鏈條：

用戶設備 → 互聯網或局域網 → 閘道 → 應用主機 → 後端服務

在這個鏈條中的任何故障都可能阻止用戶執行他們的工作，即使應用程序運行正常。這對於分散式組織特別相關，因為應用程序可能在數據中心正常運行，但對於位於其他位置的用戶卻無法訪問。

端點

應用程序的彈性不一定需要用戶的正常工作站可用。

提供授權用戶從替代設備或通過瀏覽器訪問集中托管應用程序的手段，可以確保在筆記本電腦無法使用、辦公室無法進入或員工需要在不同地點工作時仍能訪問。

應用交付架構可以是更廣泛的業務持續性策略的一部分。

建立 Windows 應用程式韌性的過程是什麼？

沒有單一技術能使應用程序具備彈性。IT 團隊必須減少可能導致完整功能中斷的故障數量，並為仍然存在的故障準備可控的恢復機制。

1. 確定關鍵應用程式和業務流程

並非所有應用程式都需要相同程度的保護。首先確定哪些應用程式支持主要操作，哪些用戶依賴它們以及他們的停機容忍度。

兩個恢復目標將業務需求轉化為技術規範。 NIST的應急計劃指導 定義恢復時間目標 (RTO) 和恢復點目標 (RPO) 為確定恢復需求的關鍵參數：

• 恢復時間目標 (RTO)：在服務恢復之前可接受的停機時間。
• 恢復點目標 (RPO)：可接受數據損失的時間間隔。

一個被密集使用來處理訂單的應用程式可能有幾分鐘的恢復時間目標，而每週運行一次的財務報告應用程式則可以承受幾天的停機時間。

RTO 和 RPO 定義了應用程序所需的保護類型：瞬時故障轉移、快速恢復服務或僅僅是文檔化的恢復程序。

2. 映射整個應用程序依賴鏈

記錄應用程式執行其工作的所有必要事項。

不要只停留在可執行檔或 Windows 伺服器上。不要忘記資料庫、儲存、身份驗證、DNS、網路、憑證、授權系統、網關和外部服務。

對於每一個，請問：

如果這個消失了，應用程式會發生什麼事？

這個練習將揭示隱藏的單一故障點並建立恢復順序。如果應用程序主機首先恢復，但其數據庫、身份服務或存儲尚不可用，則幫助不大。

3. 移除關鍵單一故障點

一旦建立了依賴樹，根據業務重要性和恢復目標確定哪些組件需要冗餘。

在 Windows 應用程式交付的情況下，這可能涉及部署多個應用程式伺服器，而不是依賴單一主機的能力。透過負載平衡層，會話可以在正常操作期間分散到應用程式實例上。在主機故障的情況下，進來的連接可以路由到健康的應用程式伺服器實例。

冗餘規劃應該受到依賴分析的指導。然而，多個應用伺服器訪問單一關鍵數據庫、網絡閘道或存儲層仍然存在單一故障點。

高可用性設計因此必須將應用服務視為一個整合的實體。對於需要基礎設施級冗餘的 Windows Server 環境， 微軟的故障轉移叢集文檔 提供有關高可用性和災難恢復拓撲的進一步指導。

4. 將應用程式與個別端點分開

在每位員工的工作站上直接安裝關鍵應用程式可能會產生不同類型的韌性問題。如果用戶失去對其常用電腦的訪問權限，他們也可能失去對繼續工作的應用程式的訪問權限。

將應用程式集中在管理的 Windows 主機上 並向用戶展示應用程序界面消除了這一風險。數據和應用程序狀態存儲在受管理的 Windows 主機上，並由授權的端點訪問。

透過這樣做，我們使應用程式即使在用戶更換設備或位置時仍然可用。雖然集中應用程式並不能消除基礎設施問題，但它有助於將其移入一個可以由IT控制的環境中。

提供多於一種實用的訪問方法

彈性也可以通過避免對單一端點類型或連接方法的不必要依賴來實現。

根據應用交付架構，使用者可以使用不同的 遠端存取 方法，包括 RDP 兼容客戶端、專用應用程式啟動器、網頁入口或 HTML5 瀏覽器會話。

替代連接方法不應與基礎設施冗餘混淆。如果所有人都依賴同一台失效的伺服器，應用程序仍然無法使用。

他們確實提供訪問彈性，當中斷影響用戶的正常設備、安裝的客戶端或位置，而不是應用服務本身時。

6. 監控在降級成為故障之前

應用程序的韌性不僅僅是關於恢復，及早檢測可以避免降級為停機。

在 Windows 應用程式環境中有用的指標包括 CPU 使用率、記憶體壓力、磁碟容量和 I/O、網路使用率、活躍會話、應用程式進程、響應時間、連接失敗和依賴服務的可用性。

趨勢監控 這是至關重要的，因為一個不斷接近其極限的伺服器仍然可以在線，而用戶體驗卻逐漸惡化。

閾值警報使管理員能夠在用戶失去訪問權限之前調查事件的前兆。

7. 計劃容量高峰和故障轉移

一個在硬體層級故障下仍能存活，但在需求增加時完全無法運作的應用程式，並不是真正能抵抗任何類型故障的韌性。

容量規劃必須考慮到不僅是日常使用模式，還要考慮到由於季節性需求、變更班次、增長或其他應用程序的托管需求而產生的高峰。

特別是在多伺服器托管環境中，必須考慮到單一伺服器的損失，確保其他托管節點具有備用容量，以容納本來會在故障節點上執行的任何過程。

否則，故障轉移程序可能會將孤立事件簡單地轉變為廣泛的系統性能問題。

8. 保護數據和配置

如果IT無法恢復使應用程序運行所需的組件，則替換的Windows伺服器幾乎沒有用處。

這可能意味著備份程序需要包括應用程序數據、數據庫、配置文件、證書、應用程序設置、用戶配置文件、基礎設施配置、腳本和許可信息。

該策略將根據應用程序的恢復時間目標 (RTO) 和恢復點目標 (RPO) 而有所不同。

最重要的是，確保成功的備份並不等於成功的恢復。IT 團隊應該測試是否可以從受保護的數據和配置中恢復整個應用服務。

9. 減少變更的影響範圍

並不總是不可預見的災難導致中斷。這些中斷也可能是由於實施的改進所造成。因此，Windows 補丁、應用程式和驅動程式升級、安全政策和配置變更也可能對應用程式的可用性產生負面影響。如果可能，建議避免同時對所有生產主機進行類似的更改。

在多伺服器設置中，可以分階段進行改進變更，從而使管理員能夠確保一切正常運作。能夠回滾所做的變更也是至關重要的。

因此，在設計應急程序時，應考慮回滾選項。該過程應妥善記錄，並且員工應知道如果變更失敗該怎麼做，而不是僅僅依賴他們的裁量。

10. 設計以優雅降級

韌性並不是指在任何時候都保持 100% 的正常功能運行。

在某些情況下，為關鍵用戶或應用程序維持運作可能比保持所有服務對所有用戶可用更為重要。IT 團隊可以在事件發生之前確定優先事項。

如果有可用的容量，可以考慮首先將其分配給生產、客戶服務、財務或其他職能。

這是優雅的降級：保留運行產生最大商業價值的功能的能力，而不是讓不那麼關鍵的元素的故障使整個系統崩潰。

IT 團隊應如何監控應用程式的韌性？

監控個別伺服器可能有用，但彈性監控應該反映用戶所感知的整體應用服務。

一個現實的模型包含幾個層次：

層級	監控內容	範例失敗
主機	CPU, RAM, 磁碟, 作業系統可用性	伺服器過載或離線
應用程式	處理和服務狀態	應用程式崩潰
依賴性	資料庫, DNS, 身份, 存儲	應用程式啟動但無法運行
訪問	網關，入口網站，網絡路徑	用戶無法連接
會話	活躍用戶、故障、延遲	應用程式在線但無法使用
商業功能	成功的工作流程完成	使用者無法完成所需的任務

業務功能層是最容易被忽視的層之一。

基礎設施儀表板可能顯示所有伺服器、服務和網絡路徑為健康狀態，而實際用戶的工作流程卻受到影響。因此，對於關鍵應用程序來說，從它們所設計支持的操作的角度監控其健康狀態是很重要的。

應該如何測試應用程序的韌性？

一個從未經歷過控制失敗的韌性架構包含了未經測試的假設。

使用測試來評估系統在關鍵組件無法使用時的反應。測試應包括將應用程序主機下線、停止應用程序服務、模擬網絡路由丟失、驗證網關或負載平衡行為、從備份恢復以及從替代端點訪問應用程序。

測試過程應超越恢復的技術方面。IT 團隊應檢查警報是否發送給正確的管理人員，恢復步驟是否按照正確的順序執行，以及用戶在服務恢復後是否能夠執行實際的業務任務。

操作程序對於一個具有彈性的系統至關重要。警報升級程序：誰接收警報？誰有權啟動故障轉移？恢復文檔和憑證存儲在哪裡？哪個依賴項需要首先上線？

技術冗餘如果未經測試以恢復訪問的過程，則幾乎沒有好處。

應用彈性檢查清單可以是什麼？

在開始一個關鍵的 Windows 應用程序的韌性之前，IT 團隊應能回答以下問題：

• 哪些業務流程依賴於該應用程序？
• 它的 RTO 和 RPO 是什麼？
• 它需要哪些伺服器、資料庫和外部服務？
• 它的關鍵單點故障在哪裡？
• 如果一個主機失敗，另一個應用程序主機能否接受用戶？
• 如果用戶的正常端點或位置無法使用，他們可以連接嗎？
• 是否有足夠的備用容量以進行降級操作？
• 基礎設施、依賴性和會話問題是否被積極監控？
• 管理員在重要閾值變成故障之前會收到警報嗎？
• 應用程式數據和配置是否受到保護？
• 實際上有進行過恢復測試嗎？
• 問題變更可以回滾嗎？
• 恢復序列是否有文件記錄？
• 用戶在恢復後能否完成所需的業務流程？

並非所有答案都需要昂貴的高可用性基礎設施。適當的保護水平取決於停機的成本和運營影響。

重要的是，必須故意做出可用性、冗餘和恢復的決策，而不是假設。

TSplus 如何幫助保持 Windows 應用程序可用？

對於依賴現有 Windows 應用程序的組織，我們可以通過將應用程序集中在受管理的 Windows 伺服器上並通過 RDP 兼容的客戶端、RemoteApp 風格的訪問或 HTML5 網頁門戶將其交付給用戶來幫助提高可用性。這減少了對個別用戶端的依賴，並在用戶需要從其他設備或位置連接時為 IT 團隊提供了更多的靈活性。

TSplus 遠端存取 還可以支持多伺服器部署，並具備負載平衡和基於網關的訪問。當與彈性數據庫、存儲、身份服務和網絡結合時，這種架構可以減少對單一應用程序主機的依賴，並幫助在基礎設施中斷期間維持對關鍵 Windows 應用程序的訪問。

結論

應用程序的韌性取決於理解基礎設施與業務使用之間的完整路徑。冗餘、監控、備份、容量規劃和恢復程序在圍繞明確定義的應用程序依賴性和恢復目標設計時最為有效。

對於現有的 Windows 應用程式，韌性通常來自於加強軟體周圍的環境，而不是重建應用程式本身。關鍵測試仍然很簡單：當發生中斷時，使用者能否繼續工作，或者 IT 能否在約定的恢復時間內恢復所需的業務功能？