第二步: 反饋原則
資料來源: DevOps Handbook
A. 說明
讓系統從右向左的每個階段, 都能快速和持續獲得反饋
這樣的回饋可幫助, 在規模較小, 修復成本較低的情快下, 發現並修復問題
B. 做法
複雜系統的特點; 相同事情做兩次, 結果未必相同. 即使實行的靜態檢查 (static check) 和最佳實踐 (best practice), 還是不足以防止災難發生.
Steven Spear 建議可以採取以下步驟, 讓人們可以在複雜系統中更安全的工作
(1). 及時發現問題
產品開發本來就是一件很不確定性很高, 並且假設很多的活動. 要能又快又對, 需要一路上有資訊不斷回饋, 讓你可以及時調整, 並修正問題.
例如:
a. 持續整合部署機制: 不止測試自動化, static checking 也是不斷執行
b. 監控機制: 當系統出現可能的異常, 第一時間便會通知相關人員
(2). 群策群力解決問題, 並快速構建新知識
知道有問題發生還不夠, 一但知道問題發生後, 我們必須要同心協力, 一起來解決問題.
就像豐田的安東繩機制, 發生問題時及時拉下安東繩來解決問題, 如果無法在指定時間內解決, 就會停下整個生產線, 協調大家一起處理.
這樣做可以讓所有參與者得到深入的知識, 理解問題發生的脈絡, 把無法事先知道的問題, 學習後轉換成知識.
(3). 在源頭保障品質
做決策的地方, 一般和執行的地方相差很遠, 導致 review process 的有效性降低, 並且也拉長了決策週期, 讓回饋強度減弱.
應該要讓價值流中的人員, 在他們所在地方發現和解決問題. 而不是依賴於外圍高層管理者的批准和檢視.
例如:
a. 開發人員應該要多利用同儕間的檢視, 確保系統品質和即時回饋有落實 (pair programming, peer review)
b. 開發人員要自己測試自己的代碼, 不該等待到測試人員那邊才測試 (TDD, BDD, test automation)
讓每個人都負起質量的責任, 而不是某一個部門負責品質的確認. 這樣不但可以提高系統的品質, 也加速開發人員的學習.
(4). 為下游工作的人去優化
開發人員不是只要會客戶提供價值. 你還需考慮到下游內部的客戶, 像是測試人員和維護人員.
你如何讓自己寫的程式可測試性高點, 讓測試人員很容易觀察錯誤狀況, 或者控制受測程式的執行.
或者你的系統很容易安裝和升級, 並且要延展或是備份時, 也容易就可以處理.
這邊自己也有些心得:
(1) 層層保護網的設計
需要設計好層層關卡, 不同的保護措施, 這樣才能把風險降到最低. 前面階段花時間, 後面階段才能省時間, 這件事情不是每個人都接受, 並且花的時間分配也是個學問.
(2) 要對話, 不是聽話
回饋要能生效, 這個過程必須是個對話, 也就是雙方是有來來回回, 要有同理心, 不是只有一方說話, 也不是只是希望對方聽話, 這樣才能讓回饋機制真的生效.
或許你會說這過程大多是程式在進行, 哪有對話? 沒錯, 可是你應該也看過, 收到很多訊息通知, 但是都沒有反應或處理的狀況吧, 有時候太忙, 有時候還需要進一步釐清訊息是否正確, 這些都是需要進一步的對話.
好吧, 這些都是因為你在意, 你才會注意. 如果你只著重於自己事情是否做完, 這些機制可能對你來說都不是重點.
全站熱搜
留言列表
