把運維干掉不是開玩笑，用AI試了試4小時搞定3天活

作為一名AI架構(gòu)師，我沒想到一次技術(shù)實踐的分享，會在技術(shù)群里引發(fā)如此激烈的爭論。從"把運維干掉"的激進主張，到AI工具能力的認知升級，這場討論讓我看到了一些被忽視的真相。

39個存儲卷4小時遷移完成，我在群里聊天AI在干活

今天下午，我完成了一個讓自己都有些驚訝的任務(wù)。

我們運行在Kubernetes上的測試集群需要進行持久化存儲遷移——從一個NFS存儲遷移到另一個存儲。這涉及39個PV（持久化卷），覆蓋數(shù)據(jù)庫、AI訓練數(shù)據(jù)、監(jiān)控系統(tǒng)等各種應(yīng)用的重要數(shù)據(jù)。

這種遷移任務(wù)級聯(lián)修改比較多，順序也比較復雜。雖然本身技術(shù)復雜度不算太高，但非常耗時間和心力，傳統(tǒng)運維通常需要2-3天才能完成。

這次我決定嘗試使用AI編程的思路，讓Claude Code來處理。需要特別說明的是，這是在測試環(huán)境中進行的一次技術(shù)實驗，并且我們已經(jīng)做了異機全量數(shù)據(jù)備份，即使出現(xiàn)最壞情況也可以完全恢復。

關(guān)鍵的是，我只告訴了它目標，具體方案和執(zhí)行都是它自主完成的。整個4小時過程中，大部分時間Claude Code都在自主執(zhí)行，期間我還在微信群里和朋友聊天，做其他事情，很少需要干預(yù)。

結(jié)果讓我驚喜：4小時全部搞定。Claude Code不僅制定了分層修復策略，還在過程中幫我發(fā)現(xiàn)了NFS存儲服務(wù)器的配置問題，待我解決后，順利完成了全部遷移。

心情不錯的我在技術(shù)群里分享了這個成果：

"我今天讓CC干運維，做nfs存儲遷移，干的挺好"

沒想到這條簡單的消息卻點燃了一場大討論的導火索。

一句話點燃技術(shù)群："把運維干掉就好了"

我的消息剛發(fā)出去，馬工立即拋出了一個驚人觀點：

"把運維干掉就好了，運維是自動化的敵人，不是盟友，更不是客戶"

這句話就像一顆炸彈，瞬間點燃了群里的討論。爭論圍繞三個核心問題展開：

運維是否還有存在價值？

馬工的激進主張： 徹底廢除專門的運維團隊。

"不要有專門的運維組，誰開發(fā)的，誰維護，開發(fā)組自己on call。我五月份入職，八月份就完成了CI/CD，為什么這么快？因為我們沒有運維"

Nemo的專業(yè)分工論： 術(shù)業(yè)有專攻，提效而非阻礙。

"我們運維做了helm模板，核心是把開發(fā)人員的學習成本省下來，僅需要做一次工作就行了"

Player的風險控制觀： 專業(yè)能力不可替代。

"不能說AI能干就壓給一個人頭上干，服務(wù)指標、中間件狀態(tài)管理，這些是運維的事情"

爭論的焦點集中在Kubernetes上。馬工直言不諱：

"kubernetes垃圾，一個工具不降低問題的數(shù)量，反而引入更多問題，這個工具應(yīng)該打零分"

但實際使用者的體驗截然不同。我的觀點是：

"k8s只要懂五六個基本概念也就夠了，至少不用去ui上點點點"

Nick的經(jīng)驗更具參考性：

"我們用了阿里云的托管k8s，不維護k8s本身，我們只用"

這個問題沒有標準答案，需要結(jié)合具體情況。我的觀點比較務(wù)實：

"小公司要省運維團隊的錢，就是all in一朵云" "cc不僅能寫代碼，干運維也是ok的。只要給他標準化接口"

爭論看似激烈，但背后反映的是更深層的認知差異。我總結(jié)了三個關(guān)鍵發(fā)現(xiàn)：

AI接管重復工作，人類專注高價值決策

我的AI遷移實踐證明了一個重要趨勢：AI真正改變的不是某項具體能力的強弱對比，而是工作本質(zhì)的重新定義。

傳統(tǒng)運維工程師需要花費大量時間在信息收集、狀態(tài)分析、命令執(zhí)行這些基礎(chǔ)工作上。這些工作雖然重要，但本質(zhì)上是重復性的模式識別和標準化操作。AI恰恰擅長的就是這類工作。

但這并不意味著運維工作沒有價值了。恰恰相反，當AI承擔了這些基礎(chǔ)工作后，真正有價值的工作浮現(xiàn)出來了：業(yè)務(wù)理解、風險判斷、架構(gòu)設(shè)計、創(chuàng)新思維。

小團隊vs大公司：成功模式背后的適用條件

馬工3個月完成CI/CD建設(shè)的成功，有其特定條件：小團隊、扁平組織、決策鏈條短。而Nemo堅持專業(yè)分工的團隊，往往面對更大規(guī)模、更復雜的業(yè)務(wù)需求。

不同規(guī)模的公司，最優(yōu)策略確實不同：

• ? 小公司：成本敏感，AI + 云服務(wù)組合最具性價比

• ? 中型公司：需要平衡效率和風險，混合模式更合適

• ? 大型公司：業(yè)務(wù)復雜，專業(yè)化分工仍然必要

在我的遷移過程中，最關(guān)鍵的不是AI執(zhí)行了多少操作，而是我做出了哪些關(guān)鍵決策：選擇在測試環(huán)境進行、確保有完整備份、實時監(jiān)控執(zhí)行結(jié)果。這些決策背后是對業(yè)務(wù)需求、技術(shù)風險、時間約束的綜合判斷。

這讓我看到了一個新的協(xié)作模式：AI負責信息處理和方案生成，人負責目標設(shè)定和風險控制。這種分工不是基于能力的強弱，而是基于責任的承擔。

四個洞察，運維和開發(fā)都該看看

通過這場爭論，我提煉出幾個被大多數(shù)人忽視的洞察：

很多人不知道：AI會寫腳本、調(diào)API、執(zhí)行命令

這是很多人的認知盲區(qū)：大家以為AI編程工具只能寫代碼，實際上它可以自主執(zhí)行復雜的任務(wù)——寫腳本、執(zhí)行命令、調(diào)用API、分析結(jié)果。

我的遷移案例證明了這一點：Claude Code從系統(tǒng)分析到方案制定，從腳本執(zhí)行到結(jié)果驗證，完全自主完成了整個運維流程。這遠超大多數(shù)人對"AI寫代碼"的認知。

對運維的啟發(fā)：不要低估AI工具的能力，但也要明確人類的不可替代價值——業(yè)務(wù)理解、風險判斷、架構(gòu)設(shè)計。

對研發(fā)的啟發(fā)：學會與AI工具深度協(xié)作，不只是讓它寫函數(shù)，而是讓它承擔更多系統(tǒng)性工作。

馬工的犀利觀點：讓問題變多的工具都是垃圾

馬工的犀利觀點揭示了一個重要原則：

"一個工具不降低問題的數(shù)量，反而引入更多問題，這個工具應(yīng)該打零分"

這個判斷標準比技術(shù)先進性更實用。K8s很強大，但如果增加了系統(tǒng)復雜度，對小團隊可能就是負擔。Docker Compose很簡單，但如果解決不了滾動升級，對業(yè)務(wù)就是風險。

關(guān)鍵問題：這個技術(shù)選擇是讓問題變少了，還是變多了？

別盲目復制成功案例，先看看適用條件

這次爭論最大的收獲是：每個成功模式都有其隱藏的適用條件。

馬工的"無運維"模式成功，前提是小團隊、扁平組織、技術(shù)棧相對標準化。Nemo的專業(yè)分工模式有效，基礎(chǔ)是業(yè)務(wù)復雜度高、團隊規(guī)模適中、有標準化投入。

啟發(fā)：不要盲目復制成功案例，要分析其背后的適用條件。

真正的成本計算：不只是工資，還有學習和溝通成本

群里基本達成共識：小公司"All in一朵云"最經(jīng)濟。但很多人只看到表面成本，忽略了隱藏成本。

真正的成本不只是人員工資，還包括學習成本、溝通成本、風險成本、機會成本。云服務(wù)貴，但它把復雜度轉(zhuǎn)移給了專業(yè)團隊；AI工具貴，但它大幅提升了個體效能。

思考框架：總擁有成本 vs 單項成本，長期效益 vs 短期開支。

別學我瞎搞：測試環(huán)境+數(shù)據(jù)備份才敢這么玩

最后，必須提醒想要嘗試類似AI輔助運維實驗的讀者：

風險評估不可少：生產(chǎn)環(huán)境的運維操作風險極高，必須充分評估可能的影響范圍和后果。

備份是最后防線：我這次敢于大膽嘗試，關(guān)鍵在于測試環(huán)境+完整的異機數(shù)據(jù)備份。任何運維操作都應(yīng)該先確保數(shù)據(jù)安全。

循序漸進很重要：建議從簡單、低風險的任務(wù)開始嘗試AI輔助，逐步積累經(jīng)驗和信任。

人工監(jiān)督不能省：AI雖然強大，但關(guān)鍵決策點仍需人工確認，特別是涉及數(shù)據(jù)刪除、配置變更的操作。

技術(shù)進步讓我們有了新的可能性，但謹慎和負責任的態(tài)度永遠不能丟。

感謝參與討論的技術(shù)同行們：馬工、Nemo、Player、Better、Nick、傷感星星、WenJie、linhow等，你們的觀點和思考為這篇文章提供了寶貴的素材。

陳明，企業(yè)AI架構(gòu)師，AI編程布道者。專注于AI技術(shù)在企業(yè)中的實際應(yīng)用，相信技術(shù)要為業(yè)務(wù)價值服務(wù)。如果你也在思考類似的問題，歡迎交流討論。