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

# 階段 2：實作可觀測性
<a name="implement-observability"></a>

在此階段，您會開始讓團隊逐步前往北極星的程序。

## 選擇您的可觀測性平台
<a name="platform"></a>

第一步是識別正確的工具來擷取、視覺化和分析訊號，以及傳送提醒。選取工具時，請考慮其功能集、授權模型、價格、技能需求和維護。

### 功能集
<a name="features"></a>

以下是一些要考慮的問題：
+ **可設定性和自訂**。該工具提供哪些功能來簡化調查體驗，並協助減少 MTTR？ 此工具是否提供警示關聯性、指標數學、處理遺失遙測的彈性，或異常偵測？
+ **精細程度**。支援的遙測訊號擷取和視覺化精細程度為何？
+ **角色**。此工具是否支援您想要提供給開發人員、平台工程師和其他角色的體驗？ 它是否適用於技術和業務角色？
+ **小工具**。儀表板支援哪些類型的小工具？ 工具是否允許建立自訂小工具？
+ **預先建置的解決方案**。該工具提供哪些預先建置的可觀測性解決方案，以縮短實現價值的時間？
+ **自動化和生成式 AI**。該工具提供哪些功能，可協助您和您的團隊自動化或減少混沌？ 例如，自動異常偵測、預測分析和其他生成式 AI 功能有助於減輕假設和*未知因素的壓力 *（也就是您不知道或完全了解的事物）。此工具是否支援使用生成式 AI/ML 模型來增強大規模資料分析？ 它是否為您提供自動化和實作 AIOps 的選項？
+ **安全性。 **工具支援哪些類型的身分驗證和授權整合？ 使用者和登入體驗是否符合組織的需求？
+ **OpenTelemetry 支援。**工具和代理程式是否支援 OpenTelemetry？ 大多數可觀測性平台支援擷取 OpenTelemetry 相容訊號，但並非所有代理器都提供組態選項，將這些訊號轉送至可觀測性平台。
+ **整合。**工具提供哪些整合？ 考慮是否需要傳送提醒給 Slack、頁面團隊成員或自動化解決方案。
+ **延展性**。​ 工具的可擴展性和效能如何？ 可觀測性解決方案必須隨著您的需求和用量增加而擴展，因此即使您的應用程式無法使用，它也可以提供診斷。
+ **支援。**提供哪些支援模型？ 即使應用程式失敗，您的可觀測性工具也必須可用，如此您才能符合 MTTR 和應用程式可用性目標或服務層級協議 (SLAs)。開放原始碼解決方案可能提供有限的正式支援。

### 授權和部署模型
<a name="licensing"></a>

考慮解決方案的授權模式 （開放原始碼或商業） 和部署模式 （自我託管或雲端型）。開放原始碼選項通常具有較低的預付成本，但在提供價值之前，可能需要更多時間進行部署、設定和組態、維護和團隊升級。如果您正在考慮開放原始碼選項，您可能需要一個專門的可觀測性專家團隊。商業軟體通常會以更高的前期成本提供更快的價值時間，而且專用可觀測性團隊的需求會隨著採用率、複雜性和成熟度的增加而隨時間演進。與雲端型解決方案相比，自我託管解決方案需要更多時間進行部署、設定和組態、維護和操作開銷。

### 定價維度
<a name="pricing"></a>

隨著您的應用程式獲得新的使用者、更大的架構足跡或新的功能和應用程式，工具的定價模型將如何影響您的總體擁有成本 (TCO)？ 例如，某些典型的授權模式是永久的或基於訂閱、具名使用者數量、耗用量或磁碟區。考慮您的應用程式和可觀測性工具如何擴展用量，以及授權模型如何影響工具的成本。

### 團隊技能
<a name="skills"></a>

根據團隊目前的技能集和成熟度，您需要判斷需要多少提升技能。考慮廠商提供哪些支援來訓練您的團隊。同時考慮您的組織結構是否支援您選擇的工具的組態和管理。例如，如果您選擇 OpenTelemetry，您應該考慮設定專門提供可觀測性的單獨團隊。

### 操作和維護
<a name="ops"></a>

評估下列問題：
+ 可觀測性代理程式或收集器提供哪些部署選項？ 這些選項是否符合架構的要求？ 例如，如果您使用可觀測性工具的容器化部署，它是否支援協助程式集或附屬項目？ 營運團隊需要採取或使用哪些額外的步驟或工具，以確保符合安全性和所有其他程序？
+ 維護解決方案所需的工作量為何？ 更新代理程式或收集器的程序有多簡單或自動化？ 與自我部署和託管應用程式相比，完全受管和雲端型可觀測性界面通常具有較低的操作開銷，但代理程式或收集器的管理保持不變。將您的團隊結構納入考量，並考量維護您選擇的選項的人力成本。

## 檢測您的應用程式
<a name="instrumentation"></a>

上一節問題的答案為您提供檢測應用程式所需的資訊，也就是新增程式碼以擷取應用程式的遙測訊號，以及測量、觀察和驗證行為。您可以使用SDKs應用程式語言的 OpenTelemetry SDK 等 SDK 來自動檢測應用程式。您可能仍然需要新增手動檢測程式碼，以涵蓋任何差距，並確保end-to-end可見性。請特別注意您新增的遙測，並確保您可以將它連接到您在上一個階段建立的一或多個 SLIs 和 SLOs。

## 收集遙測
<a name="telemetry"></a>

設定遙測收集器或代理程式來擷取相關的遙測訊號，以符合您在[階段 1 ](define-north-star.md)中排定優先順序的結果。

## 實作可觀測性元件
<a name="components"></a>

當遙測正在流動並擷取到可觀測性平台時，請建立儀表板、警示、手冊和 Runbook。
+ **儀表板：**建立包含相關資訊的儀表板，包括與優先結果相關聯的目前和歷史趨勢視覺化呈現。將這些儀表板提供給您在[階段 1 ](define-north-star.md)中定義的利益相關者。如需詳細資訊，請參閱 Amazon Builders' Library網站上的[建置儀表板以取得操作可見](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)性。
+ **提醒：**定義提醒，在結果處於風險或違規時通知您的團隊。請考慮新增[安全性和效能問題的提醒](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.1-automate-alerts-for-security-and-performance-issues.html)。採用下列方式來最佳化警示，[以減少警示疲勞](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/o.cm.9-optimize-alerts-to-prevent-fatigue-and-minimize-monitoring-costs.html)和成本：
  + 使用異常偵測來避免設定硬閾值，這需要頻繁調整，並減少未知的發生。
  + 使用智慧提醒組合，一起查看多個相關指標，而不是為每個指標設定個別提醒。例如，不針對 CPU、記憶體和回應時間設定個別提醒，而是建立一個有意義的提醒，只在這些指標共同指出實際問題時觸發。這種方法可大幅減少警示雜訊，並協助您的團隊專注於實際的服務影響問題，而不必回應隔離的指標峰值。
  + 只有在使用者體驗或結果處於風險時，才會產生提醒。例如，當您的應用程式沒有作用中的使用者時，請避免收到由自動升級引起的 CPU 峰值提醒。
+ **手冊：**手冊為回應事件或警示的人員提供心理模型和內容，並協助他們更快識別根本原因。考慮為高度耦合、複雜的應用程式和缺少檢測但直接影響您在[階段 1 ](define-north-star.md)中識別和優先結果的應用程式建立手冊。
+ **Runbook：**使用 Runbook 定義解決事件或警示所需的步驟。

## 驗證可觀測性系統
<a name="validation"></a>

在整個軟體開發生命週期 (SDLC) 中，驗證儀表板是否在系統測試期間提供預期的行為和更新。實作[混沌工程](https://docs.aws.amazon.com/prescriptive-guidance/latest/chaos-engineering-on-aws/)並驗證手冊和 Runbook 中記錄的步驟，以確保它們準確並滿足其目的。您也應該驗證警示擁有權和呈報路徑。