AI 代理人越多，它收的保護費越多？AI是助力並非阻力？- 深入分析第55期：Datadog

(我家有隻柴犬，所以私心將它放在今期的封面圖片中，哈哈哈)

我們聊 AI，聊了很久的半導體。

從Nvidia到台積電，從 HBM 到 CoWoS，整個市場的目光都在那片矽晶片上。這很合理，在淘金潮裡，賣鏟子的人最先賺到錢。

但如果你把視野放大，就會發現半導體其實只是其中一部份。

黃仁勳曾提出一個著名的比喻：「AI 就像是一個五層大餅（AI is a 5-layer cake）。」

Chips只是其中的第一層。但在過去這段時間，整個市場幾乎把所有的注意力都賭在了這單一樓層上。

這顯然漏掉了大餅的其他美味部分。

在上一波「軟體末日（SaaSpocalypse）」的恐慌潮中，我曾清楚定義了所有 SaaS 公司的贏家與輸家（有興趣的讀者可以回頭複習舊文）。

當時我就清楚定義：資安（Cybersecurity）將會是 AI 浪潮下的直接受益者。

雖然討論的人不多，但過去這段時間，資安巨頭們的股價早已不斷默默創下歷史新高，驗證了這個判斷。

現在，資安這一層已經被市場看見，是時候把目光轉向大餅中另一個同樣關鍵的樓層：資料層（Data Layer）。

如果說矽晶片是最底層的地基，那麼地基上面得蓋樓。資料要有地方存、有地方跑、有地方被盯著。

如果錢真要往資料層走，哪一層是不管 AI 最後怎麼發展，大家都繞不過去的？

要回答這題，我們得先看懂資料在 AI 世界裡到底是怎麼流動的。

---

第一章｜資料是怎麼流動的？

我們用一個日常的生活場景來當例子。

想像一下，你對著手機上的 AI 助理說了一句話：「幫我推薦香港今天適合聚餐的餐廳，順便幫我訂位。」

這句看似簡單的要求，在後台其實啟動了一場資料的接力賽：

第一步，你的聲音被轉成文字，傳送到系統的「即時心跳層」。

系統要立刻反應，確認你是誰、你現在人在哪裡、你過去一分鐘是不是也問過類似的問題。這個步驟必須在幾毫秒內完成，否則你就會覺得這個 AI 助理反應很慢。

第二步，AI 開始動腦。

它需要去「大倉庫」裡，調出過去幾年累積的所有香港餐廳評價、營業時間、還有你過去幾百次的消費偏好。AI 的聰明程度，取決於它能多快、多精準地從這個大倉庫裡撈出正確的資料來做運算。

第三步，當 AI 幫你選好餐廳並按下「確認訂位」時，這個訂位成功的訊號，又會立刻傳回即時心跳層，更新你的會員狀態，並同時把這筆新的消費紀錄，打包送回大倉庫儲存起來，作為下一次推薦的依據。

在這個過程中，資料在不同的系統之間瘋狂地讀寫、搬運、堆積。

AI 就像是一台跑車，晶片是引擎，而資料就是汽油。 沒有汽油，再強大的引擎也動不起來。

看懂了資料的流動，我們就可以把這棟名為「資料層」的大樓，大概劃分出三個樓層(實際上可以再細分)：

---

1.1 一樓：倉儲層（代表企業：Snowflake）

這是一棟樓的大倉庫。所有歷史的、堆積的、過去幾年累積下來的資料，最後都會匯到這裡。

在 AI 時代，這裡就是「訓練模型」的燃料庫。企業要把 AI 訓練得聰明，就必須把幾百萬筆客戶對話紀錄、銷售數據、產品手冊全部塞進這個倉庫裡，讓 AI 在裡面讀書、學習規律。

---

1.2 二樓：營運資料庫層（代表企業：MongoDB）

這是資料的即時心跳。你的應用程式每一次點擊、每一筆交易、每一個當下正在發生的動作，都在這一層被讀進讀出。

在 AI 時代，這裡負責的是「即時推論與互動」。當你跟 AI 對話時，AI 需要立刻知道你上一秒說了什麼、你現在的帳戶餘額是多少。

這些需要極速反應、不斷變動的活資料，都由二樓來管。二樓管的是現在。

---

1.3 三樓：可觀測層（代表企業：Datadog）

這一層不存資料，也不直接跑業務，它做的事非常特別。它站在最高處，盯著整棟樓的運作狀況。

一樓的倉庫有沒有塞車、二樓的心跳有沒有亂、哪個環節開始變慢、哪裡快出問題，它就是那個拿著監視器、負責發現問題的人。

---

1.4 為什麼三樓是個獨特的生意？

三樓和另外兩層的生意邏輯完全不同。

它不存資料，也不直接跑業務。它扮演的是「系統的醫生」，負責把整棟樓的運作狀況，變成看得見、診斷得出、優化得了的畫面。

因此，底下的每一場技術戰爭、每一次 AI 實驗，對三樓來說都不是風險，而是燃料。

當企業從簡單的「一問一答」，變成讓多個 AI 助理在後台互相串聯、自己上網查資料、自己做決策；當 AI 的計費成本開始上下波動、運作鏈路越來越長、錯誤可能在第七步才爆發，三樓需要盯著的「範圍」就會呈現指數級擴張。

企業每多引入一個新的 AI 工具、每多部署一個 AI 助理、每多做一次省錢的優化，三樓的價值就多一層。

三樓不賭哪個模型會勝出、哪個資料庫會主導，它只賭一件事：

只要 AI 持續從「玩具」走向「真正大規模的應用」，這棟樓就只會越來越亂。 而「把亂看清楚」的需求，正是它收保護費的理由。

更重要的是，這層複雜度紅利在 AI 時代被進一步放大了。

傳統的軟體系統，工程師或許還能憑經驗硬撐。但 AI 系統本質上就是個「高不確定性、高成本」的黑盒子。

AI 消耗的字數成本（Token）可能因為你改了一句話就突然暴增；AI 助理在實際運作時的路線，可能跟在測試時完全不同；一個小小的錯誤，可能會在多個模型互相呼叫時被無限放大。

這時候，「看清楚系統運作的能力（Observability）」不再只是「有總比沒有好」的配角，而是決定企業投資 AI 能不能真正回本的關鍵地基。

當然，站在最高處看得最清楚，也代表最顯眼。憑什麼是它站在那裡？它憑什麼讓底下各種不同的資料系統、不同的 AI 框架，都願意把狀態回報給它？這門「誰都得經過」的生意，到底是怎麼長出來的？

要回答這個問題，我們得先回到十幾年前，回到兩個工程師，以及一場開發團隊與維運團隊互相對罵的戰爭。

---

第二章｜身世：兩個工程師，與那條不選邊的狗

要看懂 Datadog 的生意，我們得先回到 2010 年前後。

那是一個科技業正在發生劇烈地殼變動的年代。當時，智慧型手機剛剛普及，行動網路流量開始爆炸，亞馬遜的 AWS 雲端服務也正悄悄地改變企業架設系統的方式。

在那個時間點，有兩位在紐約一家媒體科技公司（Wireless Generation）工作的軟體工程師。一位叫 Olivier Pomel，他負責帶領軟體開發團隊（Dev）；另一位叫 Alexis Lê-Quôc，他負責帶領系統維運團隊（Ops）。

這兩個人在辦公室裡，每天都在經歷一場科技業最經典的戰爭：開發與維運的對罵。

---

2.1 辦公室裡的日常戰爭

在軟體開發的世界裡，這兩個團隊的目標天生就是衝突的。

開發團隊（Dev）的任務是「求快」。他們要不斷寫出新功能、推出新產品，把程式碼往線上送。

維運團隊（Ops）的任務是「求穩」。他們要確保伺服器不當機、網站不掛掉。對他們來說，每一次開發團隊送上來的新程式碼，都是一個可能讓系統崩潰的未爆彈。

當系統運作正常時，大家相安無事。可是一旦網站突然變慢、或者結帳功能卡住，辦公室裡就會上演這樣的對話：

維運團隊指著監控螢幕大喊：「系統記憶體過高！一定是你們剛才寫的新功能有 Bug，趕快把程式碼退回去！」

開發團隊翻著白眼回應：「我們在測試環境跑都沒問題，一定是你們的伺服器設定有問題，或者是資料庫塞車，不要每次出事都怪程式碼！」

為什麼會這樣？因為這兩個團隊看世界的視角完全不同。開發團隊看的是程式碼的邏輯與應用程式的效能；維運團隊看的是伺服器的 CPU、記憶體與網路頻寬。

最糟糕的是，他們用的是完全不同的監控工具。開發團隊看著 A 儀表板，維運團隊看著 B 儀表板。兩邊數據對不上，無法好好溝通。每次出事，大家不是先解決問題，而是先花兩個小時證明「這不是我的責任」。

這兩位工程師看著這種無意義的內耗，心裡想著：為什麼我們不能有一張共同的儀表板？

這張儀表板不偏袒開發，也不偏袒維運。它要把程式碼的狀態、伺服器的健康度、資料庫的反應時間，全部拉到同一個畫面上。當大家看著同一套數據、說著同一種語言時，戰爭自然就會結束。

甚至連「Datadog」這個名字，都帶著這段歷史的痕跡。當時在他們的公司，有一台專門用來存放各種混亂系統日誌（Logs）的伺服器，因為裡面塞滿了沒人想碰的雜亂資料，工程師們私底下都叫它「Data Doghouse」（資料狗屋）。

他們決定把這隻狗牽出來，讓它當那條把兩邊拉到同一張桌子上的狗。

---

2.2 天生的中立基因

這個身世，決定了 Datadog 從誕生第一天起，就擁有一個非常獨特的商業基因：跨陣營的中立性。

在矽谷，很多科技公司的產品是具有強烈排他性的。如果你用了甲骨文（Oracle）的資料庫，你可能就不會用微軟的 SQL Server；如果你用了亞馬遜的 AWS，你可能就會盡量避免使用微軟的 Azure。這些巨頭都想把客戶鎖在自己的生態系裡，構築高牆。

但 Datadog 不一樣。它一出生，就是為了解決「混亂與衝突」而存在的。

它不能選邊站。它如果偏向開發端，維運端就不會買單；它如果只支援亞馬遜的雲端，那些使用自建機房或微軟雲端的企業就會把它拒之門外。

為了當好那個「和事佬」，Datadog 必須對所有的技術一視同仁。不論你是寫 Java、Python 還是 Go 語言；不論你的伺服器是放在自家地下室，還是放在 AWS、Google Cloud 上；不論你用的是 MySQL 還是 MongoDB。

Datadog 的任務，就是在這些五花八門的系統裡插上它的探針，把所有的數據標準化，然後呈現在同一個畫面上。

這種「不選邊」的定位，在當時看似是一個沒有自己核心地盤的邊緣生意，但它卻完美地卡進了即將到來的時代大潮。

---

2.3 那它到底怎麼看?

一個醫生要判斷病人的狀況,不會只盯著一個數字。他會同時看三種東西:生命徵象、病歷、還有斷層掃描。

Datadog 盯著這棟樓的方式,幾乎一模一樣,靠的也是三種資料。

第一種,是指標（Metrics）,這棟樓的生命徵象。

CPU 用了幾成、記憶體多滿、每秒進來幾個請求、反應慢了幾毫秒。這些是不斷跳動的數字,像病床邊那台儀器上起伏的心跳線,讓你一眼看出現在正不正常。

第二種,是日誌（Logs）,這棟樓的病歷。

系統每做一件事,就寫下一行紀錄。出事時,工程師得回頭翻這些紀錄,才知道當下到底發生了什麼。這是三種資料裡量最大、最花錢的一種。記住這一點,它在後面的故事裡會再次出現。

第三種,是追蹤（Traces）,這棟樓的全身斷層掃描。

試想像一下，當你按下「確認訂位」時,這一個動作,可能在後台默默跳過了 50 個不同的服務:先問會員系統,再查餐廳資料庫,再呼叫地圖,再通知簡訊……環環相扣。

問題來了:如果整件事變慢了,到底是哪一站卡住的?

靠翻病歷（日誌）去找,像大海撈針。這時候就要靠追蹤。追蹤做的事,是幫「這一筆請求」綁上一個 GPS,完整記錄它一路經過哪 50 站、每一站待了幾毫秒。

於是你一眼就看到:原來是第 37 站那個資料庫,卡了整整兩秒。

而 Datadog 真正值錢的地方，還不是它同時握有這三種資料。

而是它能把三種串起來。

你先在生命徵象上看到反應時間突然飆高（指標），點一下，跳到那筆出問題的請求走過的完整路徑（追蹤），再點一下，跳到那一刻系統寫下的錯誤紀錄（日誌），直接看到是哪一行程式碼出了包。

從「哪裡怪怪的」到「就是這一行」，整個過程在同一個畫面上，幾秒內走完。

這件事聽起來理所當然，做起來卻極難。因為那三種資料，原本是散在完全不同的系統裡、格式各不相同的東西。

要把它們接起來、對齊時間、還能互相跳轉，是 Datadog 花了十幾年才磨出來的真功夫。

---

2.4 賭一個「複雜化」的未來

2010 年，這兩位創辦人決定出來創業時，正好卡在雲端運算大爆發的前夜。

在雲端時代來臨前，企業的系統其實相對簡單。一家公司可能就只有幾台大型伺服器，跑著一個巨大的單體應用程式（Monolithic）。哪裡壞掉，工程師進去重啟那台伺服器通常就能解決。

但雲端服務改變了一切。

企業開始把系統拆碎，變成幾百個、甚至幾千個微服務（Microservices）。這些微服務像樂高積木一樣，散落在不同的雲端平台上，彼此透過網路互相呼叫。

系統變得極度靈活，但也變得極度碎片化與複雜。

以前出問題，是那台唯一的伺服器壞了；現在出問題，可能是 A 服務呼叫 B 服務時慢了兩毫秒，導致 C 服務逾時，最後讓 D 資料庫卡死。

「到底哪裡出事了？」變成所有企業技術長（CTO）每天晚上的噩夢。

Datadog 賭的就是這個趨勢。它賭企業的系統不會越來越簡單，只會越來越亂、越來越碎。而系統越亂，大家就越需要一個中立的第三方，站在高處幫忙看著全局。

這個在 2010 年種下的賭注，讓 Datadog 在接下來的雲端黃金十年裡，迎來了爆發性的成長。因為每當企業多用一個雲端服務、多串一個資料庫，Datadog 就能多收一份監控的費用。

而最有趣的是，這個關於「複雜化」的賭注，並沒有隨著雲端時代的成熟而結束。

十幾年後，當 AI 浪潮鋪天蓋地而來，企業開始把大語言模型、向量資料庫、AI 代理人（Agents）塞進自己原本就已經夠混亂的系統裡時，這棟大樓的複雜度，直接被推上了另一個全新的維度。

當年那條為了平息辦公室爭吵而誕生的小狗，即將在 AI 的混亂世界裡，迎來它更大、也更瘋狂的戰場。

---

第三章｜長大：從一個工具變成一座收費站

在商業世界裡，最讓人羨慕的生意，就是蓋一座大家都避不開的收費站。

Datadog 在剛創立時，還只是一個幫忙看管伺服器硬體健康度的小工具，也就是業界常說的基礎設施監控（Infrastructure Monitoring）。

當時的它，只負責盯著 CPU 有沒有過熱、記憶體夠不夠用。這種工具在市場上並不少見，雖然好用，但隨時可以被其他便宜的選擇替代。

然而，這兩位工程師創辦人非常清楚，如果只停留在這個階段，Datadog 永遠只會是一個可有可無的工具。

他們開始了一場長達十年的產品擴張計畫。這場擴張的邏輯非常簡單，他們要讓客戶把所有與運作相關的資料，全部倒進同一個地方。