可靠性設計準則

中斷和故障是所有工作負載的嚴重考慮。 可靠的工作負載必須存留這些事件，並繼續 持續提供其預期功能。 它必須 具有復原能力 ，才能在可接受的期間內偵測、承受及從失敗中復原。 它也必須 可供使用 ，讓使用者可以在承諾的品質等級期間存取工作負載。

假設不會發生失敗並不實際，特別是當工作負載建置在分散式系統上執行時。 有些元件可能會失敗，而其他元件仍可繼續運作。 在某些情況下，用戶體驗可能會受到影響，這會影響業務目標。

工作負載架構在 應用程式程式代碼、基礎結構和作業中應具有可靠性保證。 設計選擇不應該變更商務需求所指定的意圖。 這類變更應該視為重大取捨。

設計原則旨在提供您在開發生命週期中應考慮可靠性層面的指引。 從建議的方法開始，並 證明一組需求的優點。 設定策略之後，請使用 可靠性檢查清單推動動作。

如果您未將這些原則套用至您的設計，則最可能不會準備好 預期或處理生產環境中的問題。 結果可能是導致財務損失的服務中斷。 在重大工作負載的情況下，無法套用這些原則可能會危害安全性。

針對業務需求設計

收集商務需求，並將焦點放在工作負載的預定公用程式上。

需求必須涵蓋工作負載特有的用戶體驗、數據、工作流程和特性。 需求程序的結果必須清楚陳述預期。 在指定投資的情況下，目標必須能夠達成並與小組交涉。 它們必須記載為推動技術選擇、實作和作業。

方法	優點
藉由設定 個別元件、系統流程和系統整體指標的目標來量化成功。 這些目標是否讓使用者流程更可靠？	計量量化預期。 它們可讓您 了解複雜度 ，並判斷這些複雜性的下游成本是否在投資限制內。 目標值表示理想的狀態。 您可以使用值作為測試閾值，協助您偵測該狀態 的偏差 ，以及返回目標狀態所需的時間。 合規性需求也必須具有範圍內流程的可預測結果。 優先處理這些流程 時，會注意到最敏感的區域。
瞭解平台承諾。 請考慮服務的限制、配額、區域和容量限制 。	服務等級協定 (SLA) 依服務而有所不同。 並非所有服務和功能都同樣涵蓋。 並非所有服務或功能都可在所有區域中使用。 大部分的訂用帳戶資源限制都是每個區域。 充分 了解涵蓋範圍和限制 可協助您偵測漂移並建立復原和復原機制。
判斷相依性 及其對復原的影響。	追蹤其他小組或第三方開發的相依基礎結構、服務、API 和函式，可協助您判斷 工作負載是否可以在這些相依性不足的情況下運作。 它也可協助您 瞭解串聯失敗 並 改善下游作業。 當您使用可能容易受到失敗的外部服務時，開發人員可以 實作復原的設計模式 來處理潛在的失敗。

復原的設計

工作負載必須繼續以完整或縮減的功能運作。

您應該預期元件故障、平台中斷、效能降低、資源可用性有限，以及其他錯誤都會發生。 在系統中建置復原功能，使其 容錯且可正常降級。

方法	優點
區分位於重要路徑上的元件 ，以及可處於降級狀態的元件。	並非所有工作負載的元件都必須同樣可靠。 判斷重要性可協助您根據 每個元件的關鍵性進行設計。 對於可能會稍微降低使用者體驗的 元件，您不會過度產生 復原能力，而不是在元件失敗時可能會導致端對端問題。 設計在配置資源給重要元件時可能會有效率。 您也可以實作錯誤隔離策略，讓非關鍵元件失敗或進入降級狀態時，可以隔離以防止串聯失敗。
識別系統中的潛在失敗點，特別是針對重要元件，並判斷對使用者流程的影響。	您可以 分析失敗案例、彈力半徑和錯誤強度：完整或部分中斷。 此分析會影響元件層級的錯誤處理功能設計。
使用設計模式正確建置自我保留功能，並將設計模組化以隔離錯誤。	系統將能夠 防止問題影響下游元件。 系統將能夠減輕暫時性與永久失敗、效能瓶頸，以及可能會影響可靠性的其他問題。 您也可以 將彈力半徑降到最低。
新增功能，藉 由考慮支援區域中服務的容量限制，將重要元件相應放大 (應用程式和基礎結構) 。	工作負載將能夠 處理可變容量尖峰和波動。 當系統上發生非預期的負載時，這項功能非常重要，例如有效使用量的激增。 如果工作負載的設計目的是要相應放大多個區域，甚至可能克服在單一區域中影響的潛在暫時資源容量限制或其他問題。
在各應用層上建置分層和復原的備援。 目標是在實體公用程式和立即數據復寫中備援。 也旨在涵蓋服務、作業和人員的功能層中備援。	備援有助於 將單一失敗點降至最低。 例如，如果有元件、區域性或區域性中斷，則主動-主動或主動-被動) 中的備援部署 (可讓您符合運行時間目標。 新增媒介可防止元件之間的直接相依性，並改善緩衝處理。 這兩個優點都會強化系統的復原能力。
過度布建可立即減輕 備援實例的個別失敗，並緩衝處理失控的資源耗用量。	過度布建的高投資 會增加復原能力。 即使調整作業可以開始 補救失敗，系統仍會在作用中失敗期間繼續在完整公用程式上運作。 同樣地，您可以在系統發生錯誤或積極調整之前，降低宣告計劃緩衝區、取得重大分級時間的非預期資源耗用量風險。

復原的設計

工作負載必須能夠預期並從所有範圍的大多數失敗中復原，且對用戶體驗和商務目標造成最少的中斷。

即使是高度復原的系統也需要 災害準備方法，同時在架構設計和工作負載作業中。 在數據層上，您應該有可在損毀時修復工作負載狀態的策略。

方法	優點
已結構化、測試及記載的復原計劃 符合交涉的復原目標。 除了整個系統之外，方案還必須涵蓋所有元件。	定義完善的程式會導致 快速復原 ，以防止對企業財務和信譽造成負面影響。 進行定期復原演練測試復原系統元件、數據和故障轉移和容錯回復步驟的程式， 以避免時間和數據完整性是成功的關鍵 量值。
請確定您可以修復復原目標內所有具狀態元件 的數據 。	備份是使用信任恢復點讓 系統回到工作狀態 的必要條件，例如最後已知的良好狀態。 不可變且交易一致的備份可確保無法改變數據，且還原的數據不會損毀。
在設計中實作 自動化自我修復功能 。	此自動化 可降低外部因素的風險，例如人為介入，並縮短中斷修正週期。
以 不可變的暫時單位取代無狀態元件。	建置可隨選啟動和終結的暫時單位可提供 可重複性和一致性。 使用並存部署模型，讓轉換至新的單位累加，將中斷降至最低。

作業的設計

在作業中保持左移，以預期失敗狀況。

在開發生命週期中早期和經常測試失敗，並判斷效能對可靠性的影響。 為了進行根本原因分析和事後分析，您必須在小組之間擁有相依性狀態和持續失敗的共用可見度。 來自可觀察系統的深入解析、診斷和警示是 有效事件管理和持續改善的基礎。

方法	優點
建置可觀察的系統 ，以相互關聯遙測。	監視和診斷是重要的作業。 如果某個項目失敗，您必須知道失敗、失敗 時，以及 失敗的原因。 元件層級的可觀察性是基本概念，但元件和相互關聯的使用者流程匯總可觀察性提供健康情況狀態的整體檢視。 需要此數據，才能讓月臺可靠性工程師排定補救工作的優先順序。
預測潛在的故障和異常行為。 使用優先順序和可採取動作的警示，讓作用中可靠性失敗可見。 投資可加快分級的可靠流程和基礎結構。	月臺可靠性工程師可以立即收到通知，讓他們可以 減輕進行中的實時網站事件 ，並主動減輕預測性警示所識別的潛在失敗，再成為即時事件。
模擬失敗 ，並在生產前和生產前環境中執行測試。	在生產環境中體驗失敗很有説明，因此您可以設定 復原的實際期望。 這可讓您做出適當回應失敗的設計選擇。 此外，它可讓您測試您為商務計量設定的臨界值。
以 自動化方式建置元件，並盡可能自動化。	自動化 可將人為錯誤的可能性降到最低，讓測試、部署和作業保持 一致性 。
考慮 例行作業及其 對系統穩定性的影響。	工作負載可能會受限於進行中的作業，例如應用程式修訂、安全性和合規性稽核、元件升級和備份程式。 仔細檢查這些變更可確保 系統的穩定性。
持續 從生產環境中的事件學習。	根據事件，您可以在設計與作業中判斷在生產前可能未注意到的影響和監督。 最後，您將能夠根據實際事件 推動改善 。

保持簡單

避免過度建立架構設計、應用程式程式代碼和作業。

通常是您移除的專案，而不是您新增會導致最可靠解決方案的專案。 簡單性可減少控件的介面區，將效率不佳和潛在的設定錯誤或非預期的互動降到最低。 另一方面，過度簡化可能會造成單一失敗點。 維持平衡的方法。

方法	優點
只有在元件可協助您達成目標商業價值時，才會將元件新增至您的架構。 讓關鍵路徑保持精簡。	針對商務需求進行設計可能會導致簡單的解決方案，以便 實作和管理。 避免有太多重要元件，因為每個元件都是重大失敗點。
在程式代碼實作、部署和程式中建立標準，並加以記載。 使用自動化驗證來識別強制執行這些標準的機會。	標準提供 一致性，並將人為錯誤降到最低。 標準命名慣例和程式代碼樣式指南等方法可協助您維護品質，並在疑難解答期間輕鬆識別資產。
評估理論方法是否會轉譯為適用於使用案例的 實用設計 。	太細微的應用程式程式代碼可能會導致不必要的相依性、額外作業和 難以維護。
開發足夠的程序代碼。	您將能夠避免因未預期資源耗用量、使用者或數據流失敗，以及程式代碼錯誤而造成 無效率實作的問題。 相反地，可靠性問題應該會導致程式代碼檢閱，以確保程式代碼有足夠的彈性來處理問題。
利用平臺提供的功能 和預先建置的資產，以協助您有效地符合商務目標。	此方法 可將開發時間降到最低。 它也可讓您依賴已搭配類似工作負載使用的 已嘗試和測試做法 。

下一步

可靠性檢查清單