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

# 階段 1：定義您的北極星
<a name="define-north-star"></a>

成功實作可觀測性不僅與操作和工具有關，還與培養擁有權、持續改善和主動解決問題的文化有關。如同任何成功的策略，您的可觀測性策略需要全面考慮三個支柱：人員、程序和技術。

當您想要建立或改善可觀測性狀態時，建議您先定義重要事項、從業務成果中恢復工作，並在業務、團隊和產品演進時持續檢閱、調整和重新調整策略。

在此第一階段中，您會定義並建立您的 *North Star*，這是對組織好用的一致且充分了解的定義。我們建議您在業務發展、啟動新產品、應用程式或服務，或設計重大架構變更時，重新檢視此階段中的部分或全部活動，以重新評估您的可觀測性平台和組織需求。

## 在早期的開發生命週期中整合可觀測性 （向左轉移方法）
<a name="shift-left"></a>

讓可觀測性成為工程、營運和產品團隊中每個成員的責任，並將其視為主要功能需求，類似於您處理單元測試或安全的方式。這不會將責任從營運團隊轉移到開發團隊，而是強調多個團隊所需的協作。在開發生命週期的早期，團隊協作執行以下活動很有幫助。您可能想要根據每個票證、每個功能或每個產品來執行這些操作。
+ **識別利益相關者。**如果此功能或產品無法如預期般運作，誰是利益相關者以及對他們來說什麼是重要的？ 當您識別利益相關者時，請考慮功能、可用性、安全性、成本、銷售和產品使用量等層面。利益相關者可以包括您的團隊、產品的客戶、內部業務利益相關者、平台營運團隊成員和應用程式開發人員。根據情況，您的安全和財務團隊也可以是利益相關者。
+ **識別關鍵結果。**確定關鍵成果及其對業務和每個利益相關者的影響。識別每個結果和利益相關者的成功和失敗。結果通常定義為服務層級目標 (SLOs)，且必須可量化。SLO 是每個結果的指標。良好的 SLO 具有應作為目標努力或維護的目標值。SLO 可以是使用者滿意度的指標。服務層級指標 (SLI) 是用來判斷您是否符合 SLO 的實際測量或指標：它是您針對目標追蹤的可量化資料點。範例包括將 MTTR 降低 60%、將應用程式可用性維持在 99.99%，或將開發人員生產力提高 30%。

  讓我們舉出將應用程式可用性維持在 99.99% 的範例，並定義衡量和驗證成功所需的 SLO、SLI 和指標。在此範例中，讓我們考慮 RESTful 應用程式，並將應用程式可用性定義為成功完成所有傳入的請求。這需要測量對應用程式的請求總數，以及每個請求的完成狀態。當您將這些轉換為 SLO 和 SLI 時，您需要一個擷取傳入請求的指標，另一個擷取請求狀態的指標。如果所有請求都成功完成，則應用程式會被視為可用。如果一或多個請求導致錯誤，應用程式會被視為無法使用。因此，SLI 會是錯誤請求完成的總和，除以 5 分鐘間隔內傳入請求的總和，實際上是*錯誤率*。您可以將目標新增至此 SLI，將其轉換為 SLO；例如：連續 3 個 5 分鐘的間隔內，努力將錯誤率低於 0.1%。
+ **排定關鍵結果的優先順序。 **根據您為每個結果設定的優先順序，您可以選擇先專注於具有最高影響的結果，而不是同時執行所有操作。以小幅度開始小型、反覆並改善可觀測性狀態。可觀測性是一種程序，需要持續審查、稽核、增強和改進，以提高成熟度和優勢。優先順序也可以讓您有機會定義已識別結果的增量里程碑。
+ **識別必要的檢測。**如先前步驟所述，架構或實作的哪些元件和相關功能會影響重要的結果？ 例如，當您在 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上執行應用程式時，核心和可用 RAM 的數量可能會影響應用程式的回應能力和輸送量。在此階段，判斷您使用的工具或程式庫是否已經提供部分此檢測也很有幫助。執行一系列初步檢閱或將下列問題新增至票證[的就緒 (DoR) 定義](https://scrum-master.org/en/definition-of-ready-dor-an-essential-tool-for-improving-software-development-quality/)，可讓此活動成為標準程序的一部分。
  + 如果此操作失敗，您需要知道什麼才能解決失敗？ 典型或有問題的操作如何影響涉及的元件？ 此操作應傳送哪種訊號：日誌、指標或追蹤？ 相較於其值，此檢測的成本是多少？ 在不違反 SLOs 的情況下，可以接受哪種彙總？
  + 可能導致此操作失敗的元件和相依性有哪些？ 如何識別導致失敗的元件或相依性？ 這些元件和相依性有哪些不同的組態控制桿，以及每個設定控制桿如何影響操作？
  + 確保可準確測量 SLI 和 SLO 所需的指標精細程度和取樣率是多少？
+ **定義成功條件。**對於每個排定優先順序的結果，定義與達到或未達到目標的影響相符的閾值。當團隊回應提醒時，成功條件會提供其他內容給團隊。它們還可讓您預測和權衡檢測的成本，以獲得所需的可見性。

## 設定有效的組織和團隊結構
<a name="team-structure"></a>

根據您業務的架構複雜性和大小，您可能需要設定專注於可觀測性的專用團隊。此團隊將負責設定可觀測性工具，並為其他團隊設定可觀測性平台。如果您選擇標準 OpenTelemetry 實作，我們也建議您設定專用團隊。在較小的組織中，您可以將可觀測性指派為每位團隊成員的額外責任，也可以指派可觀測性擁護者，以在整個團隊中宣傳和強制執行最佳實務。這些擁護者會在一天中擔任志願者，為組織定義程序和設定標準。它們可以作為自我協調團隊運作，也可以由專門的可觀測性專家領導。下圖顯示您的投資如何決定您的組織方法。

![如何根據投資判斷可觀測性的責任。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerate-observability-outcomes/images/complexity.png)


擁護者可以完全嵌入團隊中 （如下圖所示的團隊 2)，也可以成為讓團隊輪換以建立和提升最佳實務的團隊 （下圖中的團隊 1) 的一部分。

![設定啟用團隊或內嵌可觀測性擁護者。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerate-observability-outcomes/images/team-structure-for-observability.png)


## 追蹤成本分配
<a name="cost-allocation"></a>

組織應該跨指標、日誌和追蹤實作全面的成本追蹤和可見性，同時建立資源用量和成本的團隊特定責任。財務操作 (FinOps) 實務的成功整合需要具有預算提醒的自動化監控系統，並搭配系統性資料保留和收集最佳化。工程和財務團隊應該透過共用儀表板和定期審查來調整其目標。組織受益於實作明確的退款模型和成本分配策略，以推動擁有權和責任。

## 定義標準
<a name="standards"></a>

識別和定義應用程式所需的基本訊號和遙測，包括提醒和儀表板策略。為每個應用程式建立檢查清單或正式檢閱程序。[AWS 可觀測性最佳實務](https://aws-observability.github.io/observability-best-practices/)網站提供警示和儀表板建立的指導方針，例如設定適當的警示閾值、將警示疲勞降至最低、建立具有足夠每個角色內容的儀表板等。如需連線和精選的可觀測性體驗，請參閱 Amazon CloudWatch 文件中的[應用程式訊號](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)。

## 建立呈報程序
<a name="escalation"></a>

請務必建立並強制執行呈報機制、警示擁有權和回應程序。我們建議您提升不偏袒向上呈報的文化。

## 透過訓練提升技能
<a name="skills"></a>

找出提升現有和新團隊成員技能的最佳方式，強化可觀測性的重要性，並培養持續改進的文化。根據您的組織需求，您可以選擇由可觀測性擁護者或專家提供的預先錄製、隨需訓練或課堂訓練。 AWS 帳戶 您的團隊可以提供深入的實作培訓課程，例如 [One Observability Workshop](https://catalog.workshops.aws/observability/en-US) 或 [GameDays](https://aws.amazon.com/gameday/)，以指導和改善可觀測性技能和最佳實務。此外， 納入機制以強化最佳實務並提升組織定義的標準。