《鳳凰項目-一個IT運維的傳奇故事》是一本比較神奇的書，用講故事的方式，展現了IT團隊（開發、測試、運維）在開發效能低、系統傳遞慢的情況下，通過實踐三步工作法，在團隊中實作加快系統傳遞、提升開發效能，使團隊走上DevOps之路。而且本書有一個值得稱道的地方是，通過類比制造業的工作流程，可以直覺發現技術團隊工作過程中隐藏的問題。
這裡需要提醒一下開發人員，看書的時候一定要佛系，因為這個故事是以運維角度展開的，有一些大罵開發的情節。如果是想找具體的DevOps工具的，建議不要看了，裡面沒有具體的工具介紹，是以最樸素的方式，講述DevOps的優勢和實踐。
先說一下概念：
價值流：一個組織基于客戶的需求所執行的一系列有序的傳遞活動。或者，為了給客戶設計、生産和提供産品或服務所需從事的一系列活動，它包含了資訊流和物料流的雙重價值。
技術價值流：把業務構想轉化為向客戶傳遞價值的、有技術驅動的服務所需要的流程。流程的輸入是需求，由開發部門完成開發，進行整體測試，部署到生産環境正常運作，并為客戶提供服務，以産生價值。
前置時間：從需求确認（開發接收需求）開始計時，到工作完成時結束
處理時間：從實際開始處理工作開始計時，到工作完成結束
等待時間：從需求确認（開發接收需求）開始計時，到實際開始處理工作時結束
在制品/半成品：價值流裡沒有徹底完成的工作、處于隊列中的工作。部分完成的工作會逐漸過期，随着時間推移到最終失去價值。
限制點：價值流中的瓶頸，即整個價值流流速的上限點。
第一步：流動原則
[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-QGhU9U9x-1581262477847)(https://www.howardliu.cn/images/devops/3-ways-first-way.png)]
第一步流動原則是為了打通技術價值流通道，實作開發到運維的工作快速從左到右流動。通過加速技術價值流的流速，縮短滿足客戶需求的前置時間，提高工作品質和産量，并使企業具有更強的競争力。相關實踐包括：持續建構、內建、測試和部署，按需搭建環境，限制在制品數量，建構能夠安全實施變更的系統群組織。
通過持續加強工作内容的可視化，減小批次大小和等待間隔，内建品質以防止缺陷向下遊傳遞，
使工作可視
在制造業，原料或半成品的堆積、訂單積壓都是直覺可見，産生阻塞的地方，就是限制點。但是在技術價值流中，很多問題是隐藏的，沒有辦法很明顯的看到阻塞和限制點。同時，因為資訊的不可見或者彼此資訊不全，可能将問題傳遞到下一環節，甚至上線時才出現問題，或者根本沒法傳遞。這就需要盡可能的将工作可視化，用來識别工作在哪裡流動、排隊、停滞。
一般，可以使用Kanban管理（來自日語，就是看闆）或Sprint計劃闆作為工具。
可視化管理中有一個需要注意的地方，要着眼全局目标，而不是局部目标。全局目标是增加系統品質，提升開發效能，局部目标是開發的完成率、測試的缺陷數、系統的可用性等。不是說局部目标不重要，這些局部目标需要其他方式來優化，我們現在需要提升整體的效率，一旦我們陷入細節中，就是一葉障目不見泰山，沒有辦法把握全局了。也就是吉恩•金所說的“不允許局部優化造成整體性能下降”。
限制在制品數
工作可視化之後，就可以開始有素質的找茬了。
第一步，限制并行任務。為什麼？因為如果有并行任務，我們就需要花時間切換任務。有一種說法，如果同時進行兩個任務，會有20%的時間用于切換任務，比如理清思路、進入狀态、恢複工作環境等。如果是三個，那就會有40%的時間用于切換任務。并行任務越多，用于切換任務所花費的時間越多，造成的人力浪費越多。并行任務減少之後，浪費的時間減少，花費在工作上的時間就增加了，整體的傳遞效率也相應的提升。如果是用的是看闆管理，可以通過限制每一列或每個工作中心在制品（并行任務）數量，并把卡片數量的上限标記在每一列上。
減小批量大小
這個就是靈活中提倡的小步快跑，先傳遞，先嘗試，就可以先試錯，先改錯，有問題可以及早暴露，不至于最後內建一個大疙瘩，無力回天。
這裡不得不提持續部署，相信很多團隊在使用持續部署工具，比如Jenkins，代碼送出之後，觸發Jenkins工作流，開始進行編譯、測試、部署和釋出。我們要做的就是小批次的送出代碼，這部分代碼被編譯、測試，如果有問題，能夠盡早發現，如果沒有問題，經過測試釋出到正式環境，就能夠及早的呈現給客戶。
減少交接次數
在傳統的IT團隊中，代碼從開發完成到部署上線需要經過N多個部門，每個部門有自己的KPI，有自己的任務排期，不同部門溝通需要成本，工單審批需要時間，這樣就造成了傳遞時間的延長。另外，不同部門對于一個功能的認知有自己的認知陷阱，開發認為理所當然的時期，運維可能根本不了解。資訊的隔離，可能造成一些已知的缺陷沒有及時傳遞到下遊，出現各種返工的情況。
為了減少這種交接，可以引入自動化方式完成大部分的操作，或者調整架構，讓團隊盡量少的依賴于其他人。
持續識别和改善限制點
限制點就是瓶頸，如果整個團隊中存在限制點，傳遞工作流就會有瓶頸。随着工作的優化，限制點之前的工作會堆積到限制點，而限制點之後的角色因為任務還沒有到達，可能出現等待的情況。想要提升整體的效能，必須找到限制點，并進行拓寬，才能增加任務的吞吐量，任何不針對限制點進行的優化都是假象。
一般按照下面的步驟拓寬限制：
識别限制點，任務隊列最長的角色，就是限制點；
根據找到的限制點，找到拓寬限制點的方式；
根據2中的決定，考慮全局工作；
改善系統的限制點；
如果限制已經拓寬，整個工作流中會出現新的限制點，重複上面的步驟。
消除價值流中的困境和浪費
想要提升傳遞效率，除了開源，還需要節流。減少任何超出客戶需求和他們願意支付範圍的任何材料和資源：
半成品：價值流裡沒有徹底完成的工作、處于隊列中的工作。部分完成的工作會逐漸過期，随着時間推移到最終失去價值。比如沒有确認的需求、等待評審的變更。
額外工序：在傳遞過程中執行的、并未給客戶增值的額外工作。比如對下遊沒有使用過的文檔，或者對輸出結果沒有增值的評審。
額外功能：在傳遞過程中建構那些組織和客戶完全不需要的功能，還沒有到鍍金階段，卻要浪費時間在鍍金上，鍍金的功能會增加功能測試和管理的複雜度和工作量。
任務切換：将人員配置設定到多個項目或價值流中，因為會出現任務切換，會在價值流中耗費額外的工作流和時間。
等待：由于資源競争産生的等待，這将增加周期時間，延遲向客戶傳遞。比如等待其他部門配合。
移動：資訊或資料在工作中心之間移動的工作量。比如對于那種需要頻繁溝通的人員不在一地辦公，人員移動就産生浪費了。或者工作交接也會産生移動浪費，需要額外溝通。
缺陷：由于資訊、材料或産品的錯誤、殘缺或模糊，需要一定的工作量來确認。缺陷的産生和被檢測出來的時間間隔越長，解決問題就越困難。
非标準或手工操作：需要依賴其他人的非标準或手動的工作，比如手動部署系統
填坑俠：為了實作組織目标，不得不把有些人和團隊置于不太合理的處境。
隻有解決了上面的八種浪費，系統的改進，減輕或消除這些負擔，實作快速流動的目标。
第二步：回報原則
第一步工作法是為了使工作能夠在價值流能夠從左向右流動，第二步工作法是建立從右到左的每個階段能夠快速、持續獲得工作回報的機制。該方法通過放大回報環防止問題複發，并能夠縮短問題檢測周期，實作快速修複故障。我們的目标是從源頭控制品質，并在流程中嵌入相關知識；創造更安全的工作系統，在故障或事故發生前檢測到并解決它；最終建立安全和可靠的工作系統。
一般來說，發現和糾正問題最好的時機是發生故障時，隻有發現問題，才能夠解決問題。通過在整個工作流群組織中建立高品質的回報機制，就可以在規模比較小、成本比較低的情況下修複系統。在災難發生前消除問題，并創造出組織性學習氛圍。
在複雜系統中安全地工作
複雜系統的一個重要特征是無法将系統視為一個整體，系統中的各個元件之間通常是緊耦合且緊密關聯的，不能僅僅依據元件的行為解釋系統的行為。複雜系統中故障存在且不可避免，是以我們需要設計一個安全的工作系統，可以讓工程師們在系統中無所畏懼的開展工作，也就是各種折騰，這樣才能在災難發生前，快速檢測出錯誤。可以采取下面4項措施讓負載系統更加安全：
管理複雜的工作，從中識别設計和操作的問題
群策群力解決問題，進而快速建構新知識
在整個組織中，将區域性的新知識應用到全局範圍
上司者要持續培養有以上才能的人
及時發現問題
想要及時發現問題，一般有兩種做法：被動等待、主動試錯。
通常，我們會搭建監控系統、設定多元度名額，對系統進行監控，當系統發生故障時，相關人員會收到報警資訊，針對報警資訊開始定位解決問題。這種方式屬于被動等待的做法，因為要等待故障發生，故障發生的時機不可控，可能發生在上班的時候，更有可能發生在晚上睡覺時、周末休息時、休假旅遊時，還有的會在結婚交拜的時，但是這種方式又不能沒有，被動等待所搭建的監控系統是主動試錯的基礎。
主動試錯就是在安全的工作系統中，不斷對設計和假設進行驗證，這種方式兩個關鍵詞是主動、安全。如果我們驗證過程中把生産系統弄癱了，那就笑話了。這樣做的目标是更早、更快、以最低的成本、從盡可能多的次元增加系統的資訊流，并盡可能清晰的确定問題的前因後果。能排除的假設越多，定位和解決問題的速度就越快。同時，這個過程也是練兵的過程，能很好的學習和創新。
群策群力，戰勝問題擷取新知
這個是承接“及時發現問題”的，因為發現問題之後，需要解決問題，我們需要發動所有相關人員，群策群力，解決問題。出現問題的時候，最忌諱的是繞開問題或者用“時間不夠”這類理由搪塞。我們要做的是不惜全面停産，也要把問題解決。
至于為什麼要相關人員都參與到解決問題中，理由如下：
相關人員參與定位和處理問題，能夠讓大家更深入的了解系統，把無法規避、早期無知階段變成學習的過程。
能夠防止把問題帶入下遊環節，一旦進入下遊環節，修複成本和工作量将呈指數增加，還會欠下技術債
阻止啟動新的工作，問題不解決，就開始新的功能，就會引入新的問題
不解決問題，故障就會再次發生，修複成本更高
在源頭保障品質
這點主要是針對QA和開發兩個部門，有點類似國家政策：“誰污染誰治理”。在日常工作中，我們需要價值流中的每個人在他們的控制領域内發現并解決問題，通過這種方式，可以把品質控制、安全責任和決策制定都置于開展工作的場景裡，而不是依賴于外圍高層管理者的審批。
比如開發人員開發過程中，可以使用自動化測試，不依賴于測試團隊，這樣，開發人員就能夠在任何需要的時候快速測試自己的代碼，經過完善的自動化測試，就可以把代碼部署到正式環境中。這樣，自己對自己負責，同時也是對他人負責。
為下遊工作進行優化
這點負責的是精益原則：我們最重要的客戶是我們的下遊，為下遊優化我們的工作，需要我們對他們有同理心，更好的識别可能阻礙快速平滑流動的設計問題。比如開發需要為運維優化自己的工作，比如架構、性能、穩定性、可測試性、可配置性、安全性等一系列特性，這些優化工作，和給客戶提供功能同樣重要。
第三步：持續學習與實驗原則
第一步建立從左到右的工作流，第二步建立從右到左的回報機制，第三步就是要建立持續學習與實驗的文化，通過提升個人技能，進而轉化為團隊群組織的财富。
這一步的核心是建立高度信任的文化，這種文化強調每個人都是持續學習者，在日常工作中，主動承擔風險；通過安全的方法改進工作和開發産品，從成功或失敗中積累經驗，進而識别有價值的想法，摒棄無價值的想法。個人的努力帶動整體的進化，幫助整個團隊嘗試和實踐新技術、新方法。
必要的做法包括營造一種勇于創新、敢于冒險（相對于畏懼或盲目服從指令）以及高信任度（相對于低信任度和指令控制）的文化，把至少20%的開發和IT運維周期劃撥給非功能性需求，并且不斷鼓勵進行改進
建立學習型組織和安全文化
在複雜系統中，精确預測出結果是不現實的。也就是說，無論我們怎麼小心，故障總是會發生。
Westrum模型提出組織文化的三種類型：
病态型組織的特點是大量的恐懼和威脅，傾向于隐藏失敗。
官僚型組織的特點是嚴格的規則和流程，每個部門各掃門前雪，在這種組織中，通過評判系統處理事故，采用恩威并施的手段。
生機型組織是積極探索和分享資訊，在這種組織中，整個團隊所有員工共同承擔責任，對事故積極反思并找到根本原因。
第三步推崇的就是生機型組織，在故障發生時，團隊關注的是如何設計安全的系統，防止事故複發，而不是追究人的問題。正如Etsy的工程師拜塞尼•馬克裡說的：“不指責，就沒有恐懼；沒有恐懼，就能夠坦誠；坦誠能夠有效的預防事故。”
将日常工作的改進制度化
在技術價值流中，為了防止災難性事故的發生，團隊會陷入實施各種臨時解決方案的工作中，這樣就沒有時間去完成那些有價值的工作。是以，用臨時方案解決問題的模式，會導緻問題和技術債務的累積。是以，我們需要在日常工作中留出時間來改善日常工作，比如償還技術債務、修複bug、重構和優化代碼等，這就要求我們的團隊在開發間歇中預留一段時間，可以讓團隊成員解決問題。一件事情的果總會是另一件事情的因。我們在把日常問題解決了，有助于發現和解決潛在風險，或者有更多的精力去做更多有意義的事情。
把局部發現轉化為全局優化
局部發現轉化為全局優化就是說要在團隊中做到先富帶動後富。單個團隊或個人獲得了某種獨有的知識或經驗，應該把這種隐性知識（難以通過文檔或溝通方式傳遞的知識）轉換為顯性知識，建立全局知識庫，形成集體智慧。當其他人做類似的工作時，隻需要在知識庫中搜尋，就能夠很快找到前輩的經驗。
在日常工作中注入彈性模式
這樣做的目标是為了給團隊或系統增加彈力，提升抗脆弱性。想要抗脆弱，就要知道脆弱點在哪。根據前人的經驗，我們可以通過縮短部署實踐、提高測試覆寫率、縮短測試執行時間、系統解耦等方式，提升系統的彈力。我們可以通過故障演練，比如随機的拔網線、關電源、殺程序（比如Netflix的Chaos Monkey）等，能夠驗證系統的恢複能夠力。我們還可以通過壓測（單接口、全鍊路）來測試系統的瓶頸和上限。
上司層強化學習文化
這點是說給上司聽的，優秀的上司力不是展現在做出所有的決定都是正确的，而是能夠為團隊創造條件，讓團隊在日常工作中感受到這種卓越。因為上司者不會親自參與到一線工作，一線工作者也不了解大的組織環境或者不具備工作領域以外做出改變的權利，是以上司者與一線工作者之間是互補關系，必須互相尊重。
最後
DevOps三步工作法作為支撐DevOps的基礎原則，也衍生出了DevOps的行為和模式。相信很多團隊已經開始走DevOps之路了，下面列出來4個階段：
隻有Dev沒有Ops，所有的事情開發自己搞定。
有Dev也有Ops，他們互相獨立，Ops承接了開發代碼之外所有的工作。
Dev+Ops，Ops做了一些自動化的工具提升效率，但主要是給自己去用，開發不用。
DevOps，在上遊工作的開發願意使用下遊的運維提供的系統或平台，通過API自助、自動的完成相應的工作。
可以看下自己處于那種階段，如果沒有達到，可以參考上面的三步工作法，一步一步的實作DevOps。