DevOps的三條基本原則：流動/反饋/文化。第一條原則（流動）需要達成快速平穩地從開發向運維的價值流動，從而更快的進行價值交付。在這個過程中，作為開發或者運維的區域性目標被弱化，而開發和運維等協同所產生的整體的共同目標在這條原則中得到強化。
從業務需求到交付客戶，貫穿著從開發到運維的這條正向的通路。在這條原則的使用中，我們經常使用很多方式進行實踐以期達到交付價值的單位時間最大化，比如

而我們的目標則是降低變更交付到生產環境為止所需的時間以及提高交付的服務的質量和可靠性。

可視

區別於製造業最顯著的一個區別是：工作不像製造業那樣可視，而且也有著顯著的不同。就像製造業中的WIP，在我們實際的專案中也是一樣，由於沒有倉庫儲存的警告，浪費的發生在不經意間隨處發生，如果再加上缺乏有效管理，這些問題可能只有在快要著火的時候才會被察覺。
視覺化有很多種方法可以幫助到我們，比如看板等，通過這個我們能夠看到實實在在的任務，可以移動它從一個狀態改變為另一個狀態，確認整體的WIP狀況等等。如下是一個使用看板使用的例子

從這裡可以清楚地看到瓶頸，看到等待佇列，看到任務的分佈，以及在此基礎上可以做出的短時間範圍的預測。

限制半成品 (WIP)

像製造業那樣，控制半成品，可以達到消除浪費的目的，減少了庫存的壓力以及費用，同時更為重要的是使用原本在半成品上進行的時間和成本完成更多的交付，僅僅通過流程的控制就達到了交付能力的提升也是存活下來的製造企業最基本的實踐能力了。
軟體的開發的WIP不像製造業那樣很明顯地堆積，儲存的成本也不高，但是由此造成的更好的交付能力的下降卻是同樣的，舉個極端的例子，如果有100個功能模組，本來一個月可平均作10個，但是第一個月就同時展開30個，結果在第一個月和第二個月都沒有任何交付，到第三個月開始有爆發式的交付，結果給部署帶來極大壓力，以及bug同時出現需要對應，以及各種情況組合出現的各種複雜現象可以想象一下。
所以限制半成品非常重要，方法也很簡單。借用“Kanban: Successful Evolutionary Change for Your Technology Business”這本書的作者David J. Andersen所說的一句話進行總結：Stop starting. Start finishing.”

減小批次大小

作業內容的批次的大小會對交付和產生浪費的根源的等待產生什麼樣的影響呢?可以通過“envelope game”來研究一下。“envelope game”遊戲是James P. Womack 和 Daniel T. Jones在”Lean Thinking: Banish Waste and Create Wealth in Your Corporation”中提到的一個很有趣的遊戲。
拿“envelope game”這個精益練習中常用的遊戲為例，可以很容易地看出批次大小的調節能夠對交付產生的影響。遊戲的內容簡單說明如下：

使用不同的方式，Large Batches把Step 1的內容完成之後，才開始全部做Step 2的內容。而Single-Piece方式則是一個每次一小步。具體的等待和交付的情況如下圖所示：

可以看出，Single-Piece很快就可以穩定地提供交付成果了。有Agile經驗的開發者可能會立即意識到這在很大程度上簡單展示了傳統開發方式和Agile在價值交付方面差別。正是這樣，“小步快跑”避免摔跟頭，有問題也可以及時調整，這正是減小批次大小的意義所在。

降低手工作業次數

一旦當我們積累了數月以上的新功能特性或者修正後的模組，很多情況下在把應用部署到生產環境上會不可避免的碰到很多的手工作業，比如伺服器的設定/儲存的管理/網路的更新/負載均衡/安全管理等等，可能需要很多專案的技術高手也協同解決這些問題。
這些很難避免的手工作業，隨著次數的增加會導致溝通成本的上升，以及等待時間的顯著上升，因為這些技術高手一般都很繁忙。而且，在實際的情況下，手工作業也不可避免地造成部分資訊的丟失以及潛在隱患的埋下。
因此通過自動化或者其他流程上的改善，比如避免大規模的交付同時出現，以穩定可預期地方式穩定地更新和改善著交付給客戶的應用，能夠降低由此帶來的不好的影響。

持續評估

為了降低交付時間增加交付吞吐，需要持續確認和評估現狀以及可以改善的餘地。而這其中的關鍵則在於確認瓶頸然後再瓶頸上進行改善。正如TOC（Theory Of Constraints）的提出者Goldratt 所說的那樣：“In any value stream, there is always a direction of flow, and there is always one and only constraint; any improvement not made at that constraint is an illusion.”任何不再關鍵流程上的改善都不是真正的改善。
而如何找出這需要改善之處，Goldratt 博士也給出瞭解決的方法：五步聚焦法（“five focusing steps”）

在典型的DevOps實踐的過程中，可以使用五步聚焦法確認物件和進行改善。比如為了降低交付時間，需要改善的物件（Constraint）一般如下：

關於消除了主要制約因素的情況的美好情景，在這篇文章中已經有過說明。

消除困局和浪費

浪費在精益中被如下定義：

TPS(Toyota Production System)先驅者之一的Shigeo Shingo（新郷重夫）更是認為浪費就是對業務生存能力的最大威脅。Shigeo Shingo將製造業中的浪費分為七種。讓我們來看一下Shigeo Shingo所總結的”浪費的七宗罪”：

現代的精益實踐過程中逐漸意識到單純地消除浪費（eliminating waste）可能會帶來demeaning 和dehumanizing 的工作氛圍的風險。每個人都在象是工業時代的一個無法停止的自動揮動的扳手，任何不必要的動作則會陷入需要改善的反省中，完美對應的結果就變成了或者近乎變成了一個機器人。相反，通過每天的持續學習來解決單調乏味繁重無意義的工作困局和浪費以期實現組織的目標，這是現代精益實踐正在著力解決的問題。而這種現代對浪費的定義則更加接近我們所提倡的DevOps。
在精益軟體開發領域，同樣也有很多這樣困局和浪費一直在困擾著我們，比如：

而通過DevOps的實踐，逐步消除這些浪費和困局，將對專案的良性發展起到一個很好的推動作用。

總結

改善價值流的快速流動對達成DevOps目標非常關鍵，而我們可以通過工作視覺化/限制WIP/減小批次大小/降低手工作業次數等手段，並且持續評估和消除制約因素，從而更好地消除日常工作中的困境和浪費。

Referrence