Skip to main content

Command Palette

Search for a command to run...

導入可觀測性工程的策略、戰略和戰術

Updated
2 min readView as Markdown
導入可觀測性工程的策略、戰略和戰術

在可觀測性(Observability)領域,策略(Strategy)戰略(Tactics)戰術(Tactical Actions) 是三個不同層次的規劃與執行,分別回答「為什麼要做」、「如何做」以及「具體要做什麼」。這三者相輔相成,幫助組織構建清晰的可觀測性體系。

策略(Strategy):為什麼要做?

策略是最高層次的規劃,聚焦於「為什麼」需要可觀測性,並確保其能夠支持組織的整體目標。它不僅是一個技術問題,更與業務目標、組織文化和長期願景緊密相關。

目標:

支撐業務目標

快速響應問題,降低 MTTR(平均修復時間)。 提升用戶體驗,減少因系統問題導致的業務損失。 降低運維成本,提升運營效率。

提供決策支持

數據驅動的決策,幫助開發和運營團隊理解系統行為,優化系統性能。

支持工程流程

與 SRE(可靠性工程)和 DevOps 流程深度整合,推動自動化和高效協作。

策略的核心要素:

業務驅動

  • 可觀測性必須與業務需求直接掛鉤。

    • 例如:如果業務需要快速交付新功能,可觀測性應支持快速定位問題並加快故障排除。
  • 必須回答的問題:

    • 我們的可觀測性如何幫助降低 MTTR?

    • 它如何支持 SRE 團隊的可靠性目標?

文化驅動

  • 推動組織內「數據驅動」的文化。

    • 團隊需要從數據中尋找答案,而非依賴猜測。

    • 避免數據孤島,推動跨團隊共享洞察。

  • 必須推動的文化變革:

    • 團隊應對系統行為有共同理解(例如 SLO 的一致定義)。

    • 鼓勵開發團隊將可觀測性視為產品的一部分,而非事後補救。

未來導向

  • 預見未來技術與業務需求的增長。

    • 例如:當系統規模擴大或業務轉向多雲架構時,可觀測性是否仍然有效?

挑戰與解決方案:

  • 挑戰: 高層管理者可能不理解可觀測性的價值,認為這只是技術團隊的問題。

  • 解決方案: 使用具體的業務案例說明價值,例如展示一次重大故障如何通過可觀測性工具快速定位並解決,從而挽回了多少損失。

戰略(Tactics):如何做?

戰略是將策略具體化的方向與路徑,回答「如何做」,即如何通過技術選型與流程設計來實現策略目標。它是連接高層策略與具體執行的橋樑。

目標:

  • 定義實現可觀測性的框架和方法。

  • 建立可觀測性實踐的標準和流程。

戰略的核心要素:

  1. 技術選型與架構設計:

    • 根據策略選擇合適的工具與架構:

      • 使用 Prometheus/Grafana 進行指標監控。

      • 使用 Jaeger/OpenTelemetry 實現分布式追蹤。

      • 使用 ELK Stack(Elasticsearch、Logstash、Kibana)進行日誌分析。

    • 必須考慮的問題:

      • 工具是否支持橫向擴展?

      • 是否需要統一的可觀測性平台?

  2. 數據收集與標準化:

    • 定義數據收集的範圍與標準:

      • 哪些指標(如 CPU 使用率、請求延遲)需要被監控?

      • 哪些日誌需要被儲存,哪些可以丟棄?

      • 如何標準化分散式追蹤中的上下文內容(如 trace ID、span ID)?

    • 必須解決的問題:

      • 數據是否足夠清晰和一致,能支持問題排查?

      • 是否有足夠的數據來建立 SLO 和告警?

  3. 流程與自動化:

  • 制定標準化流程,確保可觀測性實踐能被重複和自動化。

    • 例如:在 CI/CD 流程中自動部署可觀測性工具。
  • 必須解決的問題:

    • 如何確保所有新部署的服務都符合可觀測性標準?

    • 如何減少人工配置的工作量?

挑戰與解決方案:

挑戰: 技術選型可能受限於現有工具,或不同團隊需求不一致。

解決方案: 推動跨團隊協作,建立統一標準,例如讓所有團隊共同參與 SLO 設計。

戰術(Tactical Actions):具體要做什麼?

戰術是執行層面的行動,回答「具體要做什麼」,即如何將戰略中的規劃落地。

目標:

  • 解決實際技術問題,執行具體實施步驟。

  • 確保系統的可觀測性功能按計劃交付。

戰術的核心要素:

  1. 工具配置與部署:

    • 部署和配置具體工具:

      • 安裝 Prometheus 並設置抓取規則。

      • 配置 OpenTelemetry SDK,為應用程式添加分散式追蹤標籤。

      • 設置 ELK Stack 的日誌收集規則。

    • 必須關注的細節:

      • 工具是否正確安裝並運行?

      • 配置是否滿足性能需求?

  2. 數據可視化與告警:

    • 創建儀表板與報表,幫助快速理解系統狀態:

      • 在 Grafana 中設計服務延遲圖表。

      • 定義基於 SLO 的告警規則(如「99% 的請求延遲低於 200 毫秒」)。

    • 必須解決的問題:

      • 儀表板是否能快速定位問題?

      • 告警是否準確,避免「告警疲勞」?

  3. 問題排查與優化:

    • 使用工具排查技術問題:

      • 通過分散式追蹤分析跨服務的性能瓶頸。

      • 通過日誌分析定位錯誤原因。

    • 必須解決的問題:

      • 數據是否足夠詳細,能支持問題定位?

      • 工具是否易於使用,能提高排查效率?

挑戰與解決方案:

挑戰: 工具可能需要大量手動配置,或數據量過大導致性能問題。

解決方案: 通過自動化工具減少手動工作,並定期優化數據收集策略(如刪除不必要的指標)。

總結︰三層次的協同作用

三個層次在可觀測性領域中密切相關,形成完整的規劃與執行框架:

  1. 策略 提供高層次的方向,確保可觀測性工作與業務目標一致。

  2. 戰略 將策略具體化,制定清晰的技術與流程路徑。

  3. 戰術 負責執行戰略中的具體任務,確保技術實現落地。

具體案例:三層次的應用

  1. 策略: 「我們的目標是將系統的 MTTR 從 2 小時降低到 30 分鐘,並提升用戶體驗。」

  2. 戰略: 「通過實施分散式追蹤、統一日誌平台和基於 SLO 的告警系統來實現快速問題定位。」

  3. 戰術: 部署 Prometheus 和 Jaeger。 配置 OpenTelemetry SDK,為每個微服務添加追蹤標籤。 在 Grafana 中設計儀表板,展示請求延遲和錯誤率。

More from this blog

Get Your Hands Dirty on Clean Architecture CH5 Use Case

書本連結 前言 會挑這本書看的人,應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求,也希望能滿足可維護性(maintainability)的隱性需求,以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難,因為專案通常不會按照計畫進行。可能變因有 deadline,最後的 API 與承諾的不同,又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一

Jul 2, 20264 min read26
Get Your Hands Dirty on Clean Architecture CH5 Use Case

Claude Code 監控秘錄:OpenTelemetry(OTel/OTLP)實戰指南

稟告主公:此乃司馬懿進呈之兵書,詳解如何以 OpenTelemetry 陣法,令臥龍神算之一舉一動盡在掌握,知糧草消耗、察兵器效能、辨戰報異常,使主公運籌帷幄於大帳之中。 為何需要斥候情報? 司馬懿稟告主公: 臥龍神算(Claude Code)乃當世利器,然若無斥候回報,主公便如蒙眼行軍——兵器耗損幾何、糧草消費幾許、哪路斥候出了差錯,一概不知。臣以為,此乃兵家大忌。 無情報之弊,有四: 軍

Feb 19, 202610 min read241
Claude Code 監控秘錄:OpenTelemetry(OTel/OTLP)實戰指南
M

MicroFIRE

74 posts