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

# 操作可觀測性
<a name="operational-observability"></a>

 需要可觀測性，才能獲得對您環境效能的可行洞見，並協助您偵測和調查問題。它也有次要目的，可讓您定義和測量關鍵績效指標 (KPIs) 和服務水準目標 SLOs)，例如執行時間。對於大多數組織而言，重要的操作 KPIs是偵測的平均時間 (MTTD) 和從事件復原的平均時間 (MTTR)。

在整個可觀測性中，內容很重要，因為會收集資料，然後收集關聯的標籤。無論您專注於哪個服務、應用程式或應用程式層，都可以篩選和分析該特定資料集。標籤可用來自動加入 CloudWatch 警示，以便在違反特定指標閾值時提醒適當的團隊。例如，標籤索引鍵`example-inc:ops:alarm-tag`及其值可能表示建立 CloudWatch 警示。[使用標籤為 Amazon EC2 執行個體建立和維護 Amazon CloudWatch 警示Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)中會說明示範此作法的解決方案。

 設定太多警示可以輕鬆建立警示風暴 - 當大量警示或通知快速壓倒運算子，並在運算子手動分類和排定個別警示的優先順序時降低其整體效率。警示的其他內容可以標籤形式提供，這表示規則可以在 Amazon EventBridge 中定義，以協助確保將焦點放在上游問題，而不是下游相依性。

 營運與 DevOps 的角色通常被忽略，但對於許多組織而言，中央營運團隊仍然在正常營業時間之外提供重要的第一個回應。（如需此模型的詳細資訊，請參閱[卓越營運白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)。) 與擁有工作負載的 DevOps 團隊不同，他們通常沒有相同的知識深度，因此標籤在儀表板和警示中提供的內容，可以引導他們找到問題的正確 Runbook，或啟動自動化 Runbook （請參閱部落格文章[使用 自動化 Amazon CloudWatch 警示 AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/))。