電信業者等級工作負載的容錯

電信公司已顯示，可以實作符合和超過電信業者等級可用性需求的應用程式，同時在不可靠的元素上執行。 公司透過 容錯超過這些需求，其中包括下列層面：

• 獨立、非高可用性元素的組合。
• 流量管理失敗回應機制。
• 修復和容量復原和失敗回應機制。
• 使用高可用性跨專案資料庫。

針對電信業者等級可靠性和復原進行設計時，假設每個元件都可以且 將會 失敗。 設計需要分層方法來解決失敗。 驗證設計的一部分是建立各種失敗模式的量化機率模型，以清楚識別應用程式擁有的主要相依性，並顯示應用程式可以達到必要的可用性，因為這些相依性符合自己的服務等級目標， (SLA) 。 此模型應該在開發和生產環境中保留並持續驗證，以確保測試和即時資料符合模型所預測的內容。

透過組合的高可用性

若要達到高可用性，請採用非高可用性的獨立元素，並加以合併，使其保持獨立實體。 多個元素在一起失敗的機率遠低於任何單一元素的失敗機率。 我們會將此程式定義為 共用 Nothing 架構樣式。

流量管理失敗回應

當個別元素失敗或發生連線問題時，系統的流量管理層有各種方式可以回應維護整體服務。 解決方案應該盡可能實作下列許多機制，或達到可用性的必要條件。 前兩種機制依賴用戶端中的特定行為，這不一定是選項：

1. 立即用戶端重試替代目標： 在失敗時，或在重試沒有回應之後，用戶端可以使用可能成功的另一個元素立即重試要求，而不是提交新的 DNS 查詢來識別替代專案。

2. 用戶端型健康情況清單- 維護 已知狀況 良好且 已知狀況不良的專案清單。 除非清單是空的，否則要求一律會傳送至已知狀況良好的專案。 如果為空白，則會嘗試已知狀況不良的專案。

3. 伺服器型輪詢— 系統型散發機制，例如 DNS 或 Azure 流量管理員 (ATM) ，實作自己的即時偵測和監視，以啟用狀況不良元素的路由。

修復和復原失敗回應

流量管理回應可以因應失敗，但當失敗長期或永久時，必須修復或取代瑕疵元素。 這裡有兩個主要選擇：

1. 還原備援- 元素失敗可減少整體系統容量。 系統設計應該允許透過布建備援容量來減少此容量;不過，多個重迭失敗會導致真正的中斷。 必須有一個自動化程式可偵測失敗，並新增容量以將備援還原至其正常層級。 您可以從失敗率分析判斷影響。 在許多情況下，自動還原備援層級可能會增加任何個別元素可接受的停機時間。

2. (選擇性) 修復失敗的專案— 解決方案可能需要包含偵測失敗的機制，並嘗試就地修復失敗的專案。 此解決方案可能不適用於還原備援的程式會具現化新元素來取代失敗的專案，並終止並解除委任失敗的專案的情況。

下圖顯示兩種失敗回應模式如何合作，以提供服務層級容錯：

失敗率分析

沒有任何投入量會導致完美的系統，因此請從假設一切可以和失敗開始。 請考慮解決方案整體的行為。 失敗率分析會從較低層級的個別系統開始，並將結果結合在一起，以建立完整的解決方案模型。

分析通常是使用 Markov 模型來完成，這會考慮所有可能的失敗模式。 針對每個失敗模式，請考慮下列因素：

• 費率
• 持續時間和解決時間
• 相互關聯的失敗機率 (服務 X 中失敗造成服務 Y)

結果是系統可用性的估計值，並通知考慮 彈射半徑。 擷取半徑是一組無法在特定失敗的情況下運作的專案。 良好的設計旨在限制該集合的範圍和嚴重性，因為會發生失敗。 例如，封鎖建立新使用者的失敗，但不會影響現有使用者，比停止所有使用者服務的失敗還少。

失敗率分析提供整體系統層級可用性的估計值。 分析會識別該可用性所依賴的重要相依性。 當失敗率分析指出系統可用性變短時，它也會提供特定、量化的深入解析，以瞭解需要改善的位置，以及達到何種程度。

如需 Azure 中失敗模式分析的詳細資訊，請參閱 Azure 應用程式的失敗模式分析。

串聯失敗和多載

電信業級應用程式設計必須仔細注意串聯失敗的風險，其中一個元素失敗會導致其他元素失敗，通常是因為多載。 串聯失敗對電信業級應用程式而言並不是唯一的，但可靠性與回應時間需要正常降低和自動化復原。

後續步驟

檢閱電信業者等級工作負載的已考慮資料模型設計區域。

設計區域：資料模型