營運的現實：事情總會出錯#

在營運中，一個不爭的事實是：小變更可能導致許多意想不到的結果，包括服務中斷和影響所有客戶的全局故障。這是操作複雜系統的現實——沒有任何一個人能看到整個系統全貌，也無法理解所有元件如何協同運作。

當生產環境中發生停機或其他問題時，我們往往缺乏解決問題所需的資訊。例如，在一次中斷期間，我們可能無法判斷問題是來自：

• 應用程式本身的缺陷
• 環境問題（如網路、伺服器設定）
• 外部因素（如大規模 DDoS 攻擊）

低績效的營運團隊傾向於盲目重啟伺服器來解決問題；而高績效組織則使用紀律化的問題解決方法，運用生產遙測數據來理解可能的影響因素，聚焦問題排查方向。Microsoft Operations Framework (MOF) 在 2001 年的研究發現，最高服務水準的組織重啟伺服器的頻率比平均值低 20 倍。

什麼是遙測（Telemetry）#

為了實現紀律化的問題解決行為，我們需要設計系統使其持續產生 telemetry（遙測），定義為「一種自動化的通訊流程，在遠端收集量測和其他數據，並傳輸至接收設備進行監控」。

我們的目標是在應用程式與環境中建立遙測能力，涵蓋生產和預生產環境，以及部署流水線。

Etsy 的遙測實踐#

Etsy 的 DevOps 轉型從 2009 年開始，生產監控是其中的關鍵環節。他們將所有伺服器資訊收集到 Ganglia，並將所有資訊顯示到 Graphite 中，同時在每個指標圖表上疊加部署時間的垂直線，使團隊能快速看到部署的副作用。

• 到 2011 年，Etsy 追蹤超過 20 萬個生產指標
• 到 2014 年，追蹤指標增長到超過 80 萬個
• 前 30 個最重要的業務指標顯著地展示在「部署儀表板」上

正如 Etsy 工程師 Ian Malpass 所說：「如果工程在 Etsy 有一個宗教，那就是圖表教。如果它會動，我們就追蹤它。追蹤一切是快速行動的關鍵，而唯一的方法就是讓追蹤變得簡單。」

高績效者的優勢#

2015 State of DevOps Report 發現，高績效者解決生產事故的速度比同儕快 168 倍，其中位數 MTTR 以分鐘計，而低績效者的 MTTR 以天計。促成快速 MTTR 的兩大技術實踐是：營運端使用版本控制以及在生產環境中擁有遙測和主動監控。

建立集中式遙測基礎設施#

傳統上，監控和日誌記錄一直存在資訊孤島的問題：開發只建立對開發者有用的日誌事件，營運只監控環境是否正常運行。結果是，當問題發生時，沒有人能判斷整個系統為何未按預期運作。

James Turnbull 在 The Art of Monitoring 中描述了一套現代監控架構，包含以下核心元件：

• 資料收集層：在業務邏輯、應用程式和環境各層產生事件（events）、日誌（logs）和指標（metrics）
• 事件路由器：負責儲存事件和指標，支援視覺化、趨勢分析、告警和異常偵測
• 目的地：儲存、圖表化、告警

日誌轉化為指標#

集中化日誌後，我們可以在事件路由器中將其轉化為指標。例如，「child pid 14024 exit signal Segmentation fault」這樣的日誌事件，可以被計數並彙總為整個生產基礎設施的單一 segfault 指標。透過將日誌轉化為指標，我們就能執行統計分析，例如異常偵測。

部署流水線的遙測#

除了從生產服務和環境收集遙測外，我們也必須從部署流水線收集遙測——例如自動化測試的通過/失敗狀態、部署到各環境的時間點，以及建置和測試的執行時間。這讓我們能在問題進入生產之前就發現和修復。

Adrian Cockcroft 指出：「監控系統必須比被監控的系統更可用、更具擴展性。」

建立有助於生產的應用程式日誌遙測#

我們必須確保建構和運行的應用程式產生足夠的遙測。做法是讓 Dev 和 Ops 工程師在日常工作中為新舊服務建立生產遙測。

CSG 的首席架構師 Scott Prugh 說：「每次 NASA 發射火箭時，都有數百萬個自動感測器回報每個元件的狀態。我們也應該對軟體付出同樣的關注。」在 2014 年，CSG 每天產生超過 10 億個遙測事件。

日誌等級#

不同的使用場景需要不同的日誌等級：

• DEBUG：程式中發生的所有事情，通常在除錯時使用
• INFO：使用者驅動或系統特定的動作（如「開始信用卡交易」）
• WARN：可能變成錯誤的狀況（如資料庫呼叫超過預定時間）
• ERROR：錯誤狀況（如 API 呼叫失敗）
• FATAL：必須終止的狀況（如網路守護程式無法綁定網路 socket）

Dan North 建議：「在決定訊息應該是 ERROR 還是 WARN 時，想像你在凌晨 4 點被叫醒。印表機碳粉不足不是 ERROR。」

應記錄的重要事件#

為確保可靠和安全的營運，所有重要的應用程式事件都應產生日誌記錄，包括：

• 認證/授權決策（含登出）
• 系統和資料存取
• 系統和應用程式變更（特別是特權變更）
• 資料變更（新增、編輯、刪除）
• 無效輸入（可能的惡意注入）
• 資源使用（RAM、磁碟、CPU、頻寬）
• 健康度和可用性
• 啟動和關閉
• 故障和錯誤
• 斷路器觸發（Circuit breaker trips）
• 延遲
• 備份成功/失敗

以遙測引導問題解決#

高績效者使用紀律化的方法來解決問題，而非依賴傳言和指責。當缺乏公開的遙測時，團隊可能會避免記錄和展示變更資訊，以逃避被歸咎於事故的責任。

缺乏公開遙測會導致：高度政治化的氛圍、需要轉移指控的壓力、無法建立關於事故如何發生的組織知識，以及無法學到防止再次發生的教訓。

遙測使我們能運用科學方法來制定假設，回答以下問題：

• 我們的監控中有什麼證據表明問題確實正在發生？
• 應用程式和環境中有哪些相關事件和變更可能導致了問題？
• 我們能制定什麼假設來確認因果關係？
• 如何證明這些假設是正確的並成功修復問題？

基於事實的問題解決不僅能顯著加速 MTTR，還能強化開發與營運之間的雙贏關係。

將生產指標建立納入日常工作#

為了讓所有人都能在日常工作中發現和修復問題，建立指標的過程必須盡可能簡單。理想情況下，只需寫一行程式碼就能建立一個新指標，並顯示在共同的儀表板上。

這正是 StatsD 的設計哲學。StatsD 由 Etsy 建立並開源，能用一行程式碼（支援 Ruby、Perl、Python、Java 等語言）產生計時器和計數器，通常搭配 Graphite 或 Grafana 來將指標事件渲染為圖表和儀表板。

建立自助式遙測存取與資訊輻射器#

我們的目標是將遙測資訊輻射到整個組織，確保任何想了解服務狀態的人都能自助取得資訊，無需生產系統存取權限或特權帳號。

資訊輻射器（Information Radiator）#

資訊輻射器源自 Toyota Production System 的概念，由 Agile Alliance 定義為「團隊放置在高度可見位置的任何手寫、列印或電子顯示器，讓所有團隊成員和路過者都能一目了然地看到最新資訊」。

將資訊輻射器放在顯眼位置，能促進團隊成員之間的責任感，展示以下價值觀：

• 團隊對訪客（客戶、利害關係人等）沒有什麼需要隱藏的
• 團隊對自身也沒有什麼需要隱藏的：承認並面對問題

案例：LinkedIn 的自助指標（2011）#

LinkedIn 在 2010 年面臨一個困境：雖然產生了大量遙測數據，但工程師極難存取這些資料。一位實習生 Eric Wong 的暑期專案 InGraphs 解決了這個問題——它讓工程師能自行查看 CPU 使用率等指標，進行跨資料集計算、週對週趨勢比較，甚至自訂儀表板。

InGraphs 最終成為 LinkedIn 營運中最具能見度的工具之一，其即時圖表在工程辦公室中顯著展示。

找出並填補遙測缺口#

我們需要在以下各層級建立足夠的遙測覆蓋：

• 業務層級：銷售交易數、營收、用戶註冊數、流失率、A/B 測試結果
• 應用程式層級：交易時間、使用者回應時間、應用程式故障
• 基礎設施層級（資料庫、作業系統、網路、儲存）：Web 伺服器流量、CPU 負載、磁碟使用量
• 客戶端軟體層級（瀏覯器 JavaScript、行動應用）：應用程式錯誤和當機、使用者端量測的交易時間
• 部署流水線層級：建置狀態、部署前置時間、部署頻率、環境狀態

在所有這些領域建立遙測覆蓋後，我們將能基於數據和事實來判斷服務的健康狀態，而非依賴傳言、指責和推測。

安全性的額外價值#

監控應用程式和基礎設施的異常（如程式異常終止、應用程式錯誤與例外、伺服器和儲存錯誤），不僅能讓開發和營運了解服務何時出現問題，這些錯誤往往也是安全漏洞正在被利用的指標。

應用程式與業務指標#

在應用程式層級，我們的目標不僅是追蹤應用程式健康狀態，還要衡量我們達成組織目標的程度。業務指標通常是客戶獲取漏斗（Customer Acquisition Funnel）的一部分。

我們的目標是讓每個業務指標都具有可操作性（actionable）——能夠指導產品決策並適合進行實驗和 A/B 測試。不可操作的指標很可能是虛榮指標（vanity metrics），提供的有用資訊有限。

基礎設施指標#

我們需要確保在生產和非生產基礎設施中產生足夠的遙測，以便在任何環境中發生問題時，能快速判斷基礎設施是否為問題的根因。現代的服務發現工具如 Zookeeper、Etcd、Consul 等，能自動註冊服務並動態發現，解決了 ITIL CMDB 手動維護的問題。

Ticketmaster/LiveNation 的 CTO Jody Mulkey 指出：「與其衡量停機時間的長短，不如衡量 Dev 和 Ops 對停機的真實業務影響——我們本應獲得但未能獲得的營收。」

在指標上疊加其他相關資訊#

即使建立了允許頻繁小型生產變更的部署流水線，變更仍然會產生風險。為了讓變更可見，我們在圖表上疊加所有生產部署活動，以便快速關聯變更與問題。

同樣地，我們也應該疊加其他有用的營運資訊，例如維護時段、備份進行中等，以便在適當的位置顯示或抑制告警。

結論#

Etsy 和 LinkedIn 等公司的實踐告訴我們，即時看到問題並能快速搜尋原因和修復至關重要。透過讓服務的所有元素——無論是應用程式、資料庫還是環境——都發出可分析的遙測，並讓這些遙測廣泛可用，我們能在問題造成災難之前就發現和修復它們。結果不僅是更快樂的客戶，還有一個更快樂、更有生產力的工作環境，減少了救火和危機處理，降低了壓力和倦怠。