大版本上線前，所有開發、測試、運維甚至各級技術領導都如臨大敵、打著十二分的精神熬夜加班，在夜深人靜的時候，把新程式碼偷偷的替換到線上。緊張的幾個測試回合下來，就已經發現了數個嚴重的問題。原本靜悄悄的辦公室不再保持安靜，頓時各種聲音四起。“這是誰開發的模組，快過來看看？”“在測試環境沒有問題啊，怎麼又讓運維搞砸了？”“快點快點，看看部署文件裡面的checklist是不是都執行了？”……

一個緊張的夜間大作戰後，天亮了。紅彤彤的太陽照著大地，而參與戰鬥的勇士們卻只能眯著星星鬆鬆的睡眼，用一杯速溶豆漿和幾個包子來補充能量。新版本終於上線了，現在只祈禱那脆弱的系統在上帝的保佑下平穩的度過一天。

這不是小說，這是一個我們常見的軟體或者應用釋出與部署的場景。

在《持續交付：釋出可靠軟體的系統方法》一書中，作者列出了幾種持續交付的反模式，簡單來說有以下幾種：

（1）手工部署軟體。

（2） 開發完成之後才向類生產環境部署。

（3） 生產環境的手工配置管理。

同樣，在這本書中，也給出了實現持續交付的方法，那就是構建一套部署流水線。關於如何實現部署流水線的構建，不是本文的主要內容，在此不做贅述。

不得不說，這本得到第21屆Jolt大獎的著作深深影響了一代人對DevOps的理解。甚至有人說，DevOps就是持續交付。

DevOps不僅僅是持續交付，持續交付僅僅是DevOps整個體系中的一個組成部分。DevOps是以精益（Lean）作為支撐的，由敏捷管理、持續交付和輕量級ITSM（IT Service Management，IT服務管理）為3個支柱的價值流體系。DevOps的本質是以消除浪費為最終目的的精益思想在IT服務交付方面的實踐。

該圖引自《EXINWhitepaper：Success with Enterprise DevOps》

以單件流（One PieceFlow）流式供應鏈方式構建的JIT（Just-In-Time）和自動化是精益理論的2個核心。傳統的以批量方式運作的生產模式，往往造成大量的WIP（在製品，即沒有完成價值交付的半成品）積壓和流轉不暢，因此而帶來大量浪費。而單件流模式，則以Pull（拉）的方式，以需求拉動生產流水線，並盡力減少不必要的步驟從而減少浪費，儘可能讓在製品的數量降低，以達到價值的交付。

想想吧，在我們的IT服務交付鏈中，有多少存在浪費的地方？有多少環節出現了等待？有多少處在在製品狀態的專案、軟體、系統過程？

DevOps的首要目標就是解決這些浪費。

讓開發和運維物理上坐在一個辦公室工作不是DevOps，讓開發參與運維或者運維參與開發也不是DevOps。DevOps是以精益思想為指導，以實現價值交付和杜絕浪費為最終目的，通過構建協作的文化、高效的溝通和系統整合（自動化）來實現的IT服務價值鏈。

原文來自微信公眾號：運維技術實踐；作者：胥峰