具體描述
本書共分為6 個部分：*一部分概述DevOps 的曆史和三個基本原則，即“三步工作法”；*二部分介紹開啓DevOps 轉型的過程；第三到五部分深入探討“三步工作法”的各個要素；第六部分關注如何將安全性和閤規性正確集成到日常工作中。全書涵蓋40 餘個DevOps 案例，以榖歌、、Facebook 等知名企業和組織的實際調查結果為依據，展示如何通過現代化的運維管理提升管理效率，進而為企業贏得更大市場、創造更多利潤。
本書適閤所有互聯網企業和傳統企業的從業者閱讀。
Gene Kim
Tripwire創始人、前CTO，IT Revolution創始人，DevOps企業峰會主辦人，書《鳳凰項目》閤著者。
Jez Humble
DevOps Research and Assessment公司CTO，加州大學伯剋利分校信息學院講師；曾任ThoughtWorks&席顧問。《精益企業》和Jolt大奬圖書《持續交付》的閤著者。
Patrick Debois
DevOps之父，緻力於通過在開發、項目管理和管理之中應用敏捷技術來填補項目和運維之間的鴻溝。
John Willis
Chain Bridge System創始人，曾任Docker公司布道師，現就職於SJ Technologies公司。
*一部分 DevOps介紹
*1章 敏捷、持續交付和三步法 4
1.1 製造業價值流 4
1.2 技術價值流 4
1.2.1 聚焦於部署前置時間 5
1.2.2 關注返工指標——%C/A 7
1.3 三步工作法：DevOps的基礎原則 7
1.4 小結 8
*2章 *一步：流動原則 9
2.1 使工作可見 9
2.2 限製在製品數 10
2.3 減小批量大小 11
2.4 減少交接次數 13
2.5 持續識彆和改善約束點 14
2.6 消除價值流中的睏境和浪費 15
2.7 小結 16
第3章 *二步：反饋原則 17
3.1 在復雜中安全地工作 17
3.2 及時發現問題 18
3.3 群策群力，戰勝問題獲取新知 19
3.4 在源頭保障質量 21
3.5 為下遊工作中心而優化 22
3.6 小結 22
第4章 第三步：持續學習與實驗原則 23
4.1 建立學習型組織和安全文化 23
4.2 將日常工作的改進製度化 25
4.3 把局部發現轉化為全局優化 26
4.4 在日常工作中注入彈性模式 27
4.5 領導層強化學習文化 27
4.6 小結 29
4.7 *一部分總結 29
*二部分 從何處開始
第5章 選擇閤適的價值流作為切入點 32
5.1 綠地項目與棕地項目 34
5.2 兼顧記錄型和交互型 35
5.3 從*樂於創新的團隊開始 36
5.4 擴大DevOps的範圍 37
5.5 小結 38
第6章 理解、可視化和運用價值流 39
6.1 確定創造客戶價值所需的團隊 40
6.2 針對團隊工作繪製價值流圖 40
6.3 組建專門的轉型團隊 42
6.3.1 擁有共同的目標 43
6.3.2 保持小跨度的改進計劃 44
6.3.3 為非功能性需求預留20%的
開發時間，減少技術債務 44
6.3.4 提高工作的可視化程度 47
6.4 用工具強化預期行為 47
6.5 小結 48
第7章 參考康威定律設計組織結構 49
7.1 組織原型 51
7.2 過度職能導嚮的危害（“成本優化”） 51
7.3 組建以市場為導嚮的團隊（“速度優化”） 52
7.4 使職能導嚮有效 53
7.5 將測試、運維和信息安全融入日常工作 54
7.6 使團隊成員都成為通纔 54
7.7 投資於服務和産品，而非項目 56
7.8 根據康威定律設定團隊邊界 56
7.9 創建鬆耦閤架構，提高生産力和安全性 57
7.10 小結 60
第8章 將運維融入日常開發工作 61
8.1 創建共享服務，提高開發生産力 62
8.2 將運維工程師融入服務團隊 63
8.3 為每個服務團隊分派運維聯絡人 64
8.4 邀請運維工程師參加開發團隊的會議 65
8.4.1 邀請運維工程師參加每日站會 65
8.4.2 邀請運維工程師參加迴顧會議 66
8.4.3 使用看闆圖展示運維工作 66
8.5 小結 67
8.6 *二部分總結 67
第三部分 *一步：流動的技術實踐
第9章 為部署流水綫奠定基礎 70
9.1 按需搭建開發環境、測試環境和生産環境 71
9.2 應用統一的代碼倉庫 72
9.3 使基礎設施的重建更容易 74
9.4 運行在類生産環境裏纔算“完成” 75
9.5 小結 76
*10章 實現快速可靠的自動化測試 77
10.1 對代碼和環境做持續構建、測試和集成 79
10.2 構建快速可靠的自動化測試套件 81
10.2.1 在自動化測試中盡早發現
83
10.2.2 盡可能並行地快速執行測試 84
10.2.3 先編寫自動化測試 84
10.2.4 盡量將手動測試自動化 85
10.2.5 在測試套件中集成性能測試 86
10.2.6 在測試套件中集成非功能性需求測試 86
10.3 在部署流水綫失敗時拉下安燈繩 87
10.4 小結 89
*11章 應用和實踐持續集成 90
11.1 小批量開發與大批量閤並 92
11.2 應用基於主乾的開發實踐 93
11.3 小結 95
*12章 自動化和低發布 96
12.1 自動化部署流程 97
12.1.1 應用自動化的自助式部署 100
12.1.2 在部署流水綫中集成代碼部署 101
12.2 將部署與發布解耦 104
12.2.1 基於環境的發布模式 105
12.2.2 基於應用的發布模式更安全 109
12.3 持續交付和持續部署實踐的調查 112
12.4 小結 113
*13章 降低發布的架構 114
13.1 能提高生産力、可測試性和安全性的架構 115
13.2 架構原型：單體架構與微服務 116
13.3 安全地演進企業架構 118
13.4 小結 121
13.5 第三部分總結 121
第四部分 *二步：反饋的技術實踐
*14章 建立能發現並解決問題的遙測 125
14.1 建設集中式監控架構 127
14.2 建立生産環境的應用程序日誌遙測 129
14.3 使用遙測指導問題的解決 131
14.4 將建立生産遙測融入日常工作 132
14.5 建立自助訪問的遙測和信息輻射器 133
14.6 發現和填補遙測的盲區 135
14.6.1 應用程序和業務度量指標 136
14.6.2 基礎架構度量指標 137
14.6.3 顯示疊加的指標組閤 138
14.7 小結 139
*15章 分析遙測數據以更好地預測故障和實現目標 140
15.1 用均值和標準差識彆潛在問題 141
15.2 異常狀態的處理和告警 142
15.3 非高斯分布遙測數據的問題 143
15.4 應用異常檢測技術 146
15.5 小結 149
*16章 應用反饋實現安全部署 150
16.1 通過遙測使部署更安全 151
16.2 開發和運維共同承擔值班工作 153
16.3 讓開發人員跟蹤工作對下遊的影響 153
16.4 讓開發人員自行管理生産服務 155
16.5 小結 159
*17章 將假設驅動的開發和A/B測試融入日常工作 160
17.1 A/B測試簡史 161
17.2 在功能測試中集成A/B測試 162
17.3 在發布中集成A/B測試 162
17.4 在功能規劃中集成A/B測試 163
17.5 小結 165
*18章 建立評審和協作流程以提升當前工作的質量 166
18.1 變更審批流程的危險 168
18.2 “過度控製變更”的潛在危險 168
18.3 變更的協調和排程 170
18.4 變更的同行評審 170
18.5 人工測試和變更凍結的潛在危害 173
18.6 利用結對編程改進代碼變更 173
18.7 消除官僚流程 176
18.8 小結 177
18.9 第四部分總結 178
第五部分 第三步：持續學習與實驗的技術實踐
*19章 將學習融入日常工作 180
19.1 建立公正和學習的文化 181
19.2 舉行不指責的事後分析會議 182
19.3 盡可能廣泛地公開事後分析會議結果 184
19.4 降低事故容忍度，尋找更弱的故障信號 185
19.5 重新定義失敗，鼓勵評估 186
19.6 在生産環境注入故障來恢復和學習 186
19.7 創建故障演練日 187
19.8 小結 189
*20章 將局部經驗轉化為全局改進 190
20.1 使用聊天室和聊天機器人自動積纍組織知識 190
20.2 軟件中便於重用的自動化、標準化流程 192
20.3 創建全組織共享的單一源代碼庫 192
20.4 運用自動化測試記錄和交流實踐來傳播知識 194
20.5 通過確定非功能性需求來設計運維 194
20.6 把可重用的運維用戶故事納入開發 195
20.7 確保技術選型有助於實現組織目標 195
20.8 小結 197
*21章 預留組織學習和改進的時間 198
21.1 償還技術債務的製度化慣例 199
21.2 讓所有人教學相長 200
21.3 在DevOps會議中分享經驗 201
21.4 傳播實踐的內部顧問和教練 203
21.5 小結 204
21.6 第五部分總結 204
第六部分 集成信息安全、變更管理和閤規性的技術實踐
*22章 將信息安全融入每個人的日常工作 207
22.1 將安全集成到開發迭代的演示中 207
22.2 將安全集成到缺陷跟蹤和事後分析會議中 208
22.3 將性安全控製集成到共享源代碼庫及共享服務中 208
22.4 將安全集成到部署流水綫中 209
22.5 保證應用程序的安全性 210
22.6 確保軟件供應鏈的安全 214
22.7 確保環境的安全 215
22.8 將信息安全集成到生産環境遙測中 216
22.9 在應用程序中建立安全遙測 217
22.10 在環境中建立安全遙測 217
22.11 保護部署流水綫 219
22.12 小結 219
*23章 保護部署流水綫 220
23.1 將安全和閤規性集成到變更批準流程中 220
23.2 將大量低變更重新歸類為標準變更 221
23.3 如何處理常規變更 222
23.4 減少對職責分離的依賴 224
23.5 確保為審計人員和閤規人員留存文檔和證據 226
23.6 小結 228
23.7 第六部分總結 228行動起來——本書總結 229
附加材料
附 錄 232
附錄1 DevOps的大融閤 232
附錄2 約束理論和核心的長期
衝突 234
附錄3 惡性循環列錶 235
附錄4 交接和隊列的危害 235
附錄5 工業安全神話 236
附錄6 豐田安燈繩 237
附錄7 軟件包産品 238
附錄8 事後分析會議 238
附錄9 猿猴軍團 239
附錄10 上綫時間透明化 240
參考資源 241
緻 謝 243
EXIN DevOps Professional認證備考
指南 & 模擬題① 245
...
鳳凰項目
作 者: (美)基恩·金 (Gene Kim),(美)凱文·貝爾(Kevin Behr),(美)喬治·斯帕福德(George Spafford) 著;成小留 譯 著作 定 價: 49 齣 版 社: 人民郵電齣版社 齣版日期: 2015年09月01日 頁 數: 362 裝 幀: 平裝 ISBN: 9787115403650●**部分
●第1章 9月2日，星期二
●第2章 9月2日，星期二
●第3章 9月2日，星期二
●第4章 9月3日，星期三
●第5章 9月4日，星期四
●第6章 9月5日，星期五
●第7章 9月5日，星期五
●第8章 9月8日，星期一
●第9章 9月9日，星期二
●第10章 9月11日，星期四
●第11章 9月11日，星期四
●第12章 9月12日，星期五
●第13章 9月15日，星期一
●第14章 9月16日，星期二
●第15章 9月17日，星期三
●第16章 9月18日，星期四
●第二部分
●第17章 9月22日，星期一
●第18章 9月23日，星期二......
內容簡介
金、貝爾、斯帕福德編著的《鳳凰項目(一個IT運維的傳奇故事)》講述瞭一位IT經理臨危受命，在未來董事的幫助和自己“三步工作法”理念的支撐下，很終挽救瞭一傢具有悠久曆史的汽車配件製造商的故事。小說揭示瞭管理現代IT組織與管理傳統工廠的共通之處，讓讀者不僅能對如何管理IT組織心領神會，更重要的是將以接近不同於以往的視角來看待自己的工作環境。
本書適閤所有互聯網企業和傳統企業的從業者閱讀。
(美)基恩·金 (Gene Kim),(美)凱文·貝爾(Kevin Behr),(美)喬治·斯帕福德(George Spafford) 著;成小留 譯 著作
基恩·金是Tripwire有限公司的創始人，他擔任公司CTO長達13年之久。在Tripwire公司，他一直熱衷於研究如何提高IT組織的效能。
凱文·貝爾創建瞭信息技術流程研究所，他擁有25年的IT管理經驗，為CEO和CIO們提供指導和建議。
喬治·斯帕福德是行業分析師，幫助IT組織更好地找到目標，明確必要條件，發現實現目標的方法。
用戶評價
我最近剛看完這本《鳳凰項目》，簡直被它深深地吸引住瞭。這本書用一種非常引人入勝的方式，講述瞭一個關於IT項目管理和團隊協作的傳奇故事。故事的主人公，一位項目經理，在接手一個瀕臨崩潰的項目後，如何一步步地探索和實踐DevOps的理念，最終帶領團隊走齣睏境，實現項目成功的全過程。我特彆喜歡書中對“瓶頸”概念的描繪，以及如何通過識彆和優化瓶頸來提升整體效率。這讓我聯想到瞭自己在工作中遇到的各種“攔路虎”，原來很多時候，問題的根源就在於我們忽略瞭流程中的關鍵節點。書中強調的“係統思維”也非常重要，它告訴我們要從全局的角度去看待問題，而不是隻關注局部。而且，作者在故事中穿插的那些關於“文化變革”、“授權賦能”以及“擁抱變化”的討論，都非常有深度。它不僅僅是一本關於技術和流程的書，更是一本關於如何構建高效團隊、如何激發個人潛力的書。我常常在想，如果我們公司也能像書中的“鳳凰項目”團隊一樣，建立起開放溝通、相互信任的文化，那將會有多麼大的提升。這本書的敘事節奏把握得非常好，既有緊張的情節，也有深刻的思考，讀起來既過癮又充滿啓迪。對於任何一個在IT行業工作的人來說，這本書都值得反復閱讀和細細品味。
評分這本書我已經讀完瞭，真的非常喜歡！它以一個生動的故事形式，將DevOps的理念和實踐巧妙地融閤在一起，讓我對傳統的IT運維模式有瞭全新的認識。書中的主人公們，麵對著一個個棘手的項目挑戰，通過引入DevOps的文化和技術，一步步實現瞭流程的優化和效率的提升。最讓我印象深刻的是，作者並沒有枯燥地講解理論，而是通過人物的對話、內心的掙紮以及團隊的協作，將DevOps的“流動”、“反饋”、“持續學習與實驗”等核心價值觀，如同血液般自然地滲透進故事的脈絡中。讀完之後，我感覺自己不僅僅是看瞭一個故事，更像是經曆瞭一場DevOps的實戰演習。那些書中反復提及的“三步流動”和“反饋循環”，在我腦海裏留下瞭深刻的印記，讓我開始思考如何在自己的工作中去落地這些理念。特彆是書中對“非必要工作”的識彆和自動化，以及如何打破部門之間的壁壘，建立起一個協同高效的團隊，這些都給瞭我非常大的啓發。這本書的語言風格也很親切，讀起來一點都不費力，就像在聽朋友講故事一樣，但故事背後蘊含的智慧卻是不容小覷的。對於任何想要瞭解DevOps，或者希望改善IT運維效率的讀者來說，這絕對是一本不可多得的寶藏。它用一種非常接地氣的方式，把一個看似高大上的概念，變得觸手可及。
評分說實話，在讀這本書之前，我對DevOps的概念一直有些模糊。但《鳳凰項目》這本書，就像一盞明燈，徹底照亮瞭我前進的方嚮。它沒有直接灌輸枯燥的理論，而是通過一個充滿戲劇性的故事，讓我深刻理解瞭DevOps的精髓。我最欣賞的是，書中並沒有將DevOps描繪成某種神秘的技術魔法，而是將其歸結為一種思維方式和文化實踐。它強調的是“流動”，是將工作流程可視化，讓信息順暢地傳遞；它強調的是“反饋”，是建立快速響應的機製，及時發現和解決問題；它強調的是“持續學習與實驗”，是鼓勵團隊不斷嘗試新方法，並在實踐中不斷成長。書中的主人公們，從最初的混亂無序，到後來的有序高效，這個轉變過程讓我看到瞭DevOps強大的生命力。特彆是書中關於“自動化”、“持續集成”和“持續交付”這些具體的實踐，雖然書中沒有深入的技術講解，但通過故事的鋪墊，我能感受到它們在提升效率、降低風險方麵的巨大作用。讀完這本書，我仿佛擁有瞭一套全新的工具箱，可以用來審視和改進我自己的工作方式。它讓我明白，DevOps不是某個部門的責任，而是整個IT團隊需要共同努力的方嚮。
評分我被《鳳凰項目》這本書完全徵服瞭！它巧妙地將DevOps的復雜理念，通過一個扣人心弦的故事呈現齣來，讓我仿佛置身其中，親身經曆瞭一場IT運維的蛻變之旅。書中的主人公，在麵臨一個岌岌可危的項目時，從最初的束手無策，到後來逐漸領悟到DevOps的核心精髓——“流動”、“反饋”和“持續學習”。我特彆著迷於書中所描繪的“三步流動”，以及如何通過識彆和優化流程中的瓶頸，來加速價值的交付。同時，書中對於“反饋循環”的強調，也讓我深刻認識到及時溝通和快速響應的重要性。它讓我明白，很多時候，問題的根源並非技術本身，而是溝通不暢、信息孤島等“人”的因素。最讓我印象深刻的是，書中並沒有迴避DevOps轉型中的挑戰和睏難，而是通過主人公們的實際行動，展現瞭如何剋服這些障礙，最終實現團隊的協同和效率的飛躍。讀完這本書，我感覺自己對IT運維的理解上升到瞭一個新的高度，也更加堅定瞭在工作中推行DevOps理念的決心。這本書的敘事方式非常生動，讀起來一點都不枯燥，充滿瞭智慧和啓示。
評分這是一本讓我大開眼界的好書！《鳳凰項目》以一種非常獨特的方式，將DevOps理念融入瞭一個引人入勝的故事之中。我之前總覺得DevOps是一個很抽象的概念，但讀完這本書，我纔真正明白它的核心價值。書中通過主人公們在麵對一係列棘手的IT問題時，如何運用DevOps的原則，一步步地將混亂的局麵轉化為有序的高效運作，這個過程真的非常震撼。我特彆喜歡書中關於“可視化工作流”的描寫，它讓我們看到瞭隱藏在日常工作中的“浪費”和“瓶頸”。而通過建立“反饋迴路”，團隊能夠更快地識彆問題，並及時進行調整，這極大地縮短瞭問題解決的時間。讓我感到驚喜的是，這本書並沒有僅僅停留在技術層麵，而是深入探討瞭“文化”和“領導力”在DevOps轉型中的關鍵作用。它提醒我們，技術工具固然重要，但沒有正確的文化和領導力的支持，DevOps的實踐將會舉步維艱。書中的人物塑造也很成功，他們的成長和轉變，讓整個故事更加有血有肉。讀完之後，我不僅對DevOps有瞭更深刻的理解，也對如何在自己的工作中推動變革有瞭更清晰的思路。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.coffeedeals.club All Rights Reserved. 靜流書站 版權所有