Azure 上的電信業者等級工作負載

任務關鍵性系統主要著重于將執行時間最大化，而且存在於許多產業中。 在電信產業中，它們稱為 電信業等級系統。 這些系統是由下列一或多個驅動程式所開發：

• 將生活或傷害損失降到最低。
• 符合可靠性的法規需求，以避免支付費用。
• 將服務優化給客戶，以將流失率降到最低。
• 與商務或政府客戶) (SLA 的會議合約服務等級協定。

這系列文章會套用 任務關鍵性工作負載的設計方法 ，以通知建置及操作 Azure 上高度可靠、具復原性和可用電信工作負載的規範性指引。

注意

本系列中的文章著重于在電信產業內設計 99.999% ('5 9s') 可靠性層級時，提供額外的任務關鍵性考慮。

什麼是電信業者等級的工作負載？

工作負載一詞是指支援常見商務目標或執行常見商務程式的應用程式資源集合，其中包含多個服務，例如 API 和資料存放區，共同作業以提供特定的端對端功能。

任務關鍵性一詞是指重大財務成本 (業務關鍵性) 或人力成本 (安全性關鍵性) 與無法使用或效能不佳相關聯的重大財務成本分類。

電信業者等級工作負載會同時針對業務關鍵和安全性關鍵性進行樞紐分析，其中在每一日曆年度只能運作幾分鐘或甚至幾秒的停機時間的基本需求。 若無法達到此執行時間需求，可能會導致廣泛的生命週期損失、產生重大懲罰或合約懲罰。

工作負載 的操作 層麵包括如何測量可靠性，以及其必須符合或超過的目標。 高度可靠的系統通常會以 99.999% 執行時間為目標， (通常稱為'5 9s') 或 0.001% 的停機時間， (大約 5 分鐘) 。 某些系統的目標是 99.9999% 的執行時間，或每年 30 秒的停機時間，或甚至更高的可靠性層級。 這涵蓋所有形式的中斷和原因 – 排程的維護、基礎結構失敗、人為錯誤、軟體問題，甚至是自然災害。

雖然所使用的平臺已透過商業、現成的硬體，從專用、現成的硬體演進到 OpenStack 或 VMware 雲端，但電信公司一直 ≤提供每年 5 分鐘停機的服務，而且在許多情況下，由於未排程中斷而達到 ≤ 30 秒的停機時間。

常見的挑戰為何？

基於下列主要原因，建置電信業者等級工作負載是一項挑戰：

隨即轉移方法

電信公司有妥善架構的應用程式，可在其現有的基礎結構上提供預期的行為。 不過，在假設將這些應用程式 移植 到公用雲端基礎結構不會影響其復原能力之前，請先小心。

現有的應用程式會針對其基礎結構進行一組假設，這些基礎結構不太可能在從內部部署移至公用雲端時保持正確。 架構設計人員必須確認它們仍會保存並調整基礎結構和應用程式設計，以配合新的實境。 架構設計人員也應該尋找新基礎結構移除存在於內部部署的限制的機會。

例如，必須就地升級內部部署系統，因為它無法維護足夠的硬體來建立新的部署，並以安全的方式緩慢轉換。 此升級路徑會產生管理升級和復原方式的主機需求。 這些需求會導致複雜度，並表示升級不常發生，而且只能在謹慎管理的維護時段中允許。

不過，在公用雲端中，與現有部署平行建立新的部署是合理的。 此程式可讓您在應用程式的作業設計中大幅簡化，以及使用者體驗的改善，以及期望。

整合型解決方案

跨各種任務關鍵性產業的經驗，顯示嘗試建構整合型解決方案並不實際，這可達到所需的可用性層級。 複雜系統中只有太多潛在的失敗來源。 相反地，成功的解決方案是由個別的獨立和備援元素所組成。 每個單位都有相對基本的可用性 (通常為 ~99.9%) ，但結合在一起時，總解決方案可達到必要的可用性目標。 電信業等級工程的藝術接著會確保備援元素唯一通用的相依性是絕對必要的相依性，因為它們會對整體可用性造成最大影響，通常大於設計中的其他專案。

僅建置區域性備援

使用Microsoft Azure 可用性區域是降低硬體故障或當地語系化環境變數所造成的中斷風險的基本選擇。 不過，它不足以達到電信業者等級的可用性，主要是基於下列原因：

• 可用性區域 (AZ) 的設計目的是讓單一區域中任何兩個區域之間的網路延遲≤ 2 毫秒。 AZ 無法廣泛且分散在地理上。 因此，AZ 會因自然災害而共用相互關聯的失敗風險，例如災害或大量電力中斷，這可能會停用區域內的多個 AZ。

• 許多 Azure 服務都明確設計為區域備援，因此使用這些服務的應用程式不需要明確邏輯，就能受益于可用性提升。 服務內的這個備援函式需要每個區域中元素之間的共同作業。 一個區域中的軟體失敗通常會造成其他區域中相互關聯的失敗風險。 例如，與區域備援服務搭配使用之秘密或憑證的任何問題，都可能會同時影響所有 AZ。

什麼是主要設計領域？

設計電信業者等級工作負載時，請考慮下欄區域：

設計領域	Description
容錯	應用程式設計必須允許無法避免的失敗，讓整個應用程式可以繼續在某些層級運作。 設計必須將失敗點降到最低，並採取同盟方法。
資料模型	設計必須解決資料庫的一致性、可用性和資料分割容錯需求。 電信業者等級可用性要求應用程式部署在多個區域。 此部署需要仔細思考應用程式的資料如何跨這些區域進行管理。
健康情況模型化	有效的健康情況模型提供所有元件、平臺和應用程式的可觀察性，以便快速偵測問題，並透過自我修復或其他補救準備好回應。
測試和驗證	應用程式的設計和實作必須經過徹底測試。 此外，必須測試整個解決方案的應用程式整合和部署。

後續步驟

從檢閱電信業者等級應用程式案例的設計原則開始。

設計原則