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

在可觀測性（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 中設計儀表板，展示請求延遲和錯誤率。