倒數第二次失業：DevOps 十八年演進史
DevOps 大約每五年就會被宣告死亡一次。
2011 年雲端起步時，Forrester 的 NoOps 報告提出雲端自助服務將大幅減少開發者與維運互動；2016 至 2018 年 Serverless 浪潮席捲時，各界高喊維運終結。
2022 至 2023 年平台工程興起時，「DevOps is dead」成了技術社群最吸睛的標題；到了 2025 至 2026 年，生成式 AI 與自主程式設計代理（Coding Agents）登場，第四波訃聞隨之而來。
弔詭的是，每一份訃聞都精準指出了「某些手作任務確實正在消失」，卻每一次都低估了 DevOps 作為工程文化的適應力。
這場走過將近十八個年頭的運動，從未是一條單純的工具升級曲線，而是從確立根基開始，歷經了一次走偏、一次校正，直到如今面臨全面的交付重構。
破局與誕生：從敏捷高牆到 DevOps 元年（2008–2010）
混亂之牆與對立的 KPI
2000 年代初期，敏捷軟體開發打破了傳統瀑布模型，將漫長的發布週期壓縮成較短的迭代循環。然而，敏捷運動很快在生產環境門前撞上了一堵難以逾越的高牆。
這堵牆矗立在軟體開發完成（Dev Done）與軟體穩定運作（Ops Running）之間，史稱「混亂之牆」（The Wall of Confusion）。
兩端的目標被組織結構撕裂：
- 開發團隊（Development）的使命是推動變更：工程師的價值體現在新功能上線的速度，商業市場逼迫團隊以最快頻率交付程式碼。
- 維運團隊（Operations）的使命是維持穩定：維運人員的考核繫於可用性（SLA），而未經充分驗證的變更一直是生產事故的重要風險來源。
為了防禦未知風險，維運端建立起基於 ITIL 的嚴密堡壘：變更審核委員會（CAB）、繁瑣的審核表單，以及令人疲憊的深夜停機維護窗口。
發布越充滿風險，審核就越嚴格，發布週期隨之拉長；間隔越長，單次累積的變更批次（Batch Size）就越龐大，最終必然釀成更具毀滅性的生產災難。
小批次流動與 Velocity 傳奇
比利時獨立顧問 Patrick Debois 將問題指向同一個根源：如果敏捷只停留在開發團隊內部，瓶頸只是被推往下游。
真正的破局點發生在 2009 年 6 月的 O’Reilly Velocity 大會。相片社群網站 Flickr 的兩位工程主管——John Allspaw 與 Paul Hammond，發表了後來廣受引用的演講：
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
在主流企業普遍維持每季或每月發布一次的年代，Allspaw 與 Hammond 證明了高頻變更與系統穩定能夠兼得。
演講確立了打破混亂之牆的核心邏輯：
- 極小化變更批次：發布頻率拉高到每天十次以上，單次變更半徑縮小到寥寥數行，故障查修只需數分鐘，回退風險幾近於零。
- 文化工具箱：以互相尊重、高度信任與「無指責事後檢討」（Blameless Post-mortem）為基石，承認軟體系統必然出錯，追求透明與共同承擔。
Devopsdays 與 DevOps 一詞的誕生
受到 Flickr 演講啟發，Debois 於同年 10 月在比利時根特籌辦了首屆 Devopsdays。可靠的歷史敘述把這場活動視為「DevOps」一詞進入公共技術語境的關鍵節點——開發與維運不再是兩個互相甩鍋的部門，而是同一條交付價值鏈上的共同責任者。一個文化運動有了名字，接下來需要工程紀律為它立下骨架。
部署管線確立工程紀律
2010 年 Jez Humble 與 David Farley 出版劃時代著作《Continuous Delivery》（持續交付），系統性整理了部署管線（Deployment Pipeline）的概念。
該書把部署管線描述為：從程式碼提交到發布的價值流，以自動化方式讓每次變更經過可追蹤的建置、測試與環境驗證。
這條確定性部署管線，為日後十餘年的軟體交付奠定了不可動搖的底層地基。
NOTE
高速發展與走偏：工具爆炸、組織反模式與認知過載（2011–2020）
雲端原生與工具爆炸
在文化運動擴散的同時，底層基礎設施正經歷一場劇烈的典範轉移。
2013 年 Docker 橫空出世，以容器封裝應用與相依套件，實現「一次建置、隨處執行」，開發與執行環境的落差一夕拉平。2014 年 Kubernetes 開始成形，憑藉宣告式 API 與控制迴圈擊敗 Docker Swarm 與 Mesos，成為容器編排的事實標準。
NOTE
運算資源被徹底 API 化後，交付路徑並未如預期般簡化，反而引發了一場失控的工具鏈軍備競賽。
CNCF 生態系收錄專案迅速突破千個，涵蓋日誌、監控、服務網格、安全掃描與密鑰管理等數十個細分領域。工具鏈的高速發展，悄然將工程團隊推向了另一種困境。
組織反模式：「DevOps 部門」築起第三道牆
重構組織文化與信任是緩慢且痛苦的，許多企業管理階層選擇了最容易走捷徑的反模式：成立名為「DevOps 部門」的獨立單位，並招募「DevOps 工程師」。
早在 2013 年，Matthew Skelton 建立的 DevOps Topologies 就把「DevOps Team Silo」列為反模式：成立專責 DevOps 團隊，可能迅速長出另一個穀倉。
這種做法的本質，只是把傳統維運人員換上一塊時髦招牌，在 Dev 與 Ops 之間硬生生插入第三道牆：
- 業務工程師繼續將程式碼往外拋，要求「DevOps 團隊」撰寫 Dockerfile、配置管線並查修 Pod 崩潰。
- DevOps 工程師淪為全天候處理 Jenkins 失敗與 Harbor 權限的新型工具保母。
- 生產環境變更依然卡在跨團隊工單流轉中，DevOps 靈魂被抽乾，只剩下一堆 YAML 腳本。
「You Build It, You Run It」的認知過載反噬
在光譜的另一端，過度推演亞馬遜技術長 Werner Vogels 的名言「You build it, you run it.」，則帶來了另一場災難。
這句格言原意是建立工程師對生產環境的所有權（Ownership），但在微服務與雲原生高速發展期，卻被扭曲為「開發者必須全包全管」：從業務程式碼、前端後端，一路管到 Docker、K8s 排程、Helm Values、Istio 流量路由、Prometheus 指標與 Terraform 模組。
認知心理學的認知負荷理論指出，人類工作記憶的容量極度有限。當外在認知負荷（環境與工具的無效消耗）失控暴增，便會徹底擠壓理解業務邏輯的內在認知負荷與最佳化架構的關聯認知負荷。
後端工程師每天耗費超過半數時間伺候基礎設施中介軟體，軟體工程陷入「履歷導向開發」（RDD）的泥淖，開發者集體疲憊與工作倦怠蔓延全球。
校正期：平台工程與認知邊界的重建（2021–2024）
平台工程不是背叛，而是自我拯救
面對工具失控與認知過載，2022 年 9 月 The New Stack 刊出一篇標題聳動的專文〈DevOps Is Dead. Embrace Platform Engineering〉，引發社群激烈論戰。
這場爭辯澄清了核心事實：平台工程旨在解開全包全管的認知死結，替 DevOps 重建可持續的落腳點。
平台工程將基礎設施、部署管線與觀測能力，封裝為針對內部開發者的「內部開發者平台」（IDP），並成為日後評估平台效能的關鍵依據。其核心理念在於打造「鋪平的道路」（Golden Path）：
- 為 80% 的常見業務情境提供開箱即用、預設安全的自服務範本，免去繁瑣的人工審核。
- 踐行 Dan McKinley 的「Choose Boring Technology」理念：鋪平道路採用經過時間考驗的成熟技術，避免團隊在非核心基礎設施浪費有限的冒險額度。
- 保留選擇性自由，允許特殊架構需求脫離鋪平道路，但需自行承擔相應維運責任。
反之，若平台只提供工具而缺乏清晰的服務邊界與合作文化，最終只會淪為建置成本更昂貴的工單系統。
團隊拓撲學劃定認知邊界
2019 年 Matthew Skelton 與 Manuel Pais 出版《團隊拓撲學》（Team Topologies），為混沌不清的組織設計劃出清晰的工程界限。
書中將認知負荷提升為組織設計的核心約束，以四種團隊類型與明確的互動模式取代「全員懂全端」的幻覺——每個團隊只承擔自身認知邊界內的責任，超出範圍的能力由平台團隊封裝為自服務介面。
DORA 度量與表面加速的陷阱
與此同時，DORA 團隊自 2015 年起透過研究建立了四個交付指標——部署頻率、變更前置時間、變更失敗率與服務恢復時間——證明高效能團隊可以同時改善速度與穩定性。
然而當度量被企業納入績效考核，古德哈特定律（Goodhart’s Law）隨之發作：團隊為了衝高部署頻率而將提交拆成零碎 PR，為了壓低交付時間而跳過端到端測試。數字全面加速，工程體質反而空轉退化——正是這種「指標漂亮但交付痛苦」的落差，為第三波「DevOps 已死，擁抱平台工程」的聲浪提供了最肥沃的溫床。
AI 衝擊：程式碼氾濫、穩定性下滑與新防線（2025–2026+）
程式碼不再稀缺，瓶頸倒灌下游
當業界剛剛理順平台工程與認知邊界，生成式 AI 與 Coding Agent 的爆發引發了軟體工程底層最劇烈的一場地震。
在過去三十年中，軟體交付的瓶頸始終卡在漏斗頂端：人類工程師寫出高品質程式碼的速度太慢。
下游的 CI/CD 管線、自動化測試、容器編排與監控體系，都是為了小心翼翼護送這些得來不易的程式碼安全上線而設計。
到了 2025 年，生成式 AI 將這個運作了三十年的漏斗硬生生倒置：
| 交付面向 | 傳統軟體交付模式（過去三十年） | AI 時代交付模式（2025–2026+） |
|---|---|---|
| 核心瓶頸 | 程式碼編寫緩慢（人類工程師逐行敲打） | 驗證與防線塞車（巨量 PR 倒灌審查門禁） |
| 邊際成本 | 程式碼產出昂貴且耗時 | 程式碼產生邊際成本趨近於零 |
| 管線定位 | 護送得來不易的程式碼安全上線 | 構築防禦護欄阻擋低質與幻覺程式碼 |
| 稀缺能力 | 業務程式碼與功能實作速度 | 自動化驗證、可觀測性與架構門禁 |
面對每天數十個結構看似完美、實則暗藏邊界條件漏洞的 AI PR，人類審查程式碼已不堪重負。如果自動化測試斷言脆弱或覆蓋率不足，AI 生成的幻覺程式碼將以光速摧毀生產環境。
DevOps 非但沒有死亡，反倒躍升為 AI 時代決定系統生死存亡的最底層咽喉。
NOTE
DORA 數據：AI 是組織體質的放大器
Google Cloud 發布的 DORA 2024 年度報告指出，超過 75% 受訪者表示在每日工作中至少一項職責依賴 AI；在該研究的估計中，AI 採用每增加 25%，交付穩定性下降 7.2%，交付吞吐量亦下滑 1.5%。
到了DORA 2025 年報告，90% 受訪者表示在工作中使用 AI；研究觀察到 AI 與軟體交付吞吐量轉為正相關，但與系統穩定性依然維持負相關。
DORA 報告由此給出核心結論：AI 的首要角色是放大器——放大組織既有的優勢與弱點。
如果組織本身具備健全的自動化測試、嚴謹的架構約束與成熟的 CI/CD 門禁，AI 能帶來驚人的生產力飛躍；反之，若缺乏工程紀律，AI 只會以無與倫比的速度將低質程式碼傾倒進生產系統，迅速形成龐大的「穩定性赤字」。
Agentic DevOps 的防守前瞻與確定性防線
在維運現場，基於推理模型與代理工作流的 Agentic DevOps 開始被設計成關鍵防護護欄——從事故根因診斷、語義層級的架構門禁到軟體供應鏈驗證，AI Agent 正被嵌入交付管線的各個檢查點。
然而，大語言模型的機率本質（Non-deterministic）與生產基礎設施的嚴格確定性（Deterministic）存在根本衝突。
NOTE
在真實工程中，自動化 Agent 的權限必須受到沙盒物理隔離。所有的基礎設施演進依然必須沉澱為版本化的程式碼（GitOps），絕不允許黑箱線上熱修補。
NOTE
人類工程師的角色從敲鍵盤手寫配置的工匠，正式升級為最高法官與防禦架構師——評估商業價值的真實性、排除潛在的架構漏洞，並為每次生產發布負起最終責任。
NOTE
結語：程式碼如牲畜，紀律是唯一的煞車
回顧十八年來四波訃聞，每一次都犯了同樣的錯誤：將特定手作任務的消失，誤認為整個工程運動的死亡。從 NoOps、Serverless 到平台工程，消滅的從來只是手動配機器、手寫設定檔等例行勞動；部署、監控、架構與安全責任非但沒有減少，反倒上升為更高階的工程判斷。
當程式碼生成成本趨近於零，程式碼本身成了隨壞隨換的「牲畜」。真正稀缺的，是承載團隊共識的自服務平台，以及那道在巨量程式碼面前絕不妥協的自動化驗證防線。
每一波訃聞都自信宣告「這是最後一次」，而回頭看總還有下一次——這正是標題裡「倒數第二次」的由來。因為只要軟體仍需在真實環境中運行，就會有新的手作任務被自動化消滅，也就會有人再次宣告 DevOps 已死。
DevOps 的名字或許會隨時代演變，但那份讓開發與維運共同對軟體真實運作負責的文化靈魂，始終是高速運轉世界中唯一不可或缺的煞車系統。