DevOps實施手冊 在多級IT企業中使用DevOps

DevOps 實施手冊
在多級 IT 企業中使用 DevOps
[美] Sanjeev Sharma 著
萬 金 譯
北 京
Sanjeev Sharma
The DevOps Adoption Playbook ： A Guide to Adopting DevOps in a Multi-Speed IT
Enterprise
EISBN ： 978-1-119-30874-4
Copyright © 2017 by John Wiley & Sons, Inc., Indianapolis, Indiana
All Rights Reserved. This translation published under license.
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley &
Sons, Inc. and/or its affi liates, in the United States and other countries, and may not be used without
written permission. IBM, the IBM Press logo, UrbanCode, uDeploy, System z, Rational, IBM
Watson, WebSphere, Bluemix, InfoSphere, Optim, PureApplication, DB2, SoftLayer, and Blue Box
are trademarks or registered trademarks of International Business Machines Corporation in the
United States and/or other countries. A current list of IBM trademarks is available on the web at
“copyright and trademark information” as All other
trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated
with any product or vendor mentioned in this book.
本書中文簡體字版由 Wiley Publishing, Inc. 授權清華大學出版社出版。未經出版者書面許可，
不得以任何方式複製或抄襲本書內容。
北京市版權局著作權合同登記號 圖字： 01-2017-4033
Copies of this book sold without a Wiley sticker on the cover are unauthorized and illegal.
本書封面貼有 Wiley 公司防偽標籤，無標籤者不得銷售。
版權所有，侵權必究。侵權舉報電話： 010-62782989 13701121933
圖書在版編目 (CIP) 資料
DevOps 實施手冊 在多級 IT 企業中使用 DevOps / (美) 桑吉夫·夏爾馬(Sanjeev
Sharma) 著；萬金 譯. —北京：清華大學出版社， 2018
書名原文： The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT
Enterprise
ISBN 978-7-302-49826-1
Ⅰ. ①D… Ⅱ. ①桑… ②萬… Ⅲ. ①軟體工程 Ⅳ. ①TP311.5
中國版本圖書館 CIP 資料核字(2018)第 037603 號
責任編輯：王 軍 於 平
封面設計：牛豔敏
版式設計：思創景點
責任校對：孔祥峰
責任印製：沈 露
出版發行： 清華大學出版社
網 址： ，
地 址： 北京清華大學學研大廈 A 座 郵 編： 100084
社 總 機： 010-62770175 郵 購： 010-62786544
投稿與讀者服務： 010-62776969， c-service@tup.tsinghua.edu.cn
質 量 反 饋： 010-62772015， zhiliang@tup.tsinghua.edu.cn
印 裝 者：三河市金元印裝有限公司
經 銷：全國新華書店
開 本： 148mm×210mm 印 張： 11.625 字 數： 311 千字
版 次： 2018 年 4 月第 1 版 印 次： 2018 年 4 月第 1 次印刷
印 數： 1～3000
定 價： 79.80 元
————————————————————————————————————————————————
產品編號： 075958-01
致我的夫人 Ritika，她總是激勵我做得多一點、
再多一點，從不滿足於現狀。還有我的孩子們，
Saransh 和 Shreya，他們是我不懈努力、持續前行
的動力。

譯者序
一次成功不是終點，一次失敗也並非末日，變幻的是人生的風
景，不變的是勇往直前的心。
DevOps 的理念誕生於 2009 年，在同年的敏捷大會上(Velocity 2009-
O’Reilly Conferences)， John Allspaw 和 Paul Hammond 發表了震驚業界
的演講，內容是關於如何在 Flickr 實現每天釋出 10 次更新，而當時的
平均釋出週期都是以月或年為計算單位的(釋出效率提升了百倍以上)。
可想而知， DevOps 的橫空出世對於生產環境中的釋出效率產生了怎樣
的革命性影響，用“行業地震”來描述也一點都不為過。
DevOps 的主旨是在開發與運維之間建立信任與責任共擔機制，既
要滿足開發的快速創新需求，又要保證運維的穩定性——這就需要建立
反脆弱系統。與傳統 IT 建立高可靠性系統(Mean Time To Failure，故障
前平均時間)的目標不同， DevOps 強調的是反脆弱性(Mean Time To
Recovery，平均修復時間)。顧名思義，反脆弱系統不但不會因為壓力而
崩潰，反而會隨著壓力增加而變得更加強大。透過尋找可替代系統的方
式實現反脆弱性，可以同時滿足業務快速變化與運維穩定性的需求。
驀然回首， DevOps 已經走過 8 年的發展歷程。隨著 DevOps 理念
的推廣，各種工具不斷湧現，但是對於傳統大型企業而言，每天釋出新
特性，還是難以企及的目標。只有在初創企業或網際網路企業中，才更有
可能實現從開發到運維的快速交付。 DevOps 無法在多數的大型傳統行
業實施嗎？答案當然是否定的。
我曾經在 IBM 和華為從事 DevOps 實施方面的工作， 常常需要解決
的問題就是使用什麼樣的工具才能既滿足流程規範的要求，又能提升團
隊的效率並且保證交付的質量。而幾年之後，當我作為 ThoughtWorks
的顧問思考如何縮短週期時間、縮小批次規模以及建立文化理念時，我
IV DevOps 實施手冊 在多級 IT 企業中使用 DevOps
才深刻地認識到工具與工具(根據康威定律，軟體架構體現了組織的架
構)之間竟然存在著如此巨大的效率鴻溝。就如本書的第 1 章開篇案例
所講述的故事，一個只需要執行 20 分鐘的迴歸測試任務，在實際的執
行過程中，由於部門間協作低效、環境差異、安全審計、測試資料準備
等原因，實際過程長達一週之久。一個驚人但是常常為人所忽略的事實
是，在現有框架基礎上對當前工作效率提升 20%，這一過程中的投入竟
然遠遠高於建立全新體系，尋求效率提升 10 倍的方法。你沒有看錯，
效率提升 10 倍的方法反而成本更低。一個著名的例子就是， Space X 致
力於打造出比目前火箭發射成本至少低 10 倍的產品，而其所需的資源
一定會少於美國國家航空航天局(NASA)在原有技術上的“小修小補”。
是時候開始 DevOps 變革了。
本書作者桑吉夫·夏爾馬(Sanjeev Sharma)是國際知名的 DevOps 與
雲端計算領域的思想領袖，基於豐富的行業經驗，他在本書中透過海量案
例和大量訪談，為正在實施 DevOps 的團隊提供建議與指導，其中還包
括相應的反模式案例。作為 DevOps 領域中有著多年經驗的從業者，我
在翻譯這本書的過程中一直遏制不住相見恨晚的感嘆以及一拍即合的
興奮。
我與本書的緣分始於第一屆中國 DevOpsDay 峰會，會議期間，我
偶然地獲得了翻譯本書的機會。讓我興奮的是，本書介紹的 IBM 雲計
算與 ThoughtWorks 敏捷方法論同我自己的工作與研究經歷高度吻合，
在翻閱的過程中，我竟然產生了一種既真實又虛幻的使命感：這就是為
我而寫的書。在接受翻譯任務後，我需要在工作之餘每天投入幾小時的
整塊時間，每當翻譯到令人歎為觀止的理念或者困擾我良久的問題時，
我就會完全沉浸在狂喜之中，以至忘記了時間；而每當結束一個主題章
節的翻譯時，我都深深地被兩家偉大的公司在方法論以及軟體工程領域
進行的探索所震撼，併為能夠成為其中一員而感到無比自豪。無數的清
晨和安靜的長夜，我沉浸在這些偉大的思想世界中，忘記了自我，也少
了許多陪伴家人的時間，在此非常感謝家人對我的支援。
在知識快速更新，社會變得十分浮躁的時代，寫一本書甚至只是翻
譯一本書或許都是非常奢侈的事情。 2017 年，不斷湧現出的容器、微服
務漸成熱點，雲原生和 Kubernetes 也出現在我們的視野中，難能可貴的
是，這些新理念和工具在本書的末尾都有所涉獵，作者桑吉夫也在其個
人網站上不斷更新本書的英文內容。為了方便中國讀者進行反饋和交
流，我會建立一個微信群(透過新增我的微訊號 aaron-i，我會把讀者新增
到微信群中)，以方便熱愛求知的朋友們在快節奏的生活中與同樣愛好
本書的人進行互動，微信群中已經新增了我認識的很多這個領域的大咖
級人物。
最後，致敬本書的作者桑吉夫，再次感謝我的家人，感謝清華大學
出版社以及所有為本書出版辛苦付出的人們。希望這本書對你們有所裨
益，衷心感謝大家！
萬 金
作者簡介
桑吉夫·夏爾馬是國際知名的 DevOps 與雲端計算領域的變革思想領
袖、技術高管以及作家。桑吉夫具有豐富的行業經驗，曾擔任首席技
術官(CTO)、全球技術銷售負責人、採購整合技術負責人以及 IT 架構
師。作為 IBM 的傑出工程師，桑吉夫被公認為 IBM 最高階別的核心技
術領袖。
桑吉夫主導並推動 DevOps 與雲端計算前沿解決方案、架構以及策略
的實施。 IBM DevOps 技術銷售部全球技術長的經驗，加上對業務
及 IT 需求的深刻洞察與理解力，使其對任何業務都能產生獨特的見解，
從而能夠從獨特的視角為高層管理者及高階技術管理人員提供建議與
指導，以實現跨行業、跨地域的 DevOps 及雲端計算變革。
作為雲端計算及 DevOps 專家， 桑吉夫經常在國際科技論壇上發表演講，
還經常在領先的科技刊物以及自己的部落格()與推特
(@sd_architect)上發表文章、博文以及影片。
技術審稿人簡介
李·裡德在製造與資訊科技領域擁有 30 多年的軟體工程、架構、
產品研發、技術創新以及團隊管理經驗。李·裡德是通用汽車學院
(General Motors Institute， BME)及密歇根大學(University of Michigan，
MSE)畢業的工程碩士研究生，持有四項美國專利。最近他轉行到高等
教育領域，正帶領 IT 部門將精益與 DevOps 實踐引入聖諾伯特學院(St.
Norbert College)。
致 謝
本書旨在記錄下我與客戶、同事以及 DevOps 同行關於 DevOps 以
及 IT 最佳化與創新問題所進行的無數對話、 討論(有時是激烈的)以及爭論
的內容。透過這些對話與討論，很多人為這本書做出了貢獻，我學習
用到的部落格、文章、書籍、網路研討會、影片、會議以及演講就更不
用說了。
我的同事，IBM 的 DevOps 專家及技術思想領袖們是主要的貢獻者，
他們是(按姓氏的字母順序)：
■ Al Wagner ■ David Ziskind
■ Albert Ho ■ Dibbe Edwards
■ Alex Abi Khaled ■ Eric Minick
■ Ana Lopez-Mancisidor ■ Erik Anderson
■ Andy Moynahan ■ Greg Wunderle
■ Ann Marie Somerville ■ Hayden Lindsey
■ Anshu Kak ■ Helen Dai
■ Anujay Bidla ■ Jagan Karuturi
■ Ava Hakim ■ James Pierce
■ Bala Rajaraman ■ Jeff Crume
■ Bernie Coyne ■ Jim Fieseler
■ Bill Higgins ■ Jim Moffi tt
■ Bob Bogan ■ John Lanuti
■ Brian Naylor ■ John Wiegand
■ Chris Lazzaro ■ Kay Johnson
■ Chris Lucca ■ Kedar Walimbe
■ C. J. Paul ■ Kristof Kloeckner
■ Claudette Hickey ■ Kyle Brown
■ Cliff Utstein ■ Leigh Williamson
■ Dan Berg ■ Mahendra Pingale
■ David Curbishley ■ Maneesh Goyal
■ David Leigh ■ Mark Borowski
■ Mark Meinschein ■ Robbie Minshall
■ Mark Roberts ■ Roger Snook
■ Mark Tomlinson ■ Rosalind Radcliff
■ Meenagi Venkat ■ Sal Vella
■ Michael Elder ■ Saleem Padani
■ Michael Samano ■ Steve Abrams
■ Mike McNamee ■ Steve Kagan
■ Mustafa Kapadia ■ Steven Boone
■ Paul Bahrs ■ Sudhakar Frederi
■ Paul Meharg ■ Swati Moran
■ Peter Eeles ■ Tony Doyle
■ Peter Spung ■ Tim Hahn
■ Randy Newell ■ Tim Pouyer
■ René Bostic ■ Varban Vassilev
■ Rick Weaver ■ Wendy Toh
■ Rob Cuddy
有些貢獻者是以前在 IBM 工作過的，他們是：
■ Alan Sanie ■ Jan Svoboda
■ Ashok Reddy ■ Mike Lundblad
■ Bowman Hall ■ Murray Cantor
■ David Grimm ■ Steven Pogue
■ David Myers ■ Walker Royce
作為在自己公司及組織中引領 DevOps 變革的真正領導者，一些
關鍵客戶、業務合作伙伴與專家也為本書做出了貢獻。他們的實戰案
例是汲取經驗的最好來源。很多情況下，本書中所記錄的經驗教訓與
實踐就來自他們所參與的對話。作為 IBM 的員工，我會見了這些人中
的大多數，這裡無法一一列舉。僅在此列出與我共同出席會議、聚會以
及網路研討會，並聯合撰寫文章或部落格的幾位，他們以及他們目前的僱
主是：
■ Alan Shimel, DevOps.com
■ Antony Morris, Monitise
■ Ben Chodroff, CloudOne
■ Brad Schick, Skytap
■ Carmen DeArdo, Nationwide Insurance
■ Chris Lepre, Wells Fargo
■ Gareth Evans, Monitise
■ James Governor, RedMonk
■ Jayne Groll, DevOps Institute
■ John Comas, NBCUniversal Media
■ John Kosco, Blue Agility
■ J. P. Morgenthal, CSC
■ Mark Howell, Lloyds Banking Group
■ Tapabrata “Topo” Pal, Capital One
我必須要向 DevOps 大師基恩·金(Gene Kim)表達我的特別謝意，
透過其著作以及 DevOps 企業高峰會議，他為本書做出了巨大貢獻。我
曾有機會親自與他進行一對一的交談，其中包括 2014 年錄製的影片訪談。
我還要向李·裡德表示特別感謝。我和他共事十多年的時間，他也
是我的“共謀犯”，曾經在 IBM 領導全球 DevOps 架構團隊兩年。我們
共同開發了 DevOps 價值流圖工作坊技術，我的很多想法也都是來源於
他。儘管他已經離開 IBM 到聖諾伯特學院工作，我還是請他擔任本書
的技術編輯，因為只有這樣我才有機會分享他的思想才智。沒有 Lee 的
洞察、批評與反饋，這本書就無法呈現最終精煉、清晰的結構形式。
最後，我要感謝 Wiley 出版社的傑出編輯人員， Adaobi Obi Tulton，
他的技能絕對不會辜負“絕地武士”的這個稱號， 還有 Marylouise Wiack,
感謝她對語言及表達方式的全面把握(是的，標點符號是我的剋星)。因
為他們的辛勤工作以及細緻的校正，將我的隻言片語組合成通順的句
子，這本書得以比計劃提前許久面世。
前 言
DevOps 實施手冊中涵蓋的內容
2016 年 4 月，在 2016 屆 NCAA 全國大學生籃球錦標賽上，維拉諾
瓦大學野貓隊對戰北卡羅來納大學焦油踵隊。這是有史以來最偉大的一
場賽事，一切都要歸功於距離比賽結束只剩 4.7 秒時的最後一次進球。
Joel Berry II 以一記三分球將比分追成 74 平，維拉諾瓦大學隊的教練 Jay
Wright 叫了最後一次暫停。在 NCAA ，暫停後必須要走完全場。隨即，
維拉諾瓦大學隊的 Kris Jenkins 將球傳給控球后衛 Ryan Arcidiacono 。
Arcidiacono 越過 Berry 沿著球場運球，雙方為了最終的勝利都設計了相
應的戰術。北卡羅來納對 Arcidiacono 採取 1-3-1 人盯人的壓制戰術，希
望迫使其失誤。但是，即便 Arcidiacono 成功越過 Berry ，他們還有 Justin
Jackson 、 Isaiah Hicks 以及 Brice Johnson, 所有這些人都能阻止三分球命
中。維拉諾瓦也已經設計了相應的戰術，確保 Arcidiacono 能夠把球帶到
場內，可以越過半場並找到三分線上球員的位置。 Arcidiacono 瓦解了北
卡羅納戰術，越過 Berry 並迅速將球回傳給三分線上的 Jenkins ，最終以
一記毫無爭議的三分球贏得冠軍，成功絕殺。
—— Saransh Sharma(Sharma, 2016)
一本規模化實施 DevOps 的指導手冊
優秀的團隊之所以優秀，不僅僅是因為他們擁有最好的成員、最好
的工具、最好的培訓、最好的流程或者最好的領導及教練。還因為作為
一個團隊，他們擁有上述一切的同時，也知道面對各種情況與挑戰時應
該做些什麼。他們都有一本指導手冊，裡面包含各種情形下可能會用到
的解決方案。
當面對獨特的形勢或挑戰時，作為一個團隊，球員和教練共同從指
導手冊中挑選適當的方案並執行，這點尤為重要。我的母校，維拉諾瓦
大學在比賽結束前僅僅幾秒鐘利用最終的戰術贏得了全美冠軍，因為這
些戰術他們是練習過的。他們分析形勢、選擇適當的戰術、精準執行並
最終獲勝。如果他們沒有采用讓北卡羅來納隊措手不及的戰術，結局可
能會全然不同。
同樣， IT 組織也需要有可執行的方案。對於日復一日的應用交付與
運維，可以在開發、交付以及運維流程中獲得這些所謂的方案。成功的
IT 組織都擁有良好的流程並以卓越的方式執行這些流程。然而， IT 組
織的變革是另外一回事。沒有能夠克服文化及組織惰性的明確定義的成
功方案，大多陣列織都要與變革作鬥爭。針對大型企業內的 DevOps 實
施以及大型、複雜、分散式 IT 組織的 DevOps 變革，本書提供了一套行
之有效的、可重複使用的方案。
我曾幫助幾十家規模及成熟度各不相同、來自不同行業和地域的組
織實施 DevOps，本書中的這些方案均來自於我多年的實戰經驗。當我
在 IBM 擔任 DevOps 技術銷售與實施全球技術長的時候， DevOps
還處在初期發展階段，從那時起，我就前瞻性地看到了 DevOps 必將快
速發展並日益成熟，會從初創企業的先驅實踐發展為大型企業的文化及
技術變革。我是 IBM 的 DevOps 先驅及思想領袖，而且面對 IBM 的客
戶時，我已成為 DevOps 的代言人。我研究了數百家客戶在整個組織或
企業範圍內成功實施 DevOps 所做的工作與鬥爭，並提煉出成功的模式，
納入本書內容中。
在沒有很多文化記憶的小型集中式組織中，實施 DevOps 並不困難。
即使在大型組織中，小型團隊，即眾所周知的兩個比薩團隊 ① ，也通常
能成功取得 DevOps 所承諾的業務成果。在大多陣列織中，都能見到這
樣的付出與努力，而且多數都取得了成功。提取個人與獨立團隊層面的
成功經驗，並將其推廣至整個企業，這是一項挑戰。就像組織中有一系
列的小舞團。然而，這些舞團都是獨一無二的。有的跳薩爾薩，有的跳
① 亞馬遜執行長傑夫·貝佐斯聲稱，一個不能用兩份比薩餵飽的團隊就太
大了，以致無法成為富有成效的團隊。
爵士舞，有的跳交際舞，還有其他一些人在跳我女兒稱為“嘻哈”的舞
蹈。他們無法組合起來，併成長為一個可以在下半場演出，佔滿整個體
育場表演場地的龐大舞團， 因為要做到這點， 他們不僅需要相同的舞曲，
還要統一舞蹈的表演形式。同樣，小型獨立團隊無法影響整個組織。這
些團隊需要努力實現相關實踐、流程、平臺與工具的標準化以便複製給
組織的其他團隊。
反過來，組織需要為 DevOps 實施建立適當的環境，這可以透過支援
變革努力、改變僵化的遺留程式以及自上而下共同克服文化惰性來實現。
注意： 自下而上員工導向的努力使得非常高效的獨立團隊能夠實施
DevOps 並茁壯成長；自上而下高層管理者導向的努力使這些個體的成
功能夠推廣開來。
要推廣成功，業務的參與是必不可少的。 IT 組織的存在就是為了交
付業務向其客戶交付商業價值所需要的能力。業務要求 IT 組織進行優
化，要更加敏捷，適應變化，更具有響應力，利用更少的資源做更多的
事情，更加高效，提高產能，更快速、更高質的交付，針對市場靈活應變，
加速競爭，遵守不斷變化的監管與合規制度以及，當然也要縮減開支。
此外，還可能要求創新，以允許公司進入新的市場，實現指數增長，
吸引並發展客戶群體，響應客戶需求以及縮減開支。這些要求(希望這
些要求不是同時存在)是變革需求產生的驅動力， 是實現 DevOps 實施效
益的工作動機。
注意： 實施 DevOps 不能僅僅因為它很炫酷，而是要基於業務上的原
因。敏捷或速度的訴求是 DevOps 存在的第一性原理。在過去幾年裡， DevOps
的實施日趨成熟與廣泛，這反映出當今的市場動態和客戶期望。
因此，為了使 IT 經歷變革，這個變化必須要能夠改進並增強其能
力，以交付業務能力並進一步改進及提升所交付的業務價值。業務與 IT
之間必須保持適度合作， 以便 IT 實施 DevOps 所經歷的變革能夠透過適
當平衡最佳化與創新來滿足業務最為迫切的需求。業務目標必須是驅動 IT
變革的原因，變革原因又會反過來驅動 IT 變革的方式。
本書將 DevOps 實施方案分為以下幾類：
● 最佳化 DevOps
● 創新 DevOps
● DevOps 實施的企業級推廣
● 驅動企業的 DevOps 實施
其中包括了每一項實施方案的經驗教訓、案例、成功模式以及反模
式。就像體育運動隊的戰術手冊一樣，本書旨在提供適用於不同情境及
形勢的特定方案(具體取決於組織當前的成熟度及狀態)，供組織透過實
施 DevOps 向更高績效的交付組織轉型時使用。組織需要採用這些方案，
並基於 DevOps 實施專案與團隊的實際情況策略性地執行。正如與敵人
交戰必須要有作戰計劃一樣，實施這些方案必須要有相應的行動計劃或
者使用更為廣泛的為每個組織設計的實施路線圖。
此外，任何組織在本質上都不是統一或同質的。組織中的某個部分
或許在某些領域更加成熟， 而在其他領域則不夠成熟。同在一個組織內，
有時甚至是同在一幢建築物內，一些團隊或群體或許已經實現了敏捷與
速度，而其他團隊則可能正經受嚴重的文化惰性；他們都需要相互合作
以實現規模效應。
組織可能已經擁有應用現代化敏捷與 DevOps 實踐的創新實驗室，
但核心系統團隊可能仍在進行僵化的瀑布式交付。因此，針對同一組織
中的不同部分，要應用不同的實施模式，而且要根據不同團隊的需要進
行定製化調整。為了幫助組織實施這種定製化調整，本書還應用了價值
流圖技術。作為精益實踐的組成部分，價值流圖已應用了幾十年，現在
也可以用來從這些方案中開發實施路線圖，這些實施路線圖是根據組織
的業務目標、當前成熟度以及能力狀況而定製的。
顛覆還是被顛覆，這是值得思考的問題
我們生活在一個鉅變的時代。 1960 年，財富 500 強企業的平均預期
壽命是 75 年。而如今，企業平均壽命只有 15 年，而且在未來還會進一
步下降。為什麼會這樣呢？只需要看看所謂的“優步(Uber)效應”就能
理解為什麼這麼多的公司都倒閉了。優步的創始人並非計程車行業出
身，他利用移動應用上的觸控按鍵，帶領公司顛覆了一個歷史悠久的產
業。他們使計程車服務成為按需服務經濟的一部分，消費者的需求可以
隨時得到滿足，沒有任何延遲。諸如敏捷、 DevOps 這樣的新方法以及
雲端計算、微服務這樣的新技術，加速催生了新的 IT 能力，這些能力使
初創企業也可以擁有云端及移動應用的服務，與進行大量 IT 投資、擁
有價值不菲的基礎設施、員工經驗豐富的 Uber 大型組織沒有差別。
注意： 世界上發展最快的運輸公司自己卻沒有一輛車 (Uber/ 優步 ) ；
發展最快的酒店管理公司提供房屋出租，卻沒有任何產權屬於自己
(Airbnb/ 愛彼迎 ) ；世界上發展最快的傳媒企業不製作任何的媒體內容
(Facebook) ；世界上最大的百科全書沒有全職作者 (Wikipedia/ 維基百科 ) 。
顛覆已成事實。
所以，捫心自問，你的組織是顛覆者還是被顛覆者？事實是，多陣列
織都屬於後者，這給今天的 IT 組織帶來了前所未有的壓力。無論是擔
心被競爭對手淘汰，還是基於加快步伐的業務需求， IT 組織都必須同時
兼顧最佳化與創新，既要確保核心應用的最佳化執行，又不可以放棄創新。然
而，事實上，創新與保持遺留系統的效率並不衝突。儘管與優步(Uber)、
愛彼迎(Airbnb)這樣誕生於網際網路的公司競爭，似乎前景可畏，但在整個
組織範圍內實施 DevOps，能夠讓你的 IT 團隊變得更加敏捷、高效及創
新。實施 DevOps，能夠使 IT 成為組織變革的推動者，從而抵禦顛覆及
干擾；反過來，這也會促進組織成為顛覆者。在當今技術驅動的世界裡，
IT 能力已經成為顛覆者與被顛覆者之間的關鍵差異。
定義 DevOps
在深入研究組織內實施 DevOps 時需要採用的核心能力與實踐以及
需要執行的各種方案前，必須首先理解 DevOps 的定義。
和行業內應用的任何一項新技術或技術相關運動一樣， DevOps 已
經成為一個過度流行的術語。每個人都在談論它，卻不是每個人都清楚
它究竟是什麼，最糟糕的是，許多聲稱正在實施 DevOps 的人，實際上
工作產出一塌糊塗。也有一些優秀的案例，這些公司表現出色並處在
DevOps 運動的前沿，經常被當作示例的有 Etsy、 Flickr、 Facebook 以及
Netflix。但即便如此，關於什麼才是真正的 DevOps 最佳實踐，還是存
在著爭論和爭議。 Netflix 聲稱他們的做法是無運維(NoOps)，讓開發人員
來承擔運維的責任。但是也有人反駁說這樣的情況會導致混亂與無序。
隨著 DevOps 的發展，行業在完善 DevOps 定義的過程中，存在這
樣的爭論是意料之中的。正如我在本書中將利用大量篇幅來討論的，實
施 DevOps 有各種不同的方法，每個組織應該基於各自的風險值與業務
驅動的平衡去選擇適當的實施能力與 DevOps 實踐。事實上， DevOps
實施需要先從試點專案開始啟動，然後利用本書中介紹的技術在整個企
業範圍內推廣。
如前所述， DevOps 的定義有很多，或者至少是關於“DevOps 究竟
是什麼”的觀點有很多，因為有很多的部落格和技術“專家”在談論這件
事情。關於 DevOps 的觀點中，有的認為開發為王；有的認為持續交付
是驅動力；有的認為一切都取決於雲，沒有云計算，就沒有真正的
DevOps；有的認為 DevOps 就等同於微服務。所以，我們先來看一下(相
對)中立的來源——維基百科上關於 DevOps 的定義(維基百科， 2016)：
DevOps( 開發 Development 與運維 Operations 的組合詞 ) 是一種文化、
一場運動或實踐，強調在自動化軟體交付流程及基礎設施變更過程中，
軟體開發人員與其他資訊科技 (IT) 專業人員彼此之間的協作與溝通。它
旨在建立一種文化與環境，使構建、測試、軟體釋出得以快速、頻繁以
及更加穩定地進行。
有一點要特別注意的是，隨著 DevOps 日益成熟，維基百科上的
DevOps 定義也在不斷修正。可以比較一下，這是 2013 年維基百科上的
定義：
DevOps ( 開發 Development 與運維 Operations 的複合詞 ) 是一種軟體
開發方法， 強調的是軟體開發人員與資訊科技 (IT) 專業人員之間的協作、
溝通與整合。 DevOps 是軟體開發與 IT 運維之間相互依賴的一種反應。
它旨在幫助組織快速產出軟體產品及服務。
維基百科定義的這種演變也代表了 DevOps 本身以及行業看待
DevOps 觀點的變化。除了替換掉深奧的詞彙 portmanteau ，這個詞每個
人都要到 Dictionary.com 上去查詢才能理解，還需要注意的要點有：
● 將“軟體開發方法”替換為“文化、運動或實踐”
● 增加了“自動化”一詞
● 將最終目標由“快速產出軟體產品及服務”替換為“建立一種
文化與環境，使構建、測試、軟體釋出得以快速、頻繁以及更
加穩定地進行”。由此， DevOps 變革的目標從僅僅是速度變為
速度、穩定性以及質量。
當然，史上最為簡明的 DevOps 定義絕對不能不提，這是在 2013
年 O’Reilly Velocity 會議的 T 恤衫上看到的：
DevOps—— 將命令列 (SH) 從 IT 工作中趕走
本書讀者物件
體育運動隊中不是隻有比賽當天上場的運動員們，還包括教練、助
理教練、團隊管理者、團隊高層、培訓師、醫生、營養師、物理治療師、
器械經理再到運球人員及供水服務員的所有這些人。團隊要想發揮出最
佳水平，所有這些人都是必不可少的，而且每個人都需要在各自的角色
中出色發揮，並作為一個團隊有效合作。同樣， DevOps 也不僅僅關乎開
發與運維人員，它要求應用交付流水線中的所有利益相關者都要改變其
工作方式、協作與溝通的方式，以及像高績效團隊一樣有效合作的方式。
《DevOps 實施手冊 在多級 IT 企業中使用 DevOps》是寫給組織中
的所有團隊成員的，他們是應用交付流水線中的利益相關者，從業務線
XX DevOps 實施手冊 在多級 IT 企業中使用 DevOps
負責人，到分析師、架構師、設計師、開發人員、測試人員、自動化工
程師、基礎設施工程師、運維人員、資料庫管理員、系統管理員、文件
編寫人員、專案經理、產品負責人，一直到高層管理者，都包括在內。
這些角色可能因組織而異，組織實施 DevOps 時，還需要對很多角色的
工作內容以及工作方式進行完善與調整。本書旨在讓所有這些人受益。
實施所討論的每個方案都會對不同角色的利益相關者產生不同的
影響，有些利益相關者可能會在角色以及與他人互動的方式上發生重大
改變，有些人則看不到任何變化。所有的運球人員以及供水服務員通常
都不會受到球隊戰術的影響，但是他們仍然是利益相關者，如果表現不
符合預期，是會影響到球隊的整體績效的。 IT 的支援性角色亦是如此。
其他角色，比如直接利用構建物及流程開展工作的關鍵利益相關者，他
們是應用交付流水線的組成部分，將從本書所列方案中明顯受益。他們
是方案執行人員，是為方案執行人員或支援人員提供直接支援服務的員
工，以促進執行人員實現最高績效能力。
第 1 章是 DevOps 的概述，介紹了 DevOps 從起源到今天的發展演
變。其中定義並描述了構成 DevOps 的所有常見的實踐與能力，為更廣
泛地定義 DevOps 以及 DevOps 變革奠定了基礎， DevOps 變革是本書的
主題。
第 2 章聚焦於球隊的領導者：教練、隊長以及組成團隊核心的高階
球員。重點關注的是如何評估比賽條件以及競爭對手，以開發並選擇合
適的戰術集，即團隊的戰術手冊。應用到 IT 管理中，指的是專案經理、
產品負責人、團隊領導、資深從業人員、 DevOps 教練以及渴望成為其
中一員的任何人。
第 3 章就如何為 DevOps 變革建立商業案例，以取得適當的支援與
投資來確保成功，提供了相應指導。
第 4 章到第 6 章是真正的方案。具體內容分為：
● 第 4 章——用於最佳化的 DevOps 方案：透過消除浪費，最佳化應
用交付流水線以實現效率最大化的方案。
● 第 5 章——用於創新的 DevOps 方案：使應用交付流水線更加
快速、敏捷以支援實驗能力，驅動創新的方案。
● 第 6 章——用於 DevOps 企業級推廣的 DevOps 方案：在大型、
複雜、分散式且成熟度不統一的組織中，將 DevOps 實施在整
個組織範圍內推廣的方案。
第 7 章是獻給驅動 DevOps 實施的高層管理者的。就如同體育運動
隊的總經理或高階管理者，高管們做出行政決策，確定組織的方向與文
化。他們是需要做出 DevOps 變革決策的人。他們需要為變革提供必要
的投資與支援。他們還需要了解如何建立商業案例以確定變革的投資回
報率。他們需要推動變革，從前沿試點團隊直到整個組織。
本書還有一個附錄。是一個 DevOps 變革實施路線圖的案例，是為
假想的銀行開發交付價值流圖實踐。
本書試圖有意保留工具與平臺的相容性。儘管書中列舉了一些工
具、平臺以及技術作為例子，無論是商業化的還是開源的，但這都是一些
目前市場上可用於實現自動化的工具及平臺。要實現流程自動化，使其高
效、可重複、可擴充套件並且準確無誤，工具必不可少。然而，工具和平臺都
是不斷髮展變化的，取而代之的是更新更好的版本。因此，推薦甚至記錄
現有的工具和平臺是徒勞之舉。我們的目標是強調能力，同時儘可能保持
工具與平臺的相容性，即便現有的工具與平臺仍在不斷改進。
體育運動的比喻
正是由於個人對於集體做出的貢獻，團隊、公司才能夠執行，
社會、文化才得以發展。
—— 文斯 · 隆巴迪，美式橄欖球傳奇教練
沒有什麼比體育運動更能超越文化、語言及地理的界限。如果有所
懷疑，只要再看一遍里約奧運會的重播即可。來自體育專案的比喻也完
全適用於應用的開發與交付，因為二者都是團隊活動。開發或交付新的
應用或服務，可能不要求奧運會金牌得主的體能訓練，但一定需要領導
力、溝通、協作以及信任，這是任何一項團體運動都需要的。
我個人對運動也極富熱
情。從小就是在一個熱愛運動
的家庭中長大的。我的外祖父
是印度的奧運級及國家級體育
選手，他年輕時曾效力於印度
國家曲棍球隊， 後來在 1952 年
赫爾辛基奧運會上擔任印度國
家足球隊的體育主管。 1964 年
的東京奧運會，火炬傳遞經過
印度時，他還擔任了奧運火炬
手。此後的幾十年間，包括我
的童年時期，他一直是國內足
球聯賽的體育主管。在家中伴
隨著奧運火炬長大，使我們都
很尊重運動員及婦女。
書中我列舉、引用了多個
運動專案的運動員與教練的經
驗，並將其對映到 DevOps 實
施中。這種類比旨在使方案更
加貼切易懂，並希望能夠提升
閱讀的趣味性。

圖 1 Major Lachhman Singh 曾是 64 年東京
奧運會火炬手(來源： Singh 家族的私人收藏)
目 錄
第 1 章 DevOps 概述············· 1
1.1 DevOps：起源·············2
1.2 DevOps：本源·············4
1.3 DevOps：實踐···········10
1.3.1 持續整合 ············· 11
1.3.2 持續交付 ············· 15
1.3.3 支援實踐 ············· 19
1.3.4 前移····················· 27
1.3.5 架構與降低風險 ··· 30
1.3.6 持續改進 ············· 31
1.3.7 衡量標準 ············· 31
1.3.8 業務驅動 ············· 32
1.4 DevOps：文化···········33
1.5 總結 ···························35
第 2 章 DevOps 實施··········· 37
2.1 撰寫指導手冊············39
2.1.1 識別目標狀態(業
務目標及驅動) ···· 40
2.1.2 評估現狀 ············· 43
2.1.3 選擇變革方案······ 56
2.1.4 實施變革方案······ 57
2.2 總結 ···························61
第 3 章 開發 DevOps 變革的
商業案例 ··················63
3.1 開發商業案例··········· 64
3.2 完成商業模式畫布 ··· 67
3.3 客戶細分··················· 68
3.3.1 業務線 ················ 68
3.3.2 IT 組織················ 69
3.4 價值主張··················· 70
3.4.1 業務線 ················ 70
3.4.2 IT 組織················ 72
3.5 渠道通路··················· 74
3.5.1 業務線 ················ 74
3.5.2 IT 組織················ 75
3.6 客戶關係··················· 75
3.6.1 業務線 ················ 75
3.6.2 IT 組織················ 75
3.7 收入來源··················· 75
3.7.1 業務線 ················ 76
3.7.2 IT 組織················ 76
3.8 核心資源··················· 76
3.8.1 業務線 ················ 76
3.8.2 IT 組織················ 77
3.9 關鍵業務 ···················77
3.9.1 業務線 ················· 77
3.9.2 IT 組織 ················ 77
3.10 戰略伙伴 ·················78
3.10.1 業務線 ··············· 78
3.10.2 IT 組織 ·············· 79
3.11 成本結構··················79
3.11.1 業務線 ··············· 79
3.11.2 IT 組織··············· 79
3.12 總結 ·························80
第 4 章 DevOps 方案之最佳化
持續交付流水線······· 81
4.1 DevOps 作為最佳化
運動 ···························82
4.2 核心主題 ···················88
4.2.1 縮短週期時間······ 89
4.2.2 縮小批次規模······ 91
4.2.3 建設正確文化
理念····················· 95
4.3 DevOps 實施方案······99
4.3.1 方案：建設衡量
標準與關鍵績效
指標····················· 99
4.3.2 方案：敏捷
實施··················· 107
4.3.3 方案：整合的交付
流水線 ··············· 110
4.3.4 方案：持續
整合··················· 116
4.3.5 方案：持續
交付 ·················· 120
4.3.6 方案：測試
前移 ·················· 133
4.3.7 方案：運維參與
前移 ·················· 139
4.3.8 方案：持續監控
與反饋 ·············· 145
4.3.9 方案：釋出
管理 ·················· 151
4.4 專注核心方案········· 154
4.4.1 方案：移動裝置
DevOps ············· 154
4.4.2 方案：大型機
的 DevOps········· 161
4.4.3 方案：物聯網
DevOps ············· 165
4.4.4 方案： DevOps
用於大資料及
分析 ·················· 168
4.5 總結 ························ 173
第 5 章 DevOps 驅動創新
方案 ·······················175
5.1 最佳化創新················· 176
5.2 Uber 綜合症············ 178
5.3 創新與技術的
角色 ························ 178
5.3.1 商業模式創新··· 179
5.3.2 商業模式實驗··· 180
5.3.3 使用者參與模式
創新··················· 181
5.4 核心主題 ·················183
5.4.1 實現多級 IT······· 184
5.4.2 構建正確的
事物··················· 187
5.4.3 進行實驗 ··········· 190
5.4.4 提供反脆弱的
系統··················· 192
5.4.5 IT 系統與反脆
弱性··················· 195
5.5 方案：構建 DevOps
平臺 ························199
5.5.1 應用交付與反脆
弱性··················· 202
5.5.2 環境抽象層 ······· 203
5.5.3 雲託管的 DevOps
平臺··················· 204
5.5.4 基礎設施即
服務··················· 209
5.5.5 OpenStack Heat
作為抽象層 ······· 214
5.5.6 平臺即服務 ······· 215
5.5.7 容器··················· 219
5.6 方案：交付微服務
架構 ·························223
5.6.1 微服務架構 ······· 224
5.6.2 應用的 12 要素 ··· 226
5.6.3 雲原生應用 ······· 228
5.6.4 微服務和容器···· 230
5.6.5 微服務化改造··· 230
5.7 方案： API 經濟······ 233
5.7.1 部署自動化和
API···················· 236
5.7.2 DevOps 平臺和
API···················· 236
5.8 方案：組織創新····· 238
5.9 總結 ························ 240
第 6 章 DevOps 的企業級
推廣·······················243
6.1 核心主題················· 244
6.1.1 組織文化··········· 245
6.1.2 工具與實踐
標準化 ·············· 246
6.1.3 有組織的實施··· 247
6.1.4 打破組織倉筒··· 248
6.2 方案： DevOps 能力
中心 ························ 248
6.2.1 DevOps 能力中心
的功能與目標··· 250
6.2.2 能力中心的核心
角色 ·················· 251
6.2.3 DevOps 教練····· 251
6.2.4 建立能力中心··· 253
6.3 方案：發展規模創
新文化····················· 254
6.4 方案：發展持續改進
文化 ······················· 259
6.4.1 開發實施路
線圖 ·················· 261
6.4.2 持續開發與價值
流圖··················· 262
6.5 方案： DevOps 團隊
模型 ·························264
6.6 方案：工具與流程
標準化 ····················267
6.7 方案： DevOps 的
安全性考慮··············271
6.7.1 管理安全相關
風險··················· 273
6.7.2 解決 DevOps 流程
與平臺的安全
問題··················· 275
6.7.3 API 經濟與
安全··················· 279
6.8 方案： DevOps 與
外包 ·························280
6.8.1 戰略外包 ··········· 281
6.8.2 IT 供應鏈 ·········· 282
6.8.3 利用外包實現
DevOps ·············· 283
6.9 總結 ·························283
第 7 章 引領企業的 DevOps
實施······················· 285
7.1 方案： DevOps 作為
變革運動 ················287
7.1.1 令人信服的行動
理由··················· 289
7.1.2 DevOps 變革的
反模式 ·············· 290
7.2 方案：發展協作信
任的文化················· 293
7.2.1 可見性促進
信任 ·················· 294
7.2.2 一切都關乎人··· 295
7.3 方案：業務線的
DevOps 思維··········· 296
7.3.1 業務線與 IT 的
接觸 ·················· 297
7.3.2 參與 DevOps
變革 ·················· 298
7.3.3 讓影子 IT 走出
陰影 ·················· 298
7.4 方案：利用試點
專案啟動················ 299
7.4.1 試點專案選擇··· 301
7.4.2 高層管理者
支援 ·················· 302
7.5 方案：在航空母艦
上培養獨角獸········· 302
7.6 總結 ························ 306
附錄 A 案例研究·················307
A.1 組織背景················ 307
A.2 路線圖組成············ 308
A.2.1 DevOps 的最佳化與
創新工作坊······· 309
A.2.2 背景和上下文··· 310
A.3 實施路線圖·············312
A.3.1 業務驅動
因素··················· 312
A.3.2 現有的 IT
舉措 ··················· 313
A.3.3 瓶頸 ·················· 314
A.3.4 根因分析·········· 316
A.3.5 DevOps 實踐···· 316
A.3.6 實施路線圖······ 321
參考文獻 ······························323
第 1 章
DevOps 概述
開發經理的咆哮
事情是這樣的，開發人員在週一下午完成了新服務的編碼工作。她
構建程式碼、執行單元測試，並將程式碼提交到整合流中以便進行持續整合
(CI) 構建。為了測試其服務，開發人員在下班前給測試 (QA) 團隊開了一
個任務單。
星期二早上， QA 團隊進來看到了這個分配給他們的任務單。一個
測試人員拿到了任務單並給開發人員發郵件請求部署說明。由於沒有自
動化部署，開發人員回應說她將親自部署服務到 QA 環境中。星期二下
午，他們參加電話會議進行程式碼部署。開發人員發現測試環境與其程式碼
不相容。他們需要一個新環境。星期二晚上，測試人員開了一個任務單
給運維 (Ops) 團隊申請一個不同規格的新環境。
星期三早上，運維團隊把工作單分配給處理規格和處理防火牆埠
變更的工程師。當他去吃午餐的時候，他開出一個任務單給安全團隊以
批准埠變更。星期三下午，安全團隊給安全工程師開出任務單，安全
工程師批准了變更。星期三晚上，運維工程師收到批准，並開始構建新
環境 。他需要手動構建虛擬機器 (VM) ，其中包括作業系統 (OS) 、應用服
務器、資料庫以及 Web 伺服器。
星期四早晨，伺服器構建完成，任務單關閉。測試人員再次發郵件
給開發人員部署新服務。開發人員部署了新服務，並且測試人員開始準
備可用的測試指令碼。他需要執行迴歸測試，但是他需要額外的資料進行
重新測試。星期四下午，他給生產支援團隊開出一個申請新測試資料任
務單。
星期五早晨，生產支援團隊指派了一名資料庫分析師 (DBA) 從生產
環境收集資料。但此時已經是星期五下午了。每個人都知道 DBA 們在
星期五的下午是不工作的。星期一的早晨，測試人員從 DBA 手中得到
了測試資料。他用了 20 分鐘時間執行迴歸測試，並且發現一個缺陷。
他把任務單退回給開發人員，在程式碼編寫構建完成整整一週之後。在這
份程式碼之上整整一週的編碼工作等待處理，不知道是否存在缺陷。我們
現在又落後一週了。
這個故事的可怕之處在於，當我把它講給其他公司的同行聽時，他
們並不感同身受，只是驚訝：相比他們，我們竟然如此高效！
—— 又一個沮喪的開發經理
1.1 DevOps：起源
DevOps 運動始於約翰·阿爾斯帕瓦和保羅·哈蒙德(當時他們都服
務於 Flickr/Yahoo)在 2009 O’Reilly 敏捷大會上的一次具有開創性意義的
演講。演講的題目是《每天 10+部署：開發與運維在 Flickr 的協作》 ① 。
每天 10 次部署被認為是史無前例的。同年，帕特里克·德布瓦在比
利時根特組織第一次 DevOpsDays 活動時，最終將他們的方法稱為
DevOps。
這個名稱開始流行起來並引發極大關注，但最初僅限於初創公司，
更具體地說，是那些提供 Web 應用的組織。這些應用由開發人員(Dev)
建立，他們通常以非常迅速的方式向其 Web 應用提交變更。他們所面
臨的主要障礙來自於運維(Ops)團隊，由於變更管理流程僵化而且苛刻，
① 。
以致運維團隊在部署變更時速度非常緩慢。
DevOps 運動的目標就是要解決開發與運維團隊之間的阻抗失衡；
彌合彼此之間的鴻溝；促進更多溝通、合作與信任。從本質上講，這是
一次文化運動，致力於改變開發與運維團隊之間的文化差異，透過自動
化使應用交付更快速、更高效並最終做到持續交付。 2010 年，當時在
ThoughtWorks 公司工作的傑茲·漢姆，在他的著作《持續交付》中編
寫了一些 DevOps 的核心實踐，使得 DevOps 的實施變得切實可行，由
此，將 DevOps 介紹給全行業的從業人員。
不過， DevOps 被看作是那些獨角獸公司才做的事情，也就是那些
處在創新前沿的， 沒有大型的、 複雜的遺留系統需要維護的初創型組織，
還沒有成為大型企業的主流。然而，這些大型企業看到了初創公司運用
DevOps 所取得的成功，並且試圖實施 DevOps 以滿足其自身需求。像
IBM 這樣的組織開始涉足自動化部署以及虛擬化環境架構， 甚至將兩種
能力相融合。與此同時，像 UrbanCode 這樣在自動化構建領域信譽卓著
的公司，隨著 uDeploy 的釋出，也開始轉向 DevOps, 由此建立了一類新
的持續交付工具。自動化領域的其他公司，比如 Nolio 也加入行列之中
並提供自己的競爭產品。同時，運維和基礎設施即程式碼(infrastructure as
code)方面的公司，如 Opscode(現在稱為 Chef)和 Puppet Labs 也受到關
注(Opscode 的 Chef 和 Puppet Labs 的 Puppet)。
2012 年， IBM 利用 SmartCloud Continuous Delivery 開始了其第一
項短暫的持續交付實驗，自此， DevOps 開始真正走進了大型企業。一
些諮詢公司，比如 Thoughtworks 和 IBM，也開始為組織，尤其是想要
實施 DevOps 的大型組織提供諮詢服務，協助其將獨角獸公司的成功經
驗轉換成企業適用模式。透過分別收購(巧合的是在 2013 年 4 月的同一
天)UrbanCode 與 Nolio， IBM 和 CA Technologies 宣佈正式進軍 DevOps
領域。然而， DevOps 運動有史以來最重要的轉折點是發生在 2013 年基
恩·金(Gene Kim)的著作《鳳凰專案》 (Phoenix Project)出版的時候。這
本書的靈感來源於艾利·高德拉特(Eliyahu M. Goldratt)的著作《目標》，
正如高德拉特的著作曾領先製造業幾十年的時間，《鳳凰專案》現已成
為現代 IT 界貫徹執行精益實踐以及高德拉特約束理論的必讀書籍。利
用這本書，還有後來每年與傑茲·漢姆和帕位元·萊博斯聯合釋出的
《DevOps 現狀調查報告》，基恩·金使 DevOps 真正成為主流。
1.2 DevOps：本源
DevOps 從哪裡來？雖然我已經大概講述了其起源的故事，但 DevOps
真正的起源要早於 Allspaw、 Debois、 Humble 和 Kim 將近一個世紀的時
間。這需要追溯到發源於 20 世紀 10 年代的精益運動。
隨著亨利·福特在 T 型車生產線中應用了精益流程管理， 精益運動
開始在製造業興起。自 20 世紀 30 年代起，豐田的豐田喜一郞(Kiichiro
Toyoda)與大野耐一(Taiichi Ohno)將這項工作進一步擴充套件、細化及整理，
二戰後得以真正迅速發展起來。 20 世紀 50 年代，這項工作受到戴明博士
(Dr. William E. Deming)提出的計劃-執行-檢查-處理(Plan–Do–Check–Act，
PDCA)迴圈理論的影響不斷改進，以持續提高生產質量。 基於其最為核心
的方法，精益生產運動旨在持續改進產品質量的同時減少生產過程當
中的浪費。在詹姆斯·P. 沃麥克(James P. Womack)和丹尼爾·T. 瓊斯
(Daniel T. Jones)1990 年出版的《改變世界的機器》 (必讀)以及 1996 年
出版的《精益思想》 (Lean.org， 2016)這兩本著作中，精益得到進一步
的詮釋。
戴明的精益思想與持續改進
戴明博士教導說，透過採取適當的管理原則，組織可以在提高質量
的同時降低成本 ( 透過減少浪費、返工、員工流失及客戶投訴，同時提
高客戶的忠誠度 ) 。關鍵是要實施持續改進，並且視生產為一個完整系
統，而非零零碎碎的 。
—— 戴明博士的管理培訓 ( 戴明， 1998)
2001 年，敏捷出現了。包括庫克伯恩和馬丁·福勒在內的 17 個思
想領袖發表了敏捷宣言 ② 。宣言的核心是擺脫僵化、瀑布式的、文件化
的軟體開發世界，這是大多少數軟體開發專案延期、超預算或是慘痛失
敗的原因。
他們的目標是找到一種迭代的方法，實現與客戶、終端使用者或代理
人的持續互動。他們不想再透過諸如需求文件之類的主要硬性指標來衡
量進度，因為這類指標不會提升程式碼的交付速度。另一目標是利用實際
執行的程式碼(執行的軟體)作為衡量進度的真正標準；審視計劃與實際進
展的匹配；建立不需要預先編寫，但會隨著應用的開發而改進與完善的
需求。
隨著極限程式設計(Extreme Programming， XP)、敏捷軟體開發(Scrum)
以及近期出現的規模化敏捷框架或是 SAFe 這些方法論的發展，敏捷得
到進一步提升。今天，不論大型還是小型的組織都在利用敏捷方法交付
各種規模與技術的專案。
敏捷是 DevOps 需求的前驅，並已成為核心的驅動力。隨著開發人
員加快程式碼交付速度，程式碼需要更快速地測試；還需要更加頻繁地部署
到開發及測試伺服器，並最終部署到生產環境。但是運維團隊並沒為此
做好準備，這導致了開發到測試的交接過程中出現了瓶頸，因為測試無
法根據需要按時建立適當的測試環境，更為重要的是釋出時的生產環
境。產品釋出仍然是一個重大的任務，“釋出週末”通常都會持續到周
末以後。
釋出週末
記得 90 年代早期我在一家金融機構從事開發工作 ( 當時稱為銀行後
臺 ) ，在週末釋出時，令我非常懊惱的是，我們被要求在週五的早上帶
著睡袋去工作。我們預計整個週末都要待在那了。開放了多間設有電話
會議橋的會議室，讓每一個團隊彼此溝通。一個會議室就如同一個作戰
室，專案負責人透過一個大型的電子表格協調所有利益相關者。管理層
盡最大努力想要營造一種聚會的氣氛，但最初的幾小時過後就煙消雲散
②
了。我們第一次和運維人員進行交流。我們把程式碼交給了此前從未見過
這些程式碼的人。他們使用我們所不熟悉的指令碼與工具，將程式碼部署到我
們無法訪問的環境中。整個週末都一團糟。大量的食品和變味的咖啡，
似乎一切都沒有按計劃進行。我們支援的商人都是很聰明的。他們總是
在接下來的週一安排一次郊遊或野餐。他們知道一切都會停擺，而且他
們是對的。幸運的是，我們一年只有兩次這樣的情況。對我個人而言更
為幸運的是，我在那裡工作期間只趕上兩次釋出。
程式碼的短迭代快速開發，增強了開發與運維團隊之間更好溝通與協
作的需求。生產環境釋出頻頻失敗，揭示出開發人員對類生產環境的訪
問需求。僅僅提高流程中的一個部分，即開發程式碼的效率，使整個流程
的低效暴露無遺，這就導致測試與運維成為主要瓶頸。如果把應用開發
及交付流程比作工廠裡的生產線，在下游的工序仍然低效工作的情況
下，僅僅加快其中某一道工序的工作速度來增加零部件的數量，對提高
整條生產線的交付速度沒有任何幫助，只會製造更多的積壓而已 (如圖
1-1 所示) 。這不僅是運維的挑戰，也是交付生命週期中所有利益相關
者的挑戰。

圖 1-1 交付流水線瓶頸
如今的焦點轉向週期時間最小化。週期時間指的是從需求或者使用者
故事開始到把功能交付到客戶手中，或者至少是完成整合、測試並已為
部署到客戶機做好準備的時間。這導致 DevOps 兩項核心能力的發展：
持續整合(已經是敏捷的核心競爭力)與持續交付。稍後將詳細討論這兩
項能力。將運維團隊納入交付生命週期中，作為流程的一個部分，而非
在程式碼釋出前都不參與進來的獨立筒倉，這種超越開發-測試周期的敏
捷擴充套件已成為 DevOps 的核心原則。
解決開發與運維的對立
開發與運維在傳統開發過程中位於不同的筒倉中，有著不一致甚至
是對立的優先順序。開發(Dev)的任務是提供創新並儘快交付給使用者。運維
(Ops)的任務是確保使用者可以訪問穩定、快速的響應系統。儘管開發和運
維的最終目標都是讓使用者滿意其提供的系統，但對於如何達成這個目標，
他們的觀點在本質上卻是對立的。任何開發人員都不是故意製造一個玩
具車一樣的系統，當使用者使用時，應用就崩潰。所有運維人員都希望開
發人員能不斷更新產品，使其具有更新、更令人興奮的效能及功能。這
就 是 他 們 的 差 異 所 在 。 這 是 一 種 典 型 的 情 形 ， 被 稱 為 敏 捷 瀑 布
(water-Scrum-fall， Forrester, 2011)。開發人員想要並期望能快速為產品提
供新效能。運維想要並期望能創造一個在任何時候都穩定執行的系統。
1. 開發對運維
在敏捷出現之前，在純粹的瀑布型案例中，開發人員和運維人員生
活在真正獨立的世界中時，這些對立的優先順序並不是那麼嚴重的問題。
開發和運維人員的工作日程只是在釋出時有限互動。開發人員清楚釋出
日期，並且只在釋出日才釋出新的效能。如果截至釋出日期，他們沒能
開發出新的效能，那就只能等待下一趟釋出列車了。運維人員清楚釋出
列車何時到來，所以，在部署之前，他們有足夠的時間對新功能進行測
試，並且可以用幾天(週末)的時間將它們部署到客戶機。對於大型系統，
他們甚至可以長期進行分階段部署，保持穩定性。
敏捷改變了所有這一切。利用持續整合(CI)，開發人員現在可以每
天部署新的效能。不需要再等待釋出列車；這是一條時刻運轉的傳送帶
(流水線)。現在開發人員希望其開發的新功能能夠在開發環境、測試環
境以及最終的生產環境中按照生產與整合同步的頻率良好執行。他們希
望運維人員能支援所有這些新版本。
運維人員現在要處理的不再只是偶爾的一次釋出，而是持續不斷的
密集 CI 構建。這些構建可能做好了也可能還沒有做好部署準備，但必
須由運維人員進行管理並部署到測試以及最終的生產環境中。現在運維
人員更關心質量。開發人員與測試人員關心的是如何快速獲得開發及測
試環境，以及這些環境是否與生產環境類似。他們不想在一個功能和表
現與生產環境不相似的環境中測試其程式碼。因此，運維人員不可以再花
上幾天時間去配置及構建開發、測試以及最終的生產新環境。他們做這
一切的同時，仍然保持生產環境穩定和可靠。他們必須在保持生產系統
穩定性與可靠性的同時做到這一切。
週期時間？
如果迭代開發 (Scrums) 週期是兩週，卻需要三個星期時間才能取得
新的測試伺服器，那麼這個迭代週期是多長？
2. 開發與運維
開發人員與運維人員之間這場戰爭的解決方案正是 DevOps 要給出
的，即：實現創新與穩定、交付速度與質量之間的平衡。要實現這一點，
開發人員和運維人員都需要改進其工作方式以相互融合。
開發視角 之前的內容可能會讓人產生一種運維人員需要比開發
人員改變更多的印象，但是開發人員也同樣需要做出一些改變：
● 開發人員需要與運維人員合作，瞭解其應用所執行的生產系統
的性質。生產系統(環境模式)的標準是什麼？他們的應用在系統
中如何執行？應用的運維有哪些約束條件？現在，開發人員需
要了解系統以及企業架構。
● 開發人員應該更多地參與測試工作。 這意味著不僅是要確保程式碼
零缺陷，而且還要測試應用，看看其在生產環境中將如何執行。
這就要求開發人員與測試人員(QA)緊密合作， 並且在類生產環境
中對其應用進行測試。
● 開發人員還需要學習如何監控部署後的應用，並理解運維人
員所關心的衡量指標。他們要能夠破譯程式是如何互動的，
以及一個程式如何導致另外一個程式慢下來甚至崩潰。他們
需要理解程式碼的變化如何影響整個生產系統，而非僅僅影響
自己的應用。
● 開發人員需要和運維人員更好地溝通、協作。
運維視角 運維人員需要具備快速配置新環境的能力，他們需要構
建系統以接納快速變化。
● 運維人員需要清楚程式碼的來源及其對系統可能產生的影響。這
就要求他們從瞭解應用的需求以及系統規格開始，就要參與開
發協同。這個過程在精益與 DevOps 中稱為前移(shift left)。他
們需要確保其系統能夠適應這些增強版的應用。
● 運維人員需要自動化系統管理方式。沒有自動化，就無法實現
快速、穩定的變更。自動化不僅使快速變更得以實現，也能在
系統崩潰時實現快速回滾。
● 理想情況下，運維人員需要版本化其系統。只有當基礎設施以
及所有的變更都可以作為版本控制的程式碼獲取並管理的時候，
才能完成這樣的版本化。因此，他們需要引入基礎設施即程式碼
實踐，軟體定義的環境就更好。
● 無論在哪種運維團隊所管理的環境下，運維人員都需要監控整
個交付流水線中的一切。他們需要在最短的時間內發現潛在的
不穩定因素。
● 運維人員需要與開發人員更好地溝通、協作。
簡而言之，開發人員和運維人員都需要納入 DevOps 規範中。他們
都需要知道，這不是一件容易的事，也不是一蹴而就的事。他們需要擬
定計劃並逐步實施變更以實現 DevOps 的承諾。開發人員與運維人員或
許永遠無法合成一個團隊，至少在多數情況下無法實現，但是他們都需
要理解自己的角色將隨著 DevOps 的實施而發生改變。他們需要儘可能
改變自己以進行協同工作，找到組織所需的開發與運維之間恰當的合作
模式並進一步改善。
也就是說，開發與運維之間的分歧並不是快速交付生命週期的唯
一障礙。交付生命週期中的所有利益相關者都需要進行更好的溝通與
協作。
業務視角 來看一下業務的視角。最終， IT 透過交付的應用與服務
提交的是業務需求。業務(業務線的需要更加明確)需要什麼？
● 業務需要的是 IT 所交付應用與服務的狀態的可見性。 他們是否
按時並依照預算交付了應用與服務？
● 業務需要應用交付團隊就客戶及終端使用者如何使用應用與服務
為其提供反饋。他們能否獲得預期的商業價值？
關於業務視角以及 IT 期望方面更為詳細的分析， 以及 DevOps 如何
為業務提供幫助，將在下一章詳細討論。
1.3 DevOps：實踐
關於構建 DevOps 所需的功能，書中已經寫了很多，部落格文章中甚
至更多。一些思想領袖把這些實踐分為不同的類別，某些情況下甚至
使用的是不同的名稱。 IBM 列舉了幾項這樣的實踐，均包括在以下幾
大類中：
● 思考
● 程式碼
● 交付
● 執行
● 管理
● 學習
● 文化
這種分類來自 IBM Garage Method ③ ，這是一種專注於交付 Cloud
Native 及 Hybrid Cloud 託管應用的採用 DevOps 實施的新方法論。
③ https://www.ibm.com/devops/method
DevOps 有兩個關鍵核心能力：持續整合及持續交付。沒有這兩種
能力，就沒有 DevOps。這兩種能力連同其他擴充套件能力或者支撐能力是
實施 DevOps 所必須考慮到的。這兩個概念聚焦於週期時間最小化。再
來回顧一下週期時間的定義。
注意：
週期時間：從需求或者使用者故事開始到把能力交付到客戶手中，或
者至少是完成整合、測試並已為部署到客戶機做好準備的時間。
1.3.1 持續整合
而今，交付軟體應用或系統涉及負責不同元件開發的多個團隊。通
常，已經完成的應用還需要與其他應用或服務互動才能實現其功能。其
中一些外部應用或服務可能是企業中現存的遺留應用，或者是外部第三
方的服務。因此，開發人員必然需要將自己的工作與其他開發團隊構建
的元件以及其他的應用與服務進行整合。
這種需求使得整合工作成為軟體開發生命週期中的一項必要且
複雜的任務。按固定節奏進行整合的過程通常稱為持續整合，持續集
成是敏捷的一項關鍵實踐。在傳統的開發流程中，整合是在元件(有
時是完整的應用)構建之後才進行的次要任務。這樣的順序本質上是
高成本且不可預測的， 因為本來應該只在整合過程中發現的不相容問
題及缺陷，卻要在開發流程的後期才能發現，這通常會導致返工及風
險的劇增。
透過元件的持續整合， 敏捷運動引入了一個邏輯步驟來降低這種
風險。在這一步驟裡，開發人員定期(至少每天)將其工作與團隊中其
他開發人員的工作整合並進行測試。在跨越多個平臺、應用或服務的
企業級系統中，開發人員還會盡可能頻繁地與其他系統及服務進行集
成。跨越多個團隊與元件的持續整合案例如圖 1-2 所示。

圖 1-2 持續整合
這些整合結果的步驟使整合風險得以儘早發現並揭示出來。在企業
級系統中，這些步驟還能夠揭示出關於可能存在風險的技術或者日程的
已知及未知的依賴關係。隨著這些實踐日益成熟，一些組織已採用持續
整合實踐，開發人員每次提交程式碼時都會遵循這些實踐。在大多數成熟
的組織中，持續整合會帶來持續交付的能力，在持續交付流程中，程式碼
和元件不僅整合，還會交付到類生產環境中進行測試和驗證。這部分內
容將在下一節討論。
業務及客戶對開發組織的需求推動了敏捷開發實踐在開發團隊的
廣泛應用。這些實踐旨在縮小業務(或客戶)與開發團隊的分歧。開發團
隊主要透過三種途徑來開展工作：
● 透過將開發工作分解成可以在迭代週期內完成的小塊工作。這
使得開發人員能夠儘早地識別及解決風險，而不是等到完成整
個專案或大部分工作的時候才能發現。
● 透過讓終端使用者或代表使用者的代理在迭代週期中與開發團隊互
動。這有助於開發人員更好地理解使用者需求，從而使變更需求
更快上線。
● 透過在每一次迭代結束時釋出軟體。這使開發人員能夠定期地
演示所構建的最新應用，以便獲得使用者反饋。
如前所述，持續整合是這種敏捷開發的原則之一。使開發人員得以
將其軟體元件與內、外部的其他開發人員所開發的元件進行定期整合，
以便儘早識別風險。
持續整合實踐
馬丁·福勒曾簽署了著名的敏捷宣言，是持續整合流程開發的思想
領袖。他把持續整合的概念分解成如下所述的十個實踐：
(1) 維護同源的程式碼庫。無論管理程式碼還是檔案，使用版本管理工
具來管理原始碼是至關重要的，以實現多使用者訪問及程式碼流化 ④ ，或者
分支開發與程式碼合併，還能夠實現分佈在不同地點的多位開發人員在同
一組檔案上工作。對於任何多平臺的開發工作，使用通用的、跨平臺的
同原始碼庫就更加重要。如果這類程式碼庫不能跨平臺執行，那麼任何獨
立的平臺(例如， System Z 或移動平臺)都將無法參與持續整合實踐。在
獨立平臺上進行的任何工作整合都將成為一種後處理、瀑布式的整合。
對於多年來可能一直使用相同功能的遺留系統開發團隊而言，向
現代原始碼庫的轉換代表著巨大的變化。然而，同原始碼管理(Source
Code Management， SCM)工具對於管理所有的構建物，幫助打破筒倉
以及消除關鍵瓶頸是至關重要的。
(2) 自動化構建。自動化構建使持續整合得以持續。此外，如果需
要，應該還可以跨多個平臺協調構建。
(3) 測試自動化。正如構建需要自動化，測試也同樣需要自動化。
持續整合的目標不僅僅是整合團隊的工作，還要審視所構建的應用或系
統在功能與效能方面的表現是否符合預期。這就需要為單元級測試、組
件及應用級測試建立一套自動化測試指令碼。在真正的持續整合中，開發
人員是可以透過提交程式碼時啟動適當的測試來發起整合構建的。這個流
程要求構建指令碼具備按需構建軟體、提供測試伺服器、配置測試環境、
將軟體部署到測試伺服器、初始化測試資料以及執行正確的測試指令碼這
一系列能力。
要求配置可以進行構建、部署及隨時進行自動化測試的環境有助於
提高最終程式碼的質量。這需要系統資源可用，願意定期執行大量自動化
測試以及開發自動化測試。
(4) 確保每個人每天都能堅持主線交付。 讓跨越所有元件及所有開
④ Streaming：以流的方式訪問程式碼和文件最新版本，而不是靜態訪問其分支上的某一個版本。
發環境的每一位開發人員每天提交程式碼到開發流的主線，這個目標有助
於確保整合簡單化。即使到了今天，許多開發人員仍然獨立工作直到最
終的構建完成，也只有這時，他們才意識到自己的工作是受到其他開發
人員的工作影響的。這可能導致功能釋出延期，或者上線前變更未經充
分測試就部署到生產環境中。程式碼定期整合有助於確保迅速識別出這些
依賴關係，以便開發團隊能夠及時處理，並且不需要受時間限制。
(5) 確保每次提交都在整合伺服器構建主線。 這是實踐(4)的第二部
分。確保每一次提交程式碼都執行了構建，並且執行了自動化迴歸測試，
這樣有助於確保在開發生命週期中更早地發現及解決問題。
(6) 保持快速構建。 事實上，執行時間過長的構建才是持續整合的
最大阻礙。由於構建的標準化實踐就只是轉換檔案，使用現代的工具進
行構建通常速度很快。
(7) 克隆生產環境中的測試。 在無法準確代表生產系統的環境中進
行測試會給系統帶來很多風險。這一實踐的目的是在克隆生產環境中進
行測試。然而，也不太可能每次都僅僅為了測試而建立完整的多伺服器
克隆環境，建立一個有其他工作負載執行的克隆環境就更加困難。
這個實踐要求建立類似的生產環境，稱為“類生產環境”。類生產環
境的規格應該儘可能接近生產環境。還應具備適當的測試資料管理能
力。測試環境中不應該包含生產資料，因為在許多情況下，資料需要脫
敏。適當的測試資料管理還可以縮小測試環境的規模，降低複雜程度。
由預先存在的(比如其他服務與應用)元件及開發的新元件所構成的
多元件複雜系統也帶來了挑戰。應用需要訪問及互動的所有元件、服務
還有系統可能無法用以執行測試。導致這種情形發生的原因有很多：組
件、服務或系統可能還沒有構建完成；可能已經構建，但只能作為生產
系統使用，無法進行非生產資料測試；或者其使用會帶來額外的成本。
比如，對於第三方服務，成本就是一個主要的問題。
(8) 使任何人都能輕鬆獲得最新的可執行檔案。 任何專案相關人員
都應該擁有構建的訪問許可權並獲得與之互動的途徑。這樣可以驗證構建
是否符合預期。
(9) 確保每個人都能看到發生的一切。 這是一個溝通與協作相關的
最佳實踐，而不是一個持續整合相關的實踐。但其對於團隊實踐持續集
成的重要性不容忽視。透過中央門戶或儀表盤展示持續整合進度，為所
有團隊成員提供資訊。
這樣可以鼓舞士氣，並有助於建立目標一致的團隊合作意識。如果
發生問題，可見性可以促進人們參與並幫助他人或其他團隊克服挑戰。
透過公共團隊門戶實現可視性對異地工作的團隊尤為重要，不過對於同
地工作的團隊還有負責不同元件的跨平臺團隊而言也是非常關鍵的。這
種可視性應儘量將所有資訊反饋給業務。正如前面所述，所交付應用與
服務當前狀態的可視性是業務的重要需求。
(10) 自動化部署。持續整合自然而然地導致了持續交付的概念與持
續交付的實踐——將軟體自動化部署到測試、系統測試、類生產以及生
產環境的過程。
1.3.2 持續交付
持續交付僅僅是把持續整合的概念引入下一個階段。在每一次持續
整合構建的最後，應用一旦完成構建，就會被交付至生命週期的下一個
階段。交付到測試(QA)團隊進行測試，然後交付給運維團隊進行生產環
境釋出。持續交付的目標是儘快獲得開發人員為客戶及使用者建立的新性
能。而今，並非從持續整合工作中產生的所有構建都需要交付給測試團
隊；只有那些具有功能特性的可以在開發階段進行測試的“良好”構建
才需要交付。
同樣，並非所有經過測試的構建都需要交付到生產環境。只有那些
在功能性、穩定性以及其他非功能需求方面都準備就緒的構建才會進行
生產環境上線。為了測試是否已做好生產釋出的準備，應當先將構建交
付到類生產的部署或測試環境。定期將開發中的應用交付給測試及運維
進行驗證並潛在釋出給客戶的這種實踐稱為持續交付。
持續交付需要建立一條交付流水線(如圖 1-3 所示)， 其核心功能是
實現持續交付自動化。隨著持續整合產品以穩定的節奏構建，這些構
建需要快速地交付至流水線中的其他環境。構建需要部署到測試環境
中進行測試，部署到整合環境進行整合與測試等，最終部署到生產環
境。持續交付有助於將應用根據需要從一個環境部署到另一個環境。

圖 1-3 交付流水線
然而，持續交付不只是移動檔案那麼簡單。需要編排程式碼部署、內
容、應用、中介軟體以及環境配置，還需要變更流程，如圖 1-4 所示。

圖 1-4 持續交付
關於持續交付，還要記住兩個關鍵點：
● 並不是說每一次將變更部署到生產，都是通常所說的持續部署
流程。相反，持續交付不是一個流程，而是隨時根據需要部署
到任何環境的能力。
● 持續交付並不總是意味著部署完整的應用。部署的可能是完整
的應用、一個或多個應用元件、應用內容、應用或中介軟體配
置變更，或是應用部署的目標環境。還可能是這些內容的任
意組合。
十項持續整合實踐中有兩項構成了持續交付的連結，並且是持續交
付所必需的：
● 在克隆生產環境中進行測試
● 自動化部署
在克隆生產環境(第七項實踐)中進行測試時，或許也是一項測試
實踐，也需要持續交付能力，以將新的構建交付到克隆測試環境中。
交付過程中可能需要配置測試環境、虛擬化的服務例項與應用。除了
將應用真正部署到適當的測試環境之外， 可能還需要配置相關的測試
資料。
第十項持續整合實踐，即自動化部署是持續交付的核心實踐；沒
有自動化的部署流程，持續交付不可能實現。無論目標是部署完整的
應用還是僅僅部署一個元件或配置變更，持續交付都需要準備好適當
的工具與流程，以根據需要將應用或元件隨時部署到交付流水線中的
任意環境。
實踐持續交付也是對實際的部署流程進行測試。將應用部署到生產
環境時，組織遭遇嚴重問題的情況並不少見。然而，透過自動化部署流
程以及生產上線前多次部署到類生產環境進行驗證，是有可能在交付生
命週期的早期就發現這些問題的。
持續交付與持續部署
過去，像 Flickr 這樣的公司會在部落格 ⑤ 上釋出，截至目前，他們在
一天或一週內一共部署了多少次。看到一個每週上線 89 次生產環境的
組織可能會覺得很恐怖。更重要的是，迴避了一個問題：“一週之內向
生產環境部署 89 次，究竟都部署了什麼內容？”
這是一個會讓人想要遠離 DevOps 實施的情景，因為他們認為必須
將每一項變更都部署到生產環境。情況肯定不是這樣的。首先，需要了
解的是這裡部署的內容是什麼，其次(也更加重要)，必須要明白，這對
於每一個組織而言都是不適用、不必要的，甚至是不可行的。
一週 89 次部署都部署了什麼？ 當組織說他們每天進行兩位數生產
部署時，這並不意味著他們每天都交付幾十個新效能或是修復幾十個漏
洞。這些公司實施的是真正的、全方位的持續部署。這意味著每個開發
人員的每一個變化都會影響到生產環境。這些可能並非完整的效能；幾
⑤
天之內，由多個開發人員完成的一些這類更改有可能構成一個完整的可
用效能。這部分效能可能是客戶根本看不見的；只有在全部效能可用並
經過測試之後，客戶才能看見。然後，這也可能是 A/B 測試的一部分，
所以只有少數客戶能見到。部署也可能是從未有人見過的簡單配置或數
據庫架構的變更，但會改變某些效能或功能表現。另一種情況是，部署
涉及新的環境變化，而不涉及應用的變更，即作業系統(OS)或中介軟體補
丁、作業系統或中介軟體配置的變更、新資料庫架構的版本、全新的架構
拓撲節點等。
這樣的流程對許多組織來說是不可行的。有些組織可能有一些類似
于敏捷瀑布的要求和政策，要求在部署到生產環境之前要透過手動審批
流程。其他組織可能要求職責分離，要求部署到生產環境的人與開發可
部署資產的人必須是不同的人或團隊。
是否要進行持續部署？ 人們還是會混淆持續部署與持續交付的概念。
持續交付並不意味著每一次變化都要儘快部署到生產環境。而
是意味著每一次變化都是隨時可以部署的。
—— Carl Caum(Caum， 2013)
這條 Carl Caum 的微博，簡簡單單的一句話卻抓住了問題的本質，
組織應該做什麼與能夠做什麼。 依據這種標準區分， 持續交付是必須的，
而持續部署是一個可選項。具有持續部署的能力比實際持續地生產上線
更為重要(這裡的關鍵詞是生產上線)。遺憾的是，這些術語仍然為大多
數人交替使用。
在交付生命週期中，需要的是可以部署到任何環境的測試與驗證能
力，最終到生產環境上線。或許只能持續部署到一個預生產環境(簡配
的環境)，例如，使用者驗收測試(User Acceptance Testing， UAT)，預生
產……， 但是部署的環境應該與生產環境類似， 以確信真正生產上線時，
最終的部署不會出現任何問題。
持續交付是對開發、測試環境以及其他(簡配環境)非生產環境的每
一次變更進行交付。最終選擇部署到生產環境的將會是一項完整的效能
或一組效能，又或者是一項完整的應用或服務。
1.3.3 支援實踐
除了 DevOps 的兩項核心實踐持續整合與持續交付(不應用這兩項
實踐，就不是在實施 DevOps)以外，還有一些支援實踐，用以支援及促
進這兩項核心實踐。以下是其中的一些實踐，這些實踐是支援性的，卻
是必不可少的。
1. 基礎設施即程式碼
運維世界的主人
想象一個經驗豐富的運維工程師。在職業生涯中，他肯定已經開
發出一個指令碼工具包，利用這個工具包，只需要透過很小的改動，就
可以完成他所有的日常工作， 配置及管理他所見過的與處理過的大批
環境。進行配置的時候，他清楚所有的管理控制檯，就像自己的手背
一般。為了解決所面對的問題，他可以登入並對應用伺服器的配置進
行精確的調整。對於資料庫相關的問題，他確切地知道應該給誰打電
話，而且知道 DBA 已經掌握其終端業務，就像他所熟練掌握的那樣。
他按例行程式處理事情。他確切知道下一次應用釋出是什麼時候。它
知道什麼時候作業系統會進行下一次更新。他是自己世界的主人。
隨 著 系 統 的 虛 擬 化 以 及 開 發 人 員 啟 動 持 續 集 成 (Continuous
Integration， CI)實踐，情況開始發生變化。運維工程師必須處理 9 的環
境及例項的數量增加了好幾個數量級。開發人員不再每隔幾個月才釋出
一次更新或新版本；他們每天都在推出持續整合構建，實際上是每天構
建多個版本。所有這些構建都需要測試和驗證。這就要求新的環境例項
要快速週轉。這些構建還經常伴隨著配置變更。登入控制檯逐一進行變
更已不再可行。此外，對速度的需求至關重要。開發人員的構建正在創
建一個龐大的任務列表，因為連測試構建的環境在需要時都無法使用。
“休斯敦，我們有麻煩了。”
先來重新介紹兩個概念：
1) 週期時間。週期時間指的是，從審批透過新需求、提出變更請
求，或是識別出需要透過補丁進行修復的漏洞，直到交付至生產環境上
線的平均時間。敏捷組織希望交付週期時間做到最短。這限制了他們向
客戶釋出新效能與修復缺陷的能力。電商 Etsy 已經將週期時間降到分鐘
級的水平！雖然這對於企業應用來說是不可能的，但是當前數週的週期
時間有時甚至是數月的週期時間是絕對不能接受的。
2) 版本化環境。要根據要求維護開發當前所需的多個不同配置及
補丁級別的環境，需要運維人員改變其處理變更和維護這些環境的方法。
無論是打補丁還是變更配置，運維人員所進行的任何環境變更都應該視
為建立了新版本的環境，而非僅僅是透過控制檯調整了配置項。正確管
理的唯一方法是透過指令碼執行所有變更。這些指令碼在執行時將建立所運
行環境的新版本。在不影響運維的最佳實踐 IT 基礎設施庫(Information
Technology Infrastructure Library， ITIL)和 IT 服 務 管 理 (Information
Technology Service Management， ITSM)的同時，這一流程使變更管理更
加簡單、高效，並可以實現規模化。
透過獲取並管理基礎設施即程式碼，可以同時解決最小化週期時間和
環境版本化這兩種需求。上線一個新虛擬環境或一個環境的新版本，就
變成執行指令碼的過程，指令碼可以建立並提供一個或一組映象，完成從操
作系統到完整的應用堆疊的安裝與配置。過去花費幾小時的任務現在只
需要幾分鐘。
正如在配置管理系統(SCM)中將程式碼版本化一樣，對這些指令碼進行
版本化可以實現適當的配置管理。如今，建立新的環境版本要包括簽出
正確的指令碼以及對指令碼做出必要的修改，即給作業系統打補丁、更改應
用伺服器設定或者安裝新版本的應用，然後在執行之前，將指令碼作為一
個新的環境版本重新檢查。
注意： 如果沒有基礎設施即程式碼，運維會很容易成為瀑布式敏捷的
最後釋出瓶頸。
已經出現了一些用來獲取及管理基礎設施即程式碼的自動化架構。流
行的架構中包括 Chef、 Puppet、 Salt 以及 Ansible。
隨著雲端計算的發展， IT 即將完成軟體定義環境(Software Defined
Environment， SDE)的轉變。這需要使用程式碼定義、版本化及維護完整
環境。像 OpenStack CloudFormation (亞馬遜 Web 服務)這樣的技術成為
行業領導者。例如 OpenStack，可以根據需要，利用 Heat 模板以軟體方
式定義全棧環境， 使其可以利用 Chef 與 Salt 進行版本管理、 建立及配置，
還可以進行環境的擴容管理。運維操作人員不再專注於管理那些生命周
期很長的獨立伺服器；他們現在管理的是大量的臨時伺服器，按需進行
環境的提供和釋放。只有軟體定義環境才能實現這種規模化與敏捷性。
注意： 在軟體定義環境的世界裡，伺服器是“牲畜”，而非“寵物”
(McCance ， 2012) 和 (Bias ， 2012) 。
2. 持續反饋
回過頭來從整體上認識一下持續反饋，其本質上意味著從交付流水
線的每一個功能區域到其左側區域獲取反饋。因此，開發人員隨著程式碼
的開發與交付，向架構、業務分析及業務線提供相應的反饋；測試人員
透過持續測試提供反饋給開發人員、架構、業務分析以及業務線；最後，
運維人員提供反饋給測試人員、開發人員、架構、業務分析以及業務線，
如果還有其他的利益相關者，將繼續反饋下去。
持續反饋的目的是，對生成的程式碼進行驗證，對與其他開發人員還
有其他應用元件的程式碼所整合的程式碼進行驗證，確保其功能與效能表現
符合設計預期。一旦應用部署到生產系統，對應用進行監控以確保其功
能及效能在生產環境中按照設計要求執行，如同終端使用者使用時一樣，
這也是持續反饋的目標。持續反饋是實現持續改進與提高質量的必要條
件，也是戴明 PDCA 迴圈的核心，因為其能夠提供相應的資訊輸入，以
決定要改變什麼以及如何行動。
注意： 沒有持續反饋，持續整合與持續交付 ( 幾乎 ) 沒有任何意義。
不進行持續的測試與監控，就無法瞭解應用在生產環境中的執行狀態，
整個 DevOps 流程也就沒有了實際意義。如果不滿意使用者開出的投訴單
是發現應用功能或效能低於標準的唯一方式，那麼擁有無縫的持續交付
流程該有多好！
要實現持續反饋，需要兩項 DevOps 實踐：持續測試與持續監控。
持續測試 持續測試是在應用交付流水線的每個階段實施應用、環
境以及交付流程測試的能力。測試專案與測試型別可以根據交付生命周
期的不同階段而進行更改。如果正確地執行，持續測試實際上與持續集
成及持續交付流程緊密相關。下面介紹其具體的運作模式。
開發人員獨立編寫程式碼。他們正在進行的其中一些工作任務(工作
項)可能包括：修復缺陷、新增新效能、增強功能或提高程式碼執行速度。
完成後，他們自己執行單元測試，然後交付程式碼並與團隊中的其他人員
開發的程式碼連同未做更改的程式碼進行整合(持續整合)。整合完成後，對
整合程式碼進行單元測試。他們也可能執行其他的測試，比如白盒安全測
試、程式碼效能測試等。之後，工作會交付到團隊級別的公共整合環境，
將專案與構成服務、應用或開發系統的所有程式碼元件的所有團隊的工作
進行整合。
這是持續整合流程的本質。為整合簽入程式碼的時候，單個開發人員
的程式碼會與團隊的程式碼進行整合，這使得流程得以持續進行。這裡要注
意的重點是持續整合流程的目標：驗證是否所有級別上的程式碼整合都準
確無誤，並且所有測試都是由開發人員準確執行。因此，確切地說，持
續測試始於開發人員。
在確認完整的應用(服務或者系統)構建無誤之後，應用交付到測
試區域。將開發環境的程式碼交付到測試環境是持續交付的第一個重要步
驟。當開發人員將程式碼交付到團隊的整合空間以及專案的整合空間時，
持續交付就開始了，但這僅限於開發空間內部，沒有新的目標環境。
當交付到測試時，我指的是從一個環境到另一個環境的完整遷移。
測試有自己的環境來執行功能與效能測試套件。 DevOps 原則要求的是
類生產環境。此外，測試每次執行測試套件時也可能需要新的資料集。
由於持續整合會導致持續穩定的交付構建，每天可能一次或多次出現這
種需求。這意味著持續交付不僅要求從開發到測試的程式碼遷移流程，還
需要重新整理或提供新的測試所需的類生產環境，並且使用正確的配置及相
關測試資料執行相應的測試。這使得持續交付流程更加複雜，而非僅僅
是程式碼複製。需要特別注意的一點是，持續交付的目標是為測試及釋出
準備程式碼，並持續不斷地將應用部署到合適的環境中，以便應用得以進
行持續測試。
如果將此處描述的流程擴充套件到將服務、 應用或者系統交付至部署
環境及最終生產環境的過程中，那麼其過程和目標也是相同的。在將
應用交付到必須盡全力保障穩定的生產環境之前， 運維團隊希望執行
自己的一系列冒煙測試、驗收測試和系統穩定性測試。這個過程是利
用部署環境完成的。如同測試環境一樣，部署環境也是需要配置的一
個類生產環境。運維人員執行驗收測試與效能測試，也需要必要的腳
本及測試資料。只有完成最終階段的持續測試後，應用才會進行生產
上線。因此，持續交付流程同樣執行獲取部署與生產環境以及交付應
用的任務。
深入研究這一流程，發現持續測試是透過測試應用與環境的所有方
面得以實現的，其中包括但不限於以下方面：
● 單元測試
● 功能測試
● 效能測試
● 整合測試
● 系統整合測試
● 安全測試
● 使用者驗收測試
在持續測試中，最大的挑戰是執行某些測試所需的應用、服務以及
資料來源都是不可用的，或者即使可用，相關的使用成本也會使測試無法
持續執行。此外，用以支援並行開發多個應用的所有團隊的大型測試環
境，其維護成本也非常高。
引入被稱為“測試虛擬化”的實踐(如圖 1-5 所示)，可以解決這個
問題。該實踐利用虛擬化的樁程式碼取代了在測試期間必須與應用進行通
信與互動的實際應用、服務以及資料來源。這些虛擬化的環境使應用的功
能、整合以及效能測試得以實現，而不需要呼叫整個生態系統。這種虛
擬化的方式可以用來執行此前所述的各種型別的測試。

圖 1-5 測試虛擬化案例
談到 DevOp 情境下的測試， 除了持續測試， 還有測試前移實踐(Shift
Left，在價值流圖中流的前端在左側)，本章後面 1.3.4 節“前移”會進
行詳細說明。
持續監控 在生產環境中，運維團隊透過持續監控來管理並確保應
用執行符合預期。運維團隊有自己的工具來監控環境以及執行系統。最
終，從流程級到系統監控工具所不允許的更低階別，運維團隊需要保證
應用都能正常執行。這就要求運維團隊使用能夠監控應用效能及異常的
工具。可能還需要與開發人員合作，將自監控或分析收集功能植入到所
構建的應用中。這就實現了真正的持續的端到端監控。
隨著這一領域中技術的發展，出現了相應的工具與服務，可以用來
監控應用的表現以及使用者情緒，為開發人員及業務線提供有用的、詳細
的反饋。
簡而言之，持續監控需要獲取並分析以下四個方面的衡量指標：
● 應用效能
● 系統效能
● 應用使用者行為
● 使用者情緒
然而，運維團隊不僅要收集這些資料，而且還要對其進行分析，這
是非常必要的。此外，反饋必須要讓其目標受眾能夠接受並應用，無論
目標受眾是技術性強的運維人員，比如效能工程師，還是非技術性的業
務線利益相關者。資料能用才有價值。好的資料，資料分析就更具意義，
可以實現真正的持續改進，因為交付流水線中從業務線到開發人員、測
試人員的各級決策都是由資料驅動的。
反饋的前景是可預見的
隨著 IBM 的沃森認知功能的出現，在反饋資料預測性分析領域中，
反映出巨大的市場潛能。現在有關使用者行為、應用行為以及系統行為的
資料都可以進行分析，利用認知技術，從系統故障到使用者行為 ( 高興或
不滿意 ) 的各種預見性結果都能交付。預測分析可以使業務部門提前採
取行動，防止產生當機以及使用者不滿意。
3. 持續業務計劃
持續業務計劃的 DevOps 實踐關注的是業務線及其計劃流程。企業
需要敏捷以及快速響應客戶反饋。為了做到這一點，而今的許多企業
都採用了精益思維技術。這些技術包括，透過識別測試業務願景或價
值所需的成果與資源來啟動小規模業務，然後根據客戶反饋不斷進行
調整。
為了實現這些目標，組織要衡量當前的基線狀態，找到客戶真正想
要的，然後透過更新業務計劃來相應地調整方向，使其能夠在資源受限
的環境中不斷做出權衡決策。
利用精益創業運動所推廣的，以及埃裡克·萊斯(Eric Reis)在其著
作《精益創業》中所描述的那些技術，領域內已經開展了很多工作。在
想要開拓新市場以及嘗試新業務模式，卻不想為了向這些新領域提供
複雜的 IT 系統而制定完整計劃的企業中，像萊斯在其著作中所介紹的
提供最小可行產品這類的技術已經廣泛流行。這個問題將在第 4 章進行
詳細討論。
最近增加的功能庫不僅可以確保交付成果的正確構建，而且還能確
保構建正確的交付成果，這就是設計思維。與精益和敏捷一樣，設計思
維已經在工業產品設計的各個發展階段應用了幾十年。彼得·羅(Peter
Rowe)1987 年出版的著作《設計思維》使其成為主流。設計思維最近才
應用於 IT 領域，特別是專注於使用者體驗的應用設計方面。第 4 章將對
設計思維進行詳細討論。
4. 協同開發
協同開發是由 IBM 推出而流行的，主要作為協同生命週期管理
(Collaborative Lifecycle Management，CLM)工具套件所支援的一種實踐。
這種實踐對於確保具有大型分散式團隊的組織實現跨職能部門操作人
員以及跨筒倉團隊之間的協作與可見性是必不可少的。這可以透過確保
跨交付流水線的兩項功能來實現：
● 提供給操作人員的訪問許可權與可見性，不只是針對相關功能領
域的構建物、工作項以及衡量指標，而是應該針對所有的功能
領域(當然，訪問許可權是根據角色及安全需要進行管理的)。
● 構建物在操作人員或團隊間進行無縫遷移。這有可能跨越功能
邊界，不需要對構建物進行任何編譯或轉換，以避免損耗。
這些功能只能透過交付流水線上的操作人員及團隊使用整合工具
套件來實現。
如果將 DevOps 視作一項文化運動，促進溝通、協作與信任是為之
努力的核心原則，那麼也可以將協同開發視為 DevOps 的核心能力。讓
操作人員之間使用統一的工具(不是電子郵件)進行溝通，是促進溝通、
協作與信任的最佳途徑。
這可以利用諸如 Slack 或 Rational Team Concert 這樣的流行工具來
實現。利用工作項間的工具協作，促進操作人員之間彼此轉移工作項、
新增註釋、附加程式碼變更集，並實現對其他團隊成員曾經從事或是正在
進行的對本身工作產生影響的專案視覺化，能夠進一步促進協作。
談到可見性，沒有什麼比可見性更能促進信任的。如果測試人員對
開發人員正在進行的單元測試具有可見性，開發人員就知道如果沒進行
適當的單元測試，就不可以提交程式碼。
注意： 完全的可見性驅動全面的信任。
在我們公司，將不再要求填寫費用報銷單。你可以任意消費，
而我們都會報銷。不問任何問題。唯一的要求就是把收據放到開放
的維基頁面，而公司的每一位員工都可以看到這個頁面。相信我，
你會明智地消費。
—— 矽谷初創公司 CEO
1.3.4 前移
前移也是一個源於精益的概念。這裡的基本思想是將生命週期中影
響質量的任務儘可能提前，以此來提高質量。這是貫穿整個生命週期的
活動。潛在的前提是，越早發現質量問題，就能越早識別問題產生的根
本原因並解決。
注意： 測試領域有一個眾所周知的原理：在需求階段發現並修復一
個缺陷或問題如果需要花費一美分，那麼在開發階段修復同樣的問題則
需要花費十美分；在測試階段要一美元，在生產環境則需要十美元 (Rice ，
2009) 。
當然， 這些都是說明性的數字， 並不是基於對實際成本的統計分析。
然而，邏輯是正確的。前移能識別缺陷與問題的任務，可以節省成本並
提高質量。
從 DevOps 文化角度來看，也可以將前移視作一種方法，透過讓原
本處於流水線後端的相關功能人員在生命週期的早期參與進來，促進協
作與溝通。
DevOps 還是婚姻諮詢？
我已經被架構師邀請去見他一個客戶的開發總監及運維總監。我們
共進午餐，架構師和我坐在桌子的一邊，兩位總監坐在另一邊。我立刻
就知道他們的情況不太妙。他們彼此分開坐著。開發總監抱怨運維人員
有多不敏捷，而運維總監說開發人員交給他們的都是垃圾，把伺服器弄
崩潰了都無法執行。他們甚至在談論對方的時候看著自己的手。我感覺
我是在做婚姻諮詢。
我推薦給他們的解決方案是從小處著手，將運維工作前移。他們的
主要挑戰是在部署到生產環境之前，開發團隊和運維團隊之間完全沒有
可見性。我的建議是選擇一個關鍵專案，每週一次，由運維團隊指派
一名成員參加開發的每日例會，只需要聽不需要參與，看看情況是否
有所改善。不到三個月後，在一次會議上遇到了兩個總監，我進行了
跟蹤。他們很高興地說，運維人員現在出席每日例會，不只是聽，而
且還積極參與，分享他們的進展、計劃和困難。運維管理已然前置。他
們實現了協作。
為了最大限度地提升質量，有兩個主要方面需要在交付流水線中進
行前移。
1. 測試前移
測試人員從需求階段就開始參與，可以使其更清楚需要測試的內
容，相反，他們也可以確保所編寫的需求都是可測試的。然而，我們的
目標是在生命週期的早期開始測試。 在工業領域越來越重視“前移測試”
實踐，所有的精力都用於確保在生命週期早期進行整合測試。雖然前移
生命週期中其他形式的測試(如之前“持續測試”部分所述)也很重要，
但是整合測試前移的意義最為重大。
當團隊實踐持續整合時，測試那些整合點以儘早識別整合及架構缺
陷對質量存在重大影響。如果在整合時無法與其他服務及元件互動，那
麼擁有完美功能及效能的服務或元件又有什麼用處呢？為了能夠在生
命週期的早期進行整合測試，測試虛擬化成為必要前提，因為完成測試
需要的所有服務或元件屆時可能都不可用。測試虛擬化利用虛擬例項為
無法獲得的服務打樁，使整合測試以及其他測試得以在生命週期的早期
進行，從而實現測試前移。要實現眾所周知的“儘早測試、頻繁測試”
的目標就需要前移測試。
2. 運維前移的關注點
正如本章開頭故事所描述的，運維團隊通常被視作交付生命週期中
的一個單獨筒倉。他們通常在專案開始時加入，運維需求確定後就會離
開，直到交付生產環境之前開始準備運維的時候，運維人員與開發人員
之間都沒有相互聯絡。運維人員在生命週期的早期加入並參與開發-測
試周期，可以防止由於運維參與較晚而在部署到生產環境的過程中出現
困難。運維人員儘早參與，會使他們清楚交付的內容及其可能導致的運
維環境變化，因為需求有可能會偏離設計的狀態。
運維人員儘早參與，也有助於確保開發-測試期間所部署的開發及
測試類生產環境確實與真正的生產環境類似，而沒有偏離。最後，運維
人員的儘早參與還能確保開發團隊所開發的部署流程及程式可以為運
維團隊所用。在 DevOps 出現之前，在釋出週末進行生產部署時最大的
挑戰之一就是運維人員此前從未使用或測試過這些部署流程。程式碼部署
到非生產環境時，要利用與運維團隊相同的流程及程式，儘早並且頻繁
地對這些流程進行反覆測試，確保其在生產環境中也可以正常執行。
前移的一個重要影響是使操作人員的角色發生變化。這些變化隨著
時間的推移悄然發生，涉及所需技能以及最終的流水線人員分配時卻帶
來了意想不到的結果。
隨著職責的前移，操作人員的角色從執行者轉變為服務供應商。測
試人員可能不再是進行測試的人，轉而成為自動化測試供應商，開發人
員透過自助服務完成測試。同樣，對於運維人員來說，他們不再執行構
建、配置以及伺服器的釋放，取而代之的是構建伺服器映象、管理服務
器例項並對問題做出響應。開發人員、測試人員及其他操作人員，利用
運維團隊提供並管理的自助服務，根據需要提供、配置並釋放伺服器實
例。這就提高了測試人員和運維人員工作的抽象性，進而影響所需的技
能以及資源數量。
1.3.5 架構與降低風險
架構思維
在 20 世紀 90 年代中期加入 Rational 軟體公司的時候，我在思想中
開始關注架構。隨著“ UML 三友”， Grady Booch 、 James Rumbaugh 和
Ivar Jacobson 開發出 UML 理論以及 Philippe Kruchten 開發出 4+1 軟體
架構檢視模型 (Kruchten ， 2002) ，架構思維滲透到我的血液裡。
為了實現 DevOps 的全部承諾，架構終於開始在應用交付領域獲得
所需的關注。你無法透過大型的單片系統實現持續交付。架構重組在
DevOps 早期曾被嚴重忽視，而今卻成為主流，這主要歸功於微服務的
發展(或稱之為 12 要素應用 ⑥ )。當關於微服務能否真正為每種應用交付
價值的爭論還在進行的時候，微服務所受到的關注已經再次引發對於架
構的關注需求。如果真正瞭解 12 要素應用，會發現其對於 Web 應用以
及軟體即服務的關注是顯而易見的。沒有昂貴的程式碼及資料重構，它們
不可能為大型的、複雜的、資料龐大的遺留應用及系統帶來附加價值。
只有當那些系統現代化到雲原生應用時，這種投資才是可行的和必要
的。微服務以及 12 要素應用將在第 5 章進行深入討論。
無論是否使用微服務，實現持續交付所需的架構轉換使變更得以按
照小批次進行交付，從而縮小了批次規模。“批次”指的是在每個週期
或迭代中所交付變更的數量。這些變更包括構成開發到運維完整週期的
所有程式碼、配置、基礎設施、資料、資料模式、指令碼、部署流程等的變
更(記住，並非每次都將所有的變更部署到生產環境)。縮小批次規模必
須做到以下幾點：
● 降低風險
● 提高質量
● 實現更快交付
這些好處是不言而喻的。在提高速度的同時，管理風險與質量最有
⑥ 。
效的方法是在每次迭代中縮小批次規模。這是一種思想轉變，要轉向更
小規模、更頻繁的新版本交付。批次規模縮小時，每一個週期中要進行
的測試及驗證就會更少；部署也會更少；而且，因為變化較少，風險也
會隨之降低。即使識別出挑戰或問題，其影響也僅限於小批次內部，通
過修復或回滾可能更容易地降低風險。
1.3.6 持續改進
最終， DevOps 的核心在於實現持續改進。不管你起點在哪裡，處
於什麼成熟度水平， DevOps 實施都不是一次性的工作，而是需要持續
不斷的努力。正如彼得·聖吉(Peter Senge)在 20 世紀 90 年代所展望的
那樣， 最終的目標是成為學習型組織(David A. GarvinAmy C. Edmondson,
2008)。在 DevOps 背景下，學習型組織是要不斷地從剛剛交付的內容中
學習並持續改進。改進的是什麼？有以下三個方面可以改進：
● 應用。 剛剛交付的應用變更，其功能與效能是否符合預期？從
持續反饋中學到了什麼可以用於下一次迭代中的應用改進？
● 環境。 應用執行的環境，其效能及表現是否符合預期？是否滿
足服務水平協議(SLAs)的要求？從持續反饋中學到了什麼可以
用於下一次迭代中的環境改進？
● 程式。 可以從操作人員或利益相關者的經驗中學到什麼可以用
於下一次迭代中的交付流程改進？
雖然大多陣列織都致力於不斷改進所交付的應用，但就真正的衡量
指標而言，很少有組織會像持續改進執行環境那樣嚴格。擁有持續改進
交付流程相應方案的組織就更少了。儘管精益運動以及相應變異形式，
如敏捷 Scrum 方法還有廣泛的精益創業， 已經完成成為學習型組織或團
隊所需要的相應構建，並且在流程層面上不斷改進，但情況就是如此。
1.3.7 衡量標準
無法衡量，便無法管理。
—— 據說源自彼德 · 德魯克 (Peter Drucker)
無論彼得·德魯克是否說過這句話，或是這種說法是否準確(Kaz，
2013)，事實上，為了管理並持續改進某件事情，就必須能夠測量一些關
鍵的指標：關鍵績效指標(Key Performance Indicator， KPI)。既要有這些
關鍵績效指標的衡量基線來標識初始狀態，也要有持續的衡量標準以確
認是否有所改進。不僅要從積極的方面評價進展，還需要了解背後原因
及影響要素，即什麼行為導致了關鍵績效指標的改進。如果對人員與流
程進行了一些改變，那麼弄清楚究竟是哪種變化導致了關鍵績效指標的
改進，這點至關重要。
1.3.8 業務驅動
要知道哪些指標需要衡量與改進，就必須瞭解業務驅動。所要追求
的是什麼樣的業務影響？組織若要投入 DevOps 實施變革，瞭解需要處
理的業務驅動是前提。這有助於確定衡量指標，進而確定所要關注及投
入的能力。僅僅關注速度意味著對世界的看法是非常短視的。
作為醫療器械製造商，對於我們而言，質量比速度更重要。我
們寧願推遲裝置釋出，也不要發生必須召回產品的情形。可以想象，
召回已經安裝的起搏器對於任何人來講都不是一件好事。
—— 醫療器械製造商測試總監
什麼樣的關鍵績效指標或衡量指標需要評價並努力改進呢？如前
所述，這完全取決於業務驅動。業務線要求 IT 組織進行哪些改進？ (即
使在同一組織內部，不同的業務線也會有不同的要求)。是速度、質量、
敏捷性、創新能力還是成本降低？是更高層次的要求，例如部署新的業
務模式或是佔領新市場的能力？還是更低層次的要求，例如減少平均故
障間隔時間(Mean Time Between Failures， MTBF)、改善平均修復時間
(Mean Time To Resolve， MTTR)，或是降低程式碼缺陷密度？能否利用 API
開發合作生態系統？是否縮短了 IT 交付新應用所需審批的處理時間？
是否能透過參與開源專案吸引更多技術人才？(眾所周知，向開源專案
貢獻程式碼的都是很厲害的公司)。
這是一套 DevOps 核心衡量指標子集， 是 IBM 的一個部門用來衡量
DevOps 實施影響的。下述所列的這些衡量指標，均是根據這個團體需
要施以影響(投放市場的速度、市場份額以及提高所交付產品的利潤率)
的業務驅動而確定的。
● 專案啟動
● 清理積壓
● 總體開發時間
● 綜合構建時間
● 冒煙測試(Build Verification Test， BVT)可用性
● 迭代測試時間
● 總部署時間
● 整體上線時間
● 釋出間隔時間
● 創新/維護佔用時間比率(百分比)
1.4 DevOps：文化
“每個人都對生產交付負有責任。”這是 T 恤衫上印著的口號。
我把它發給了所有人，甚至包括與專案關係不太密切的人。當然，
分配到此專案的分析師、設計師、開發人員、測試人員、運維人員
全部都有 T 恤衫。而企業架構團隊、應用架構團隊還有安全人員也
都發了 T 恤衫。專案管理辦公室 (PMO) 的人肯定要給。我給樓層管理
員發了一件，如果廁所壞了，工程師就要浪費 20 分鐘去另外一個樓
層，樓層管理員現在要為線上釋出的延遲負責。我給咖啡機維修工
發了一件，如果咖啡機出了問題，我們就得派實習生去星巴克買咖
啡，咖啡機維修人員現在就得為延期負責。我快遞給我們的 CFO 一
件。如果她不能在 12 月份管理好哪怕是其中一個外包商的預算與休
假，就像去年那樣，那麼她就造成了生產上線延遲。 CIO 得到一件，
以便讓我們的團隊遠離電子郵件氾濫。送給 CIO T 恤是想讓其不要
拖延技術審批。糟糕，如果我妻子沒能讓我相信那是個壞主意，我
應該會給出席公司野餐活動的每一位“重要他人”都發一件這樣的 T
恤衫。 DevOps 文化對於我就意味著朋友。
—— 一家大型保險公司副總裁對 DevOps 文化的定義
如前所述， DevOps 核心是文化運動。那麼，你如何改變文化呢？
最終，即使組織完成所有的流程改進及自動化工作，也只有克服了組織
內根深蒂固的文化惰性，才能夠成功實施 DevOps 文化。組織具有惰性，
本能地抗拒變化。改變並不容易，尤其是在大型組織中，這些組織的文
化經過多年的沉澱積累並潛移默化地影響著成百上千的操作人員。這些
人員，作為獨立個體，他們或許認可 DevOps 實施的價值，但作為一個
群體，他們就會抗拒變化，進而形成惰性。克服這種惰性是關鍵所在。
文化惰性可以透過以下表達方式表現出來：
“我們這裡就是這樣做的。”
“是的，但是要改變 X 不是我所能控制的。”
“我們的流程沒什麼不好，為什麼要改變？”
“你需要跟 Y 去談， 我們無法改變他人的工作方式。”
“管理層絕對不會允許的。”
“難道你不知道我們處在一個受管制的行業嗎？”
“DevOps 是這個月的新花樣。我們看看這項工作能持續多久。”
久而久之，組織發展出了行為規範；團隊和群體按照組織線劃分職
責分工； 以管理之名設立檢查平衡機制， 縱然這並非真正意義上的管理；
流程存在，卻沒人去思考其中的原因，只是視作“本來就有”；報告寫
出來已無人閱讀，卻沒人願意提出取消；以往發生的事故透過加強審批
防止其再次發生等。所有這些行為形成了組織文化的惰性。
實施 DevOps 需要什麼樣的文化呢？信任、溝通和協作缺一不可。
除非這種文化開始發展，否則單獨實施 DevOps 實踐無法培養出這樣的
文化， DevOps 實踐也不會根深蒂固並固化為組織的 DNA。這是先有雞
還是先有蛋的問題，需要共同努力去克服文化惰性。文化惰性可以透過
解決以下三個方面的問題來克服：
1. 可見性。本章前面用了很長的篇幅來討論這個問題，其價值不容忽
視。對必須共事的團隊以及操作人員缺乏可見性，不能確定他們在將構建
物移交過來之前都做過些什麼，這是導致彼此缺乏信任的最重要原因。
2. 有效溝通。在 DevOps 環境下，電子郵件及語音郵件不可以作為
溝通方式；專案計劃、狀態文件、幻燈片、電子表格也一樣。溝通需要
現場面對面地進行，而不是透過電子郵件、工作單或是透過管理手段進
行。操作人員不需要透過一連串的命令，就能夠根據需要與其他任何相
關的操作人員進行溝通。這些實時溝通應該取代電子郵件、狀態更新與
協作，並且應該流化。諸如 Slack、 HipChat、 Yammer 和 Wrike 這類工
具因此流行起來。
3. 通用衡量標準。除了此前所提及的，操作人員與團隊缺少適當的衡
量標準，是最容易導致惰性的原因。除非將新的、所期望的行為作為評價
標準，否則人們的行為是不會發生改變的。此外，為了實現真正的協作，
並形成每個獨立團隊都朝著跨越筒倉的整體目標而努力的意識，就要對所
有操作人員採用相同的成功衡量標準。開發、測試及運維需要有相同的，
或至少是相似的成功衡量標準。每一個人都必須對生產上線部署負責。
1.5 總結
DevOps 現在是主流。假設每個人都對 DevOps 的概念有著不同的
理解，在更為重要的如何實施問題上也沒有達成共識。非常遺憾，正確
的答案是“視情況而定”。確實如此。這取決於為之奮鬥的業務目標；
取決於實踐當前的成熟度；取決於組織能夠吸收的變化速度。為了實現
業務增值，必須採取變革，但不能以犧牲成本為代價。任何中斷都會導
致生產力下降，實施 DevOps 也定會如此。
實施 DevOps 也是一段旅程，首先要識別出 A 點(當前的狀態)與 B
點(業務目標)。一旦這些點確認完成，就可以繪製實施路線圖來實施本
章所介紹的正確實踐與能力(合適的方案)。如何繪製這樣的實施路線
圖？這是下一章的內容。

購買地址：