2026 年 11 月 4 日，掘金上一篇關於 OpenTelemetry 生產實踐的文章引起不少討論。作者拆解了兩套公開的參考實作：一邊是 Skyscanner 跨 24 個生產集羣、數百個 Collector 實例的大規模治理方案；另一邊是 Mastodon 每個 Namespace 一個 Collector 的極簡設計，由小團隊兼職維護。

技術上這篇文章講得很清楚：標準只解決了協定與 SDK 層面的問題，真正落地最難的往往是 Collector 怎麼部署、怎麼管理、怎麼控制成本。但我們這次想從另一個角度陪你讀這篇文章：如果你就是那個被叫去「把 OTel 落地」的人，這兩種規模落差極大的方案，其實也照出了兩種很不一樣的工作負荷，和你可能正在承受的疲勞。

大規模方案背後，是一個專職團隊

Skyscanner 的做法是分層 Collector：節點級 Agent 做輕量處理，集羣級 Gateway 承擔採樣、過濾、路由、限流，再用區域聚合層彙整後寫入後端。配置全部集中在統一倉庫版本化管理，靠 GitOps 分發到 24 個集羣。

這套架構的重點不是「厲害」，而是它背後有一個專職的可觀測性平臺團隊在撐。文章裡寫得很誠實：Skyscanner 是用架構複雜度換治理能力。

如果你的公司只有兩三個人要扛類似的規模，照搬這套分層設計，很容易變成白天開會、深夜排查管線的日常。這不是你能力不夠，是方案與團隊資源本來就不匹配。判斷「我們到底需要多少可觀測性」，跟你判斷「我今天還能不能再戰一小時」是同一種功課，我們先前在Dartastic OpenTelemetry 背後聊聊工程師身體訊號那篇也提過類似的事。

小團隊方案的價值：可預測，包含你的作息

Mastodon 那邊走的是完全相反的路：每個 Namespace 一個 Collector，配置跟著應用清單一起版本化，頭部採樣為主、低比例，追求「零運維」。文章總結得很到位：用功能克制換維護成本。

對兼職維護監控的人來說，「夠用而且可預測」經常比「功能完整」更健康。因為零運維的設計意味著你半夜被 alert 叫起來的機率低一些，週末不需要盯著 Grafana 面板確認管線有沒有堵住。

這裡有一個可以實際採用的判斷方式：評估監控方案時，除了看功能清單，也把「維護它需要的人力」算進去。如果一個方案需要專職團隊而你們沒有，那它的複雜度遲早會轉嫁到某個人的睡眠上。長期下來，疲勞累積、注意力下滑，排查事故反而更容易出錯，這在需要高度專注的基礎設施工作上特別劃不來。

兩套方案，同一個提醒：規模要匹配，包括你的負荷

這篇文章最有價值的一句話，是「兩者沒有優劣之分，只有規模與團隊約束的匹配度差異」。技術選型如此，工作量安排也是如此。

幾個可以順手做的檢查：

  • 如果你正在主導 OTel 導入，先盤點團隊能投入的人力，再決定要走集中式 Gateway 還是分散式極簡方案，而不是先看別人的架構圖。
  • 排查管線問題容易一坐兩三小時，記得設個提醒起來走動、讓眼睛離開螢幕休息幾分鐘。
  • 如果你發現自己為了顧這些系統連續犧牲睡眠、假日也在改配置，這已經是身體在提醒負荷過重的訊號，值得和主管談資源，而不是硬撐。

最後照例說清楚：這篇文章的技術內容來自掘金作者的整理與兩家公司的公開實踐，屬於經驗分享層次，不是什麼放諸四海皆準的標準答案。挑方案的時候，跟照顧自己一樣，適合自己的約束條件，才是最好的條件。