凌晨 2 點，你的手機突然震動。網(wǎng)站宕機了，Slack 上滿是紅色警報，用戶已經(jīng)開始在推特上抱怨。你半睡半醒地盯著屏幕，完全不知道該從哪里著手排查。

這是站點可靠性工程師（SRE）們再熟悉不過的場景。這些工程師必須不惜一切代價保障在線服務(wù)持續(xù)運行，而當(dāng)服務(wù)中斷時，壓力值會瞬間飆升。故障恢復(fù)是一場與時間的賽跑，但大多數(shù)團隊在真正開始排查問題前，就要花費第一個小時收集線索。

“最初五分鐘是恐慌期，” 紐伯德（NeuBird）首席執(zhí)行官兼聯(lián)合創(chuàng)始人高瑟姆?拉奧表示，“接下來的 25 分鐘是召集團隊確認(rèn)問題 —— 比如是代理錯誤，然后趕緊上 Slack、打電話、聯(lián)系相關(guān)人員?！?應(yīng)急指揮室迅速組建，電話會議緊急召開，團隊之間相互指責(zé)，而故障持續(xù)的時間仍在一分一秒流逝。

紐伯德人工智能：更快定位根源，更少應(yīng)急會議

智能體 AI 技術(shù) 了解更多

拉奧對這種痛苦深有體會。這位連續(xù)創(chuàng)業(yè)者曾不得不從舊金山飛往阿姆斯特丹，在漆黑的數(shù)據(jù)中心里修復(fù)自己產(chǎn)品的漏洞 —— 只因為客戶不允許遠(yuǎn)程訪問。這次故障的持續(xù)時間，基本上就是他的飛行時間。他意識到一定有更好的解決辦法，于是紐伯德公司應(yīng)運而生。

這家初創(chuàng)公司得到了微軟的投資，且與亞馬遜云服務(wù)（AWS）建立了合作關(guān)系，其推出的產(chǎn)品正讓上述繁瑣的故障處理流程成為歷史。這款名為 “鷹眼”（Hawkeye）的產(chǎn)品是一款人工智能驅(qū)動的 SRE 工具，能在你的團隊還沒完全清醒時就自動展開故障調(diào)查。拉奧強調(diào)，這絕非另一款用于查詢?nèi)罩镜牧奶鞕C器人，而是一個能形成假設(shè)、通過遙測數(shù)據(jù)驗證假設(shè)，并最終告訴你實際故障點的智能體系統(tǒng)。

為什么云運維會陷入瓶頸？

拉奧表示，SRE 自動化的實現(xiàn)早已箭在弦上。支撐現(xiàn)代軟件運行的架構(gòu)，恰恰也是讓故障排查變得極為棘手的根源。在過去二十年里，面向服務(wù)架構(gòu)成為了行業(yè)標(biāo)準(zhǔn)，因為它能讓團隊更快地開發(fā)產(chǎn)品。然而，這種架構(gòu)也形成了一張錯綜復(fù)雜的依賴關(guān)系網(wǎng)，很少有人能完全理解。這些復(fù)雜系統(tǒng)中，在一個系統(tǒng)中進行的微小操作，可能會導(dǎo)致數(shù)千英里外的另一個系統(tǒng)崩潰。

拉奧描述了這樣一個場景：你的網(wǎng)站出現(xiàn)超時問題。憑直覺判斷，這似乎是用戶界面（UI）或 Web 應(yīng)用層的問題，你可能會認(rèn)為是前端出了差錯。但真正的問題，其實是三層之下的某個數(shù)據(jù)庫資源耗盡。

“網(wǎng)站運行緩慢的根本原因，與 Web 應(yīng)用程序或計算資源毫無關(guān)系，而是因為容量不足，” 他解釋道，“誰能想到會是這樣？人們往往需要花費很長時間才能理清這些關(guān)聯(lián)?！?/p>

本應(yīng)提供幫助的工具，反而帶來了新的問題。如今，AWS 環(huán)境中數(shù)千個資源會生成數(shù)百萬個遙測數(shù)據(jù)點。你可以對所有內(nèi)容進行監(jiān)控，但更高的可見性往往意味著更低的清晰度 —— 這個問題被稱為 “可觀測性悖論”。

根據(jù) AWS 的數(shù)據(jù)，70% 的警報需要工程師手動跨多個服務(wù)進行關(guān)聯(lián)分析。通常情況下，工程師要花費 3 到 4 個小時調(diào)查復(fù)雜故障，這還不包括實際修復(fù)問題的時間。

拉奧很快指出，這并非要取代人類。“這不是用更少的人做同樣的事，” 他說，“在任何創(chuàng)新周期中，情況從來都不是這樣。真正的價值是用現(xiàn)有資源做更多的事?！?/p>

智能體 AI 有何不同之處？

智能運維（AIOps）市場早已擁擠不堪，許多工具只是在日志查詢功能上套了個聊天機器人的外殼，就宣稱是創(chuàng)新。而 “鷹眼” 正在進行結(jié)構(gòu)性的創(chuàng)新 —— 如果你要將生產(chǎn)環(huán)境的安全托付給它，這種區(qū)別至關(guān)重要。

大多數(shù)企業(yè)級 AI 產(chǎn)品采用檢索增強生成（RAG）技術(shù)：將文檔輸入大型語言模型（LLM），進行向量化處理，然后就相關(guān)內(nèi)容提問。這種方法適用于企業(yè)知識庫和政策文件，但如果用于 IT 遙測數(shù)據(jù)，就會完全失效。

“你不能把所有 IT 遙測數(shù)據(jù)都復(fù)制到 ChatGPT 中，然后說‘幫我解決問題’，” 拉奧解釋道，“這根本行不通?！?這些數(shù)據(jù)是由日志、追蹤信息、配置數(shù)據(jù)和時間序列指標(biāo)構(gòu)成的動態(tài)集合，且以毫秒級的粒度捕獲。你不可能把所有這些數(shù)據(jù)都輸入提示窗口，還指望得到有用的結(jié)果。

智能體系統(tǒng)則顛覆了這種思路。它不是將內(nèi)容輸入 LLM 再提問，而是讓 LLM 先確定自己實際需要哪些信息，然后從數(shù)據(jù)源中精準(zhǔn)提取。LLM 生成的是調(diào)查程序，而非自然語言答案。

這正是 “上下文工程” 比 “提示工程” 更重要的地方。拉奧用醫(yī)學(xué)類比來解釋這種區(qū)別：即使是世界上最好的醫(yī)生，如果患者無法準(zhǔn)確描述癥狀，也無法做出準(zhǔn)確診斷。

“LLM 的問題在于，無論你問什么，它總能給出答案，” 他說，“這對生產(chǎn)系統(tǒng)來說是個大問題，因為你不想誤導(dǎo)他人?！?如果給 LLM 提供了錯誤的上下文，它會信心滿滿地去解決一個根本不存在的問題。關(guān)鍵在于，要確保它在開始推理之前，向正確的數(shù)據(jù)源提出正確的問題。

一個能學(xué)習(xí)、會自我編寫指令的系統(tǒng)

“鷹眼” 的底層是紐伯德公司自主研發(fā)的 “渡鴉 AI 表達式語言（RAEL）”。這是一種結(jié)構(gòu)化語法，能讓 LLM 創(chuàng)建可驗證的調(diào)查程序，而非自然語言響應(yīng)。這些程序可以被驗證和編譯，從而消除調(diào)查過程中的幻覺問題（即 AI 生成虛假信息）。

“對我們來說，智能體系統(tǒng)是專家系統(tǒng)與生成式 AI 認(rèn)知能力的結(jié)合體，” 拉奧解釋道。該系統(tǒng)將專家系統(tǒng)的可靠性與生成式 AI 的創(chuàng)造性融為一體，既具備足夠的結(jié)構(gòu)性以確?？尚哦?，又擁有足夠的靈活性以應(yīng)對新情況。

將調(diào)查技術(shù)編碼化的能力，讓工程師能夠隨著時間的推移調(diào)整調(diào)查流程。用通俗易懂的英語告訴 “鷹眼” 下次更關(guān)注網(wǎng)絡(luò)問題，其底層的 RAEL 語法（由 LLM 自行創(chuàng)建）就會相應(yīng)調(diào)整。你不是在配置一個靜態(tài)的規(guī)則引擎，而是在訓(xùn)練一個認(rèn)知系統(tǒng)。

有一位客戶就發(fā)現(xiàn)了這一功能：當(dāng)時 “鷹眼” 無法解釋 DNS 請求突然下降的原因，最終查明根源是外部 Cloudflare 的故障，而 “鷹眼” 之前無法獲取相關(guān)可見性數(shù)據(jù)。該客戶隨后在未來的調(diào)查中添加了 Cloudflare 狀態(tài)檢查功能 —— 這個系統(tǒng)在不斷學(xué)習(xí)。

一支由大型語言模型組成的 “軍團”

“鷹眼” 也并非依賴單一的 LLM 運行。紐伯德采用了拉奧所說的 “模型艦隊”：有些模型更適合時間序列分析，有些則擅長解析 JSON 結(jié)構(gòu)。目前的模型組合包括 Anthropic 的 Claude 和各類 GPT 模型，不過其架構(gòu)設(shè)計允許隨著市場發(fā)展更換模型。企業(yè)也可以接入自己的 Bedrock 模型，在使用 “鷹眼” 調(diào)查框架的同時，消耗已承諾的云服務(wù)預(yù)算。

該平臺原生集成了 AWS 的多項服務(wù)，包括 CloudWatch、EKS、Lambda、RDS 和 S3，同時也支持 Azure 和本地部署環(huán)境。Dynatrace、Splunk 和 Prometheus 等標(biāo)準(zhǔn)可觀測性工具棧開箱即用。對于使用自研工具的企業(yè)，模型上下文協(xié)議（MCP）可為專有系統(tǒng)提供連接橋梁。

安全性將是潛在用戶的主要顧慮?！苞椦邸?僅擁有只讀權(quán)限，且不存儲任何遙測數(shù)據(jù)，僅保留一些用于標(biāo)識環(huán)境特征的元數(shù)據(jù)，例如 EC2 實例數(shù)量或 Kubernetes 集群信息。對于需要額外隔離的企業(yè)，該平臺提供完整的虛擬私有云（VPC）部署選項 —— 所有處理過程都在 VPC 內(nèi)部進行，數(shù)據(jù)永遠(yuǎn)不會離開用戶的 AWS 環(huán)境。

保持人類的主導(dǎo)權(quán)

“鷹眼” 僅提供建議，不會自動執(zhí)行修復(fù)操作 —— 這是刻意設(shè)計的?！拔覀兲匾庀拗屏怂膱?zhí)行權(quán)限，” 拉奧解釋道，他認(rèn)為智能體系統(tǒng)對很多人來說有點像自動駕駛汽車：概念很酷，但還不夠成熟，不足以讓大多數(shù)人完全放手。不過，對于愿意自動化重復(fù)操作的客戶，紐伯德也提供了相應(yīng)的自動化選項。

一些完全無風(fēng)險的操作（例如切換功能標(biāo)志）是允許的 —— 這類功能標(biāo)志本身已經(jīng)過測試，其可能產(chǎn)生的后果也已明確。但編寫代碼或修補 Helm 圖表？目前還不支持。

顧慮在于：95% 的成功率伴隨著 5% 的嚴(yán)重失敗，可能會徹底破壞人們對智能體系統(tǒng)的信任。因此，目前最好讓人類參與決策循環(huán)，逐步建立信任。

當(dāng) “鷹眼” 無法解決某個問題時，它會如實告知。該系統(tǒng)會根據(jù)實際遙測數(shù)據(jù)驗證自己的結(jié)論，因此最壞的情況是承認(rèn)不確定性，而非信心滿滿地誤導(dǎo)用戶。它還有一個有趣的后臺功能：利用相互競爭的 LLM 對彼此的發(fā)現(xiàn)進行辯論。這種辯證過程能讓結(jié)果經(jīng)過合理性檢驗，變得更加可靠。

“鷹眼” 的儀表盤會生成報告，顯示每次調(diào)查節(jié)省的預(yù)估時間。定制技術(shù)解決方案提供商 Model Rocket 運行著包含 Lambda、RDS、ElastiCache 和 EKS 的復(fù)雜環(huán)境，部署該平臺后，其平均恢復(fù)時間縮短了 90% 以上。

認(rèn)知層面的轉(zhuǎn)變

紐伯德處于一個有利地位：微軟是其投資方，該公司還參與了雷德蒙德（微軟總部所在地）的精英項目 Pegasus，得以接觸到 Adobe、歐特克（Autodesk）和雪佛龍等企業(yè)客戶。在 AWS 方面，紐伯德入選了多個 AWS 項目，包括生成式 AI 加速器計劃，并獲得了生成式 AI 能力合作伙伴認(rèn)證，其 “鷹眼” 產(chǎn)品也已在 AWS Marketplace 上架。

能取得這些成就，部分原因在于紐伯德明白：智能體 AI 并非配置一次就可以拋之腦后的軟件。“你必須把它當(dāng)作一個認(rèn)知實體、一個認(rèn)知系統(tǒng) —— 因為這正是它的核心本質(zhì)，” 拉奧說，“訓(xùn)練它、與它協(xié)作、給它反饋、讓它參與協(xié)同工作。它不是一個非黑即白的二元系統(tǒng)?！?/p>

凌晨 2 點給 SRE 們打來的緊急電話不會消失。基礎(chǔ)設(shè)施總會以各種意想不到的方式在不合時宜的時間發(fā)生故障。但如果紐伯德的愿景能夠?qū)崿F(xiàn)，那么當(dāng)你穿著拖鞋、端著咖啡走到辦公桌前時，“鷹眼” 可能已經(jīng)在順利推進根本原因分析了。