聊《大模型崗位變了運(yùn)維工程師該補(bǔ)的還是算法嗎》之前先說一句實(shí)在的別急著背概念先看它在真實(shí)項(xiàng)目里到底解決什么問題。摘要去年我?guī)F(tuán)隊(duì)做了個(gè)AIOps AgentPrompt調(diào)得挺順日志分析、告警歸因、自動重啟都能跑通。Demo演示時(shí)領(lǐng)導(dǎo)點(diǎn)頭結(jié)果上線第一周就出了兩件事一次是Agent給生產(chǎn)庫刪了不該刪的表另一次是它改了配置后完全沒留下審計(jì)記錄出了問題查不到誰干的。這兩個(gè)事故把我打醒了。之前我花大量精力在優(yōu)化模型輸出質(zhì)量上但真正讓團(tuán)隊(duì)不敢把Agent放出去用的不是它不夠聰明而是它不夠可控。這篇文章不想聊怎么調(diào)Prompt、怎么搭RAG而是聊我踩過坑之后才想明白的事運(yùn)維轉(zhuǎn)大模型真正的學(xué)習(xí)斷點(diǎn)不在模型能力而在權(quán)限邊界和可觀測性。---目錄運(yùn)維能力的遷移腳本思維 vs Agent思維日志分析從查日志到讓Agent幫你查告警歸因Agent的強(qiáng)項(xiàng)也是它的陷阱自動處置Agent權(quán)限是生死線安全與審批不是阻礙是保護(hù)總結(jié)運(yùn)維轉(zhuǎn)型的真實(shí)學(xué)習(xí)路線運(yùn)維能力的遷移腳本思維 vs Agent思維很多運(yùn)維工程師轉(zhuǎn)型時(shí)最容易陷入的誤區(qū)是把Agent當(dāng)成更智能的腳本。腳本是確定性的輸入A執(zhí)行B輸出C。Agent是非確定性的輸入A模型可能執(zhí)行B也可能執(zhí)行C取決于它怎么理解你的意圖。我見過最典型的翻車場景是這樣的# 運(yùn)維時(shí)代的腳本思維 def handle_alert(alert): if alert.severity critical: restart_service(alert.service) notify_oncall(alert.service) elif alert.severity warning: log_issue(alert)這段邏輯清晰、邊界明確。但當(dāng)你把它翻譯成Agent的Prompt時(shí)你是一個(gè)運(yùn)維助手。當(dāng)收到告警時(shí)根據(jù)嚴(yán)重程度執(zhí)行相應(yīng)操作。 嚴(yán)重告警需要重啟服務(wù)并通知值班人員警告告警只需記錄日志。模型可能會自作主張把warning也當(dāng)成critical處理了或者重啟服務(wù)前沒確認(rèn)是否真的需要重啟或者通知了錯(cuò)誤的人。我的判斷標(biāo)準(zhǔn)是如果你寫的邏輯可以被嚴(yán)格if-else表達(dá)那就不需要Agent用腳本就夠了。只有當(dāng)問題需要理解上下文、權(quán)衡利弊、做出判斷時(shí)Agent才有價(jià)值。---日志分析從查日志到讓Agent幫你查運(yùn)維看日志是基本功但讓Agent看日志是另一回事。我早期寫的日志分析Agent輸出結(jié)果看起來很漂亮發(fā)現(xiàn)異常2024-03-15 14:32:01 ERROR: Connection refused to redis-01 建議檢查redis-01節(jié)點(diǎn)狀態(tài)確認(rèn)網(wǎng)絡(luò)連通性 置信度85%但問題是這個(gè)Agent能告訴你發(fā)現(xiàn)了什么卻沒法告訴你為什么它認(rèn)為這是異常。它跳過了原始日志片段跳過了排除其他可能性的推理過程。后來我改了方案強(qiáng)制Agent輸出完整的推理鏈# 改進(jìn)后的日志分析Agent輸出格式 { finding: Redis連接失敗, evidence: [ 2024-03-15 14:32:01 ERROR: Connection refused to redis-01:6379, 2024-03-15 14:32:05 WARN: Failover triggered, promoting redis-02 ], reasoning: [ 連接失敗發(fā)生在14:32距離上次健康檢查已過120秒, 系統(tǒng)自動觸發(fā)了故障轉(zhuǎn)移說明主節(jié)點(diǎn)redis-01確實(shí)不可達(dá), 但redis-02在14:33才成為主節(jié)點(diǎn)這1分鐘的間隙可能導(dǎo)致寫入丟失 ], confidence: 0.85, alternative_hypotheses: [ 可能是網(wǎng)絡(luò)抖動而非redis-01故障但故障轉(zhuǎn)移日志支持主節(jié)點(diǎn)故障假設(shè) ] }這個(gè)輸出格式讓我能回溯Agent的判斷依據(jù)也能讓運(yùn)維團(tuán)隊(duì)質(zhì)疑它的結(jié)論。取舍建議日志分析Agent不需要追求100%準(zhǔn)確但必須保證可追溯。寧可輸出保守的結(jié)論帶置信度也不要輸出確定的結(jié)論沒依據(jù)。---告警歸因Agent的強(qiáng)項(xiàng)也是它的陷阱告警歸因是Agent最有價(jià)值的場景之一。傳統(tǒng)方式依賴運(yùn)維專家的經(jīng)驗(yàn)Agent可以批量分析多個(gè)告警之間的關(guān)聯(lián)。但我踩過的坑是Agent會過度關(guān)聯(lián)。有一次生產(chǎn)環(huán)境同時(shí)出現(xiàn)CPU告警、磁盤IO告警和內(nèi)存告警。Agent分析后認(rèn)為這是同一個(gè)根因——某個(gè)進(jìn)程泄漏導(dǎo)致連鎖反應(yīng)。但實(shí)際上CPU告警是因?yàn)橐淮闻咳蝿?wù)磁盤IO告警是因?yàn)槿罩据嗈D(zhuǎn)內(nèi)存告警是另一個(gè)獨(dú)立的泄漏問題。Agent把三個(gè)獨(dú)立事件強(qiáng)行關(guān)聯(lián)成一個(gè)根因?qū)е逻\(yùn)維團(tuán)隊(duì)把精力浪費(fèi)在了錯(cuò)誤的排查方向上。我的修正方案1. 強(qiáng)制Agent輸出多個(gè)假設(shè)而不是單一結(jié)論2. 每個(gè)假設(shè)必須有獨(dú)立的證據(jù)支持3. 如果證據(jù)不足明確標(biāo)注無法確定而不是強(qiáng)行關(guān)聯(lián)告警分析結(jié)果 假設(shè)1批量任務(wù)導(dǎo)致CPU和磁盤IO升高證據(jù)任務(wù)調(diào)度日志匹配置信度70% 假設(shè)2內(nèi)存泄漏導(dǎo)致OOM證據(jù)dmesg有OOM kill記錄置信度90% 假設(shè)3以上兩個(gè)假設(shè)獨(dú)立發(fā)生證據(jù)時(shí)間戳不完全重合置信度40% 建議優(yōu)先級先排查內(nèi)存泄漏再確認(rèn)批量任務(wù)影響---自動處置Agent權(quán)限是生死線這是我最想強(qiáng)調(diào)的部分。自動處置Agent一旦上線它就有能力改變生產(chǎn)環(huán)境。我見過太多團(tuán)隊(duì)在這個(gè)環(huán)節(jié)翻車原因不是Agent不夠智能而是權(quán)限給得太寬。我的權(quán)限設(shè)計(jì)原則1. 最小權(quán)限Agent只能執(zhí)行它必須執(zhí)行的命令不能隨便ssh到其他機(jī)器2. 審批門檻高危操作刪庫、改配置、重啟服務(wù)必須經(jīng)過人工審批3. 審計(jì)日志所有操作必須記錄包括誰、什么時(shí)候、做了什么、為什么做# 權(quán)限控制示例 class AIOpsAgent: def __init__(self): self.permissions { read_only: [grep, cat, tail, systemctl status], restart_service: [systemctl restart], # 需要審批 modify_config: [], # 禁止直接修改 execute_script: [] # 禁止執(zhí)行任意腳本 } def execute(self, command, context): # 檢查權(quán)限 if not self.has_permission(command, context): raise PermissionDenied(f命令 {command} 不在權(quán)限范圍內(nèi)) # 高危操作需要審批 if self.is_high_risk(command): approval self.request_approval(command, context) if not approval.granted: raise ApprovalDenied(f操作被拒絕: {approval.reason}) # 記錄審計(jì)日志 self.audit_log.log({ user: context.user, command: command, timestamp: datetime.now(), approval_id: approval.id if approval else None }) return self.run_command(command)學(xué)習(xí)建議如果你正在轉(zhuǎn)型先把權(quán)限設(shè)計(jì)和審計(jì)機(jī)制搞明白再研究怎么讓Agent更聰明。權(quán)限問題不解決你的Agent永遠(yuǎn)只能停留在Demo階段。---安全與審批不是阻礙是保護(hù)很多工程師覺得審批流程拖慢了效率但我的觀點(diǎn)相反沒有審批的Agent才是效率的敵人。一次未經(jīng)審批的誤操作可能導(dǎo)致幾小時(shí)的故障恢復(fù)時(shí)間。而審批流程雖然多花幾分鐘但能避免災(zāi)難性的錯(cuò)誤。我的審批機(jī)制設(shè)計(jì)低風(fēng)險(xiǎn)操作自動執(zhí)行事后審計(jì)如查看日志、重啟測試環(huán)境服務(wù)中風(fēng)險(xiǎn)操作自動執(zhí)行實(shí)時(shí)通知如重啟生產(chǎn)環(huán)境非核心服務(wù)高風(fēng)險(xiǎn)操作必須人工審批如刪庫、修改核心配置、重啟數(shù)據(jù)庫審批不是卡Agent而是給Agent一個(gè)安全網(wǎng)。---總結(jié)運(yùn)維轉(zhuǎn)型的真實(shí)學(xué)習(xí)路線回到最初的問題運(yùn)維轉(zhuǎn)大模型該補(bǔ)什么我的答案是1. 先補(bǔ)權(quán)限和審計(jì)這是Agent能上線的前提也是團(tuán)隊(duì)信任的基礎(chǔ)2. 再補(bǔ)可觀測性讓Agent的決策過程可見、可追溯、可質(zhì)疑3. 最后補(bǔ)模型能力Prompt工程、RAG、工具調(diào)用這些有了前兩步的支撐才能發(fā)揮價(jià)值我之前把順序搞反了花了大量時(shí)間優(yōu)化模型輸出質(zhì)量結(jié)果Agent因?yàn)闄?quán)限和審計(jì)問題不敢上線。這個(gè)彎路我走了半年希望你們能少走一點(diǎn)。運(yùn)維工程師做Agent有天然優(yōu)勢我們懂權(quán)限、懂審計(jì)、懂生產(chǎn)環(huán)境的復(fù)雜性。把這些優(yōu)勢發(fā)揮出來比單純學(xué)模型調(diào)優(yōu)更有價(jià)值。資料展示下面是我整理的AI大模型學(xué)習(xí)資料和工具包預(yù)覽適合收藏后按主題逐步學(xué)習(xí)。如果你想看完整資料目錄可以在評論區(qū)留言「資料」也歡迎告訴我你更關(guān)注AI大模型里的哪類內(nèi)容。