2017年10月10日 星期二

DevOps HandBooks - 第二章 The First Way 流程的原則



鳳凰專案這本書中一直提到卻沒有詳細說明的三步法(不知道翻三扳斧如何XD),作者故意留到DevOps Handbooks 這本書才詳細說明,這就是傳說中得埋梗。

第一步: 流程的原則 (the principle of flow)


所謂的流程談論的就是如何有效率的傳遞價值流程( Value Stream):也就是從 Business 端產生想法和需求,到 Customer 真正使用並且給予回饋(不論是金錢或是評價),所以第一部流程的原則就是減少 lead time,也就是減少從需求到部署商轉的時間。

書中整理出優化流程的步驟,也是我們每天努力改善的項目:

1. 把工作視覺化 

2. Limit WIP


這兩個步驟應該不用多說,之前在鳳凰項目沙盤推演 workshop 遊戲流程也有提到,想要深入瞭解可以參考"看板實戰"。

3. 減少Batch Size (single piece flow)

4. 減少工作移交的數量



圖片來源:The DevOps HandBooks


所謂Single Piece Flow 翻成白話文就減少批次處理的量,最好是一次做好一件事,只要做到這點就能減少工作移交的數量,越多工作移交的數量,就會需要更多的溝通和更多的文件。


5. 持續找出並鬆綁瓶頸


這也是鳳凰專案中不斷引用高德拉特博士的移除瓶頸的聚焦五步驟

1. 找出系統的制約因素
2. 決定如何利用系統的制約因素
3. 根據上述的決定,調整其他的一切
4. 把系統的制約因素鬆綁
5. 加入四打破了原有的制約因素,回到步驟一


既然第一步是要找出制約的因素,作者也幫忙列出 DevOps 常見的瓶頸產生處:
  • 環境建立 (不管是開發和營運環境)
  • 程式部署 (程式從git 拉下來到部署到Production 需要多少時間?)
  • 測試建置與執行
  • 過緊密的架構

消除價值流中得困難和浪費


除了瓶頸外,在整個價值流中處處都可能藏著浪費,等著我們找出來消滅:

  • Particaly Done Work(開發過程中的半成品,甚至是等待review 的工作)
  • Extra Processes(對於客戶與開發沒價值的SOP/文件/簽核)
  • Extra Features(傳說中得 Over Design和 Gold plating)
  • Task Switching(萬惡的Content Switch)
  • Waiting(等待指示或簽核,等待資訊,等待誰同意....)
  • Motion/ Handoffs (工作交流和換手的過程一些資訊很有可能跟著遺失或變質)
  • Defects(不正確/遺失/不清楚的資訊和產品產生,從發現到解決拖的越長越浪費時間)
  • Nonstandard or Manual work (工程師都知道重複做超過三次的東西都該自動化~XD)
  • Heroics    

最後一點 Heroics (action that is dramatic)特別值得拿出來講,書中舉的例子就是為了達成組織的某個(恐怖的)目標,某些人或某些team 必須承受一些不合理的行動,而這些動作甚至會變成他們每天的工作,每次半夜兩點部署新的程式到Production ,都會產生一堆新的ticket 要處理(那變少測試,那邊要微調,那邊忘了升級,那邊配合人員沒通知....)

結論


瓶頸和浪費不會消失,但是希望可以透過視覺化的方式加速發現的過程,並且透過系統化的方式減少甚至消滅這些浪費。這時候就要透過第二步 Feedback 來幫忙。

謎之音


要注意!上面輕描帶寫的列出許多要改進的地方,要注意的事項,但是隨便一項就可以做到死,要怎麼從Day1 就把這些概念Build in 在日常的開發中就是硬實力,不是靠嘴巴講出來的,是要靠做出來的。這也是為什麼直到Docker出現後,DevOps 的議題才如烈火燎原般燒開,他從根本解決了許多瓶頸,有興趣可以參考這篇文章: Docker and the Three Ways of DevOps Part 1: The First Way – Systems Thinking





張貼留言