定義可靠性目標的建議
適用於此 Power Platform Well-Architected 可靠性檢查表建議：
| 回復：04 | 為元件、流程和整體解決方案定義可靠性和復原目標。 將目標視覺化來進行討論、達成共識、設定期望和推動行動，以達到理想狀態。 使用定義的目標組建健全情況模型。 健全狀況模型會定義正常、降級和不良狀態的外觀。 |
|---|
本指南介紹為關鍵工作負載定義可用性和復原目標計量的建議。 可靠性目標是透過與業務利害關係人的工作坊練習得出的。
透過監視和測試改進目標。 與內部利害關係人合作，建立現實的可靠性期望。 此練習還將幫助利害關係人支持您的架構設計選擇，並了解您的設計是為了最好地實現您商定的目標。
Microsoft Power Platform 可以為您處理大多數基礎結構層級的可用性和可靠性問題。 但是，您所建置工作負載的可用性是一項共同的責任。 重要的是要瞭解，即使 Microsoft 致力於高可用性，系統停機的風險也永遠不會為零。
請考慮使用以下計量來量化業務需求。
| 詞彙 | 定義 |
|---|---|
| 服務等級目標 (SLO) | 表示元件運作狀況和可靠性層的百分比目標。 層數越高，元件越可靠。 複合 SLO 表示整個工作負載的聚合目標，並考慮元件 SLO。 |
| 服務等級指標 (SLI) | 服務發出的計量。 彙總 SLI 計量以量化 SLO 值。 |
| 服務等級協定 (SLA) | 服務提供者和服務客戶之間的合約協議。 該合約定義了 SLO。 未能遵守合約可能會讓服務提供者在財務上蒙受損失。 |
| 平均復原時間 (MTTR) | 偵測到故障後還原元件所花費的時間。 |
| 平均故障間隔 (MTBF) | 在發生故障之前，工作負載可以不間斷地執行預期功能的持續時間。 |
| 復原時間目標 (RTO) | 事件發生後應用程式不可用的最長可接受時間。 |
| 復原點目標 (RPO) | 事件期間資料遺失的最長可接受持續時間。 |
在使用者和系統流程的內容中定義這些計量的工作負載目標值。 根據這些流對您的需求的重要性來識別這些流 並對其進行評分。 使用這些值在架構、審查、測試和事件管理作業方面推動工作負載的設計。 未能達到目標將影響超出容忍水準的業務。
關鍵設計原則
技術討論不應影響您如何定義關鍵流程的可靠性目標。 相反，業務利害關係人應關注其要求和工作負載終端使用者的期望。 技術專家幫助利害關係人分配滿足這些要求的實際數值。 透過交換資訊，技術專家能夠就可行的 SLO 進行討論並達成一致。
考慮如何將需求映射到可測量數值的範例。 利害關係人估計，對於關鍵使用者流程，正常工作時間內一小時的停機會導致每月收入損失 X 美元。 該金額與設計可用性 SLO 為 99.95% (而不是 99.9%) 的流程估計成本進行了比較。 決策者必須討論收入損失的風險是否超過防範收入損失所需的額外成本和管理負擔。
在檢查流程並建置完整的目標清單時，請遵循此模式。
請記住，可靠性目標不同於效能目標。 可靠性目標側重於可用性和復原。 若要設定可靠性目標，請先定義最廣泛的要求，然後定義更具體的計量以滿足進階要求。
例如，最高層級的可靠性和復原要求以及相關計量可能包括，所有區域的應用程式可用性為 99.9%，美洲區域的目標 RTO 為 5 小時。 定義這些類型的目標有助於確定這些目標中涉及哪些關鍵流程。 然後，您可以考慮元件層級目標。
可用性計量
可用性目標對應於 SLO、SLA 和 SLI 計量。
SLO 和 SLA
可用性計量與用於定義 SLA 的 SLO 相關。 工作負載 SLO 決定在指定時間內可以容忍多少停機時間；例如，每月少於 1 小時。 要確保您可以滿足 SLO 目標，請查看 Microsoft 每個元件的 SLA。
若要建立 SLO，請考慮：
未來 1-2 年內工作負載的非功能性需求 (例如，峰值要求率、同時使用者數)。
有關在特定時間段內可衡量之內容的可用計量。 此資料將告知要指定哪些 SLI。
收集各個工作負載元件的 SLA 後，計算複合 SLA。 複合 SLA 應與工作負載的目標 SLO 相符。 計算複合 SLA 涉及多個因素，具體取決於架構設計。
需要花時間仔細考慮才能定義出適當的 SLO。 業務利害關係人應了解可靠性容忍度。 此意見反應應告知目標。
SLA 值
下表定義了常見的 SLA 值。
| SLA | 每週停機時間 | 每月停機時間 | 每年停機時間 |
|---|---|---|---|
| 99% | 1.68 小時 | 7.2 小時 | 3.65 天 |
| 99.9% | 10.1 分鐘 | 43.2 分鐘 | 8.76 小時 |
| 99.95% | 5 分鐘 | 21.6 分鐘 | 4.38 小時 |
| 99.99% | 1.01 分鐘 | 4.32 分鐘 | 52.56 分鐘 |
| 99.999% | 6 秒鐘 | 25.9 秒鐘 | 5.26 分鐘 |
在使用者和系統流程的內容中考慮複合 SLA 時，請記住，不同的使用者和系統流程具有不同的關鍵性定義。 在建置複合 SLA 時，請考慮這些差異。 非關鍵流程可能包含應在計算中省略的元件，因為它們短暫無法使用時不會影響客戶體驗。
SLI
將 SLI 視為有助於 SLO 的元件層級計量。 從客戶的角度來看，最重要的是會影響關鍵流程的 SLI。 對於許多流程，SLI 包括延遲、輸送量、錯誤率和可用性。 良好的 SLI 可幫助您確定 SLO 何時面臨被破壞的風險。 盡量將 SLI 與特定客戶相關聯。
為避免收集無用的計量，請限制每個流程的 SLI 數量。 如果可能的話，目標是每個流程三個 SLI。
復原計量
復原目標對應於 RTO、RPO、MTTR 和 MTBF 計量。 與可用性目標相比，這些度量的恢復目標在很大程度上不依賴於 Microsoft SLA。 Microsoft 僅針對某些產品 (如 SQL 資料庫) 發佈 RTO 和 RPO 保證。
實際復原目標的定義依賴於失敗模式分析，以及業務連續性和災難復原的計劃和測試。 在完成這項工作之前，請與利害關係人討論理想目標，並確保架構設計盡量支援復原目標。 與利害關係人明確溝通，任何未針對復原計量進行全面測試的工作負載都不應該保證 SLA。 確保利害關係人了解，隨著工作負載的更新，復原目標可能會隨時間而變化。 隨著您採用新技術來改善使用者體驗，工作負載可能會變得更加複雜。 這些變更可能增加或減少復原計量。
注意
MTBF 可能很難定義和保證。 平台即服務 (PaaS) 或軟體即服務 (SaaS) 可能會在沒有雲端提供者通知的情況下失敗和復原，並且該過程對您來說是完全透明的。 如果為此計量定義目標，則僅涵蓋受您控制的元件。
建置運作狀況模型
使用為可靠性目標收集的資料，為每個工作負載和相關的關鍵流程建置運作狀況模型。 運行狀況模型將流量和工作負載定義為良好、降級和不良*狀態。 各狀態可確保適當的業務優先順序。 此模型也稱為紅綠燈模型。 該模型將綠色指定為良好，黃色指定為降級，紅色指定為不良。 運作狀況模型可確保您了解流程的狀態何時從良好變成降級或不良。
如何定義良好、降級和不良狀態取決於可靠性目標。 以下是一些定義狀態的方法範例：
綠色或良好狀態表示完全滿足關鍵的非功能性需求和目標，並且資源得到最佳利用。
黃色或降級狀態表示流程的一個或多個元件正在根據其定義的閾值發出警示，但流程正在運作。 例如，已偵測到儲存限制。
紅色或不良狀態表示降級持續時間超過可靠性目標允許的時間，或者流程變得不可用。
注意
運作狀況模型不應將所有失敗視為相同狀況。 運行狀況模型應區分 暫時性 故障和非 暫時性 故障。 它應該清楚地區分預期瞬時但可復原的失敗和真正的災難狀態。
該模型的工作原理是使用根據持續改進原則開發和執行的監視和警示策略。 隨著工作負載的發展，運作狀況模型也必須隨之發展。
有關監視和警示設定的詳細指南，請參閱運作狀況監視指南。
視覺效果
為了讓您的營運團隊和工作負載利害關係人了解工作負載運作狀況模型的即時狀態和整體趨勢，請考慮在監視解決方案中建立儀表板。 與利害關係人討論視覺化解決方案，以確保您提供他們重視且易於使用的資訊。 他們可能還想查看每週、每月或每季產生的報告。
Power Platform 簡易化
Power Platform SLA 提供 Microsoft 正常運行時間和連接性的承諾。 不同的服務具有不同的 SLA，有時服務內的 SKU 具有不同的 SLA。 如需詳細資訊，請參閱線上服務的服務等級協議。
Power Platform SLA 包括在未滿足 SLA 時獲取服務點數的過程，以及每個服務的可用性定義。 SLA 的這方面充當強制策略。
Microsoft 業務應用程式為 Dynamics 365 和 SaaS 應用程式中的所有生產類型 環境提供業務連續性和災難恢復 (BCDR) 功能 Power Platform 。 Microsoft 瞭解如何確保您的生產數據在區域性中斷期間具有彈性。
組織一致性
雲端採用框架為與整個組織的監視相關的 SLO 和 SLI 建議提供指引。
如需詳細資訊，請參閱雲端監視 SLO。
可靠性檢查清單
請參閱完整的建議集。