可靠性設計原則

本文翻譯自：Microsoft 發布 Reliability design principles
原文連結：https://github.com/MicrosoftDocs/well-architected/blob/main/well-architected/reliability/principles.md
翻譯日期：2024-12-27

服務中斷與故障對於所有工作負載(workload)來說都是嚴重的問題。可靠的工作負載必須要能安然度過任何可能造成服務中斷與故障的事件，並持續穩定提供其原本的功能。可靠的工作負載同時必須具有韌性，以在可接受的時間內偵測、承受故障並恢復運作。最後，可靠的工作負載還必須可用，以便使用者能在約定的期間內以約定的服務品質水準存取工作負載。

假設故障不會發生是不切實際的，特別是當工作負載建置在分散式系統上執行時，是可能發生有些元件故障，而其他元件是可以繼續運作的情況。在某些狀況下，使用者體驗可能會受到影響，因而損害業務目標。

工作負載的架構，應該在程式碼、基礎架構與運作等方面具有可靠性保證。架構設計的選擇不應改變業務需求，因為此類改變應被視為影響程度重大的權衡取捨。

設計原則的目的，是在開發生命週期全程中，指引您考慮到可靠性的各個面向。從建議的方法開始著手，依循設計原則並驗證這樣做所帶來的好處。設定策略之後，請使用可靠性設計檢查清單來推展後續行動。

如果未應用這些原則至您的架構設計中，則可能無法預測或處理正式環境中的問題，結果導致服務中斷或造成財物損失。在關鍵工作負載未應用這些設計原則，可能會危及安全性。

針對業務需求進行設計

目標：收集業務需求，並專注於工作負載的預期作用

架構設計必須顧及到工作負載的使用者體驗、資料、工作流程以及特性。業務需求必須清楚說明期望架構設計能達成什麼樣的目標與狀態。在指定投資的情況下，目標必須可以實現且經過與團隊協商，記錄下投資是否能實現目標的可行性評估，以及與團隊協商的細節，據以選擇適合的技術、落實到後續營運中。

方法	效益
透過為各個元件、系統流程與系統整體指標訂定目標值，以量化成果。這些目標值是否能提升使用者流程可靠性？	指標可將期望量化，讓您能了解系統的複雜性，並判斷這些複雜性衍生的成本是否在預算範圍內。目標值表示理想狀態。您可以使用這些值作為測試閾值(threshold)，幫助您偵測與理想狀態的差異以及返回目標狀態所需的時間。合規性要求也必須確保範圍內的流程產生可預測的結果。優先考慮這些流程，能讓您關注最重要的領域。
了解平台承諾。請考量服務的限制、配額、區域與容量限制。	服務水準協議(SLA)視服務而異，並非所有服務與功能的涵蓋範圍都相同，也不是所有服務或功能在所有區域都可以使用。大多數的訂閱資源限制都是按區域劃分。充分了解涵蓋範圍與限制，可以幫助您偵測變動(drift)並建立韌性與復原機制。
判斷相依性及其對韌性的影響。	追蹤其他團隊或第三方開發的基礎架構、服務、API和功能與工作負載的相依性，有助於您確認工作負載是否能在沒有外部依賴的狀況下運作。它還可以幫助您了解連鎖故障(cascading failures)並改善下游系統的運作。當您使用容易發生故障的外部服務時，開發人員可以採用韌性設計模式(resilient design pattern) 處理可能會發生的故障。

韌性導向設計

目標：工作負載必須在完整或減少功能的狀況下繼續運作

您應該預期會發生元件故障、平台服務中斷、效能下降、資源可用性有限與其他故障。在系統中建立韌性， 使其具有容錯能力並能優雅地降級服務(degrade gracefully)。

方法	效益
區分出關鍵路徑上的元件，以及可處於降級狀態的元件。	並非所有工作負載中的元件必須同樣可靠。判斷各元件的重要性，可協助您根據每個元件的關鍵性進行設計。相較於可能只會稍微影響使用者體驗的元件，您會想投入較多心力照顧關鍵元件的韌性，因為如果此關鍵元件發生故障時，可能會造成整個流程的問題(end-to-end problems)。 此設計方法可以將資源有效分配給關鍵元件。同時，您也可以採取故障隔離策略，以便在非關鍵元件發生故障或進入降級狀態時將其隔離，以防止連鎖故障發生。
識別系統中的潛在故障點，尤其是關鍵元件，並判斷對使用者流程的影響。	您可以分析故障案例、影響範圍與故障程度：是全部中斷或部分中斷。針對元件層級錯誤，設計錯誤處理功能時可參考這些分析結果。
透過正確使用設計模式與模組化設計來隔離故障，建立自我保護能力。	透過這些設計，系統將能防止問題影響下游元件，並能夠緩解暫時性與永久性故障、效能瓶頸以及其他可能影響可靠性的問題。同時，您也可以儘量將故障的影響範圍縮小到最低限度。
透過考量受支援區域中服務的容量限制，增加關鍵元件(應用程式與基礎架構)的擴展(scale out)能力。	工作負載將能處理持續變動的容量高峰值與波動。當系統出現意外負載(例如有效使用量激增)時，這項擴展能力非常關鍵。如果工作負載設計能擴展至多個區域，甚至可以克服潛在的臨時資源容量限制或解決影響單一區域的其他問題。
在各個應用層上建立分層與具備韌性的備援。	備援可以最大限度地減少單點故障的風險。例如，如果有元件、地區或區域服務中斷，備援部署(active-active 或 active-passive 模式)都能幫助您達成業務持續運作的時間目標。此外，新增媒介服務可以防止元件之間的直接相依性，並改善緩衝處理。這兩個好處都強化了系統的韌性。
冗餘布建(overprovision)可透過備援執行個體立即緩解個別執行個體故障帶來的影響，並為失控的資源消耗(runaway resource consumption)提供緩衝(buffer)。	對冗餘布建的投資將進一步增強系統韌性。即使在擴展式架構開始修復故障之前，系統仍會在故障尚未排除的期間，維持完整功能運作。此設計還能降低意外狀況耗盡預留的資源餘裕(planned buffer)的風險，並在系統故障或更大規模擴展發生之前，取得關鍵的分級處置時間(critical triage time)。

復原導向設計

目標：工作負載必須能預測大多數、各種程度的故障並從中復原，同時將對使用者體驗與業務目標的干擾降至最低

即使是具有高度韌性的系統，也需要在架構設計與工作負載運作方面採取災害因應措施(disaster preparedness approaches)。在資料層上，您應該制訂當發生損壞時，修復工作負載狀態的措施。

方法	效益
制定能達成復原目標的復原計畫(應結構化、驗證過、文件化)。計畫必須涵蓋整個系統以及所有元件。	定義明確的流程可以實現快速復原，以防止對企業的財務與聲譽產生負面影響。當時間與資料完整性是衡量成功的關鍵標準時，必須定期進行復原演練測試復原系統的元件、資料、故障移轉以及故障回復步驟流程，避免在緊急狀況下手忙腳亂。
請確定您可以修復復原目標內所有具狀態元件的資料。	備份是使用受信任的復原點讓系統還原到運作狀態的必要條件，例如最後已知的良好狀態。備份必須是不可變(immutable)，且確保所有交易紀錄(transactionally consistent) 無法被竄改，並確保復原的資料不會損毀。
在設計中實現自動化自我修復能力。	這種自動化可降低外部因素的風險，例如人為介入，並縮短中斷的修復週期。
以不可改動的臨時元件取代無狀態元件。	建置可視需要啟動與銷毀的臨時元件，確保可重複性與一致性。使用並存部署的模式，逐步轉換到新元件上，將服務中斷風險降至最低。

營運導向設計

目標：在運作週期中向左移動以預測故障狀況

在開發生命週期中儘早並經常進行測試，確認效能對可靠性的影響。為了進行根本原因分析與事後分析，您需要跨團隊共享相依性狀態與已知尚未修正的故障。觀察系統得來的洞察、診斷與警示，是有效事件應變與持續改善的基礎。

方法	效益
建立可以監控的系統	如果某個元件故障了，需要接收故障通知、故障時間以及故障原因。元件層級的可監控性是基礎要求，還需要元件與使用者流程相互關聯的彙整成整體健康的狀態資訊，才能讓可靠性工程師根據這些訊息決定各項修復作業的優先順序。
預測潛在的故障與異常行為。 透過具有優先順序與可採取動作的警示，讓正在發生的可靠性問題可被監測。 投資可以加速分級處置(triage)的流程與基礎架構，有助於提高應對故障的效率。	可靠性工程師可以立即收到通知，以便緩解正在發生且尚未解除狀況的事件，並在預測警示發現的潛在故障時，成為即時事件之前主動緩解這些故障。
在正式環境與正式上版前的測試環境中模擬故障並執行測試，以利準備應對實際情況。	在正式過程中模擬故障是有幫助的，這樣您就可以訂定更符合實際狀況的復原期望，進一步做出設計選擇，順利因應故障。此外，它還讓您能測試為業務指標設定的閾值。
建置元件時考量自動化，並盡可能提高自動化程度。	自動化可儘量減少人為失誤的機率，進而實現測試、部署與營運的一致性。
考量日常作業及其對系統穩定性的影響。	工作負載可能會受到持續發生的各項營運作業影響，例如應用程式改版、安全性與合規性稽核、元件升級與備份流程。仔細檢查這些變更可確保系統的穩定性。
持續從正式環境發生的事件中學習。	您可以評估正式環境內發生事件的影響程度，找出設計與營運過程可能忽略的細節，並根據真實事件推動改善。

簡化作業流程

目標：避免過度設計，簡化架構設計、程式碼與作業流程

通常，最可靠的解決方案往往來自於精簡而非增加元素。 簡單性能減少需要管控的範圍，避免效率低下、設定錯誤或意外交互作用的風險。然而，過度簡化可能導致單點故障。在簡化設計與過度設計之間取得平衡會是關鍵。

方法	效益
只有在元件能幫助您實現業務價值時，才將其納入架構。讓關鍵路徑保持精簡。	針對業務需求進行設計，可以獲得容易實施與管理的簡單解決方案。避免過多的關鍵元件，因為每個元件都可能成為潛在故障點。
程式碼實作、部署與流程都應建立標準並文件化。使用自動驗證確保依照標準執行。	標準可提供一致性，儘量減少人為失誤。標準命名慣例與程式碼格式指南等方法可幫助您保持品質，並使資產在故障排除時容易識別。
評估理論方法是否可轉化為適用於您使用案例的實用設計。	過於細瑣的程式碼可能會產生不必要的相互依賴、額外的營運作業以及難以維護的問題。
程式碼適量即可。	程式碼應保持適量，避免因效率不彰而產生的問題，例如資源消耗過大、使用者或資料流程出錯以及程式碼漏洞。相反的，應對可靠性問題應該進行程式碼審查，以確保程式碼有足夠的韌性能處理故障。
利用平台提供的功能與預先建置的資產，以協助您有效地實現業務目標。	這個方法可顯著縮短開發時間。同時，它也可讓您借鑒性質類似的工作負載驗證過與經過測試的最佳做法。

後續步驟(簡化作業流程)

可參考 可靠性設計檢查清單，來檢視自己目前當下策略狀況。

可靠性設計檢查清單

此檢查清單提供一組建議，供您用於評估架構設計中的可靠性、韌性與故障復原策略。為了確保可靠性，請確定適合您工作負載的最佳基礎架構與應用程式設計，並根據對應到可用性與可恢復性目標指標的業務需求進行這些決策。

若要實作可靠的設計，請徹底考量設計中的決策點，並了解這些決策如何影響您的工作負載。此檢查清單與指南文件連結，可幫助您做出這些決策。請將工作負載可靠性作為整個工作負載設計、開發與營運生命週期的核心考量因素。

檢查清單

在設計時專注於可靠性，有助於確保您能夠設計出具有韌性、可管理且可重複的工作負載。如果您未應用可靠性設計原則並根據專案狀況作出取捨，您的設計可能會有風險。因此，請仔細考量檢查清單中的所有要點，以鞏固您對系統可靠性的信心。

	文件編碼	建議
☐	RE:01	設計您的工作負載以符合業務目標，並避免不必要的複雜性或開銷。使用務實且平衡的方法做出設計決策，以實現所需的結果。讓您的設計滿足必要條件，以減少效率不彰與潛在問題。
☐	RE:02	識別並評估使用者與系統流程。 根據您的業務需求使用嚴重性來確定流程的優先順序。
☐	RE:03	使用故障模式分析(FMA)來識別解決方案元件中的潛在故障並確定其優先順序。 執行 FMA 可協助您評估每種故障模式的風險與影響，並了解工作負載如何回應與復原。
☐	RE:04	定義元件、流程與整體解決方案的可靠性與復原目標。 將目標視覺化呈現，以便 進行協商、達成共識、訂定期望，並推動行動 以實現理想狀態。根據設定的目標建立健康狀態模型，該模型定義了健康、降級與不健康狀態。
☐	RE:05	在不同的層級加入備援，尤其是對於關鍵流程。 根據確定的可靠性目標，將備援應用於運算、資料、網路與其他基礎架構層。
☐	RE:06	在應用程式、資料與基礎架構層級實作即時且可靠的擴展策略。
☐	RE:07	透過實施自我保護與自我修復措施，強化工作負載的韌性與可恢復性。 規劃解決方案時，引入基於基礎架構或軟體的可靠性設計模式，來處理元件故障與暫時性錯誤。使系統具備偵測故障的能力，並自動啟動處理措施，同時確保工作負載以完整功能或降級的狀態持續營運。
☐	RE:08	透過在測試與正式環境中應用混沌工程原則，測試韌性與可用性情境。 透過執行主動故障與模擬負載測試，使用測試來確保您實作的優雅降級服務與擴展策略有效。
☐	RE:09	實施與復原目標一致的結構化、經測試並文件化的業務連續性與災害復原(BCDR)計畫。 計畫必須涵蓋所有元件與整個系統。
☐	RE:10	持續測量解決方案的健康狀態訊號並對其進行建模。 從整個工作負載以及各個元件與關鍵流程中，持續擷取正常運作時間與其他可靠性資料。

後續步驟(可靠性設計檢查清單)

我們建議您查看可靠性權衡取捨以探索其他概念。

註解：本文最後一行提及的「可靠性權衡取捨」提供了一個外部連結，以進一步說明如何在可靠性設計中進行取捨的原則與方法。若對此主題有更深入的需求，可以點擊連結查閱詳細內容。