鳳凰計畫中提到三步工作法, 他是一個落實 DevOps 的基礎原則, 透過這些能使工作有效率, 並且達到全局優化. 但是在鳳凰計畫中似乎沒有太多描述, 因此特別翻了一下 DevOps Handbook, 期待能了解更多內容, 以下是一些重點記錄和心得.
第一步: 流動原則
A. 說明
建立從開發到運維之間的快速流動, 讓客戶的價值可以被快速交付.
B. 做法
(1) 使工作可視
軟體的開發工作, 在過程中常常是無法被人看見其狀況. 所以你不知道哪邊遇到困難, 哪裡堆積很久. 為了幫助流程順暢, 我們需要將工作流程給視覺化.
看板是一種可以將工作流程視覺化的工具. 基本上, 要從需求提出開始, 到需求上線為止, 整個端到端的處理流程
(2) 限制同時處理的工作數量
多工其實是讓工作變慢的原因之一. 開發人員在不同專案或是任務之間切換, 中間需要花很多時間了解上次做到哪裡, 這些都是浪費.
(3) 減少批量大小
以前開發時, 通常一口氣都是做一堆功能, 常常造成時間要花費很久, 並且整合起來複雜度也很高. 如果每次我們只處理小量功能, 不但整體處理時間較少, 也比較不會出錯.
在 The principles of Product Development Flow 一書, 有專文介紹大批量和小批量的 cost, 有興趣的可以去看看.
(4) 減少交接次數
當工作在不同角色或是不同部門之間傳遞時, 往往會造成資訊量失真減少. 並且, 雙方工作頻率不同, 工作可能要等待下一關有空, 才能處理得完; 或者上一關太慢, 下一關沒事做.
為了減少這類問題的出現, 我們要嘛減少交接次數, 要不就是把這些工作給自動化進行. 前者需要調整組織結構, 並且要讓工作人員有能力處理較多不同性質的工作. 後者, 需要花時間建置自動化機制和平台.
(5) 持續識別和改善瓶頸
高德拉特在目標一書中提到, 一個系統中總是會有一個瓶頸. 在非瓶頸的地方進行改進都是假象, 對改善系統效率沒有幫助.
書中提到如果要改進工作流程的效率, 一般需要依序優化以下瓶頸:
a. 環境建置
如果環境建置需要很長的時間, 價值的交付自然也要很久. 因此需要建立完全自動化的服務環境, 讓團隊需要環境時, 很快就可以自動產生.
b. 系統部署
當系統已經完成, 需要複雜和繁瑣的步驟才能安裝好, 這不但耗時且容易出錯. 因此這裡也需要以自動化方式處理
c. 測試的準備和執行
即使系統雖很快被部署到用戶環境, 但若沒有經過嚴密的測試, 這是非常危險的一件事情. 尤其當系統有大量的舊功能時, 回歸測試的處理會花很久, 如果可以有自動化測試來輔助, 才能縮短上線時間
d. 架構拆解
當系統是一個龐大並且緊密耦合的架構, 每次做些變更時, 會導致很多地方受到影響, 不但修改時間很長, 測試時也需要每個地方都確認一下, 這樣是不利於快速交付的. 因此, 需要修改成鬆散耦合的架構, 才能應付頻繁交付.
(6) 消除價值流中的浪費
在精實思維中, 浪費是導致系統變慢的重要因素. 但是要消除這些浪費前, 你需要先知道哪些地方有浪費. 在 Implementing Lean Software Development 一書中, 提到了幾種常見的浪費:
a. 半成品
b. 額外工作程序
c. 額外功能
d. 任務切換
e. 等待
f. 移動
g. 缺陷
DevOps Handbook 的作者又補上兩條
h. 非標準或手動操作
有些地方沒有標準化, 需要手動操作, 或者要依賴某些人來做. 這部分就是一個值得消除浪費的點
i. 填坑俠
為了讓組織的目標能達成, 會犧牲某些人或部門, 讓他們在不合理的時間或是環境工作, 例如半夜工作, 或者是用人海戰術來取代自動化等等.
整理完第一部分後, 自己有些小小的心得
(1) Kanban board 的設計是關鍵
Kanban board 的設計是關鍵的技能. 目前大多數的 task board 有以下問題
a. 無法顯示端到端的整個流程
大多人都只是 scrum board, 都只是顯示開發端的工作, 但是需求的處理, 系統的部署, 這些都沒有被一起考量
b. 看不出哪裡是瓶頸
在 task board 中只看到 in progress 塞了一堆便利貼. 需要去細看才知道問題出在哪些, 在 task board 無法一下分辨出哪裡出了問題
c. 無法依據 taks board 上的資訊做出決策
即使看出哪裡有問題, 上面的資訊也無法讓你做出判斷, 接下來要如何怎麼辦, 例如: 跟誰或部門有關, 接下可以處理哪個工作, 他同時做這麼多 task 還是只有在忙其中某些 task 等等
(2) 沒有測試自動化, 品質的問題怎解
很多人實施 DevOps 只是把部署和監控機制做好, 但是並且測試自動化, 或是什麼確認品質的機制, 去確保系統是運作正常的. 完全是讓用戶當你的測試人員. 這不是快速失敗, 快速回饋, 這會快速滅亡的.
(3) 沒有測試自動化, 重構架構是不可能的任務
要重構一個複雜或是緊密耦合的系統, 但是沒有測試自動化的安全網, 我不太了解如何有保握不會出事, 感覺起來就是在賭人品好不好, 人品好可能就沒事, 人品不好或許就可以考慮或地方再重新培養人品了.
看板方法 和 測試自動化 對 DevOps 來說重要嗎?
如果是, 提的人好像不多.
如果不是, 那品質和架構問題如何解呢?
下一篇: 筆記: 三步工作法之反饋原則
全站熱搜
留言列表
