Datadog用7年把監(jiān)控從運(yùn)維踢進(jìn)開發(fā)

2019年，Datadog（數(shù)據(jù)狗，云監(jiān)控平臺）內(nèi)部搞了個實(shí)驗(yàn)：讓開發(fā)團(tuán)隊(duì)在代碼提交前自己查性能瓶頸。結(jié)果故障排查時間從平均4小時壓到23分鐘——不是運(yùn)維工具變快了，是問題在上線前就被掐死了。

這個數(shù)據(jù)被寫進(jìn)他們2023年的工程博客，卻沒多少人注意到背后的轉(zhuǎn)向。可觀測性（Observability，通過系統(tǒng)輸出推斷內(nèi)部狀態(tài)的能力）正在從"運(yùn)維的滅火器"變成"開發(fā)的顯微鏡"，而大多數(shù)公司的組織架構(gòu)還沒反應(yīng)過來。

運(yùn)維背鍋的時代：為什么監(jiān)控成了"事后諸葛亮"

傳統(tǒng)分工里，開發(fā)寫代碼，運(yùn)維管機(jī)器，監(jiān)控是運(yùn)維的KPI。系統(tǒng)崩了，運(yùn)維熬夜重啟，開發(fā)睡個好覺。這套邏輯在單體架構(gòu)時代跑得通——故障點(diǎn)少，日志集中，運(yùn)維翻幾遍日志就能定位。

微服務(wù)把這套打碎了。Datadog 2022年的客戶數(shù)據(jù)顯示，平均一個中型企業(yè)有300+個服務(wù)實(shí)例，調(diào)用鏈跨十幾個團(tuán)隊(duì)。運(yùn)維拿到告警時，面對的是一團(tuán)纏繞的依賴關(guān)系，而寫代碼的人早已離職或轉(zhuǎn)崗。

「我們見過最極端的案例，一個P0故障根因是三年前某個開發(fā)加的緩存策略，但沒人能解釋為什么當(dāng)時要這么寫。」Datadog產(chǎn)品副總裁Yaniv Makover在2023年KubeCon上提到。運(yùn)維成了考古學(xué)家，而開發(fā)團(tuán)隊(duì)對生產(chǎn)環(huán)境一無所知。

三個信號：你的可觀測性是否還在"踢皮球"

信號一：故障復(fù)盤會變成了"甩鍋大會"。開發(fā)說"我本地跑得好好的"，運(yùn)維說"資源監(jiān)控沒異常"，最后結(jié)論是"網(wǎng)絡(luò)抖動"——這種模糊歸因意味著數(shù)據(jù)沒打通，兩邊各看各的儀表盤。

信號二：可觀測性預(yù)算只花在"買工具"，沒花在"改流程"。Gartner 2023年調(diào)研顯示，企業(yè)在可觀測性工具上的支出年增長34%，但"開發(fā)階段集成監(jiān)控"的比例僅從12%升到19%。工具買了，人還是那套用法。

信號三：SRE（站點(diǎn)可靠性工程）團(tuán)隊(duì)成了"人形API"。開發(fā)提交工單等SRE查數(shù)據(jù)，而不是自己上手。Datadog內(nèi)部測算，這種模式下信息傳遞損耗超過60%，一個簡單查詢平均要轉(zhuǎn)3個人。

這三個信號的核心矛盾是：數(shù)據(jù)在運(yùn)維手里，上下文在開發(fā)腦子里，中間隔著一堵組織墻。

Datadog的解法：把可觀測性"左移"到IDE里

他們的做法不是給運(yùn)維換更貴的工具，而是讓開發(fā)在寫代碼時就能看到生產(chǎn)環(huán)境的數(shù)據(jù)。具體有三層：

第一層，代碼級埋點(diǎn)自動化。通過靜態(tài)分析在編譯期注入監(jiān)控邏輯，開發(fā)不需要手動寫日志語句。2022年推出的CI Visibility（持續(xù)集成可見性）產(chǎn)品，能把測試階段的性能回歸直接標(biāo)在PR（Pull Request，代碼合并請求）評論里。

第二層，統(tǒng)一數(shù)據(jù)模型。指標(biāo)（Metrics）、日志（Logs）、鏈路追蹤（Traces）三套數(shù)據(jù)用同一個標(biāo)簽體系，開發(fā)查一個請求慢，能直接看到它經(jīng)過了哪些服務(wù)、哪段代碼、哪臺機(jī)器，不需要運(yùn)維翻譯。

第三層，成本可視化。可觀測性數(shù)據(jù)存儲成本很高，Datadog給每個團(tuán)隊(duì)看自己的賬單，倒逼開發(fā)優(yōu)化埋點(diǎn)策略。Makover透露，這個功能上線后，客戶平均數(shù)據(jù)量下降了40%，但有效告警反而增加了——因?yàn)樵胍羯倭恕?/p>

國內(nèi)玩家的跟注：阿里云、字節(jié)跳動的不同打法

阿里云2023年把ARMS（應(yīng)用實(shí)時監(jiān)控服務(wù)）和云效（DevOps平臺）打通，做法偏"平臺整合"——在一個控制臺里既能看監(jiān)控也能發(fā)版。適合已經(jīng)深度用阿里云的客戶，但跨云場景支持弱。

字節(jié)跳動的內(nèi)部實(shí)踐更激進(jìn)。他們的Mona平臺把可觀測性數(shù)據(jù)直接接進(jìn)代碼評審流程，如果PR涉及的服務(wù)在過去7天有P1故障，系統(tǒng)會自動@相關(guān)SRE參與評審。這個機(jī)制讓開發(fā)在寫代碼時就得考慮"這段代碼上次出過什么事"。

兩種路徑的共同點(diǎn)是：可觀測性不再是運(yùn)維團(tuán)隊(duì)的"專業(yè)領(lǐng)域"，而是變成開發(fā)工作流里的默認(rèn)配置。區(qū)別在于，阿里云賣的是工具集成，字節(jié)跳動賣的是組織習(xí)慣——后者更難復(fù)制。

一個值得注意的細(xì)節(jié)：Datadog 2023年Q3財報里，"開發(fā)階段使用"的客戶占比首次超過50%，而2020年這個數(shù)字是17%。這不是產(chǎn)品升級，是用戶畫像的徹底換血。

組織阻力：為什么知道該改卻改不動

最大的障礙不是技術(shù)，是考核指標(biāo)。運(yùn)維團(tuán)隊(duì)的KPI是MTTR（平均修復(fù)時間），開發(fā)團(tuán)隊(duì)的KPI是交付速度。讓開發(fā)花時間查監(jiān)控，短期看是拖慢迭代；讓運(yùn)維放權(quán)給開發(fā)，長期看是削弱部門價值。

Datadog的應(yīng)對是賣"共同指標(biāo)"：給CTO看"故障預(yù)防率"——有多少問題在上線前被攔截。這個指標(biāo)同時綁架開發(fā)和運(yùn)維，倒逼協(xié)作。2023年他們推出的Service Catalog（服務(wù)目錄）產(chǎn)品，本質(zhì)上是一個"組織關(guān)系可視化"工具，讓誰該對哪個服務(wù)負(fù)責(zé)變得無法推諉。

國內(nèi)某頭部云廠商的解決方案架構(gòu)師私下吐槽：「我們跟客戶講這套，客戶說'我們先買個工具試試'。買完了還是老用法，第二年續(xù)費(fèi)的時候問為什么沒效果。」

工具買得再貴，組織不跟著動，可觀測性就還是運(yùn)維的背鍋俠。

Datadog 2024年的產(chǎn)品路線圖里有個功能叫"AI輔助根因分析"，但內(nèi)部文檔明確寫了：「AI只能縮小排查范圍，最終判斷需要寫代碼的人參與。」這個備注沒出現(xiàn)在任何新聞稿里，卻可能是整個趨勢最真實(shí)的注腳——數(shù)據(jù)可以集中，決策權(quán)正在分散。你的公司，監(jiān)控數(shù)據(jù)在誰手里，決策又在誰手里？