DEVOPS精要：業務視角（簡體書）

前 言

這是一本IT經理寫給IT專業人士、IT經理和IT管理層的書。這本書闡述 DevOps 時，並不是將 DevOps 作為一種與新的自動化工具、程序設計方法或技術相關聯的現象來說明，而是面向投身於信息技術的管理者來探究 DevOps 在管理領域的話題。

有別於其他 DevOps 書籍，本書通過結構化的方式來進行敘述（或許您會覺得過於結構化），試圖從一個基礎基本面來完整覆蓋 DevOps 全貌。這並不意味著這些敘述是停留於表面的，只是剛好足夠用來創建對這個嶄新領域的認知。“基本面”意味著構建以下的基礎內容： DevOps 的起源；其湧現的必然性；關鍵的先決條件及其在實踐中的反映；實踐本身及其背後所遵循的原則。這些都是我將要在本書中探討的。

儘管 DevOps 這個領域有著大量的文獻，但在我自己學習研究 DevOps 的時候，還真的找不到一本像這樣的書。我致力於對這個複雜卻又有趣的話題提供一個清晰、結構化且精煉的總結。我敢說，這本書裡沒有一句多餘的話，反過來說，所有必須要有的信息，也都在這裡。

我必須對我的家庭和朋友表達我誠摯的謝意。他/她們並沒有幫我寫書，幸運的是，他/她們的生活與 DevOps 這樣的事情沒有多少交集。然而，在我寫書過程中，從2017年7月直到12月，他/她們絕對受了不少罪，因為我就像人間蒸發了一樣，疏於響應他/她們的訊息，有時我甚至要求他/她們在晚上要保持安靜。

我也必須感謝我在 Cleverics 的同事。我和我所遇到過的最聰明的夥伴一起創立了現在的業務，這是我生命中最重要的一個決定。共同的目標與原則、自由的決策制定、對產出成果的責任以及當需要時隨時可以支援我的夥伴們，沒有這些，我不可能有時間以結構化方式來呈現我對 DevOps 的思路並將其提煉到本書之中。

最後，我想感謝我們的客戶，他/她們給我們提供了新的、令人興奮的待解決的問題，還有新的挑戰。他/她們持續提出對新的培訓、工作坊和沙盤模擬的需求，他/她們想要更多、更好的……他/她們簡直由不得我們原地踏步，驅動我們持續向前。

目 錄

01 什麼是DevOps 1

1.1 起源 3

1.1.1 敏捷軟件發展方法 3

1.1.2 管理基礎設施即代碼 7

1.1.3 這是必然的 11

1.2 定義 11

1.3 為什麼要實施DevOps？ 14

1.3.1 縮短市場響應時間 14

1.3.2 減少技術債務 19

1.3.3 消除脆弱性 20

1.4 歷史起源 23

1.5 常見誤解 25

1.5.1 DevOps是敏捷的一部分 25

1.5.2 DevOps是工具和自動化 28

1.5.3 DevOps是一個新的職業 29

1.6 小結 29

02 基礎 31

2.1 精益生產 31

2.1.1 關鍵事實 31

2.1.2 挑戰 34

2.2 敏捷 37

2.2.1 關鍵事實 37

2.2.2 挑戰 38

03 原則 41

3.1 價值流 41

3.2 部署流水線 45

3.3 一切都應存儲在版本控制系統中 49

3.4 自動化配置管理 50

3.5 完成的定義 51

3.6 小結 52

04 關鍵實踐 53

4.1 和傳統實踐的關鍵區別 53

4.1.1 發佈是日常活動 53

4.1.2 發佈是業務決定 55

4.1.3 一切都是自動化的 56

4.1.4 事件要立即解決 57

4.1.5 缺陷是立即被修復的 58

4.1.6 流程是持續更新的 59

4.1.7 像初創公司一樣行動 60

4.2 非同尋常的團隊 61

4.3 工作可視化 64

4.4 限制在製品（WIP） 68

4.5 減小批次大小 72

4.6 留意運維需求 74

4.7 儘早檢測並修正缺陷 76

4.8 管理的而不是受控的改善和創新 77

4.9 為創新提供資金 80

4.10 任務優先順序 83

4.11 持續識別、發掘並評估約束 85

4.12 小結 86

05 應用實踐 87

5.1 DevOps適用性及限制 87

5.2 COTS 93

5.3 架構演進 95

5.4 DevOps與ITSM 99

5.5 貨物崇拜 103

5.6 從當前所處位置啟航，反覆運算推進 104

5.7 以價值流為核心 107

5.8 小結 108

06 結語 111

附錄 113

附贈資源 119

IT管理方法不是一成不變的。如今，信息系統開發和運維所使用的方法明顯區別於幾十年前的。這些方法一直在演進，明天可能又會出現下一代基於新的知識、經驗和技術的方法。大多數時候，管理方法會基於某些基本的原理和假定，打磨之前已有的模型並使之體系化，逐漸地演進。但是，時不時也會出現一些非連續的情況，個別領先組織在信息技術的有效與高效應用上，已經大步向前邁出了重要的步伐。

IT管理從聚焦於IT系統，轉變為聚焦於IT服務的管理，就是一個很好的例子。如圖1.1所示，從2000年左右開始，對於管理的認識變化，使得領先者贏得了重要的競爭優勢。這些湧現出來的管理實踐，被先行者成功採納之後，成為了所謂的最佳實踐.有些最佳實踐進一步演進為被業界廣泛接受的做法，甚至對行業標準產生了影響。當然，也有些組織並沒有在工作中應用這些最佳實踐或標準，因為在那個時候，並非所有的經濟領域都顯著依賴於IT。

圖1.1 新實踐的湧現與使用

我們以IT服務管理為例來看一看。在20世紀80年代，這樣的想法開始出現：信息技術以服務的形式提供價值，並以流程的形式組織IT活動。有些歐洲公司成為先行者，他們發展出組織工作的新實踐及解決管理問題的新方法。其中有些實踐，例如服務臺的引入、事件和問題的區分、IT基礎設施變更的受控過程等，在2000～2001年的ITIL等重要出版物（那時ITIL代表IT基礎設施庫） 中清晰地闡述出來，使得這些實踐得以進入最佳實踐之列，開始引入它們的不光是領先者組織，也包括追隨者。最終，在2002年，BS 15000-1:2002 即IT服務管理的首個標準發佈，這為那些尋求構建一個連貫的IT服務管理系統的組織而言，建立了一個可以遵循的具體標準。也就是說，實踐、出版物和標準，都未曾停止過發展的腳步，如圖1.2所示。

圖1.2 實踐的發展

從敏捷軟件發展中，也可以觀察到類似的發展動態。然而，這次醞釀的革命所影響的範圍，已經超出了軟件發展本身，帶來的影響面不亞於當年的ITSM。

如今，新湧現出來的實踐，被打上DevOps（開發+運維）的標籤。實際上，DevOps的內涵，如同ITIL超出“庫”的概念以及COBIT超出受控物件的含義一樣，已經大大超出其原始的含義。

這麼說來，DevOps的現象值得研究。要想理解DevOps的完整要義，需要結合相關的背景來瞭解其思想連同與之關聯的運動。

1.1 起源

一般認為，DevOps的出現源於兩個因素：敏捷軟件方法的廣泛採用以及IT基礎設施即程式碼的管理方式。我們分別來看一看。

1.1.1 敏捷軟件發展方法

在20世紀末期，主流的軟件發展方法是圖1.3所示的所謂“瀑布模型”：順序式執行預定義的階段，每個階段花很長時間，並以達成先前協商好的結果作為結束；很多時候，只有在前一個階段已經完整且正式完工時，才能轉移到下一個階段。這個模型的另一個顯著特徵是，每個階段所涉及的人員職能有專業化的分工：分析師、架構師、開發人員和測試人員等。

當開發的是功能可預先定義、對快速產品交付沒有或很少有要求的大型信息系統時，這個模型能夠確保我們創建高質量產品並進行有效與精細的成本控制。

然而，在20世紀90年代末期，隨著互聯網技術與Web程序設計的快速發展，瀑布模型的消極作用開始顯現，影響到信息系統客戶（內部或外部業務）與提供者（內部或外部軟件發展者）之間的交互和理解。事實上，對業務客戶的市場機會不斷湧現，這要求團隊能夠快速發佈（最多在幾個月之內）新產品到市場上。然而，從項目啟動到第一個可運行原型的典型開發閉環，可能要花6到18個月時間；而在大型企業中，甚至需要2到3年。此外，隨著很多在之前並不為人知曉但有潛在前景的市場機會湧現，客戶的需求在開發過程中很可能會發生變化，這樣一來，要有效應對市場機會而不延誤截止日期，且同時還不降低產質量量，就變得極為困難，如圖1.4所示。