共用方式為

可靠性成熟度模型

可靠性旅程是一個逐步程式，每個階段都是以上一個階段為基礎，以確保系統保持可用，並符合使用者的期望。 此成熟度模型旨在協助您評估目前的狀態，並提供結構化路徑來改善。

基礎開始啟動 Azure 所提供的基礎可靠性功能，方法是使用內建的 Azure 可靠性功能，例如區域備援，以立即改善，而不需要大量額外的優化工作。

反直覺地說，實現可靠性高的方式是接受失敗是不可避免的。 與其嘗試預防每一個問題，不如更有效地規劃您的系統在問題發生時的應對方式。 您的商務需求有助於判斷哪些風險值得主動解決。 Teams 投資於具有結構化檢視能力的進階監控功能，擴展失敗緩解措施以包含應用程式層級的考量，並開始測試復原性措施。

接下來，小組將商務見解與技術技能整合。 各 Teams 實施健康模型、進行失敗模式分析，以便準備完整的災害復原計劃。 此階段透過可測量的目標和各種失敗案例的系統性準備來確保責任。

系統上線之後，重點在於管理生產環境的挑戰，包括變更管理和處理數據成長和作業複雜度，以及這些挑戰如何影響系統的可靠性。

最後一個層級會無限期執行，並保持復原性是其目標。 此層級代表技術控件與架構適應性以外的演進。 此層級著重於讓系統在工作負載發展及成長時承受新的和無法預見的風險。

此模型會結構化為五個不同的成熟度層級，每個層級都有主要目標和一組核心策略。 使用下方的索引標籤式檢視來探索每個層級。 請務必在進行過程中檢閱已標示的取捨及相關風險。

目標圖示 打下工作負載基礎設施與運營韌性的堅實基礎，而不是耗費時間在優化工作上。

成熟度模型的層級 1 是設計來協助工作負載小組為系統可靠性建置堅實的基礎。 重點是自舉，這是建立未來可靠性決策基本概念的過程。 此階段大多牽涉到功能實現，並對目前做法的小幅擴充。

此階段包括研究、獲取見解，以及建立您的系統目錄。 它也使用 Azure 上的內建可靠性功能，例如啟用區域備援以立即改善。

藉由建立這些基本概念，您可以準備小組，以逐步提升系統的復原能力和效能，以進一步提升可靠性成熟度模型的水準。

重要策略

✓ 評估卸除作業責任的機會

此策略基本上是 自行開發 與 購買或依賴外部方案 的方法。 這一決定取決於在這個階段可以管理多少責任，同時仍然支持未來的發展。 您希望使用與工作負載相關的資源，但應該始終尋找機會減少或外包其維護工作。 以下是一些您可能想要套用此方法的傳統使用案例。

  • 藉由選擇平臺即服務 （PaaS） 解決方案，將責任卸載至雲端平臺。 它們為常見的復原需求提供現成的解決方案，例如複製、故障轉移和備份儲存區。 當您採用這種方法時，雲端提供者會處理裝載、維護和復原改善。

    例如，雲端提供者會跨多個計算節點複寫數據，並將複本分散到可用性區域。 如果您在虛擬機 （VM） 上建置自己的解決方案，您必須自行管理這些層面，這很耗時且複雜。

  • 卸除不直接與工作負載的商務目標相關的作業責任。 某些特製化作業，例如資料庫管理和安全性，可能會影響工作負載的可靠性。 探索有經驗的小組、技術或兩者都處理這些工作的可能性。

    例如，如果您的小組沒有資料庫專業知識，請使用受控服務來協助將責任轉移至提供者。 當您開始時，此方法很有用，因為它可讓小組專注於工作負載的功能。 許多企業已共用、集中管理的服務。 如果平臺小組可供使用，請使用它們來處理這些作業。 不過，此方法可能會新增相依性和組織複雜性。

    或者，如果您的小組具備正確的專業知識，您可以明確決定使用其技能，並選取不包含管理功能的服務。

  • 將責任卸除給非Microsoft廠商。 選擇現成的產品作為起點。 只有當自定義解決方案能提高您工作負載對商業的價值時，才建置這些解決方案。

風險： 如果 購買或依賴 選項部分符合您的需求，您可能需要實作客製化擴充功能。 此方法可能會導致「自定義鎖定」的情況，其中更新和現代化變得不切實際。 定期檢閱您的需求，並將其與解決方案的功能進行比較。 在兩者之間有顯著偏差時，開發退出策略。

相反的情況也是風險。 雖然 購買或信賴 的選項起初看似較為簡單，但如果 PaaS 服務、供應商解決方案或平臺資源的限制無法滿足工作負載所需的粒度或自主管理層級，可能稍後需要重新評估與設計。

✓ 識別重要的用戶和系統流程

在這個階段，將工作負載分解成流程非常重要。 專注於 使用者 和 系統 流程。 使用者流程會決定用戶互動，而系統流程會決定未直接與使用者工作相關聯的工作負載元件之間的通訊。

例如，在電子商務應用程式中，客戶會執行前端活動，例如瀏覽和訂購。 同時，後端交易和系統觸發程式會滿足使用者要求，並處理其他工作。 這些不同的流程是相同系統的一部分，但它們牽涉到不同的元件，並有不同的用途。

開始在這個階段建置流程目錄。 觀察用戶互動和元件通訊。 列出和分類流程、定義其起點和終點，以及記下相依性。 為了清楚起見，請使用圖表記錄結果和例外狀況。 此目錄可作為與商務項目關係人進行初始交談的重要工具，以從他們的觀點識別最重要的層面。 此交談可以提供優先考量的首要層面的資訊。

藉由評估主要商務活動的風險和影響，將流程分類為關鍵。 如果您預期發生中斷，則正常降低著重於維護這些重要流程。 在電子商務範例中，重要流程包括產品搜尋、將專案新增至購物車，以及結帳，因為這些工作對商務而言很重要。 其他流程，例如更新產品數據和維護產品圖片，並不那麼重要。 確保關鍵流程在中斷期間保持運作，以防止營收損失，讓用戶繼續搜尋產品，並將專案新增至購物車。

備註

即使商業流程對時間不敏感，它仍然可能是關鍵的。 時間關鍵性是一個關鍵因素。 例如，滿足稽核要求是一個重要過程，但您可能不需要立即呈現稽核數據。 此過程仍然很重要，但其可靠性不是即時而是重要，因為在數小時內復原是可接受的。

如需詳細資訊，請參閱 Azure Well-Architected Framework：使用流程優化工作負載設計。

✓ 選取正確的設計模型、資源和功能

您應該在下列層級套用此策略：

  • 建築： 工作負載設計應該考慮各種基礎結構層級的可靠性預期。 您的初始決策可能是裝載應用程式的容器化或 PaaS 之間的選擇。 或者，您可以考慮網路設定，例如中樞和輪輻或單一虛擬網路。

    您也應該設定界限，根據功能建立分割。 例如，不要在單一區域虛擬磁碟的一部 VM 上裝載所有專案，請考慮分割計算和數據記憶體，並使用專用服務。

    謹慎

    在移轉案例中，在不檢閱新機會的情況下採用「直接搬移」方式，可能會導致錯失的好處和效率低下。 請務必儘早研究現代化，以避免遇到難以變更的設定，並利用更好的選項和改進功能。

  • Azure 服務： 使用判定樹來協助您為設計選取正確的服務。 選擇符合您目前需求的元件，但保持彈性，讓您可以在工作負載發展且需要更多功能時切換服務。

  • Azure 服務內的 SKU 或階層： 檢閱每個 SKU 的功能，並瞭解平臺的可用性保證。 評估服務等級協定，以瞭解與已發佈百分位數相關的涵蓋範圍。

  • 支援可靠性的功能： 選擇雲端原生服務，透過簡單的設定來增強可用性，而不需變更程序代碼。 請務必瞭解選項，並刻意選取組態，例如增加區域備援或將數據復寫至次要區域。

✓ 使用基本層級備援進行部署

在您的解決方案的每個部分中，避免單一失敗點，例如單一實例。 請改為建立多個實例以進行備援。 Azure 服務通常會為您處理備援，特別是使用 PaaS 服務，通常預設會包含本機備援，以及升級的選項。 最好使用區域備援，將這些實例分散到多個 Azure 數據中心。 如果您未這麼做，請至少確保本機備援，但此方法的風險較高。 在未來的層級中，您可以藉由使用異地備援元件擴充解決方案，來評估可靠性需求是否符合。

折衷： 一個重要的取捨是備援成本增加。 此外，跨區域通訊可能會帶來延遲。 對於需要最少延遲的舊版應用程式，備援可能會降低效能。

風險： 如果應用程式不是針對多個實例環境所設計，它可能會與多個作用中實例作鬥爭，這可能會導致數據不一致。 此外，如果應用程式是針對低延遲的內部部署設定所建置，則使用可用性區域可能會中斷其效能。

✓ 啟用計量、記錄和追蹤以監視流程

選擇 Azure 監視器之類的平臺原生工具，以確保計量、記錄和追蹤的可見度。 使用內建功能來設定潛在問題的警示。 您應該已備妥基本警示，以傳送通知並取得警示。 利用指出服務健康狀態變更的 Azure 平臺功能，例如：

設定基礎結構和應用程式的 Azure 監視器動作群組 。

權衡： 當您收集更多記錄時，您需要管理不斷增加的數量，這會影響這些記錄的儲存相關成本。 使用保存策略來管理數據量。 使用 Azure 監視器在工作區上設定每日上限。 如需詳細資訊，請參閱 可靠性的設定建議。

開始在下列層級建置可觀察性。

基礎結構

從啟用診斷記錄開始，並確定您從平台元件收集原生計量進行分析。 收集資源使用量的相關信息，例如 CPU、記憶體、輸入/輸出和網路活動。

應用程式

收集應用層級計量，例如記憶體耗用量或要求延遲，以及記錄應用程式活動。 在與主要應用程式線程分開的線程或進程中執行記錄作業。 這種方法不會讓記錄讓應用程式的主要工作變慢。

此外，請檢查Application Insights中 的基本可用性測試 。

資料

若要監視基本層級的資料庫，請收集資料庫資源發出的關鍵計量。 類似於基礎結構元件，監控在資料存儲庫情境下的資源使用量，例如網絡指標。 收集有關連線池化方式的數據對於提升後續階段的效率非常重要。

為了可靠性，務必追蹤連線指標，例如監視活動中和失敗的連線。 例如，在 Azure Cosmos DB 中，當要求數目超過配置的要求單位和連線開始失敗時，會傳回 429 狀態代碼。

✓ 開始建置失敗風險降低劇本

故障範圍涵蓋從間歇性到稍微延長期間的瞬間故障，以及災難性中斷。

在第一層級中，將焦點放在平台故障。 即使它們超出您可控的範圍，您仍然應該有應對它們的策略。 例如，使用可用性區域解決區域性中斷。 預期平台層級的暫時性錯誤，並在您的作業負載中處理這些錯誤。

處理這些失敗的程式會根據複雜性而有所不同。 開始記錄潛在的平臺層級失敗、其相關聯的風險，以及風險降低策略。 此練習主要是理論性的，而且在後期階段通過自動化來提升成熟度。

您應該記錄失敗，包括其可能性、影響和風險降低策略等因素。 使用符合您工作負載目標的關鍵性等級。 您的規模可能包括：

  • 高。 完整的系統中斷，導致重大財務損失和使用者信任下降。

  • 中等。 影響部分工作負載並造成使用者不便的暫時中斷。

  • 低。 影響應用程式非必要功能的次要軟體問題，僅造成使用者極短暫的停機時間。

以下是範例範本：

問題 風險 來源 嚴重程度 可能性 緩和措施
暫時性網路失敗 用戶端會失去與應用程式伺服器的連線。 Azure 平台 高 很可能 在客戶端邏輯中使用設計模式，例如重試邏輯和斷路器。
區域中斷 使用者無法連線到應用程式。 Azure 平台 高 不太可能 在所有元件上啟用區域復原功能。
傳輸層安全性 （TLS） 憑證到期 用戶端無法與應用程式建立 TLS 工作端。 人為錯誤 高 有可能 使用自動化 TLS 憑證管理。
CPU 或記憶體使用量達到定義的限制，並導致伺服器失敗。 要求逾時。 應用程式 中等 有可能 實作自動重新啟動。
元件在更新期間無法使用。 使用者在應用程式中遇到未處理的錯誤。 部署或設定中的變更 低 部署期間極有可能，有時不太可能 處理客戶端邏輯中的元件。

在層級 1 中，請勿爭取完整性，因為總是有無法預見的失敗案例。 如果您遇到非預期的中斷情況，請在劇本中記錄原因和風險降低措施。 將此資產視為您隨著時間更新的活體檔。

✓ 新增機制以從暫時性失敗中復原

在雲端環境中，暫時性失敗很常見。 一般來說，這些問題在重試後能在幾秒內解決，表明只是短期問題。

使用內建 SDK 和組態來處理這些錯誤，讓系統保持作用中。 內建組態通常是預設設定，因此您可能需要測試以驗證實作。 此外，實作設計用來處理架構中暫時性失敗的模式。 如需詳細資訊，請參閱 支援可靠性的架構設計模式。

持續性問題可能表示故障並非短暫，或是中斷的開始。 這個情境不僅需要解決應用程式內部的局部問題。 它涉及檢查系統的重要使用者和系統流程，以及新增自我保留技術和復原工作。 這些方法是層級 2 所描述的成熟做法。

✓ 執行基本測試

在軟體開發生命週期的早期階段整合基本可靠性測試。 尋找執行測試的機會，從單元測試開始，以驗證功能和設定。

此外，針對您在風險降低劇本中識別的問題，開發簡單的測試案例。 專注於高影響力、較低成本的緩解措施。 例如，模擬網路中斷或間歇性連線問題，以查看重試邏輯如何解決中斷情況。

風險： 測試通常會在開發週期中帶來摩擦。 若要降低此風險，請讓可靠性測試與開發工作一起追蹤。

特徵開發是優先事項，而測試可以在開發週期中引入摩擦。 在功能開發完成之前，更容易開始測試。 在開始設計應用程式的非功能性需求時，可以讓您在新增功能時加以擴充，而不是累積將來需解決的問題。 雖然此方法一開始需要更多工作，但可管理並防止稍後發生較大的問題。

後續步驟

  • Last updated on