本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 與 SaaS 產品網路存取相關的卓越營運指標
<a name="assessment-engineering-ops"></a>

**Topics**
+ [操作彈性和災難復原](#assessment-engineering-ops-resilience)
+ [服務和應用程式效能監控](#assessment-engineering-ops-monitoring)

## 操作彈性和災難復原
<a name="assessment-engineering-ops-resilience"></a>

網路存取方法應可協助 SaaS 產品承受各種類型的中斷，並快速從任何災難中復原。

### 高分數條件
<a name="assessment-engineering-ops-resilience-high-score-criteria"></a>

建立和測試的災難復原計劃一致地顯示網路存取方法符合災難復原要求。網路存取方法支援高可用性組態，並支援自動、快速且可靠的容錯移轉機制。

### 低分數指標
<a name="assessment-engineering-ops-resilience-low-score-indicators"></a>

網路存取方法使得難以建立一致的災難復原策略。您會在中斷後觀察到較長的復原時間。網路基礎設施的頻繁操作失敗正在影響服務交付。

### 自我評定問題
<a name="assessment-engineering-ops-resilience-self-assessment-questions"></a>
+ 上次災難復原演練是什麼時候，結果是什麼？
+ 中斷後需要多長時間才能復原關鍵服務？ 網路基礎設施的哪個部分需要重新部署？
+ 可以對網路基礎設施進行哪些改善，以簡化災難復原計劃？
+ 是否有針對最關鍵的網路元件進行備援？
+ 在重大中斷之後，您是否已自動化網路基礎設施的潛在重新部署？
+ 網路存取方法如何支援容錯能力和可靠性？ 是否有內建機制來處理網路中斷和維護資料完整性？

## 服務和應用程式效能監控
<a name="assessment-engineering-ops-monitoring"></a>

網路存取方法可能會影響用於驗證最佳操作和服務執行時間的效能監控工具。視服務而定，您可能可以存取低階指標 （例如封包捨棄率） 或更高層級指標 （例如工作階段持續時間）。低階指標提供網路行為的詳細技術洞見，但可能難以解釋。相反地，更高層級的指標通常提供更直接、更簡單的方法來衡量整體使用者體驗。這是因為它們將基礎網路條件的影響彙總為明確的服務品質指標。

### 高分數條件
<a name="assessment-engineering-ops-monitoring-high-score-criteria"></a>

提供近乎即時洞見的全方位監控工具隨時可用。您有可解決效能問題的自動警示和回應系統。您可以預測潛在的服務瓶頸或故障，然後再影響使用者。

### 低分數指標
<a name="assessment-engineering-ops-monitoring-low-score-indicators"></a>

經常發生服務中斷或效能問題，而未受到觀察或採取行動。缺乏對服務效能的可見性會導致對效能瓶頸的回應緩慢。需要多方團隊來疑難排解網路基礎設施問題。

### 自我評定問題
<a name="assessment-engineering-ops-monitoring-self-assessment-questions"></a>
+ 目前有哪些監控工具和網路基礎設施指標可用？ 它們偵測服務異常的效果如何？
+ 您可以多快識別和解決效能問題？
+ 您是否有可預測潛在效能問題的機制？
+ 您可以進行哪些改善來增強可觀測性功能？