適用於以下 Azure Well-Architected Framework 可靠性檢查清單建議：
| RE：08 | 藉由套用混亂工程的原則來測試復原和可用性案例。 利用可靠性測試來驗證你的工作負載能否承受故障、按需擴展，並在設定目標內恢復。 |
|---|
可靠性測試能在架構缺陷造成停電前發現。 若不針對失敗情境進行刻意測試，你無法知道韌性模式是否有效，或工作負載是否能在既定目標內恢復。
當你測試影響可用性的安全風險、導致系統無法使用的效能問題，以及限制事件回應的營運缺口時，你能強化工作負載的可靠性。 運用本文中的策略，建立一個測試節奏，定期驗證你的工作負載與其失敗模式的對照。 隨著架構變動及事件揭露新弱點，逐步演進你的測試。 建立信心，相信你的工作負載能承受故障、可擴展以滿足需求，並在 RTO 與 RPO 目標內恢復，同時建立反饋循環，隨時間強化你的可靠性態勢。
本文的關鍵策略建立在 OE：09 《測試架構策略》中所述的基礎測試實務之上。 先看那篇文章。 本指南中的建議以可靠性為核心，並著重於建立對工作負載在目標範圍內承受故障與恢復能力的信心。
下表定義了本文中主要使用的可靠性術語。
定義
| 字詞 | Definition |
|---|---|
| Availability | 應用程式工作負載以狀況良好狀態執行的時間量，而不需要長時間停機。 |
| 混亂工程 | 這種做法是將混亂測試安全地融入團隊文化、工程實務與開發生命週期，推動系統韌性持續改進。 |
| 混沌測試 | 一個受控實驗，驗證了關於工作負載在破壞性條件下應如何行為的特定韌性假說。 |
| 錯誤插入 | 一種在元件、相依項或系統路徑中刻意引入故障的技術。 |
| 復原能力 | 在復原時間目標（RTO）和復原點目標（RPO）內，具備中斷後還原正常作業的能力。 |
| Resiliency | 工作負載能否承受故障（如短暫錯誤、基礎設施中斷、需求激增），並持續在可接受的使用者體驗內運作。 |
| 故障轉移 | 當主要元件故障時，切換到次要元件的過程。 |
| Failback | 在主要區域復原後，於該區域恢復作業的過程。 |
| 錯誤預算 | 系統在特定期間內的最大可接受故障等級，依據服務水準目標（SLOs）得出。 |
根據服務類型定義可靠性測試範圍
在定義可靠性測試範圍時，請考慮你所使用服務的共同責任模式。 每種服務類型（IaaS、PaaS、SaaS）都有不同的可靠性保證，以及對故障處理的控制層級也不同。 將測試重點放在你擁有的可靠性方面。
讓測試深度符合你的責任。 對於基礎設施服務（IaaS），你的團隊擁有大部分的可靠性決策權，因此應投資於混沌工程與故障注入的徹底驗證。 對於平台（PaaS）和軟體（SaaS）服務，供應商負責管理大部分底層的可靠性。 重點放在你的工作負載如何與這些服務互動，例如它如何處理 PaaS 中的基礎設施故障轉移、限速、服務降級或負載模式的變化。
考慮混合服務的工作負載。 當你的工作負載跨越多種服務類型時，測試責任會在不同元件間有所不同。 你可能會在可用區域發生中斷時，測試以 VM 為基礎的基礎架構元件之故障轉移；但對於專為高可用性而設計的 PaaS 資料庫，則可依賴供應商提供的保障。 找出這些界線，並確保你的測試涵蓋了兩者之間的空隙。
根據您的可靠性目標進行端對端測試
你的可靠性目標，如 SLO、RTO 和 RPO，定義了你在故障條件下工作負載應如何表現。 將它們作為完整關鍵流程的通過與不通過標準，而非僅僅是單一元件。
在整個流程中驗證復原。 即使單一元件可能在其 RTO 內復原，但如果下游相依項目也需要復原，整體復原時間仍可能超出您的目標。 考慮整個流程的總復原時間，包括偵測問題與回應的時間。
以 SLO 和錯誤預算定義測試範圍。 你的錯誤預算表示你可投入於故障注入的資源。 限制混沌測試以維持在 SLO 範圍內，並利用流量恢復目標來定義每個測試的邊界。
從關鍵流程與故障模式建立可靠性情境
從你工作量中的關鍵流程開始，以及可能影響它們的故障模式。 運用 你的失敗模式分析 找出最具影響力的失敗情境，並建立驗證韌性與復原策略的測試。
依影響和可能性來優先排序。 並非所有故障模式都值得相同的測試投資。 首先聚焦於對使用者影響最大且發生機率最高的情境。 讓你的故障模式分析來主導這個優先順序。
驗證您的容錯與恢復機制
專注於最可能造成停機或降低使用者體驗的情境。 運用本節策略，建立測試以驗證您的工作負載處理故障與有效復原能力。
備份與還原
您的備份與還原測試應驗證您的資料保護方法是否符合復原目標。
制定測試週期。 根據備份設定、資料結構或基礎設施變更的頻率，判斷你需要多久測試還原。 更頻繁的變更需要更頻繁的還原測試。
設定復原目標。 將實際還原時間與你的 RPO 和 RTO 目標比較，以確認你的備份策略符合復原目標。
不要假設備份完全完整。 備份可能會被錯誤設定，只捕捉部分資料。 驗證資料的完整性與完整性，而不僅僅是還原操作是否成功。
單獨測試。 在與生產環境分開的環境中驗證還原，這樣你才能在不中斷即時工作負載的情況下進行徹底檢查。
暫時性錯誤
暫時性故障，如短暫的網路中斷、短暫的服務中斷及連線逾時，都是常見的可靠性風險。 驗證你的工作負載能在不影響使用者的情況下處理這些故障。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
專注於你擁有的東西。 如果你的 SDK 或平台服務能自動處理重試和斷路，請測試當這些內建機制耗盡時會發生什麼，例如所有重試失敗或斷路器開啟時。
驗證故障處理配置。 評估你的工作負載的故障處理配置。 驗證重試政策、斷路器閾值及逾時值在真實故障條件下是否如預期般運作。
測試暫時性與持續性失效的界線。 驗證您的工作負載在故障持續時間超過預期門檻時，是否能從重試機制平順地轉為後援機制或降級模式。
考慮韌性特徵帶來的暫時性故障。 區域冗餘及類似設計常在正常故障轉移操作中產生暫態故障。 例如，區域冗餘資料庫可能在流量轉移到健康區域時造成短暫連線失敗。 測試你的工作負載是否能在不對使用者造成重大影響的情況下處理這些預期的暫時性故障。
負載與縮放反應
確認你的工作量在需求變化時，無論是突發高峰還是漸進式增加，都能維持可靠性。 欲了解更多資訊，請參閱 擴展策略。 有關載荷與應力測試的指引，請參見 測試建議。
同時測試擴展（scale-out）與縮減（scale-in）。 確認新容量上線的速度夠快，且擴展不會丟棄請求或留下孤立資源。
將縮放延遲納入考量。 從達到觸發擴展條件到新容量準備好之間，總是會有延遲。 判斷你的工作量是否能在這段空檔中應付需求，或是否需要預先預備額外容量。
相依性失敗
你的工作量很可能依賴於你無法直接控制的服務，例如第三方 API、受管理平台服務或共享的內部服務。 驗證您的工作負載在這些相依性發生故障時，仍能妥善因應，而不會對使用者造成重大干擾。
依關鍵性分類相依關係。 並非所有依賴都值得相同的測試投資。 優先測試位於您的關鍵流程中，且缺乏內建冗餘機制或後備路徑的相依項目。
測試每個相依項的回退行為。 當某項依賴變得無法使用時，您的工作負載應回退至替代路徑或替代行為，而不是完全失效。 確認每個備援都能正確啟用，且其他無關功能也能正常運作。
將部分故障與級聯故障納入考量。 依賴項很少會以非此即彼的方式失效。 不要只測試完全中斷的情況。 涵蓋延遲增加、間歇性錯誤及部分資料可用性。
驗證隔離效果及影響範圍的侷限性。 確認單一相依性失敗不會連帶到無關的功能。
自我保護與復原
驗證你的 自我修復與自我保護設計 在故障時的反應，包括在完全恢復尚未立即發生時，你的工作量是否能以較低的狀態繼續運作。
測試端對端自動復原。 評估你的健康模型，確保包含正確的檢查。 確認這些檢查能準確偵測故障，如預期觸發自動修復，並在可接受的時間內將系統恢復到健康狀態。
驗證手動復原執行手冊。 自動恢復無法涵蓋所有情況。 在現實條件下測試手動跑程簿，確保操作員能在壓力下執行，並在你的恢復時間目標內完成。
認可優雅的降級行為。 當某個元件失效時，你的工作負載應平順降級，而不是完全失效。 測試系統是否能以降級模式運作，例如將請求排入佇列以供人工審查，並確認這種降級後的體驗是否為使用者所接受。 確認你的團隊知道如何在此狀態下操作工作負載，以及如何恢復完整功能。
事件與災難復原（DR）
當事件或災難發生時，您能迅速偵測並有效回應的能力至關重要。 測試您的計畫與流程，確保它們能處理災難性故障與重大事故。 使用專用環境進行災難復原測試，以避免影響生產工作負載。 欲了解更多資訊，請參閱 災難復原計畫。
驗證事件偵測機制。 模擬事件，以驗證監控日誌是否捕捉必要資訊，且警示是否正確觸發。 例如，測試偵測到增加的請求失敗率的速度，以及監控資料的取樣頻率。
測試事件管理流程。 確認您的團隊能有效遵循事件應變程序。 欲了解更多資訊，請參閱 事件應變。
全面測試故障切換與故障復原。 單獨測試單一零件可能會漏掉只有在真實切換時才會出現的協調失敗。 驗證完整的故障轉移序列，包括 DNS 切換、恢復備份與資料複製一致性，以及用戶端重新連線。 也要測試切換回主要部署，這通常比初次切換更複雜。
在故障轉移環境中驗證容量。 確認你的備援環境是否有足夠的預設容量，能在備援時立即處理流量，且不會在負載下崩潰。 測試環境是否能維持運作，同時擴展機制啟動並驗證你的擴展方法。 欲了解更多資訊，請參閱 負載與擴展響應。
對照你的目標衡量。 如果 DR 測試未達到您的 RTO 或 RPO 目標，請分析其中的差距，並據此更新您的 DR 計畫。
驗證人員與流程。 災難復原測試應驗證通訊管道，確認操作員擁有執行復原程序所需的存取權與權限，並確保能在壓力下迅速找到災難復原專屬的跑程簿。
用桌上練習來測試和評估你的計畫
桌上遊戲練習能幫助你在真實事故揭露前，找出可靠性測試的漏洞。 透過與團隊模擬故障情境，您可以識別未測試的狀況，並驗證回應程序是否如預期運作。
模擬真實事件。 走過一個失敗情境，例如區域性停機或部署損壞，並讓你的團隊描述他們會採取哪些步驟來偵測、回應及恢復。 這些討論常常揭露了尚未經過測試驗證的系統行為假設。
將發現轉化為測試案例。 利用演習中浮現的漏洞與未知數，來創造新的可靠性測試。 如果團隊發現沒有人知道當某個相依性失敗時，工作負載會如何運作，這就是你可以加入測試策略的情境。
善用計劃性與非計劃性中斷
當您的工作負載因為計劃性維護或非計劃性中斷而離線時，您有機會執行測試並改善您對工作負載的理解。
計劃性維護
在更新或修補的維護期間，測試與維護工作無關的元件和流程。 你可以執行測試，而不會有意外降低工作負載或讓它離線的風險。 如果時間充足，工作完成後也請測試維護作業中涉及的元件。
非計劃性中斷
每一次意外中斷都是強化可靠性測試策略的好機會。 恢復服務並完成事後審查後，利用你的發現來改進你的測試。
測試你的緩解措施。 如果你已經用了臨時或變通方法，請在永久修正前驗證它能承受預期負載。
掃描類似的弱點。 檢查其他元件是否包含導致停電的相同配置或設計模式。 在這些元件以同樣方式失效前，先對這些元件進行測試。
結合不同類型的測驗
當你同時執行不同類型的測試時，可以發現獨立執行時看不出來的可靠性問題。 工作負載在正常情況下可能處理特定負載，但同一負載在引入故障時會導致故障。
重複使用現有的測試基礎設施。 如果你已經有基礎建設和負載測試線束，可以用它同時執行混沌測試。 在同一次測試中結合負載與故障注入，可以展示在需求與故障同時發生的真實條件下，你的工作負載表現如何。
從非生產環境開始。 在風險較低的環境中開始可靠性測試，這樣你就能安全地探索故障模式。 只有在你已充分從非生產環境獲得可用洞察，並已設妥防護措施以限制影響範圍及快速回滾後，才可轉入生產環境測試。
使用故障注入和混沌工程
錯誤注入與混沌工程透過刻意引入故障並觀察回應，幫助你建立對工作負載韌性的信心。 在進行實驗前，務必確保你有應對措施。
定期進行混沌實驗。 評估你的 測試範圍。 在你原本認為可靠的元件和流程中注入故障。 隨著架構的改變，新的失效模式會出現，過去的假設可能不再成立。 以規律的節奏進行實驗，捕捉迴歸現象、驗證新的依賴性，並確認近期變更沒有引入弱點。
利用你的失敗模式分析來聚焦實驗。 每個實驗都應針對特定故障或一組故障，並有明確的假設，例如測試特定流動承受特定組件損失的能力。 當實驗發現新的故障模式或未發現的依賴性時，請更新你的故障模式分析以保持最新。
實驗期間控制爆炸範圍。 以可快速復原的元件為目標，並根據充分資訊設定對每次故障注入影響的預期。 如果實驗超出範圍或產生意外結果，就停止。 在收集有意義資料與盡量減少對使用者影響之間取得平衡。
以基線來衡量。 建立每個實驗中流程與元件的一致性可靠性與效能指標。 將退化狀態指標與這些基準線比較，以了解故障的全部影響，並判斷你的韌性設計是否達到目標。
將結果回饋到你的測試策略中。 利用實驗結果推動新測試、更新復原計畫，並告知補救積壓項目。 當出現意外行為時，針對這些行為建立針對性的測試並設計補救策略。
取捨：生產環境中的故障注入測試可能會造成干擾，而且可能會導致停機。 對利害關係人保持透明，說明此可能性。 設置防護措施，讓你能迅速停止實驗並回撤，並在敏感期間靈活決定何時進行測試或避免測試。 為了防範意外停機，請規劃足夠的 備援 ，並確保利害關係人了解成本的取捨。
風險： 可靠性測試可以擴大涵蓋多種故障模式，但一旦它不再提供有意義的價值，就應該停止。 如果你已經有一堆已知的可靠性問題，優先解決這些問題，而不是增加更多測試。
Azure 支援服務
Azure 測試計畫 是一款基於瀏覽器的測試管理解決方案，提供計畫手動測試、使用者驗收測試、探索性測試及利害關係人回饋收集所需的所有功能。
Azure Chaos Studio 是一項管理服務，利用混沌測試幫助你衡量、理解並提升雲端應用與服務韌性。
Azure 應用程式測試 是一項服務，允許你用 Azure 負載測試 來執行包含 劇作家工作區 的功能測試和效能測試，以識別應用程式中的問題。
Azure 服務健康狀態 有一個計畫維護窗格，是Azure入口網站中專門的區域，隨時告知即將進行的維護活動。 它會突顯可能影響 Azure 資源的事件，幫助你提前做好準備。
連線監視器 是 Azure 網路監看員 的功能，可用來綜合監視和即時測試 Azure 和混合式環境中的網路連線。 在混沌工程場景中，連線監視器可用於將故障注入目標網路元件，並持續測量延遲和封包遺失等關鍵指標。 此功能可讓團隊觀察中斷如何影響網路可靠性，無論是個別流程元件還是端對端網路路徑。 若要評估故障的影響並確定需要改進的領域，請將連線監視器遙測與基準指標進行比較。
相關連結
可靠性檢查清單
請參閱一組完整的建議。