全局優(yōu)化DevOps系統(tǒng)工作流

1、 全局優(yōu)化DevOps系統(tǒng)工作流目 錄 TOC o 1-3 h z u HYPERLINK l _Toc522795201 一、使工作可見(jiàn) PAGEREF _Toc522795201 h 3 HYPERLINK l _Toc522795202 二、限制在制品數(shù) PAGEREF _Toc522795202 h 5 HYPERLINK l _Toc522795203 三、減小批量大小 PAGEREF _Toc522795203 h 7 HYPERLINK l _Toc522795204 四、減少交接次數(shù) PAGEREF _Toc522795204 h 11 HYPERLINK l _Toc5227

2、95205 五、持續(xù)識(shí)別和改善約束點(diǎn) PAGEREF _Toc522795205 h 12 HYPERLINK l _Toc522795206 六、消除價(jià)值流中的困境和浪費(fèi) PAGEREF _Toc522795206 h 14 HYPERLINK l _Toc522795207 七、小結(jié) PAGEREF _Toc522795207 h 16本文以谷歌、亞馬遜、Facebook等全球知名企業(yè)和組織的實(shí)際調(diào)查結(jié)果為依據(jù)，展示如何通過(guò)現(xiàn)代化的運(yùn)維管理提升管理效率，為企業(yè)贏得更大市場(chǎng)、創(chuàng)造更多利潤(rùn)。在技術(shù)價(jià)值流中，工作通常是從開(kāi)發(fā)人員流向運(yùn)維人員，也就是業(yè)務(wù)和客戶(hù)之間的所有職能部門(mén)。本文要描述的第一步

3、工作法，就是建立從開(kāi)發(fā)到運(yùn)維之間快速的、平滑的、能向客戶(hù)交付價(jià)值的工作流。要為這個(gè)全局目標(biāo)進(jìn)行優(yōu)化，而非圍繞一系列局部目標(biāo)，如功能開(kāi)發(fā)的完成度、測(cè)試中問(wèn)題的發(fā)現(xiàn)率和修正率、運(yùn)維維護(hù)的可用性等。通過(guò)持續(xù)加強(qiáng)工作內(nèi)容的可視化，減小每批次大小和等待間隔，內(nèi)建質(zhì)量以防止缺陷向下游傳遞，從而增強(qiáng)流動(dòng)性。通過(guò)加速技術(shù)價(jià)值流的流動(dòng)，可以縮短滿(mǎn)足內(nèi)部客戶(hù)和外部客戶(hù)需求的前置時(shí)間，進(jìn)一步提高工作質(zhì)量，并使我們更加敏捷，能夠比競(jìng)爭(zhēng)對(duì)手更為出色。我們的目標(biāo)是在縮短代碼從變更到生產(chǎn)環(huán)境上線所需時(shí)間的同時(shí)，提高服務(wù)的質(zhì)量和可靠性。實(shí)際上，我們可以在制造行業(yè)中找到價(jià)值流應(yīng)用的相關(guān)線索，幫助我們將精益原則應(yīng)用到技術(shù)價(jià)值流中

4、。一、使工作可見(jiàn)技術(shù)行業(yè)的工作內(nèi)容是不可見(jiàn)的，這是其與制造業(yè)價(jià)值流相比的一個(gè)顯著差異。相對(duì)于工業(yè)產(chǎn)品的生產(chǎn)過(guò)程而言，在技術(shù)價(jià)值流中很難發(fā)現(xiàn)工作過(guò)程的阻塞點(diǎn)，例如，在哪里受阻了，在哪個(gè)環(huán)節(jié)產(chǎn)生了積壓。而在制造業(yè)的價(jià)值流中，工作在不同工作中心間的轉(zhuǎn)移通常是顯而易見(jiàn)并且緩慢的，因?yàn)楸仨氄嬲剞D(zhuǎn)移庫(kù)存產(chǎn)品。另一方面，技術(shù)工作的流轉(zhuǎn)通過(guò)單擊一次鼠標(biāo)就可以完成，譬如將工單重新指派給另一個(gè)團(tuán)隊(duì)。由于點(diǎn)擊的操作太過(guò)容易，所以不同團(tuán)隊(duì)可能會(huì)因?yàn)樾畔⒉煌暾鴮⒐ぷ鳌疤邅?lái)踢去”，存在的問(wèn)題也會(huì)被傳遞到下游工序，而這些問(wèn)題完全是不易察覺(jué)的，直到無(wú)法按時(shí)向客戶(hù)交付產(chǎn)品，或者應(yīng)用程序在生產(chǎn)環(huán)境中出了問(wèn)題。為了能識(shí)別工作在

5、哪里流動(dòng)、排隊(duì)或停滯，就需要將工作盡可能地可視化?？梢暬ぷ靼迨且环N較好的工作方式，如在看板或Sprint計(jì)劃板上，使用紙質(zhì)或電子卡片將各項(xiàng)工作展示出來(lái)。工作通常從左側(cè)發(fā)起（從待辦事項(xiàng)中拉?。?，然后從一個(gè)工作中心拉取到下一個(gè)工作中心（用列表示），最后到達(dá)工作板的最右側(cè)，而這一列也通常被標(biāo)記為“完成”或“已上線”。通過(guò)這種方式，不僅能將工作內(nèi)容可視化，還能有效地管理工作，加速其從左至右的流動(dòng)。此外，還可以通過(guò)卡片從在看板上創(chuàng)建到移動(dòng)至“完成”這一列，度量出工作的前置時(shí)間。理想情況下，看板應(yīng)該覆蓋整個(gè)價(jià)值流；僅當(dāng)工作到達(dá)看板最右側(cè)時(shí)，才能算是已完成（見(jiàn)圖1）。開(kāi)發(fā)完成某個(gè)功能不能算是“已完成”，只

6、有應(yīng)用程序在生產(chǎn)環(huán)境里成功地運(yùn)行起來(lái)，并開(kāi)始為客戶(hù)提供價(jià)值的時(shí)候，才能算是“已完成”。圖1橫跨需求、開(kāi)發(fā)、測(cè)試、預(yù)生產(chǎn)和生產(chǎn)的看板示例來(lái)源：David J. Andersen和Dominica DeGrandis 2012年的工作坊培訓(xùn)材料“ITOps的看板”通過(guò)將每個(gè)工作中心的所有工作都放進(jìn)隊(duì)列中，并且可視化地展示出來(lái)，利益干系人更容易從全局目標(biāo)出發(fā)，確定各項(xiàng)工作的優(yōu)先級(jí)。這樣，每個(gè)工作中心都能采用單任務(wù)的處理方式，從優(yōu)先級(jí)最高的任務(wù)開(kāi)始，依次完成所有工作，以增加工作中心的吞吐量。二、限制在制品數(shù)制造業(yè)的日常工作通常是由定期（如每天、每周）生成的生產(chǎn)計(jì)劃決定的，根據(jù)客戶(hù)訂單、交貨日期、零件庫(kù)

7、存等條件，確定執(zhí)行哪些任務(wù)。但技術(shù)工作通常是動(dòng)態(tài)的尤其是存在共享服務(wù)的情況下，團(tuán)隊(duì)必須要同時(shí)滿(mǎn)足很多利益干系人的需求，這導(dǎo)致臨時(shí)安排控制了日常工作。緊急的工作可能會(huì)來(lái)自于各種渠道，譬如工單系統(tǒng)、宕機(jī)告警、電子郵件、電話、即時(shí)通信的消息或管理層決定的事件。生產(chǎn)中斷在制造業(yè)里很顯眼，且代價(jià)極高，當(dāng)正進(jìn)行中的工作戛然而止時(shí)，所有的半成品都將報(bào)廢，然后再啟動(dòng)一批新作業(yè)。這種高昂的代價(jià)，讓人們不希望中斷頻繁發(fā)生。但是技術(shù)工作者很容易被打斷，因?yàn)閷?duì)所有人而言，這個(gè)中斷的后果似乎是不可見(jiàn)的，即便它對(duì)生產(chǎn)效率的影響比制造業(yè)更甚。例如，將一個(gè)工程師同時(shí)分配到多個(gè)項(xiàng)目里，他不得不在多個(gè)任務(wù)、認(rèn)知規(guī)則和目標(biāo)之間來(lái)回

8、切換，付出重新進(jìn)入角色的成本。研究表明，即便是完成簡(jiǎn)單任務(wù)，如將各種幾何形狀分類(lèi)，當(dāng)同時(shí)執(zhí)行多個(gè)任務(wù)時(shí)，效率也會(huì)顯著降低。從認(rèn)知上看，技術(shù)價(jià)值流中的工作，顯然要比分類(lèi)幾何形狀復(fù)雜得多，所以多任務(wù)會(huì)導(dǎo)致更長(zhǎng)的處理時(shí)間。當(dāng)使用看板管理工作時(shí)，可以限制多任務(wù)的出現(xiàn)，例如對(duì)看板的每一列或每個(gè)工作中心設(shè)置在制品數(shù)量的限制，并把卡片數(shù)量的上限標(biāo)記在每一列上。例如，將測(cè)試工作的在制品數(shù)量上限設(shè)置為3。當(dāng)測(cè)試隊(duì)列中已有3張卡片時(shí)，除非某張卡片完成了，或?qū)?張中的一張退回到前一個(gè)隊(duì)列（左側(cè)的那一列），否則禁止添加新卡片。另外，在把一項(xiàng)工作用卡片的形式顯示在看板上之前，任何與之相關(guān)的工作都不能開(kāi)展，這強(qiáng)調(diào)了任何工

9、作都必須可視化。Dominica DeGrandis是在DevOps中運(yùn)用看板的專(zhuān)家之一，他指出：“控制隊(duì)列的長(zhǎng)度（即在制品數(shù)）是一個(gè)非常強(qiáng)大的管理工具，因?yàn)檫@是影響前置時(shí)間的重要因素之一對(duì)于大多數(shù)的工作條目而言，在它們完成以前，其實(shí)并無(wú)法預(yù)測(cè)到底需要多長(zhǎng)時(shí)間?！蓖ㄟ^(guò)限制在制品數(shù)，還能更容易地發(fā)現(xiàn)工作中的阻礙。例如，當(dāng)限制在制品時(shí)，可能會(huì)發(fā)現(xiàn)居然沒(méi)什么工作可干的，因?yàn)橐却渌?。大野耐一把限制在制品比喻為給水庫(kù)排水來(lái)識(shí)別出阻礙快速流動(dòng)的所有問(wèn)題。正如看板方法：科技企業(yè)漸進(jìn)變革成功之道的作者David J. Anderson所說(shuō)：“停止開(kāi)始，開(kāi)始結(jié)束。”雖然進(jìn)行一項(xiàng)新工作（即“干點(diǎn)什么總比什么

10、都不干強(qiáng)”）可能很誘人，但此時(shí)更好的做法是查明導(dǎo)致等待的原因，并協(xié)助解決那個(gè)等待的問(wèn)題。實(shí)際上，糟糕的多任務(wù)處理發(fā)生的原因，通常是同時(shí)給一個(gè)人分配多個(gè)項(xiàng)目，造成了很多優(yōu)先級(jí)沖突問(wèn)題。三、減小批量大小建立平滑而快速的工作流的另一個(gè)關(guān)鍵點(diǎn)，是通過(guò)小批量的模式完成工作。在精益革命以前，大批量（或規(guī)模）生產(chǎn)的方式在制造業(yè)司空見(jiàn)慣，在作業(yè)配置或作業(yè)之間的切換相當(dāng)耗時(shí)且昂貴時(shí)尤其如此。例如，在生產(chǎn)大型汽車(chē)時(shí)，需要將巨大而沉重的模具放到金屬?zèng)_壓機(jī)上，這個(gè)過(guò)程可能需要好幾天時(shí)間。鑒于成本如此高昂，通常會(huì)用大批量作業(yè)，一次沖壓出盡可能多的車(chē)身板，從而減少模具的更換次數(shù)。然而，大批量導(dǎo)致在制品的暴漲，并在整個(gè)制造

11、工廠中產(chǎn)生流量級(jí)聯(lián)的變化。最后導(dǎo)致前置時(shí)間長(zhǎng)、產(chǎn)品質(zhì)量差的后果如果發(fā)現(xiàn)了一個(gè)車(chē)身板有問(wèn)題，整個(gè)批次都必須報(bào)廢。在精益中，一個(gè)重要的經(jīng)驗(yàn)是：為了縮短前置時(shí)間和提高交付物質(zhì)量，應(yīng)當(dāng)持續(xù)不斷地追求小批量模式。理論上，最小的批量是單件流，也就是每次操作只執(zhí)行一個(gè)單位產(chǎn)品的處理。也稱(chēng)為“1的批量大小”或“11流量”，該術(shù)語(yǔ)表示批量大小和在制品都限制為1。關(guān)于小批量和大批量之間的巨大差異，James P. Womack和Daniel T. Jones在精益思想 一書(shū)里，通過(guò)“模擬郵寄宣傳冊(cè)”的經(jīng)典案例進(jìn)行了說(shuō)明。這個(gè)例子假設(shè)要郵寄出10本宣傳冊(cè)。郵寄之前，每本宣傳冊(cè)都必須經(jīng)歷4個(gè)步驟：折疊，插入信封，給信

12、封封口，蓋戳。如果采用大批量策略（即“大規(guī)模生產(chǎn)”），我們會(huì)對(duì)每本宣傳冊(cè)按順序執(zhí)行上述4個(gè)步驟。換句話說(shuō)，首先要將10張紙全都折疊完，再將每張紙分別插入信封，然后給所有的信封封口，最后全部蓋章。另一種方式是小批量策略（即“單件流”），即對(duì)每本宣傳冊(cè)順序地執(zhí)行所需的所有步驟，然后再開(kāi)始處理下一本宣傳冊(cè)。換句話說(shuō)，先折疊一張紙，將其插入信封，再給信封封口，之后蓋章；然后，取下一張紙，并重復(fù)以上過(guò)程。采用大批量和小批量策略之間的差異是巨大的（見(jiàn)圖2）。假設(shè)對(duì)所有10個(gè)信封都必須采取如上4個(gè)步驟，并且每一步操作需要10秒。如果使用每批5個(gè)的大批量策略處理，則完成第一個(gè)蓋戳的信封需要用310秒。譯者注：

13、這里是“51流量”，即批量大小為5，在制品為1。由于這里是單人模擬的場(chǎng)景，并且一雙手同時(shí)只能加工一個(gè)信封，所以在制品數(shù)量也只能為1。310秒 = (5 10 + 5 10) + (5 10 + 5 10) + (5 10 + 5 10) + 10。圖2模擬“信封游戲”（折疊、插入、封口、蓋章）來(lái)源：Stefan Luyten的文章“單件流：為什么大批量生產(chǎn)不是最有效的處理工作的方式”。參考鏈接：/stefanluyten/single-piece-flow-5d2c2bec845b#.9o7sn74ns更糟糕的是，假設(shè)我們?cè)谛欧夥饪诓僮髦邪l(fā)現(xiàn)第一步的折疊做錯(cuò)了，在這種情況下，我們能發(fā)現(xiàn)錯(cuò)誤的最

14、早時(shí)間是在200秒之后，那樣我們就不得不將這個(gè)批次的10個(gè)小冊(cè)子再重新折疊并裝回信封中。相比之下，使用小批量策略時(shí)，僅用40秒就完成了第一封蓋戳信的生產(chǎn)，比大批量策略快8倍。如果第一步出錯(cuò)了，只需要返工一本小冊(cè)子。小批量生產(chǎn)的在制品更少，前置時(shí)間更短，錯(cuò)誤檢測(cè)更快，返工量更少。對(duì)于技術(shù)價(jià)值流而言，大批量的副作用和制造業(yè)一樣。我們制訂了軟件發(fā)布的年度計(jì)劃，將一整年的開(kāi)發(fā)成果一次性地都發(fā)布到生產(chǎn)環(huán)境中。這種大批量的發(fā)布會(huì)造成突發(fā)的、大量的在制品，導(dǎo)致所有下游工作中心（多指數(shù)據(jù)中心的運(yùn)維部門(mén)）大規(guī)模的混亂，其結(jié)果是流動(dòng)性變差，質(zhì)量下降。這和我們闡述的經(jīng)驗(yàn)是類(lèi)似的，即對(duì)生產(chǎn)環(huán)境的變更越大，問(wèn)題的定位和

15、修復(fù)就越困難，修復(fù)時(shí)間也就越長(zhǎng)。Eric Ries在“創(chuàng)業(yè)經(jīng)驗(yàn)教訓(xùn)”（Startup Lessons Learned）這篇文章中說(shuō)：“在開(kāi)發(fā)（或DevOps）流程中，批量大小是工作產(chǎn)品在不同階段間移動(dòng)的單位數(shù)。對(duì)于軟件而言，最容易看到的是代碼。當(dāng)工程師簽入代碼時(shí)，他們就批量地處理了一定數(shù)量的工作。有許多控制批處理的方式，從持續(xù)部署要求的小批量，到相對(duì)傳統(tǒng)的基于分支的大型模塊開(kāi)發(fā)，都是聚合多個(gè)開(kāi)發(fā)人員幾周或幾個(gè)月所工作的代碼?！痹诩夹g(shù)價(jià)值流中，單件流可以通過(guò)持續(xù)部署實(shí)現(xiàn)。其中，每一個(gè)提交到版本控制系統(tǒng)的變更都會(huì)集成、測(cè)試并部署到生產(chǎn)環(huán)境。（本書(shū)強(qiáng)調(diào)的是端到端的價(jià)值流，只有在部署之后，把價(jià)值交付給

16、客戶(hù)了，一項(xiàng)工作才算完成，因此是持續(xù)部署。）四、減少交接次數(shù)在技術(shù)價(jià)值流中，如果部署的前置時(shí)間以月作為周期單位，通常是因?yàn)橐獙姹究刂葡到y(tǒng)中的代碼部署到生產(chǎn)環(huán)境需要數(shù)百甚至數(shù)千個(gè)操作。實(shí)際上，代碼在價(jià)值流流轉(zhuǎn)的過(guò)程中，需要各個(gè)不同部門(mén)的協(xié)同才能完成相關(guān)任務(wù)，包括功能測(cè)試、集成測(cè)試、環(huán)境搭建、配置服務(wù)器、存儲(chǔ)管理、網(wǎng)絡(luò)、負(fù)載均衡設(shè)備和信息安全加固等。一項(xiàng)工作在團(tuán)隊(duì)之間交接時(shí)，需要大量的溝通請(qǐng)求、委派、通知、協(xié)調(diào)，而且經(jīng)常需要排優(yōu)先級(jí)、調(diào)度、消除沖突、測(cè)試和驗(yàn)證。這些工作可能還需要使用不同的工單系統(tǒng)或項(xiàng)目管理系統(tǒng)，編寫(xiě)技術(shù)規(guī)范文檔，用會(huì)議、電子郵件或電話的形式進(jìn)行溝通，可能還涉及文件共享服務(wù)器、F

17、TP服務(wù)器和Wiki頁(yè)面的使用。實(shí)際上，上述流程中的每個(gè)環(huán)節(jié)都有其潛在的隊(duì)列，當(dāng)依賴(lài)不同價(jià)值流共享的資源（例如集中式操作）時(shí)，就會(huì)出現(xiàn)工作等待。這些請(qǐng)求的前置時(shí)間通常會(huì)很長(zhǎng)，從而導(dǎo)致那些本應(yīng)按期操作完的工作持續(xù)地延期。即使在最好的情況下，有些信息或者知識(shí)也不可避免地在交接過(guò)程中丟失。經(jīng)歷了多次的交接后，問(wèn)題的上下文和所支持的組織目標(biāo)可能會(huì)完全丟失。例如，服務(wù)器管理員可能會(huì)收到一個(gè)關(guān)于創(chuàng)建用戶(hù)賬號(hào)的新工單，但是他并不知道是什么應(yīng)用程序或服務(wù)會(huì)使用這個(gè)賬號(hào)，為什么需要新建賬號(hào)，其他的依賴(lài)關(guān)系是什么，或者這到底是不是一個(gè)重復(fù)勞動(dòng)。為了減少這類(lèi)問(wèn)題的出現(xiàn)，要么努力減少交接次數(shù)，要么用自動(dòng)化方式執(zhí)行大部

18、分操作，要么重新調(diào)整組織結(jié)構(gòu)，讓團(tuán)隊(duì)不必依賴(lài)其他人就可以獨(dú)立地為客戶(hù)提供價(jià)值。因此，要通過(guò)減少隊(duì)列中的等待時(shí)間以及非增值工作的時(shí)間來(lái)增加流動(dòng)性。五、持續(xù)識(shí)別和改善約束點(diǎn)為了縮短前置時(shí)間、提高吞吐量，我們需要不斷地識(shí)別系統(tǒng)中的約束點(diǎn)，提高工作產(chǎn)能。Goldratt博士在Beyond the Goal一書(shū)中提到：“在任何價(jià)值流中，總是有一個(gè)流動(dòng)方向、一個(gè)約束點(diǎn)，任何不針對(duì)此約束點(diǎn)而做的優(yōu)化都是假象。”如果我們優(yōu)化約束點(diǎn)之前的那個(gè)工作中心，那么工作必將在這個(gè)約束點(diǎn)上更快地積壓起來(lái)。反之，如果優(yōu)化約束點(diǎn)之后的工作中心，那么它還會(huì)處于饑餓狀態(tài)，等待約束點(diǎn)處工作的結(jié)束。對(duì)于這種現(xiàn)象，Goldratt博士給

19、出了解決方案，定義了如下“5個(gè)關(guān)鍵步驟”：識(shí)別系統(tǒng)的約束點(diǎn)；決定如何利用這個(gè)系統(tǒng)約束點(diǎn)；基于上述決定，考慮全局工作；改善系統(tǒng)的約束點(diǎn)；如果約束點(diǎn)已經(jīng)突破了，請(qǐng)回到第一步，但要杜絕慣性導(dǎo)致的系統(tǒng)約束。在DevOps的轉(zhuǎn)型過(guò)程中，如果希望前置時(shí)間從月或季度縮短為幾分鐘，那么一般需要依次優(yōu)化下面的約束點(diǎn)：環(huán)境搭建：如果生產(chǎn)或測(cè)試環(huán)境的搭建總是需要數(shù)周或數(shù)月，則按需部署就無(wú)法實(shí)現(xiàn)。解決措施是按需建立完全自服務(wù)的環(huán)境，保證團(tuán)隊(duì)在需要環(huán)境的時(shí)候，能通過(guò)自動(dòng)化方式創(chuàng)建。代碼部署：如果代碼的部署需要花數(shù)周或更長(zhǎng)時(shí)間（譬如每次部署需要1300個(gè)手動(dòng)、易出錯(cuò)的操作，涉及多達(dá)300名工程師），那么就無(wú)法按需部署。解

20、決措施是盡可能自動(dòng)化部署的過(guò)程，以便讓任何開(kāi)發(fā)人員都可以按需自動(dòng)化地部署。測(cè)試的準(zhǔn)備和執(zhí)行：如果每次代碼部署都需要兩周的時(shí)間來(lái)完成測(cè)試環(huán)境的準(zhǔn)備和數(shù)據(jù)集的配置，手動(dòng)執(zhí)行所有的回歸測(cè)試還需要另外四周時(shí)間，那么就無(wú)法實(shí)現(xiàn)按需部署。解決措施是實(shí)現(xiàn)自動(dòng)化測(cè)試，這樣才能在安全、并行地執(zhí)行部署的同時(shí)，使測(cè)試的速度能跟上代碼開(kāi)發(fā)的速度。緊密耦合的架構(gòu)：如果架構(gòu)是緊密耦合的，那也無(wú)法實(shí)現(xiàn)按需部署，因?yàn)槊看我龃a變更時(shí)，工程師都不得不從變更評(píng)審委員會(huì)里獲得執(zhí)行變更的許可。解決措施是創(chuàng)建松散耦合的架構(gòu)，這樣開(kāi)發(fā)人員才能安全、自主地進(jìn)行變更，提高生產(chǎn)力。如果能突破以上的約束點(diǎn)，那么接下來(lái)的約束有可能是開(kāi)發(fā)部門(mén)或產(chǎn)

21、品經(jīng)理。因?yàn)槲覀兊哪繕?biāo)是讓小型開(kāi)發(fā)團(tuán)隊(duì)可以獨(dú)立、快速、可靠地開(kāi)發(fā)、測(cè)試和部署，并持續(xù)為客戶(hù)創(chuàng)造價(jià)值，所以這些環(huán)節(jié)應(yīng)該是約束點(diǎn)集中的所在。對(duì)于高績(jī)效者來(lái)說(shuō)，不管工程師是處于開(kāi)發(fā)、QA、運(yùn)維還是信息安全崗位，他們的目標(biāo)都是盡量提高生產(chǎn)力。當(dāng)約束點(diǎn)出現(xiàn)在開(kāi)發(fā)階段時(shí)，我們將僅受限于有多少創(chuàng)意精良的業(yè)務(wù)假設(shè)，以及能否開(kāi)發(fā)出必要的代碼來(lái)用真實(shí)客戶(hù)來(lái)測(cè)試這些假設(shè)。以上所述的約束點(diǎn)在DevOps轉(zhuǎn)型中是相當(dāng)普遍的在價(jià)值流中識(shí)別約束點(diǎn)的技術(shù)，諸如如何使用值流映射和度量的方法，以后會(huì)詳細(xì)描述。六、消除價(jià)值流中的困境和浪費(fèi)豐田生產(chǎn)系統(tǒng)的先驅(qū)之一新鄉(xiāng)重夫認(rèn)為，浪費(fèi)是業(yè)務(wù)興盛的最大威脅精益中對(duì)浪費(fèi)的常用定義是“使用了超

22、出客戶(hù)需求和他們?cè)敢庵Ц斗秶娜魏尾牧匣蛸Y源的行為”。他定義了制造業(yè)里7種主要的浪費(fèi)類(lèi)型：庫(kù)存、過(guò)量生產(chǎn)、過(guò)度加工、運(yùn)輸、等待、移動(dòng)和缺陷?，F(xiàn)代化的精益理念解釋道：“消除浪費(fèi)”會(huì)有點(diǎn)貶義和不近人情的意味，我們的目標(biāo)其實(shí)是想通過(guò)持續(xù)的學(xué)習(xí)來(lái)破除日常工作中的困境，從而更好地實(shí)現(xiàn)組織的目標(biāo)。在本書(shū)的后續(xù)內(nèi)容里，“浪費(fèi)”一詞意味著這個(gè)更具現(xiàn)代感的定義，因?yàn)樗螪evOps所期望的理想境界。Mary和Tom Poppendieck在Implementing Lean Software Development: From Concept to Cash一書(shū)中描述道：浪費(fèi)和困境是軟件開(kāi)發(fā)過(guò)程中導(dǎo)致交付延遲的主要因素。下面是該書(shū)中描述的關(guān)于浪費(fèi)和困境的部分類(lèi)型：半成品：它指的是價(jià)值流里任何還沒(méi)有徹底完成的工作（例如，需求文檔或尚未審核的變更單）、處于隊(duì)列中的工作（如等待QA審核或服務(wù)器管理員審核的工單）。部分完成的工作會(huì)逐漸地過(guò)期，隨著時(shí)間的推移最終失去了價(jià)值。額外工序：在交付過(guò)程中執(zhí)行的、并未給客戶(hù)增值的額外工作，可能包括那些在下游工作中心從沒(méi)使用過(guò)的文檔，或是對(duì)輸出結(jié)果做出的并不增值的評(píng)審或?qū)徟?。額外工序不僅增加了處理的工作量，還增加了前置時(shí)間