DevOps實施手冊 在多級IT企業中使用DevOps ( 簡體 字) |
| 作者：[美]Sanjeev Sharma 著 萬金 譯 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：清華大學出版社 |  3dWoo書號： 49328
詢問書籍請說出此書號！【缺書】
NT售價： 400 元 |
| 出版日：4/1/2018 |
| 頁數：340 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787302498261 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：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實施手冊-在多級IT企業中使用DevOps》提供了一套行之有效的、可重復使用的方案。
我曾幫助幾十家規模及成熟度各不相同、來自不同行業和地域的組織實施DevOps，《DevOps實施手冊-在多級IT企業中使用DevOps》中的這些方案均來自于我多年的實戰經驗。當我在IBM擔任DevOps技術銷售與實施全球首席技術官的時候，DevOps還處在初期發展階段，從那時起，我就前瞻性地看到了DevOps必將快速發展并日益成熟，會從初創企業的先驅實踐發展為大型企業的文化及技術變革。我是IBM的DevOps先驅及思想領袖，而且面對IBM的客戶時，我已成為DevOps的代言人。我研究了數百家客戶在整個組織或企業范圍內成功實施DevOps所做的工作與斗爭，并提煉出成功的模式，納入《DevOps實施手冊-在多級IT企業中使用DevOps》內容中。
在沒有很多文化記憶的小型集中式組織中，實施DevOps并不困難。即使在大型組織中，小型團隊，即眾所周知的兩個比薩團隊 ，也通常能成功取得DevOps所承諾的業務成果。在大多數組織中，都能見到這樣的付出與努力，而且多數都取得了成功。提取個人與獨立團隊層面的成功經驗，并將其推廣至整個企業，這是一項挑戰。就像組織中有一系列的小舞團。然而，這些舞團都是獨一無二的。有的跳薩爾薩，有的跳爵士舞，有的跳交際舞，還有其他一些人在跳我女兒稱為“嘻哈”的舞蹈。他們無法組合起來，并成長為一個可以在下半場演出，占滿整個體育場表演場地的龐大舞團，因為要做到這點，他們不僅需要相同的舞曲，還要統一舞蹈的表演形式。同樣，小型獨立團隊無法影響整個組織。這些團隊需要努力實現相關實踐、流程、平臺與工具的標準化以便復制給組織的其他團隊。
反過來，組織需要為DevOps實施建立適當的環境，這可以通過支持變革努力、改變僵化的遺留程序以及自上而下共同克服文化惰性來實現。
注意：自下而上員工導向的努力使得非常高效的獨立團隊能夠實施DevOps并茁壯成長；自上而下高層管理者導向的努力使這些個體的成功能夠推廣開來。
要推廣成功，業務的參與是必不可少的。IT組織的存在就是為了交付業務向其客戶交付商業價值所需要的能力。業務要求IT組織進行優化，要更加敏捷，適應變化，更具有響應力，利用更少的資源做更多的事情，更加高效，提高產能，更快速、更高質的交付，針對市場靈活應變，加速競爭，遵守不斷變化的監管與合規制度以及，當然也要縮減開支。
此外，還可能要求創新，以允許公司進入新的市場，實現指數增長，吸引并發展客戶群體，響應客戶需求以及縮減開支。這些要求(希望這些要求不是同時存在)是變革需求產生的驅動力，是實現DevOps實施效益的工作動機。
注意：實施DevOps不能僅僅因為它很炫酷，而是要基于業務上的原因。敏捷或速度的訴求是DevOps存在的第一性原理。在過去幾年里，DevOps的實施日趨成熟與廣泛，這反映出當今的市場動態和客戶期望。
因此，為了使IT經歷變革，這個變化必須要能夠改進并增強其能力，以交付業務能力并進一步改進及提升所交付的業務價值。業務與IT之間必須保持適度合作，以便IT實施DevOps所經歷的變革能夠通過適當平衡優化與創新來滿足業務最為迫切的需求。業務目標必須是驅動IT變革的原因，變革原因又會反過來驅動IT變革的方式。
《DevOps實施手冊-在多級IT企業中使用DevOps》將DevOps實施方案分為以下幾類：
● 優化DevOps
● 創新DevOps
● DevOps實施的企業級推廣
● 驅動企業的DevOps實施
其中包括了每一項實施方案的經驗教訓、案例、成功模式以及反模式。就像體育運動隊的戰術手冊一樣，《DevOps實施手冊-在多級IT企業中使用DevOps》旨在提供適用于不同情境及形勢的特定方案(具體取決于組織當前的成熟度及狀態)，供組織通過實施DevOps向更高績效的交付組織轉型時使用。組織需要采用這些方案，并基于DevOps實施項目與團隊的實際情況策略性地執行。正如與敵人交戰必須要有作戰計劃一樣，實施這些方案必須要有相應的行動計劃或者使用更為廣泛的為每個組織設計的實施路線圖。
此外，任何組織在本質上都不是統一或同質的。組織中的某個部分或許在某些領域更加成熟，而在其他領域則不夠成熟。同在一個組織內，有時甚至是同在一幢建筑物內，一些團隊或群體或許已經實現了敏捷與速度，而其他團隊則可能正經受嚴重的文化惰性；他們都需要相互合作以實現規模效應。
組織可能已經擁有應用現代化敏捷與DevOps實踐的創新實驗室，但核心系統團隊可能仍在進行僵化的瀑布式交付。因此，針對同一組織中的不同部分，要應用不同的實施模式，而且要根據不同團隊的需要進行定制化調整。為了幫助組織實施這種定制化調整，《DevOps實施手冊-在多級IT企業中使用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實施手冊-在多級IT企業中使用DevOps》中將利用大量篇幅來討論的，實施DevOps有各種不同的方法，每個組織應該基于各自的風險值與業務驅動的平衡去選擇適當的實施能力與DevOps實踐。事實上，DevOps實施需要先從試點項目開始啟動，然后利用《DevOps實施手冊-在多級IT企業中使用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實施手冊-在多級IT企業中使用DevOps》讀者對象
體育運動隊中不是只有比賽當天上場的運動員們，還包括教練、助理教練、團隊管理者、團隊高層、培訓師、醫生、營養師、物理治療師、器械經理再到運球人員及供水服務員的所有這些人。團隊要想發揮出最佳水平，所有這些人都是必不可少的，而且每個人都需要在各自的角色中出色發揮，并作為一個團隊有效合作。同樣，DevOps也不僅僅關乎開發與運維人員，它要求應用交付流水線中的所有利益相關者都要改變其工作方式、協作與溝通的方式，以及像高績效團隊一樣有效合作的方式。
《DevOps實施手冊 在多級IT企業中使用DevOps》是寫給組織中的所有團隊成員的，他們是應用交付流水線中的利益相關者，從業務線負責人，到分析師、架構師、設計師、開發人員、測試人員、自動化工程師、基礎設施工程師、運維人員、數據庫管理員、系統管理員、文檔編寫人員、項目經理、產品負責人，一直到高層管理者，都包括在內。這些角色可能因組織而異，組織實施DevOps時，還需要對很多角色的工作內容以及工作方式進行完善與調整。《DevOps實施手冊-在多級IT企業中使用DevOps》旨在讓所有這些人受益。
實施所討論的每個方案都會對不同角色的利益相關者產生不同的影響，有些利益相關者可能會在角色以及與他人交互的方式上發生重大改變，有些人則看不到任何變化。所有的運球人員以及供水服務員通常都不會受到球隊戰術的影響，但是他們仍然是利益相關者，如果表現不符合預期，是會影響到球隊的整體績效的。IT的支持性角色亦是如此。其他角色，比如直接利用構建物及流程開展工作的關鍵利益相關者，他們是應用交付流水線的組成部分，將從《DevOps實施手冊-在多級IT企業中使用DevOps》所列方案中明顯受益。他們是方案執行人員，是為方案執行人員或支持人員提供直接支持服務的員工，以促進執行人員實現最高績效能力。
第1章是DevOps的概述，介紹了DevOps從起源到今天的發展演變。其中定義并描述了構成DevOps的所有常見的實踐與能力，為更廣泛地定義DevOps以及DevOps變革奠定了基礎，DevOps變革是《DevOps實施手冊-在多級IT企業中使用DevOps》的主題。
第2章聚焦于球隊的領導者：教練、隊長以及組成團隊核心的高級球員。重點關注的是如何評估比賽條件以及競爭對手，以開發并選擇合適的戰術集，即團隊的戰術手冊。應用到IT管理中，指的是項目經理、產品負責人、團隊領導、資深從業人員、DevOps教練以及渴望成為其中一員的任何人。
第3章就如何為DevOps變革創建商業案例，以取得適當的支持與投資來確保成功，提供了相應指導。
第4章到第6章是真正的方案。具體內容分為：
● 第4章——用于優化的DevOps方案：通過消除浪費，優化應用交付流水線以實現效率最大化的方案。
● 第5章——用于創新的DevOps方案：使應用交付流水線更加快速、敏捷以支持實驗能力，驅動創新的方案。
● 第6章——用于DevOps企業級推廣的DevOps方案：在大型、復雜、分布式且成熟度不統一的組織中，將DevOps實施在整個組織范圍內推廣的方案。
第7章是獻給驅動DevOps實施的高層管理者的。就如同體育運動隊的總經理或高級管理者，高管們做出行政決策，確定組織的方向與文化。他們是需要做出DevOps變革決策的人。他們需要為變革提供必要的投資與支持。他們還需要了解如何創建商業案例以確定變革的投資回報率。他們需要推動變革，從前沿試點團隊直到整個組織。
《DevOps實施手冊-在多級IT企業中使用DevOps》還有一個附錄。是一個DevOps變革實施路線圖的案例，是為假想的銀行開發交付價值流圖實踐。
《DevOps實施手冊-在多級IT企業中使用DevOps》試圖有意保留工具與平臺的兼容性。盡管書中列舉了一些工具、平臺以及技術作為例子，無論是商業化的還是開源的，但這都是一些目前市場上可用于實現自動化的工具及平臺。要實現流程自動化，使其高效、可重復、可擴展并且準確無誤，工具必不可少。然而，工具和平臺都是不斷發展變化的，取而代之的是更新更好的版本。因此，推薦甚至記錄現有的工具和平臺是徒勞之舉。我們的目標是強調能力，同時盡可能保持工具與平臺的兼容性，即便現有的工具與平臺仍在不斷改進。
體育運動的比喻
正是由于個人對于集體做出的貢獻，團隊、公司才能夠運行，社會、文化才得以發展。——文斯·隆巴迪，美式橄欖球傳奇教練
沒有什么比體育運動更能超越文化、語言及地理的界限。如果有所懷疑，只要再看一遍里約奧運會的重播即可。來自體育項目的比喻也完全適用于應用的開發與交付，因為二者都是團隊活動。開發或交付新的應用或服務，可能不要求奧運會金牌得主的體能訓練，但一定需要領導力、溝通、協作以及信任，這是任何一項團體運動都需要的。
我個人對運動也極富熱情。從小就是在一個熱愛運動的家庭中長大的。我的外祖父是印度的奧運級及國家級體育選手，他年輕時曾效力于印度國家曲棍球隊，后來在1952年赫爾辛基奧運會上擔任印度國家足球隊的體育主管。1964年的東京奧運會，火炬傳遞經過印度時，他還擔任了奧運火炬手。此后的幾十年間，包括我的童年時期，他一直是國內足球聯賽的體育主管。在家中伴隨著奧運火炬長大，使我們都很尊重運動員及婦女。
書中我列舉、引用了多個運動項目的運動員與教練的經驗，并將其映射到DevOps實施中。這種類比旨在使方案更加貼切易懂，并希望能夠提升閱讀的趣味性。
|
內容簡介：《DevOps實施手冊-在多級IT企業中使用DevOps》展示了如何：
● 理解DevOps的要素與能力
● 應對多級IT環境的挑戰
● 識別出可以與DevOps相互匹配的大型企業的商業目標
● 在大型企業的IT環境中實施DevOps
● 在低成本、低風險的前提下實現高價值的創新與優化
● 通過更高效的產品發布超越業務目標
● 在從大型機、移動設備、容器、微服務到云計算的多重技術棧中應用DevOps |
目錄：第1章DevOps概述1
1.1DevOps：起源2
1.2DevOps：本源4
1.3DevOps：實踐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.4DevOps：文化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.2IT組織69
3.4價值主張70
3.4.1業務線70
3.4.2IT組織72
3.5渠道通路74
3.5.1業務線74
3.5.2IT組織75
3.6客戶關系75
3.6.1業務線75
3.6.2IT組織75
3.7收入來源75
3.7.1業務線76
3.7.2IT組織76
3.8核心資源76
3.8.1業務線76
3.8.2IT組織77
3.9關鍵業務77
3.9.1業務線77
3.9.2IT組織77
3.10戰略伙伴78
3.10.1業務線78
3.10.2IT組織79
3.11成本結構79
3.11.1業務線79
3.11.2IT組織79
3.12總結80
第4章DevOps方案之優化持續交付流水線81
4.1DevOps作為優化運動82
4.2核心主題88
4.2.1縮短周期時間89
4.2.2縮小批次規模91
4.2.3建設正確文化理念95
4.3DevOps實施方案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方案：移動設備DevOps154
4.4.2方案：大型機的DevOps161
4.4.3方案：物聯網DevOps165
4.4.4方案：DevOps用于大數據及分析168
4.5總結173
第5章DevOps驅動創新方案175
5.1優化創新176
5.2Uber綜合癥178
5.3創新與技術的角色178
5.3.1商業模式創新179
5.3.2商業模式實驗180
5.3.3用戶參與模式創新181
5.4核心主題183
5.4.1實現多級IT184
5.4.2構建正確的事物187
5.4.3進行實驗190
5.4.4提供反脆弱的系統192
5.4.5IT系統與反脆弱性195
5.5方案：構建DevOps平臺199
5.5.1應用交付與反脆弱性202
5.5.2環境抽象層203
5.5.3云托管的DevOps平臺204
5.5.4基礎設施即服務209
5.5.5OpenStackHeat作為抽象層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部署自動化和API236
5.7.2DevOps平臺和API236
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.1DevOps能力中心的功能與目標250
6.2.2能力中心的核心角色251
6.2.3DevOps教練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.3API經濟與安全279
6.8方案：DevOps與外包280
6.8.1戰略外包281
6.8.2IT供應鏈282
6.8.3利用外包實現DevOps283
6.9總結283
第7章引領企業的DevOps實施285
7.1方案：DevOps作為變革運動287
7.1.1令人信服的行動理由289
7.1.2DevOps變革的反模式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.1DevOps的優化與創新工作坊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.5DevOps實踐316
A.3.6實施路線圖321
參考文獻323
|
| 序： |
