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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運維是否還有存在價值？

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

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

Nemo的專業分工論： 術業有專攻，提效而非阻礙。

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

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

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

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

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

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

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

Nick的經驗更具參考性：

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

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

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

爭論看似激烈，但背后反映的是更深層的認知差異。我總結了三個關鍵發現：

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

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

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

但這并不意味著運維工作沒有價值了。恰恰相反，當AI承擔了這些基礎工作后，真正有價值的工作浮現出來了：業務理解、風險判斷、架構設計、創新思維。

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

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

不同規模的公司，最優策略確實不同：

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

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

• ? 大型公司：業務復雜，專業化分工仍然必要

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

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

四個洞察，運維和開發都該看看

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

很多人不知道：AI會寫腳本、調API、執行命令

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

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

對運維的啟發：不要低估AI工具的能力，但也要明確人類的不可替代價值——業務理解、風險判斷、架構設計。

對研發的啟發：學會與AI工具深度協作，不只是讓它寫函數，而是讓它承擔更多系統性工作。

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

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

"一個工具不降低問題的數量，反而引入更多問題，這個工具應該打零分"

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

關鍵問題：這個技術選擇是讓問題變少了，還是變多了？

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

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

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

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

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

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

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

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

別學我瞎搞：測試環境+數據備份才敢這么玩

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

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

備份是最后防線：我這次敢于大膽嘗試，關鍵在于測試環境+完整的異機數據備份。任何運維操作都應該先確保數據安全。

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

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

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

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

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