共用方式為

電信業者等級工作負載的健康情況模型

  • 發行項

高可用性需要仔細的健康情況監視，才能在幾秒內自動偵測和回應問題。 此監視需要金鑰相依性的內建遙測，才能可靠地偵測失敗。 應用程式本身需要額外的遙測 (服務等級指標) ，以應用程式使用者察覺的方式精確地報告應用程式的健康情況。 可能需要對 SLO 進行評估。

應用程式的失敗率分析和一般健康情況模型應該產生清楚的計量，指出其組成元素的服務與健康情況。 這些計量必須包含在設計中，才能監視真正的服務可用性。 藉由包含計量，您可以追蹤最實用的前置指標來觸發自動化失敗回應，並產生人為介入所需的警示。

重要

如需如何為您的任務關鍵性工作負載建置健康情況模型的詳細資訊， 請參閱這裡。

管理和監視

監視和管理需要下列考慮程式：

  • 應用程式如何處理架構中的 Bug？
  • 應用程式如何升級？
  • 事件期間應該採取哪些動作？

例如，解決方案可能依賴 Azure DevOps (ADO) 來裝載其所有設定的 Git 存放庫。 如果裝載該 ADO 存放庫的 Azure 區域失敗，復原時間是兩小時。 如果解決方案部署在相同的區域中，就無法修改組態，以在該兩小時期間的其他位置新增容量。 因此，應用程式架構設計人員必須考慮金鑰服務的相互關聯失敗模式，例如：

這些金鑰服務的相互關聯失敗模式可能是應用層級回應失敗的必要部分。 建立不受相同應用程式失敗影響的控制平面非常重要。

問題診斷和疑難排解所需的管理工具必須與用於一般日常作業工作的工具相同。 類似的工具可確保熟悉且經過證實才能運作。 類似的工具也會最大化使用者對使用者介面和程式步驟的熟悉度。 要求操作員切換至不同的工具集來解決高壓力中斷，並不適合有效地識別和解決問題。

同盟模型

高可用性應用程式或服務必須具備高可用性管理和監視基礎結構，其建置方式與同盟和容錯的相同架構原則。 建置於這些妥善架構原則上的基礎結構可確保在中斷連線時，個別區域可以自我足夠。

如果有中斷線上活動，系統會將系統分解成個別運作的島，而不是使用主要/備份系統。 同盟模型具有彈性且具彈性，並會自動適應分割和重新線上活動。

例如，記錄和計量會儲存在可用性區域 (AZ) 產生的位置。 計量查詢會使用同盟搜尋的不透明程式，來查詢所有可連線 AZ 中的計量存放區。 特定應用程式對於應複寫至其他區域之記錄、計量和警示資料層級的特定應用程式需求有關。 一般而言，應該複寫警示，但複寫記錄和計量的理由可能不足。

健康情況和狀況不良的計量

內部計量可作為 狀況不良 的計量。 這些計量能可靠地指出問題是否存在，但反向則不成立。 當客戶察覺健康情況時，沒有不良健康情況的辨識項不是良好健康情況的辨識項。

例如，DNS 問題表示要求未抵達資料庫服務。 DNS 錯誤不會影響資料庫讀取成功計量，因為此計量未看到任何錯誤。 不過，使用者因為無法存取資料庫而察覺到總中斷。 至少必須以外部方式測量一部分 的健康 情況計量，讓這些計量包含終端使用者將體驗的所有專案。

監視和追蹤

支援小組能夠偵測、診斷和解決問題，是提供高可用性應用程式的重要部分。 為了確保成功，監視和追蹤元素必須提供高層級的可見度，以便找到並解決千種類型事件中的事件。

只記錄 0.1% 要求的追蹤解決方案，只有一百萬個記錄這類事件的機會，這表示診斷和解決不太可能。 不過，無法解決這類問題會對可用性造成有意義的影響。

後續步驟

檢閱電信業者等級工作負載的測試與驗證設計區域。

設計區域：測試和驗證