DevOps Handbook

本文譯自gene kim和jez humble的"Devops Handbook"，僅用于個(gè)人學(xué)習(xí)。

image.png

更新

2017.7.26 本周更新

CH12 自助部署

CH14遙測(cè)

CH1 三個(gè)方法

引言

引言

想象下，如果產(chǎn)品負(fù)責(zé)人、開(kāi)發(fā)、測(cè)試、運(yùn)維、信息安全等相互之間不再只是相互幫助信息共享，而是作為一個(gè)整體一起工作保證整個(gè)組織的目標(biāo)實(shí)現(xiàn)。他們通過(guò)快速的對(duì)應(yīng)，迅速地部署，實(shí)現(xiàn)了一流的穩(wěn)定性/可靠性/安全性的系統(tǒng)服務(wù)。

在這里，跨職能的團(tuán)隊(duì)的合作并不僅僅是為了實(shí)現(xiàn)用戶要求的功能，還關(guān)心積極保障價(jià)值流中的工作平滑高頻流動(dòng)，而不會(huì)給IT運(yùn)營(yíng)及內(nèi)外客戶帶來(lái)中斷和混亂。

QA(這里指測(cè)試)、運(yùn)維、信息安全等人員會(huì)一起工作降低摩擦而使得開(kāi)發(fā)人員更有效率。通過(guò)給測(cè)試/運(yùn)維/信息安全人員提供自動(dòng)化的自助服務(wù)，過(guò)去那些必須各個(gè)團(tuán)隊(duì)的骨干在一起才能解決的問(wèn)題通過(guò)這些工具和平臺(tái)來(lái)實(shí)現(xiàn)，在每日的工作中，各個(gè)團(tuán)隊(duì)彼此之間倚賴性大大降低，這種情況下極大地提升了效率。

這使得一個(gè)小型的團(tuán)隊(duì)也能夠快速獨(dú)立的完成開(kāi)發(fā)/測(cè)試/發(fā)布，將開(kāi)發(fā)快速/安全/可靠地為客戶做價(jià)值的轉(zhuǎn)化。這使得組織能夠最大化開(kāi)發(fā)者的生產(chǎn)效率，提升員工滿意度，在市場(chǎng)競(jìng)爭(zhēng)中脫穎而出。

這些是DevOps所帶來(lái)的結(jié)果。而在更多的現(xiàn)實(shí)世界中，不存在一個(gè)整體，到處是割裂的碎片。 開(kāi)發(fā)和測(cè)試是水火不容的，仿佛雙方都是為了證明愚蠢的是對(duì)方而存在。測(cè)試和信息安全行為的結(jié)合只是在項(xiàng)目的結(jié)束才會(huì)引入，一般都已經(jīng)太晚基本上是走個(gè)過(guò)場(chǎng)，或者大體解決面上的問(wèn)題。 留給我們很多手工去處理的余地，以及這些不穩(wěn)定性所帶來(lái)的各種副作用。不僅僅是交付時(shí)間變長(zhǎng)，更多的是這些工作的質(zhì)量往往是不可控的，因?yàn)樵谶@種情況下，現(xiàn)實(shí)情況已經(jīng)成為最終出場(chǎng)救火隊(duì)員必須擔(dān)負(fù)這些割裂所能帶來(lái)的如同大廈將傾的趨勢(shì)，在現(xiàn)實(shí)的世界中這些救火隊(duì)員不斷的扮演奇跡，但是也有很多很多的失敗。成功的救火往往也能留下各種隱患，潛在以及時(shí)而出現(xiàn)的由此引起的問(wèn)題給項(xiàng)目帶來(lái)很大的影響，而且無(wú)法避免地影響到顧客和業(yè)績(jī)。最終的結(jié)果就是，項(xiàng)目在短期目標(biāo)上的失敗，整個(gè)組織對(duì)IT的各種不滿，以及由此帶來(lái)的預(yù)算收緊，同時(shí)眾多面對(duì)各種變更和不可知的質(zhì)量部署的郁悶和無(wú)助的運(yùn)維人員。

為了更好的理解DevOps的變革，讓我們把目光投射到上世紀(jì)八十年代制造業(yè)的變革上。通過(guò)踐行精益原則，制造業(yè)組織成功地極其顯著地提升了生產(chǎn)效率，降低了交付時(shí)間，提高了產(chǎn)品質(zhì)量以及客戶滿意度，成功的企業(yè)在殘酷的市場(chǎng)中贏得了一席之地。

在這場(chǎng)改革開(kāi)始之前，制造行業(yè)平均交付時(shí)間為6周，而且只有少于70%的訂單能夠按時(shí)交付。而到2005年，隨著精益實(shí)踐的廣泛推行，平均交付時(shí)間已經(jīng)少于三周，而且95%的訂單能夠按時(shí)交付。那些沒(méi)能跟上的組織失去了市場(chǎng)份額，他們之中的很多最終被淘汰出局。

軟件行業(yè)是如此的相似，在上世紀(jì)七八十年代，大多數(shù)項(xiàng)目需要一到五年才能實(shí)現(xiàn)完成開(kāi)發(fā)和部署，經(jīng)常伴隨著極其高昂的成本，而失敗也是會(huì)帶來(lái)極其嚴(yán)重的影響和后果。

隨著Agile的踐行，新功能的開(kāi)發(fā)已經(jīng)降到周或者月為單位了，但是部署到生產(chǎn)仍然需要數(shù)周甚至數(shù)月，而且經(jīng)常還會(huì)伴隨災(zāi)難性的后果。

接下來(lái)隨著軟件和硬件的不斷升級(jí)，帶來(lái)了永不停息的服務(wù)的普遍實(shí)施的可能性，而Cloud更是將其全面推展開(kāi)來(lái)。

DevOps的引入更是使得這些需要部署到生產(chǎn)的服務(wù)變成了以小時(shí)甚至以分鐘計(jì)的尋常操作，很多企業(yè)在這輪變革中已經(jīng)先行，部署對(duì)他們來(lái)說(shuō)已經(jīng)是日常和低風(fēng)險(xiǎn)的的作業(yè)。借助于DevOps，這些企業(yè)甚至能夠在實(shí)際的環(huán)境下現(xiàn)行驗(yàn)證他們的Idea，以確認(rèn)哪些Idea能夠帶來(lái)最大程度的效益，以此來(lái)決定所要開(kāi)發(fā)的功能，而這些功能最終將非常安全地被部署到生產(chǎn)環(huán)境之中。

image.png

時(shí)至今日，DevOps原則的踐行已經(jīng)在一日部署上百甚至上千變更。舉個(gè)極端的例子Amazon在2011年每天大約能夠完成7000部署，而到了2015年這個(gè)數(shù)字上升到了13萬(wàn)次每天。

跟上個(gè)世紀(jì)八十年的的制造業(yè)變革何其相似，這個(gè)時(shí)代的軟件行業(yè)已經(jīng)在變革。快速的市場(chǎng)對(duì)應(yīng)以及不懈的探索和努力已經(jīng)成為必備的要素。無(wú)法實(shí)現(xiàn)的企業(yè)注定要付出失去市場(chǎng)的代價(jià)。就像2016年DORA的DevOps調(diào)研報(bào)告的研討會(huì)中提到的那樣，你可以不相信那些看起來(lái)好像不太符合常規(guī)邏輯的速度，但是這些確確實(shí)實(shí)的發(fā)生在我們的身邊。

這個(gè)時(shí)代，不管在哪個(gè)領(lǐng)域中進(jìn)行的商業(yè)競(jìng)爭(zhēng)，對(duì)價(jià)值的交付最終都將依賴于科技價(jià)值流的實(shí)現(xiàn)。說(shuō)得再簡(jiǎn)單一些，就像通用電器的CEO Jeffrey Immelt曾經(jīng)說(shuō)過(guò)的那樣，“任何一個(gè)領(lǐng)域和公司，如果他們還未曾將軟件引入到他們的核心業(yè)務(wù)，他們注定會(huì)被顛覆”。這不是危言聳聽(tīng)，技術(shù)對(duì)于任何組織都是用于贏得競(jìng)爭(zhēng)一席之地或者生存下去的極為重要的工具。

了解了所有的這一切，讓我們來(lái)看一下這些問(wèn)題的征兆，以及為什么會(huì)發(fā)生這些問(wèn)題，為什么沒(méi)有強(qiáng)有力的干預(yù)，這些問(wèn)題會(huì)隨著時(shí)間變得愈發(fā)嚴(yán)重

我們需要改進(jìn)

大多數(shù)企業(yè)需要數(shù)周甚至數(shù)月的準(zhǔn)備來(lái)部署他們的產(chǎn)品，他們也不能定例地低風(fēng)險(xiǎn)地交付部署新的功能特性，甚至他們中的很多都認(rèn)為，這么快的部署需求本身就是一件很?chē)W眾取寵的事情。但是和當(dāng)初制造業(yè)的變革一樣，這場(chǎng)革命實(shí)際上已經(jīng)無(wú)聲無(wú)息地展開(kāi)了，在這個(gè)時(shí)代快速和高水準(zhǔn)的服務(wù)已經(jīng)是必要條件，已經(jīng)有很多優(yōu)秀的企業(yè)先行一步，掀起了變革的浪潮。沒(méi)有危機(jī)意識(shí)的企業(yè)在上個(gè)世紀(jì)八十年代應(yīng)該也有很多，沒(méi)有奮起直追的大多數(shù)在那場(chǎng)變革中已經(jīng)消失在滾滾洪流之中。部署只是海面上的冰山，從工具到流程，從組織結(jié)構(gòu)到文化，有太多的環(huán)節(jié)需要注意，而改善也已經(jīng)刻不容緩。

長(zhǎng)期且核心的沖突

幾乎在每一個(gè)IT組織中，開(kāi)發(fā)和運(yùn)維之間都會(huì)產(chǎn)生一個(gè)“下行的惡性循環(huán)”，使得產(chǎn)品或功能交付的時(shí)間增加，質(zhì)量下降，更為糟糕的是那與日俱增的技術(shù)債務(wù)。

技術(shù)債務(wù)是Ward Cunningham最初提出來(lái)的一個(gè)術(shù)語(yǔ)，像財(cái)務(wù)債務(wù)一樣，技術(shù)債務(wù)描述了我們所做的決策可能會(huì)引起的逐漸累積的問(wèn)題，隨著這些債務(wù)的不斷增加，解決這些問(wèn)題也會(huì)花費(fèi)越來(lái)越多的成本和時(shí)間。

開(kāi)發(fā)和運(yùn)維產(chǎn)生隔閡的原因在于分工和目標(biāo)的不同。IT組織需要滿足很多目標(biāo)，其中有兩個(gè)必須同時(shí)滿足：

應(yīng)對(duì)快速變化的市場(chǎng)態(tài)勢(shì)

給客戶提供穩(wěn)定、可靠、安全的服務(wù)

開(kāi)發(fā)團(tuán)隊(duì)為快速將產(chǎn)品推向市場(chǎng)作出努力，當(dāng)然穩(wěn)定和安全等也是必要的，在現(xiàn)實(shí)的世界中，這些更多是作為非功能性要素不會(huì)出現(xiàn)在大多數(shù)的開(kāi)發(fā)人員的視線范圍，而且在大部分情況下這些也不是交付的要素。運(yùn)維則需要負(fù)責(zé)穩(wěn)定這個(gè)要素，兩個(gè)團(tuán)隊(duì)，兩個(gè)目標(biāo)，兩套KPI，相互沖突，無(wú)論是在這個(gè)地球的哪個(gè)國(guó)家，類(lèi)似的隔閡和問(wèn)題都一直在出現(xiàn)。

制造業(yè)變革運(yùn)動(dòng)的奠基者之一的Goldratt將這種情況稱之為核心的固有沖突（the core, chronic conflict）, 正是這種沖突帶來(lái)了螺旋下行的惡性循環(huán)。

下行螺旋

這種螺旋下行的惡性循環(huán)產(chǎn)生在現(xiàn)實(shí)世界中往往有下面三個(gè)簡(jiǎn)單要素。

運(yùn)維的目標(biāo)是保持應(yīng)用程序和基礎(chǔ)框架持續(xù)運(yùn)行以使得組織能夠交付服務(wù)給到最終顧客。但是由于應(yīng)用程序和基礎(chǔ)框架及其復(fù)雜，缺少文檔，以及難以置信的脆弱，這使得運(yùn)維人員每天都必須面對(duì)和處理的事情。當(dāng)我們救火的時(shí)候總是想再抽空順便就把這些個(gè)問(wèn)題修復(fù)，但是一直沒(méi)有抽到空，而這樣的技術(shù)債務(wù)則在不斷地增長(zhǎng)。

而且，當(dāng)這些日漸脆弱的系統(tǒng)所支持的是創(chuàng)造利潤(rùn)的關(guān)鍵業(yè)務(wù)時(shí)，問(wèn)題會(huì)變得更加復(fù)雜，本來(lái)能夠?qū)?yīng)的問(wèn)題也會(huì)因?yàn)閾?dān)心和憂慮以及沒(méi)有非功能性機(jī)能的保障而信息不足。問(wèn)題越積越多，一個(gè)小小的改動(dòng)，最終都可能引起多米諾骨牌效應(yīng)。所以每次只能最少限的修改，只能頭痛醫(yī)頭，腳痛醫(yī)腳。CSA根本問(wèn)題分析對(duì)應(yīng)？分析后有錢(qián)改么？敢改么？這樣的結(jié)果造成了大家每日都在接觸到的現(xiàn)實(shí)世界的一幕一幕。

理想的項(xiàng)目，缺錢(qián)給錢(qián)，缺人給人，項(xiàng)目范圍穩(wěn)定，變更管理有序，在Q（Quality）C（Cost）T(Time)三角進(jìn)行管理的經(jīng)驗(yàn)豐富的PM也游刃有余。

而現(xiàn)實(shí)的世界是，很多項(xiàng)目是要錢(qián)沒(méi)有，資源有限，根本無(wú)變更管理。即使是這樣的項(xiàng)目也在搶著做的情況下，基于各種場(chǎng)景，很多難以兌現(xiàn)的許諾就這樣被添加了。比如項(xiàng)目管理上稱之為鍍金的行為，實(shí)際的項(xiàng)目中往往是給強(qiáng)勢(shì)的外部以真金白銀的無(wú)底線自殘。

然而最終這些許諾會(huì)壓到開(kāi)發(fā)團(tuán)隊(duì)那里，給原本就不太寬裕的項(xiàng)目進(jìn)度狠狠地來(lái)上一刀。這些任務(wù)的往往兼具難度大/工期緊/經(jīng)費(fèi)少/人手不足等諸多明顯標(biāo)志，完成任務(wù)已經(jīng)是精疲力竭，至于技術(shù)債務(wù)，自然會(huì)進(jìn)一步的積累不斷升高。

螺旋下行的惡性循環(huán)還差最后一根稻草。只需要在來(lái)一點(diǎn)，每件事情都復(fù)雜一點(diǎn)點(diǎn)，每個(gè)人都再忙一點(diǎn)點(diǎn)。一點(diǎn)一點(diǎn)，每個(gè)人都變得越來(lái)越忙，工作時(shí)間越來(lái)越長(zhǎng)，交流時(shí)間越來(lái)越短，任務(wù)列表越堆越高。每個(gè)人的工作都和別人的工作緊密相關(guān)，一個(gè)小的動(dòng)作都可能帶來(lái)很大的失敗，自然而然，對(duì)變更充滿畏懼和排斥。工作需要更多的溝通/協(xié)調(diào)/批準(zhǔn)，各個(gè)團(tuán)隊(duì)必須等待更長(zhǎng)一點(diǎn)時(shí)間以確保所依賴的部分已經(jīng)完成。扯皮和吵架變成為了自保的必備生存技能。

這種情況下，部署的時(shí)間越來(lái)越長(zhǎng)，更要命的是，開(kāi)始變得容易出問(wèn)題了，而對(duì)這些問(wèn)題的救火行為消耗了大量的時(shí)間和成本，使得原本可以著手對(duì)付那高壘的技術(shù)債務(wù)的最后一絲機(jī)會(huì)也喪失殆盡。到了這個(gè)時(shí)候，就是英雄輩出的時(shí)代，對(duì)待那基本上已經(jīng)困難重重的系統(tǒng)，非常規(guī)的能力出眾的個(gè)人或者小的團(tuán)體的非常規(guī)的努力，保證系統(tǒng)能夠運(yùn)行的同時(shí)繼續(xù)推高系統(tǒng)的技術(shù)債務(wù)，為下一次爆發(fā)提供了良好的條件。

為何會(huì)形成下行螺旋

這種情況對(duì)我們來(lái)說(shuō)是如此常見(jiàn)，知道了下行的惡性循環(huán)是如何發(fā)生的，但是為什么會(huì)這樣普遍存在呢？

每個(gè)IT組織都有快速和穩(wěn)定兩個(gè)相反的目標(biāo)，最終形成了Goldratt所說(shuō)的核心的固有沖突，為這種存在提供了基礎(chǔ)。

另外還有一點(diǎn)，現(xiàn)代社會(huì)中，不管被意識(shí)到與否，各行各業(yè)的任何一家公司都是科技公司，科技在各個(gè)行業(yè)的滲透已經(jīng)超出了大多數(shù)人的想象，思維方式的轉(zhuǎn)變勢(shì)在必行。

正如一位資深的軟件負(fù)責(zé)人所言：“所有的公司都是科技公司不管他們自己認(rèn)為他們自己在什么領(lǐng)域。一家銀行也只是有著銀行營(yíng)業(yè)許可的IT公司而已。”在作咨詢的時(shí)候，我們也經(jīng)常會(huì)跟客戶說(shuō), 在這個(gè)時(shí)代，”Your software is not part of your business, it is your business”，其實(shí)都是一樣的道理。是否最終的發(fā)展像Jeffrey Immelt所說(shuō)的那樣可能還需要時(shí)間的檢驗(yàn)可以拭目以待，但是對(duì)任何企業(yè)來(lái)說(shuō)這都是一場(chǎng)輸不起的賭博。

由此導(dǎo)致的成本

在下行的惡性循環(huán)中的很多人，被迫面對(duì)怪獸一般的系統(tǒng)，那種憂郁/孤立無(wú)援/無(wú)助甚至絕望的心情估計(jì)只能是如人飲水，冷暖自知了，由此帶給個(gè)人家庭的傷害也是無(wú)法估量的。但是這個(gè)世界花在IT上的成本確是清楚的。比如IDC和Gartner都曾發(fā)布過(guò)，2011年全球花在IT上的錢(qián)大體是GDP的5%，這個(gè)數(shù)字高達(dá)3.1萬(wàn)億美元。試想一下即使一個(gè)很小的比例與這3.1萬(wàn)億一起計(jì)算，在經(jīng)濟(jì)上付出了多大的成本不言自明。

DevOps道德規(guī)范：有更好的方法

與傳統(tǒng)方式不同，DevOps協(xié)調(diào)各個(gè)部門(mén)向著組織共同目標(biāo)協(xié)同努力同時(shí)改善工作的環(huán)境和文化，正是因?yàn)槿绱耍拍茉谶@么短的時(shí)間內(nèi)得到了眾多人群的青睞而得到了迅速的發(fā)展。

用DevOps打破下行螺旋

理想狀況下，小型的開(kāi)發(fā)團(tuán)隊(duì)也能實(shí)現(xiàn)自己的機(jī)能特性，在類(lèi)生產(chǎn)環(huán)境中驗(yàn)證正確性，能將他們的代碼快速安全地部署到生產(chǎn)環(huán)境。代碼的部署是可預(yù)期的日常行為，部署不再是必須等待到周五下班然后開(kāi)始倒計(jì)時(shí)在周一開(kāi)始之前必須完成的噩夢(mèng)。運(yùn)維人員終于可以在工作日進(jìn)行例行的部署作業(yè)。而客戶對(duì)此一無(wú)所知，只有在他們發(fā)現(xiàn)新的可用機(jī)能或者被修改好了的bug時(shí)，才會(huì)意識(shí)到部署的動(dòng)作已經(jīng)完成。

在整個(gè)過(guò)程之中，每個(gè)操作都需要有快速的反饋，每個(gè)人都能快速地看到他們的動(dòng)作所帶來(lái)的影響和結(jié)果。當(dāng)變更的代碼提交到版本庫(kù)中之后，自動(dòng)測(cè)試開(kāi)始在類(lèi)生產(chǎn)環(huán)境中運(yùn)行以確認(rèn)此次變更是否達(dá)到能夠部署到生產(chǎn)環(huán)境中的標(biāo)準(zhǔn)。

自動(dòng)測(cè)試幫助發(fā)現(xiàn)更多的問(wèn)題而不致于留下很多的技術(shù)債務(wù)，通過(guò)自動(dòng)測(cè)試的確認(rèn)，發(fā)現(xiàn)的技術(shù)債務(wù)立即解決而不是等待日后再行處理。

不同于傳統(tǒng)的非黑即白的部署，經(jīng)過(guò)測(cè)試的代碼，可以早早的放到生產(chǎn)環(huán)境之中，除了內(nèi)部用戶和一些被選擇的特定用戶，其他所有用戶均此時(shí)均不會(huì)意識(shí)和看到或者使用到此部分部署的機(jī)能，而且也不會(huì)被此部分功能所影響。這樣在生產(chǎn)環(huán)境通過(guò)內(nèi)測(cè)或者小部分用戶的試行方式極大的提高了信息安全相關(guān)的保障。

即使出現(xiàn)問(wèn)題，也可以快速回滾到上一個(gè)版本以避免無(wú)法對(duì)外提供正常服務(wù)。整個(gè)部署是可控的，可預(yù)測(cè)的，可回滾的，低風(fēng)險(xiǎn)的。

相比于畏懼出錯(cuò)/重于懲罰的文化，高度信任和協(xié)作的文化更加被推崇。只有這樣，有些問(wèn)題點(diǎn)才會(huì)被提出來(lái)而不是裝作不知道被藏起來(lái)。畢竟，我們只有先看到問(wèn)題才能去解決這些問(wèn)題。同時(shí)即使當(dāng)問(wèn)題發(fā)生的時(shí)候，啟動(dòng)的也不是問(wèn)題追責(zé)機(jī)制，而是無(wú)追責(zé)的事后檢討或者反省活動(dòng)，不是為了懲罰某人，而是為了避免下次同樣的問(wèn)題再次出現(xiàn)，組織級(jí)別的學(xué)習(xí)和成長(zhǎng)使用這種方式不斷展開(kāi)。這是一個(gè)理想的狀況，各種企業(yè)都在使用自己的方式去實(shí)現(xiàn)自己的DevOps。

DevOps的業(yè)務(wù)價(jià)值

正如DevOps調(diào)研報(bào)告中所提到的那樣，通過(guò)對(duì)多達(dá)25，000職業(yè)技術(shù)人員的調(diào)研，發(fā)現(xiàn)踐行了DevOps的高效能人員相比于低效者，在很多方面都展現(xiàn)出很大的優(yōu)勢(shì)。比如:

流量指標(biāo)

代碼和變更部署效率(頻率高30倍以上)

代碼和變更部署前置時(shí)間

可靠性

生產(chǎn)部署成功率

平均恢復(fù)時(shí)間

生產(chǎn)效率、市場(chǎng)份額、利潤(rùn)目標(biāo)

市值增長(zhǎng)

規(guī)模開(kāi)發(fā)線性等效(DEVOPS HELPS SCALE DEVELOPER PRODUCTIVITY)

當(dāng)開(kāi)發(fā)人員的數(shù)目增加的時(shí)候，由于規(guī)模效應(yīng)所增加的溝通/協(xié)作等額外作業(yè)不可避免的對(duì)個(gè)體開(kāi)發(fā)者產(chǎn)生比較明顯的影響。就像人月神化中所解釋的那樣，當(dāng)項(xiàng)目遲延時(shí)，增加開(kāi)發(fā)者時(shí)，不但會(huì)降低個(gè)體開(kāi)發(fā)者的效率，同樣會(huì)降低整體的效率。

而DevOps則從另外一個(gè)角度，告訴我們，當(dāng)我們有合適的架構(gòu)，合適的技術(shù)實(shí)踐，合適的文化氛圍，小的團(tuán)隊(duì)也能高效地完成作業(yè)。同時(shí)，大規(guī)模的團(tuán)隊(duì)也同樣適合DevOps，正像google前管理者Randy Shoup在google中所觀察到的那樣，“數(shù)千人的團(tuán)隊(duì)，架構(gòu)和實(shí)踐依然能使得小團(tuán)隊(duì)像初創(chuàng)公司那樣產(chǎn)生不可思議的超高效率”。

2015年DevOps報(bào)告清晰地展示了當(dāng)人數(shù)上升時(shí)候踐行DevOps的高效能人員所組成的團(tuán)隊(duì)依然能夠保證著小團(tuán)隊(duì)的線性增長(zhǎng)效率。

image.png

方案的普適性

大量證據(jù)顯示上述問(wèn)題和解決方案是普適的。

第一部分 三個(gè)方法

CH1 敏捷、持續(xù)交付和三個(gè)方法

制造業(yè)中的價(jià)值流

在精益中一個(gè)最基礎(chǔ)的概念就是價(jià)值流。價(jià)值流的定義是“the sequence of activities re-quired to design, produce, and deliver a good or service to a customer, including

the dual flows of information and material”。

在制造業(yè)中，從接到客戶訂單的那一刻起，價(jià)值的流動(dòng)用眼睛就能清晰地看到。碓在工廠里面的原料，開(kāi)來(lái)開(kāi)去的叉車(chē)，精益運(yùn)動(dòng)帶來(lái)的價(jià)值流改善甚至直接能夠從堆放的WIP半成品的高度來(lái)進(jìn)行確認(rèn)。

技術(shù)價(jià)值流(THE TECHNOLOGY VALUE STREAM)

==注: 下文都用IT價(jià)值流代替技術(shù)價(jià)值流==

在科技領(lǐng)域看到的堆放的原料和叉車(chē)告訴我們價(jià)值流動(dòng)的無(wú)處不在。在軟件開(kāi)發(fā)等科技領(lǐng)域，價(jià)值流同樣存在，而且制造業(yè)的原則和經(jīng)驗(yàn)同樣適用。同樣是接到由業(yè)務(wù)部門(mén)提供了的明確的需求定義，開(kāi)發(fā)，測(cè)試，部署，交付給運(yùn)維，最終價(jià)值的流向同樣流向了客戶。區(qū)別于傳統(tǒng)制造業(yè)的產(chǎn)品，一般科技領(lǐng)域的價(jià)值流最終交付的形式更多是以服務(wù)的形式進(jìn)行的。

價(jià)值的體現(xiàn)只有在我們開(kāi)發(fā)/測(cè)試了的軟件運(yùn)行在面向最終客戶的生產(chǎn)環(huán)境之上時(shí)，在IT領(lǐng)域價(jià)值的流動(dòng)才最終完成，在那之前也都只是WIP而已，這個(gè)就是為何我們一直在強(qiáng)調(diào)交付時(shí)間。而這些也是在最近十年之內(nèi)互聯(lián)網(wǎng)公司諸如Amazon作的比較好的一個(gè)地方。

雖然交付時(shí)間非常重要，在DevOps中，交付時(shí)間也不是全部。“快”很重要，但是可靠性/穩(wěn)定性/擴(kuò)展性/安全性同樣重要。DevOps追逐的快速價(jià)值流動(dòng)，是建立在不會(huì)因此而帶來(lái)服務(wù)中斷/安全事件等混亂性事件的基礎(chǔ)之上的。

聚焦在部署前置時(shí)間

image.png

定義前置時(shí)間(Lead Time)和處理時(shí)間(Processing Time)

客戶感知的是lead time, 因此lead time才是核心指標(biāo)。process time可以體現(xiàn)處理效率，但仍然會(huì)因?yàn)殛?duì)列、等待等各種原因?qū)е潞荛L(zhǎng)的lead time。

deployment lead time是指從代碼提交到上線之間的時(shí)間。

一般情況部署前置時(shí)間需要數(shù)月

image.png

devops理想情況是分鐘

image.png

C/A指標(biāo)

C/A: Complete / Accurate .是一個(gè)用來(lái)衡量REWORK的指標(biāo)。一般在DevOps實(shí)踐中，比較常見(jiàn)的會(huì)計(jì)算出在某一個(gè)交付周期之內(nèi)，所作的全部的Story Points和被客戶接受了的Story Points，而沒(méi)有被接受的則表明由于各種原因?qū)?huì)產(chǎn)生的REWORK。

DevOps三個(gè)基本方法

在《鳳凰項(xiàng)目》中總結(jié)的三個(gè)方法是在DevOps實(shí)踐中提煉出來(lái)的基本原則。

image.png

第一個(gè)方法 流動(dòng)

從左到右，從業(yè)務(wù)需求到交付客戶，貫穿著從開(kāi)發(fā)到運(yùn)維的這條正向的通路。在這條原則的使用中，我們經(jīng)常使用很多方式進(jìn)行實(shí)踐以期達(dá)到交付價(jià)值的單位時(shí)間最大化。這些實(shí)踐包括工作可視化、減少批次和工作間隔，內(nèi)建質(zhì)量減少缺陷，持續(xù)全局優(yōu)化等。

第二個(gè)方法 反饋

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and

recovery. By doing this, we create quality at the source and generate or embed knowledge where it is needed—this allows us to create ever-safer systems of work where problems are found and fixed long before a catastrophic

failure occurs.

第三個(gè)方法 組織學(xué)習(xí)

化方面主要從兩個(gè)方面進(jìn)行推進(jìn)，持續(xù)試驗(yàn)和持續(xù)學(xué)習(xí)。在DevOps實(shí)踐極大降低了生產(chǎn)環(huán)境中的實(shí)驗(yàn)性的嘗試可能帶來(lái)的風(fēng)險(xiǎn)的前提下，鼓勵(lì)勇于嘗試和創(chuàng)新以及高度信任的企業(yè)文化，持續(xù)試驗(yàn)結(jié)合持續(xù)學(xué)習(xí)，推動(dòng)整個(gè)企業(yè)一個(gè)整體的方式不斷推進(jìn)。

本章小結(jié)

略

CH2 流(flow)的原理

快而且平滑

可視化

軟件開(kāi)發(fā)和制造業(yè)的價(jià)值流在可見(jiàn)性方面差別很大。制造業(yè)的庫(kù)存/存貨移動(dòng)的時(shí)候是可見(jiàn)，費(fèi)力而且相對(duì)較慢的。而軟件開(kāi)發(fā)移動(dòng)不可見(jiàn)，而且非常簡(jiǎn)單，只要點(diǎn)點(diǎn)鼠標(biāo)。這樣在哪個(gè)工作中心(work center)阻塞或堆積就不容易發(fā)現(xiàn)。而且因?yàn)楹?jiǎn)單，工作可以在不同工作中心見(jiàn)來(lái)回反復(fù)，或者將問(wèn)題帶到下游，甚至到生產(chǎn)才能發(fā)現(xiàn)問(wèn)題。

看板就是很好的可視化手段，工作可視化后，就容易管理，以加快流動(dòng)速度。看板可以覆蓋整個(gè)價(jià)值流，工作完成的標(biāo)志是上線運(yùn)行，因此看板代表的是整體價(jià)值。而干系人也容易確認(rèn)工作的優(yōu)先級(jí)。

image.png

限制在制品(WIP)數(shù)量

制造業(yè)的工作相對(duì)常態(tài)化，根據(jù)計(jì)劃安排生產(chǎn)。而軟件開(kāi)發(fā)通常動(dòng)態(tài)程度高的多，因?yàn)橐獫M足不同干系人的要求，各種渠道進(jìn)來(lái)的請(qǐng)求，和各種緊急任務(wù)。

制造業(yè)的工作中斷是高可見(jiàn)和高成本的，因?yàn)橐袛喱F(xiàn)有工作，清理半成品并啟動(dòng)新的工作。因?yàn)榭梢?jiàn)，所以會(huì)致力于盡可能減少中斷。

而軟件開(kāi)發(fā)的中斷的后果不是顯而易見(jiàn)的，因而更容易被終端，哪怕成本可能比制造業(yè)還高。比如工程師的多任務(wù)切換，因?yàn)橐亟ㄉ舷挛模ㄕJ(rèn)知規(guī)則和目標(biāo)，會(huì)帶來(lái)很大成本。

有研究顯示，高度認(rèn)知復(fù)雜性的工作切換，效率損失是非常大的。

因此限制在制品數(shù)量是非常重要的，可以減少上下文切換，加快流動(dòng)，并讓阻塞可視化。

小批量

大批量導(dǎo)致了WIP的層次抬高，流動(dòng)的變異性擴(kuò)大。因此會(huì)延長(zhǎng)lead time，和推遲問(wèn)題的發(fā)現(xiàn)。越早發(fā)現(xiàn)問(wèn)題，返工成本越低。此外，批次（變更）越大，診斷問(wèn)題和修復(fù)也越難。制造業(yè)的理想是單件流，對(duì)應(yīng)軟件開(kāi)發(fā)的持續(xù)交付，即每次代碼提交，都能觸發(fā)集成、測(cè)試和部署到生產(chǎn)。

image.png

減少跨團(tuán)隊(duì)交接

工作夸團(tuán)隊(duì)交接需要大量的溝通。

每一項(xiàng)依賴其他團(tuán)隊(duì)的工作都會(huì)造成潛在的排隊(duì)，造成lead time的延長(zhǎng)。

移交還會(huì)造成知識(shí)的丟失

解決辦法是組成能夠獨(dú)自完成交付的cross-function團(tuán)隊(duì)，自動(dòng)化絕大部分工作。這樣通過(guò)減少排隊(duì)和無(wú)價(jià)值工作提高流動(dòng)速度。

持續(xù)識(shí)別和解決約束

不在瓶頸出的改進(jìn)都是幻覺(jué)，事實(shí)上可能讓瓶頸變得更加嚴(yán)重。非瓶頸資源的利用水平不是由自身潛力所決定，而是由系統(tǒng)的約束來(lái)決定。瓶頸損失1小時(shí)，相當(dāng)于整個(gè)系統(tǒng)損失1小時(shí)。非瓶頸上節(jié)約開(kāi)1小時(shí)，無(wú)實(shí)際意義。

約束理論五步法：

第一步，找出系統(tǒng)中存在哪些約束。

第二步，尋找突破（Exploit）這些約束的辦法。

第三步，使企業(yè)的所有其他活動(dòng)服從于第二步中提出的各種措施。

第四步，具體實(shí)施第二步中提出的措施，使第一步中找出的約束環(huán)節(jié)不再是企業(yè)的約束。

第五步，回到步驟1，別讓惰性成為約束，持續(xù)不斷地改善

devops轉(zhuǎn)型中的主要約束

環(huán)境創(chuàng)建，解決辦法是按需創(chuàng)建環(huán)境和自助服務(wù)

代碼部署，解決辦法是自動(dòng)化部署操作，知道全部自動(dòng)化，開(kāi)發(fā)可以自助發(fā)布

建立測(cè)試環(huán)境和運(yùn)行，解決辦法是自動(dòng)化和并行測(cè)試

緊耦合的架構(gòu)：解決辦法是將架構(gòu)松耦合，以便讓變更更安全和自主，提高開(kāi)發(fā)生產(chǎn)率。

消除價(jià)值流中的艱澀和浪費(fèi)

軟件開(kāi)發(fā)中的浪費(fèi)

部分完成工作

額外的過(guò)程，不創(chuàng)造價(jià)值的過(guò)程，如沒(méi)用的文檔和評(píng)審

額外的特性

任務(wù)切換

等待，延長(zhǎng)了cycle time(cycle time常指process time，即到了工作中心還要等在資源以便完成工作)

移動(dòng)

缺陷

非標(biāo)準(zhǔn)或人工工作，比如不可重建的服務(wù)器、測(cè)試環(huán)境和配置。理想情況下，==所有對(duì)運(yùn)營(yíng)的依賴，都應(yīng)該被自動(dòng)化、自服務(wù)，按需獲得==。

英雄主義或超常發(fā)揮

CH3 反饋的原理

技術(shù)工作大都是面對(duì)復(fù)雜系統(tǒng)，處于隨時(shí)遇到嚴(yán)重后果的風(fēng)險(xiǎn)中。我們常常在直到發(fā)生生產(chǎn)系統(tǒng)重大故障時(shí)才發(fā)現(xiàn)問(wèn)題，在客戶數(shù)據(jù)丟失時(shí)才發(fā)現(xiàn)有安全漏洞。

因此我們需要一個(gè)覆蓋端到端價(jià)值流和整個(gè)組織的，快速、頻繁和高質(zhì)量的信息流，包括反饋(feedback)和前饋(feedforward)循環(huán)。以便我們?cè)趩?wèn)題還小時(shí)，修復(fù)代價(jià)低而且容易時(shí)即使發(fā)現(xiàn)和修復(fù)，避免問(wèn)題導(dǎo)致嚴(yán)重后果，并創(chuàng)造能融合到未來(lái)的工作中的組織學(xué)習(xí)。這樣失敗和事故發(fā)生時(shí)，我們視為機(jī)會(huì)，而不是懲罰和指責(zé)的理由。

在復(fù)雜系統(tǒng)中安全地工作

復(fù)雜系統(tǒng)就是組件的交互導(dǎo)致的系統(tǒng)行為，無(wú)法單純地用組件本身的行為來(lái)描述（注：比如蟻群和螞蟻）。在復(fù)雜系統(tǒng)中，兩次同樣的行為，沒(méi)法預(yù)測(cè)到或必然會(huì)有同樣的結(jié)果。因此靜態(tài)的檢查表和最佳實(shí)踐，對(duì)于防止災(zāi)難的發(fā)生是不夠的。

復(fù)雜系統(tǒng)中的失敗是內(nèi)在和不可避免的，因此我們要?jiǎng)?chuàng)建一種安全的工作環(huán)境，能夠免于恐懼，相信錯(cuò)誤會(huì)很快發(fā)現(xiàn)，在造成嚴(yán)重后果很早以前，比如工傷、產(chǎn)品缺陷或者負(fù)面的客戶影響。

我們沒(méi)法構(gòu)造一個(gè)徹底安全的環(huán)境，但如果滿足以下四個(gè)條件，那我們?cè)趶?fù)雜系統(tǒng)中的工作就會(huì)安全些。

復(fù)雜工作收到管理，設(shè)計(jì)和運(yùn)營(yíng)中的問(wèn)題得以暴露

問(wèn)題一擁而上解決，新知識(shí)得以迅速構(gòu)建

新的局部知識(shí)對(duì)整個(gè)組織利用

培養(yǎng)持續(xù)提升這些能力的領(lǐng)導(dǎo)

在問(wèn)題發(fā)生時(shí)就看到

在安全工作中，我們必須持續(xù)地測(cè)試設(shè)計(jì)和操作假設(shè)。以此創(chuàng)造一種信息流，全面、及時(shí)、快速地反映情況，并盡可能清晰地反應(yīng)因果關(guān)系。越快地驗(yàn)證假設(shè)，就能越快發(fā)現(xiàn)和修復(fù)問(wèn)題，增加我們學(xué)習(xí)和創(chuàng)新的彈性、敏捷和能力。

在彼得圣吉的第五項(xiàng)修煉中，描述了反饋環(huán)是組織學(xué)習(xí)和系統(tǒng)思考的關(guān)鍵部分。高 績(jī)效的生產(chǎn)運(yùn)營(yíng)，總有快速、高頻、高質(zhì)量的信息流伴隨價(jià)值流。每個(gè)操作都被度量和監(jiān)控，每個(gè)缺陷或顯著偏差都被即使發(fā)現(xiàn)和處理。這是形成組織學(xué)習(xí)和提高的基礎(chǔ)。

傳統(tǒng)的軟件開(kāi)發(fā)，反饋周期太長(zhǎng)。我們的目的是要建立一個(gè)涵蓋所有階段和所有角色的反饋、前饋環(huán)。這包括自動(dòng)化的構(gòu)建、集成和測(cè)試，還包括普遍的“遙測(cè)”技術(shù)，以便快速獲知生產(chǎn)系統(tǒng)運(yùn)行出現(xiàn)預(yù)期之外的情況。快速反饋不僅僅是為了快速發(fā)現(xiàn)和解決問(wèn)題，還有利于未來(lái)規(guī)避重復(fù)產(chǎn)生問(wèn)題。這樣才能提高我們工作系統(tǒng)的安全性和質(zhì)量，以及創(chuàng)建組織學(xué)習(xí)。

擁抱和解決問(wèn)題以構(gòu)建新知識(shí)

顯然，僅僅檢測(cè)預(yù)料之外的情況發(fā)生是不夠的，當(dāng)問(wèn)題發(fā)生時(shí)，我們得一擁而上，動(dòng)員所有需要的人來(lái)解決問(wèn)題。

阻止問(wèn)題流向下游，因?yàn)檫@會(huì)導(dǎo)致修復(fù)成本上升和技術(shù)債務(wù)累積。

阻止工作中心開(kāi)始新的工作，因?yàn)檫@會(huì)給系統(tǒng)引入新的錯(cuò)誤。

如果問(wèn)題沒(méi)解決，工作中心在后續(xù)操作中會(huì)出同樣的問(wèn)題，導(dǎo)致更多的修復(fù)工作

這個(gè)實(shí)踐有點(diǎn)違背管理嘗試，即我們會(huì)在局部問(wèn)題發(fā)生時(shí)停止整個(gè)生產(chǎn)線。（注：對(duì)應(yīng)持續(xù)交付管道出問(wèn)題時(shí)，干系人都要停下手頭工作來(lái)解決）。然而，swarming 使能學(xué)習(xí)。它避免關(guān)鍵信息隨著記憶的淡忘和環(huán)境的改變而丟失。這一點(diǎn)在復(fù)雜系統(tǒng)中尤其關(guān)鍵，因?yàn)閱?wèn)題的發(fā)生糾纏在人員、過(guò)程、產(chǎn)品、位置、環(huán)境等各種因素的交互中，時(shí)間久了，難以重建當(dāng)時(shí)問(wèn)題發(fā)生時(shí)的情況。

Swarming 是實(shí)時(shí)識(shí)別、診斷和處理問(wèn)題的原則，也是一種PDCA循環(huán)。

參"Implementing Lean Software Development From Concept to Cash"

Autonomation (Jidoka) ==work is organized so that the slightest abnormality is immediately detected, work stops, and the cause of the problem is remedied before work resumes. Another name for this critical concept, and one that is perhaps easier to remember, is "stop-the-line." Autonomation means the organization has reflexes in place that will respond instantly and correctly to events without having to go to the brain for instructions.條件反射==

不斷推動(dòng)質(zhì)量向他的源頭靠近

不是指價(jià)值流的上游下游，而是指誰(shuí)負(fù)責(zé)執(zhí)行工作，內(nèi)建質(zhì)量就要放到哪里。實(shí)際上指自己完成工作，自己檢查，自己修復(fù)，這依賴大量的自動(dòng)化和自服務(wù)。客觀上就是指工作向開(kāi)發(fā)轉(zhuǎn)移，因?yàn)殚_(kāi)發(fā)就是源頭。

低效的質(zhì)量控制

讓另一個(gè)團(tuán)隊(duì)完成枯燥、易錯(cuò)、手工任務(wù)（本來(lái)可以自動(dòng)化并有自己團(tuán)隊(duì)完成）

讓遠(yuǎn)離戰(zhàn)場(chǎng)并不了解情況的”忙人“做決策

生產(chǎn)大量文檔，而這些文檔很快就過(guò)時(shí)了

將一大坨工作交給其他團(tuán)隊(duì)處理貨審核，然后就干等反饋

我們需要在價(jià)值流中所有人把在他們自己領(lǐng)域發(fā)現(xiàn)和解決問(wèn)題作為他們的日常工作。這樣，我們才能推動(dòng)質(zhì)量、安全職責(zé)、決策到工作執(zhí)行的地方，而不是依靠“遠(yuǎn)處”的主管的審核。我們用同行評(píng)審來(lái)保證設(shè)計(jì)質(zhì)量，我們將大部分原來(lái)由QA或安全部門(mén)執(zhí)行的質(zhì)量檢查自動(dòng)化，這樣開(kāi)發(fā)人員 就不需要請(qǐng)求或計(jì)劃這些測(cè)試，而只要按需執(zhí)行，這樣開(kāi)發(fā)人員可以迅速執(zhí)行他們自己的代碼，甚至部署到生產(chǎn)系統(tǒng)。

這樣，質(zhì)量成為大家共同的責(zé)任，而不是不同部門(mén)的各自的職責(zé)。信息安全不只是信息安全部門(mén)的工作，就像可用性也不只是運(yùn)維人員的工作。

讓開(kāi)發(fā)人員共擔(dān)他們所建設(shè)系統(tǒng)的質(zhì)量職責(zé)，不僅提升了產(chǎn)出，還加快了學(xué)習(xí)。

為(流水線)下游客戶做優(yōu)化

精益將客戶分成兩類(lèi)，外部客戶和內(nèi)部客戶。精益認(rèn)為我們的下游是我們重要客戶。

在技術(shù)價(jià)值流中，我們是通過(guò)為運(yùn)營(yíng)做設(shè)計(jì)實(shí)現(xiàn)為下游做優(yōu)化，這樣非功能運(yùn)營(yíng)需求優(yōu)先級(jí)和用戶特性是一樣高的。

本章小結(jié)

在技術(shù)價(jià)值流中，創(chuàng)建快速反饋對(duì)獲得質(zhì)量、可靠性和安全是非常關(guān)鍵的。我們通過(guò)在發(fā)生時(shí)立即發(fā)現(xiàn)問(wèn)題、一擁而上解決問(wèn)題構(gòu)建知識(shí)、將質(zhì)量推向源頭，并為下游做優(yōu)化來(lái)實(shí)現(xiàn)。

CH4? 持續(xù)學(xué)習(xí)的原理

在制造作業(yè)中，工作是嚴(yán)格定義好的，工人沒(méi)有能力將提升和學(xué)習(xí)融合到日常工作中，他們的提高方向是成為一塊塊沒(méi)什么區(qū)別的磚頭。這樣的環(huán)境通常伴隨這恐懼和低新人，犯錯(cuò)誤是要被懲罰的，提建議會(huì)被當(dāng)做刺頭。但在高績(jī)效的組織中，卻需要積極推動(dòng)學(xué)習(xí)，工作不是嚴(yán)格定義的，而是動(dòng)態(tài)的。

在技術(shù)價(jià)值流中，我們的目的是創(chuàng)造高度信任的文化，告訴大家我們都是在日常工作中需要承擔(dān)一定的風(fēng)險(xiǎn)的終生學(xué)習(xí)者。我們從成功和失敗中學(xué)習(xí)，識(shí)別不起作用的措施，強(qiáng)化起作用的措施。同時(shí)，局部的學(xué)習(xí)會(huì)轉(zhuǎn)化成全局的提升，新的技術(shù)和實(shí)踐會(huì)被整個(gè)組織應(yīng)用。

我們?yōu)槿粘；某掷m(xù)提升、學(xué)習(xí)預(yù)留時(shí)間。我們向我們的（工作）系統(tǒng)中施加持續(xù)提升的壓力，甚至在受控條件下注入失敗到生產(chǎn)服務(wù)中，以提高彈性。

通過(guò)創(chuàng)建持續(xù)和動(dòng)態(tài)的學(xué)習(xí)系統(tǒng)，我們讓團(tuán)隊(duì)快速和自動(dòng)適應(yīng)永遠(yuǎn)在變化的環(huán)境，這幫助我們獲得市場(chǎng)成功。

學(xué)習(xí)型組織及安全的文化

在復(fù)雜系統(tǒng)中工作，我們無(wú)法對(duì)我們行為的后果進(jìn)行完美的預(yù)測(cè)。這就是我們會(huì)不期而遇各種預(yù)期之外的事件甚至嚴(yán)重故障，哪怕我們很謹(jǐn)慎。

我們要?jiǎng)?chuàng)建一種免于指責(zé)的事后分析。

略。。。

對(duì)日常工作的改進(jìn)行為制度化

團(tuán)隊(duì)通常沒(méi)能力或者不愿做過(guò)程改進(jìn)。這不僅導(dǎo)致團(tuán)隊(duì)持續(xù)受害，而且情況還會(huì)惡化。==因?yàn)榛煦绾挽卦觯^(guò)程如果不改進(jìn)，就會(huì)隨著時(shí)間推移而退化，而不是保持不變。==

我們通過(guò)顯性地保留時(shí)間來(lái)償還技術(shù)債，修復(fù)缺陷，重構(gòu)和改善有問(wèn)題的代碼和環(huán)境，以提升日常工作。我們?cè)诿總€(gè)開(kāi)發(fā)間隔中留有時(shí)間或計(jì)劃改善行動(dòng)(kaizen blitzes)，期間工程師會(huì)在團(tuán)隊(duì)中自組織修復(fù)他們想修復(fù)的任何問(wèn)題。

這些時(shí)間的結(jié)果是，每個(gè)人都在日常工作中發(fā)現(xiàn)和修復(fù)他們控制領(lǐng)域問(wèn)題。經(jīng)過(guò)數(shù)月（或年）積累，我們開(kāi)始有精力處理不那么明顯的問(wèn)題。通過(guò)就檢測(cè)和修復(fù)不那么明顯的失敗信號(hào)，不僅我們修復(fù)問(wèn)題容易而且成本低，而且影響也小。

==注：這就是我們說(shuō)的，消除技術(shù)債務(wù)要顯性地安排，上看板。==

將局部的發(fā)現(xiàn)變成整體的改進(jìn)（不做局部?jī)?yōu)化）

我們需要有一種機(jī)制，將局部的學(xué)到和發(fā)現(xiàn)的知識(shí)傳播開(kāi)，使得整個(gè)組織收益。即，我們需要將個(gè)人或團(tuán)隊(duì)通過(guò)經(jīng)驗(yàn)變得專業(yè)的隱形知識(shí)，變成明確和顯性的知識(shí)，以便讓他人通過(guò)實(shí)踐也變得專業(yè)。

在技術(shù)價(jià)值流中，這些機(jī)制包括讓無(wú)指責(zé)時(shí)候分析報(bào)告容易搜索，創(chuàng)建共享的代碼庫(kù)，以此共享內(nèi)嵌了組織最佳知識(shí)稽的代碼、庫(kù)、配置，而且容易應(yīng)用。

==注：將大部分操作性工作都自動(dòng)化，團(tuán)隊(duì)或個(gè)人可以自服務(wù)，這樣積累在自動(dòng)化過(guò)程匯總的知識(shí)就得到了傳播、應(yīng)用。==

在日常工作中注入彈性模式

低效的組織通過(guò)增加buffer來(lái)避免中斷。比如為了避免工作中心空閑，就通過(guò)在每個(gè)工作中心增加庫(kù)存。這導(dǎo)致了WIP增加。為了避免設(shè)備故障導(dǎo)致中斷，又要購(gòu)買(mǎi)更多固定設(shè)備和雇傭更多的人。

而高效的組織，是通過(guò)不斷提升日常運(yùn)營(yíng)水平，持續(xù)引入提升的績(jī)效的張力，同時(shí)在系統(tǒng)中導(dǎo)入更多彈性來(lái)達(dá)到同樣甚至更好的結(jié)果。這就是反脆弱性(antifragility)。

在技術(shù)價(jià)值流中，我們也可以導(dǎo)入同樣的張力到系統(tǒng)中，以尋求持續(xù)降低部署前置時(shí)間，提升測(cè)試覆蓋率，降低測(cè)試時(shí)間，甚至必要時(shí)進(jìn)行重構(gòu)，從而提升開(kāi)發(fā)效率和可靠性。我們還可以"game day"練習(xí)，以此演練大規(guī)模失敗，比如數(shù)據(jù)中心斷電。也可以在生產(chǎn)系統(tǒng)中注入越來(lái)越大的失敗（如chaos monkey，隨機(jī)殺進(jìn)程和服務(wù)器)來(lái)保證我們有所希望的彈性。

注：系統(tǒng)有一定的彈性應(yīng)對(duì)沖擊、突發(fā)事件。日常的工作就像割草，高的割掉后逐漸越割越低。

Leader應(yīng)該強(qiáng)調(diào)學(xué)習(xí)文化

傳統(tǒng)領(lǐng)導(dǎo)的職責(zé)設(shè)置目標(biāo)、分配資源，以及建立關(guān)聯(lián)的激勵(lì)機(jī)制。領(lǐng)導(dǎo)者通過(guò)“制定正確決策”來(lái)領(lǐng)導(dǎo)。越來(lái)越多的證據(jù)顯示，光靠領(lǐng)導(dǎo)者指定正確決策無(wú)法獲得偉大，而是應(yīng)該通過(guò)領(lǐng)導(dǎo)角色創(chuàng)造一種讓團(tuán)隊(duì)發(fā)現(xiàn)偉大的環(huán)境。領(lǐng)導(dǎo)者和一線團(tuán)隊(duì)成員互相需要，前者不夠靠近具體工作，沒(méi)有做所有決策需要的細(xì)節(jié)。而后者沒(méi)有足夠?qū)挼慕M織背景，以及推動(dòng)他們工作領(lǐng)域外的變革。

領(lǐng)導(dǎo)者必須提升學(xué)習(xí)的價(jià)值，教會(huì)別人解決問(wèn)題。Mike Rother將這個(gè)方法正式化，并稱之為“coaching kata”。包括設(shè)立目標(biāo)，并通過(guò)迭代的方法解決問(wèn)題和障礙，以達(dá)到這個(gè)目標(biāo)。（參考《豐田套路》第三部分 改善套路 第四部分 指導(dǎo)套路，在豐田討論中，重點(diǎn)說(shuō)明了目標(biāo)狀態(tài)和目標(biāo)的區(qū)別，要達(dá)到的目標(biāo)狀態(tài)而不是目標(biāo)，而本書(shū)沒(méi)有對(duì)此進(jìn)行區(qū)分。）

目標(biāo)狀態(tài)和目標(biāo).png

領(lǐng)導(dǎo)者可以通過(guò)問(wèn)這些問(wèn)題來(lái)指導(dǎo)大家：

你最后一步做了什么，發(fā)生了什么

你從中學(xué)到了什么

你現(xiàn)在具備什么樣的條件了

你下一個(gè)目標(biāo)條件是什么

你現(xiàn)在正在努力移出什么障礙

你下一步要做什么

你期望的產(chǎn)出是什么

我們什么時(shí)候能check產(chǎn)出

本章小結(jié)

第三種方法的原理說(shuō)明了組織學(xué)習(xí)的價(jià)值，建立高信任和跨職能的信任， 接受失敗總會(huì)發(fā)生在復(fù)雜的系統(tǒng)中，并使之成為可以接受的問(wèn)題進(jìn)行討論，這樣我們就可以創(chuàng)建一個(gè)安全的工作系統(tǒng)。同事，還需要將改善日常工作制度化，局部的學(xué)習(xí)變成組織學(xué)習(xí)，以使整個(gè)組織可以使用。 不斷地向我們的日常工作注入張力，將日常工作中進(jìn)行改進(jìn)制度化。

雖然不斷學(xué)習(xí)和嘗試是第三種方法，但和第一第二中方法，流和反饋交織在一起。建立流和反饋也需要迭代和科學(xué)的方法。

結(jié)果是更好的績(jī)效，更好的彈性，更高的工作滿意度，提升的組織適應(yīng)性。

第一部分小結(jié)

略。

第二部分 從哪里開(kāi)始

怎樣決定我們?cè)谀睦镩_(kāi)始devops轉(zhuǎn)型？哪些人要參與？怎樣組織團(tuán)隊(duì)、保護(hù)他們的工作容量、最大化他們成功的機(jī)會(huì)？第二部分就是回答這些問(wèn)題。

CH5 選擇從哪個(gè)價(jià)值流開(kāi)始

新項(xiàng)目還是遺留項(xiàng)目

都可以，也都需要。

System of record 還是 System of engagement

==systems of record==, 運(yùn)行我們業(yè)務(wù)的ERP類(lèi)的系統(tǒng)（如MRP, HR, 財(cái)報(bào)系統(tǒng)), 交易和數(shù)據(jù)的準(zhǔn)確性最重要。

==systems of engagement==，面向客戶的系統(tǒng)如電商系統(tǒng)，性能最重要.

前者聚焦在doing it right，后者聚焦在 doing it fase。這兩者通常是沖突的，但從devops報(bào)告上看到，高績(jī)效的組織同時(shí)滿足高流量和高可靠性。

實(shí)際上這兩類(lèi)系統(tǒng)往往相互依賴，所以現(xiàn)在不區(qū)分這兩者，都要又快又好。

找到有創(chuàng)造性和同理心的團(tuán)隊(duì)

不要一開(kāi)始全面鋪開(kāi)，找原因采納新想法的團(tuán)隊(duì)，參技術(shù)應(yīng)用曲線，跨越鴻溝。

技術(shù)應(yīng)用曲線-跨越鴻溝.png

推廣到整個(gè)組織

找到有創(chuàng)造力的早期采納者

推廣到更多團(tuán)隊(duì)，吸引跟風(fēng)

識(shí)別阻抗

本章小結(jié)

從小范圍開(kāi)始，重點(diǎn)突破，形成支持團(tuán)隊(duì)。擴(kuò)大實(shí)踐，獲得認(rèn)可，吸引跟風(fēng)，以此推廣到整個(gè)組織。

CH6 理解我們的價(jià)值流，使之可見(jiàn)，并擴(kuò)展到整個(gè)組織

本章初略過(guò)一下，當(dāng)看完全書(shū)后再?zèng)Q定是否要細(xì)看。

找到支持我們價(jià)值流的團(tuán)隊(duì)

畫(huà)出價(jià)值流映射以便看清工作

成立專注的轉(zhuǎn)型小組

對(duì)目標(biāo)達(dá)成共識(shí)

控制提升計(jì)劃盡可能短小

小步快跑，好處很多。

調(diào)整優(yōu)先級(jí)甚至重排計(jì)劃很容易

減少工作和改進(jìn)的間隔，縮短反饋環(huán)

更快將所學(xué)知識(shí)應(yīng)用到下個(gè)迭代

減少提升所需的激活能量

盡快實(shí)現(xiàn)改進(jìn)讓日常工作變得有意義

減少項(xiàng)目還沒(méi)來(lái)得及展示成果就被關(guān)閉了

預(yù)留20%的人力給非功能需求和減少技術(shù)債務(wù)

用戶不可見(jiàn)的價(jià)值.png

提升工作可見(jiàn)性

利用工具規(guī)范行為

人類(lèi)學(xué)家將工具描述為文化產(chǎn)物。 在發(fā)明了火之后，任何關(guān)于文化的討論都必須與工具有關(guān)。DevOps也一樣，需要用工具塑造文化和加速行為改變。

統(tǒng)一的backlog

chat rooms(有這么重要嗎？難道和我們現(xiàn)在用的IM工具有不一樣特性和用法？)

==注：chat rooms有好處，也會(huì)導(dǎo)致團(tuán)隊(duì)成員工作頻繁被打斷。要平衡利弊。==

本章小結(jié)

CH7 如何用康威定律設(shè)計(jì)我們的組織和架構(gòu)

組織原型

問(wèn)題常常由職能組織引起

鼓勵(lì)市場(chǎng)導(dǎo)向的團(tuán)隊(duì)(為速度進(jìn)行優(yōu)化)

讓職能線面向工作

測(cè)試、運(yùn)營(yíng)和安全是每個(gè)人每天的工作

鼓勵(lì)團(tuán)隊(duì)成員成為通才

以服務(wù)和產(chǎn)品為導(dǎo)向，而不是項(xiàng)目導(dǎo)向

根據(jù)康威定律設(shè)計(jì)團(tuán)隊(duì)邊界

創(chuàng)建松耦合的架構(gòu)

本章小結(jié)

CH8? 如何將運(yùn)營(yíng)整合到日常開(kāi)發(fā)工作中，以提高產(chǎn)出

具體方法包括：

為服務(wù)團(tuán)隊(duì)中的開(kāi)發(fā)人員提供自服務(wù)能力，以提高開(kāi)發(fā)效率

把維護(hù)工程師內(nèi)嵌到服務(wù)團(tuán)隊(duì)中

如果做不到嵌入，則為服務(wù)團(tuán)隊(duì)指定聯(lián)絡(luò)人

為提高開(kāi)發(fā)人員效率創(chuàng)建共享服務(wù)

將運(yùn)維人員嵌入到服務(wù)團(tuán)隊(duì)

給服務(wù)團(tuán)隊(duì)指定聯(lián)絡(luò)人

將運(yùn)維集成到開(kāi)發(fā)儀式中

邀請(qǐng)運(yùn)維參加開(kāi)發(fā)站立會(huì)

邀請(qǐng)運(yùn)維參加開(kāi)發(fā)回顧會(huì)

讓相應(yīng)的運(yùn)維任務(wù)在看板上可見(jiàn)

本章小結(jié)

第二部分小結(jié)

第三部分 流(flow)的技術(shù)實(shí)踐

參《持續(xù)交付 發(fā)布可靠軟件的系統(tǒng)方法》

CH9 創(chuàng)建持續(xù)部署流水線(pipeline)的基礎(chǔ)

為了創(chuàng)建從開(kāi)發(fā)到運(yùn)維的快速、可靠的流，我們需要在價(jià)值流的任何階段使用類(lèi)似生產(chǎn)的環(huán)境。更進(jìn)一步，這些環(huán)境要能夠自動(dòng)化地創(chuàng)建，理想情況是用版本庫(kù)中的腳本和配置信息，按需創(chuàng)建，完全地自服務(wù)，不需要運(yùn)維的手工操作。我們的目標(biāo)是確保我們能夠依靠版本庫(kù)重建生產(chǎn)環(huán)境。

很多情況下，我們檢查在類(lèi)似生產(chǎn)環(huán)境下應(yīng)用如何執(zhí)行的唯一時(shí)機(jī)是部署到生產(chǎn)--這對(duì)解決問(wèn)題已經(jīng)太晚了，很難避免影響客戶。

按需創(chuàng)建開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境

為整個(gè)系統(tǒng)創(chuàng)建唯一事實(shí)的倉(cāng)庫(kù)

以前版本庫(kù)是給開(kāi)發(fā)用的，用于存儲(chǔ)源代碼和文檔。但是給客戶交付價(jià)值既包括代碼，也包括環(huán)境。因此環(huán)境也需要進(jìn)行版本管理。換句話說(shuō)，版本管理是價(jià)值流上每個(gè)角色都要做的。通過(guò)將生產(chǎn)制品納入版本控制，版本庫(kù)可以讓我們能夠重復(fù)可靠地重建生產(chǎn)系統(tǒng)的所有組件，包括應(yīng)用、生產(chǎn)環(huán)境、準(zhǔn)生產(chǎn)環(huán)境。

為了保證能夠在重大事故后能夠重復(fù)、快速地恢復(fù)生產(chǎn)環(huán)境，需要檢查以下幾點(diǎn)：

所有應(yīng)用代碼和依賴，如庫(kù)、靜態(tài)內(nèi)容等

所有創(chuàng)建數(shù)據(jù)庫(kù)模式的腳本，應(yīng)用引用的數(shù)據(jù)

所有環(huán)境創(chuàng)建工具和制品，如虛擬機(jī)鏡像、puppet或chef的recipes

所有自動(dòng)化測(cè)試和人工測(cè)試腳本

所有用于代碼打包、部署、數(shù)據(jù)庫(kù)遷移和環(huán)境開(kāi)通的腳本

所有項(xiàng)目制品，包括需求文檔，部署過(guò)程，版本說(shuō)明等

所有云配置文件（如有使用公有云的話）

創(chuàng)建提供各種服務(wù)的基礎(chǔ)設(shè)施所用腳本和配置信息(如企業(yè)總線、數(shù)據(jù)庫(kù)管理、DNS zone file、防火墻配置規(guī)則，以及其他網(wǎng)絡(luò)設(shè)備)

可以有多種類(lèi)型的倉(cāng)庫(kù) 用存儲(chǔ)不同的對(duì)象和服務(wù)。

我們不僅要能夠恢復(fù)生產(chǎn)系統(tǒng)，還要能恢復(fù)預(yù)生產(chǎn)系統(tǒng)和構(gòu)建過(guò)程，所以還要將構(gòu)建過(guò)程依賴的所有東西都放入版本庫(kù)，比如構(gòu)建工具和其所依賴的環(huán)境。

對(duì)環(huán)境進(jìn)行的版本控制是IT績(jī)效的預(yù)測(cè)因子。因?yàn)閷?duì)應(yīng)用和環(huán)境進(jìn)行版本控制，不僅有利于看到變更，有利于定位問(wèn)題，更有利于故障恢復(fù)。而且環(huán)境中可配置的內(nèi)容大于代碼，因此環(huán)境更需要做配置管理。

讓基礎(chǔ)設(shè)置重建比修復(fù)來(lái)的更簡(jiǎn)單

將開(kāi)發(fā)完成的定義修改成包含在準(zhǔn)生產(chǎn)環(huán)境運(yùn)行的內(nèi)容

本章小結(jié)

CH10 快速和可靠的自動(dòng)化測(cè)試

在這個(gè)點(diǎn)上，開(kāi)發(fā)和QA在日常工作中就會(huì)用類(lèi)生產(chǎn)環(huán)境。我們將代碼提交后的特性驗(yàn)收，集成到了在類(lèi)生產(chǎn)環(huán)境的自動(dòng)化測(cè)試中。

自動(dòng)化測(cè)試不僅僅是獲得快速反饋（容易定義問(wèn)題），而且還解決另一個(gè)問(wèn)題，即隨著業(yè)務(wù)代碼的增加，用于測(cè)試我們代碼的時(shí)間和成本原來(lái)越大，這對(duì)任何技術(shù)組織來(lái)說(shuō)都是不可擴(kuò)展的業(yè)務(wù)模型。

持續(xù)構(gòu)建和測(cè)試，將代碼和環(huán)境集成起來(lái)

我們通過(guò)將開(kāi)發(fā)運(yùn)行自動(dòng)化測(cè)試作為日常工作，實(shí)現(xiàn)內(nèi)建質(zhì)量的目的。實(shí)現(xiàn)的手段是部署流水線(deployment pipeline)。部署流水線確保每次提交代碼將自動(dòng)地在類(lèi)生產(chǎn)環(huán)境中構(gòu)建和測(cè)試。通過(guò)這個(gè)手段，我們可以在變更引入時(shí)就發(fā)現(xiàn)構(gòu)建、測(cè)試或集成錯(cuò)誤，確保我們快速解決問(wèn)題。我們因此確保總是除以可部署和發(fā)布狀態(tài)。

我們需要一個(gè)專門(mén)的環(huán)境用于運(yùn)行自動(dòng)化構(gòu)建和測(cè)試過(guò)程。這很關(guān)鍵，理由...

圖13

部署流水線和版本控制一樣，都是最基本的基礎(chǔ)設(shè)施。

構(gòu)建信息還可以用于審計(jì)和合規(guī)檢查，因?yàn)檫@些報(bào)告在日常工作中一直在產(chǎn)生。

在持續(xù)部署流水線基礎(chǔ)設(shè)施中，我們要實(shí)踐持續(xù)集成，要點(diǎn)有3：

完整可靠的自動(dòng)化測(cè)試，用于驗(yàn)證(validation)我們處于可部署狀態(tài)

如果驗(yàn)證失敗，中斷整個(gè)生產(chǎn)線

小批量、主干開(kāi)發(fā)，而不是長(zhǎng)期特性分支

創(chuàng)建快速可靠的自動(dòng)化驗(yàn)證(validation)測(cè)試套件

為什么得這么做？因?yàn)榧词故敲刻煲归g構(gòu)建（自動(dòng)化測(cè)試），也是不夠及時(shí)的。比如夜間構(gòu)建失敗，次日才發(fā)現(xiàn)，需要花時(shí)間檢查，從幾分鐘到幾個(gè)小時(shí)。而且既可能是代碼，也可能是測(cè)試環(huán)境的問(wèn)題，這樣追溯問(wèn)題，發(fā)現(xiàn)又是很多次提交了（比如整個(gè)白天的提交），快速反饋被打破了。

就是這三類(lèi)測(cè)試，從快到慢依次是：

單元測(cè)試：代碼片段測(cè)試，數(shù)據(jù)庫(kù)也是被stub out的

驗(yàn)收測(cè)試：比如驗(yàn)證user story正確實(shí)現(xiàn)，功能的回歸等

集成測(cè)試：跨生產(chǎn)系統(tǒng)和服務(wù)能夠正確交互

注：此書(shū)將集成測(cè)試定義為跨生產(chǎn)系統(tǒng)的集成，因此比驗(yàn)收測(cè)試慢，流程也長(zhǎng)。

面對(duì)deadline的壓力，我們常常犧牲單元測(cè)試，這需要通過(guò)將覆蓋率可視化，甚至在完成定義中設(shè)置覆蓋率閾值，低于閾值構(gòu)建就失敗。

==本節(jié)最后引用 martin folwer的說(shuō)法，構(gòu)建包括測(cè)試要在10分鐘完成，測(cè)試大部分是單元測(cè)試。并說(shuō)明含數(shù)據(jù)的的功能測(cè)試可能要數(shù)個(gè)小時(shí)。==

在自動(dòng)化測(cè)試中盡早捕捉錯(cuò)誤

圖 測(cè)試金字塔

確保測(cè)試運(yùn)行快速（必要時(shí)并行）

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)

盡可能多地將人工測(cè)試自動(dòng)化

將性能測(cè)試集成到測(cè)試套件中

將非功能需求測(cè)試集成到測(cè)試套件中

部署流水線中斷時(shí)拉制動(dòng)閘

為何我們需要緊急制動(dòng)

本章小結(jié)

CH11 持續(xù)集成

略。

來(lái)源：簡(jiǎn)書(shū)

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。