趁著農曆假期，再次把這本前陣子就拜讀完的經典書悠閒地翻閱一次 。將感興趣的部分整理成筆記，也打算拿來以後提醒自己以及定期反思用。
本書書名是“DevOps Handbook”，可看出很適合遇到卡住的點時，拿來翻閱參考用。
另外書厚度約350頁，沒時間看的朋友也可以加減參考。
本書分成六大章節，分別為
Part 1：三步工作法
Part 2：從何處開始
Part 3：第一步工作法：暢流的技術實踐
Part 4：第二步工作法：回饋的技術實踐
Part 5：第三步工作法：持續學習與實驗的具體實踐
Part 6：整合資訊安全、變更管理和合規性的技術實踐
///// 以下是 Part 1 的書摘筆記 /////
- Value Stream Mapping (價值流程圖)
- 起源為製造業，為豐田精益製造(lean manufacturing) 生產系統框架下的一種用來描述物流和信息流的形象化工具。
- 目的是辨識和減少生產過程中的浪費。Reduce "Work in process, WIP" & rework
- 對照到科技產業：
 |
“ The process required to convert a business hypothesis into a technology enabled service that delivers value to the customer. ”
“以科技轉化商業構想，向客戶交付價值所需的流程。從需求提出到開發、測試、部署、發布、營運整個的過程”
- Value stream 始於工程師（含開發、QA、IT營運和資安人員）向版本控制系統提交一個變更，結束於這個變更在Production環境中成功運行，為客戶帶來價值，並產生有效回饋和監控資訊。
- Deployment Lead time (部署前置時間）
- 本書重點之一，A subset of whole value stream。
- Lead time(前置時間)：從需求提出到需求被滿足的整個週期，也通常是客戶真正體驗到的時間。
- Process time: 從開始工作到工作結束。不包含in queue waiting time
- 重點擺在縮短前置時間。
- 在複雜組織中常見的、耗時數個月的科技價值流（下圖）。
(好複雜XD)
- DevOps目標：部署前置時間只需要數分鐘。
- 達成目標的關鍵行為：小批量程式碼變更、自動化測試、探索測試、模組化、高內聚、低耦合架構...
- 三個關鍵指標：Lead time 、Process Time以及重工指標( %C/A)
- %C/A：下游端有多少%的時間接收到“真正可用”的工作。
- The Three Ways(三步工作法)
- 第一步：The Principle of Flow (暢流原則)
- 第一步是讓工作具有可視化，可透過大家耳熟能詳的看板(Kanban) 或者Sprint計畫板，讓目前的task位處於哪個狀態一目了然。
- 限制再製品數量(WIP, work in process)可幫助辨識阻礙快速流動的問題，另外同時處理多任務會造成更漫長的處理時間。
- 每一次工程師的code Check in 盡量維持小規模，更快的檢測出錯誤，減少重工。
- 盡量透過減少交接次數、自動執行作業以及調整組織結構，讓團隊不需依賴他人就可以獨立為客戶提供價值。
- 辨識系統中的constraint：根據經驗，通常依序要改善以下約束點。
- 環境佈建
- 程式碼部署
- 測試準備和執行
- 過度耦合的組織架構
- 開發部門或產品經理有可能是以上問題解決完後接下來的約束點（要盡可能提升個人和團隊的生產力）
- 浪費和困境的類型：半成品、多餘加工、不被需要的功能、任務切換、等待、motion(如工作交接、資訊需要過多轉移溝通和釐清)、瑕疵、家常便飯的救火、非標準化或手動作業。
- 第二步：The Principle of Feedback (回饋原則)
- 在問題發生時立即察覺：目標包含建立自動化機制建構、整合與測試流程，同時搭配遙測技術，以監控每一個組件在 production environment 的運行狀態。
-
聚集並解決問題，建構新知識：建立等同“豐田安燈索(Toyota Andon Cord)”和相對應的蜂擁式對策(Swarming)，同時建立讓人可以在出現差錯時勇於拉動 Andon Cord 的組織文化。一但拉動Andon Cord，所有人必須蜂擁而上共同解決問題。
 |
| Source: Andon system from https://medium.com/serious-scrum/andon-processes-can-help-your-team-value-fire-prevention-over-fire-fighting-23fdeee504f5 |
- 將品質意識推進至源流：利用Peer reivew來確認變更可以按照設計方式運行。盡量將過去由只有QA霍伊安部門才可執行的Test自動化，Developer可隨時依需求執行這些測試，確保品質。
- 為下游工作中心提供改善活動：精實法則認為最重要的消費者是接續我們下一階段的人。藉由設計完整的作業流程來優化下游工作中心。注重Quality at the source。
- 第三步：The Principle of Continual Learning and Experimentation 持續學習與實驗原則
- 激發學習與安全的組織文化：問題發生時採行一種“不怪罪任何人的事後驗證(blameless post-mortems)”，快速釐清原因，在改善系統方面取得最佳對策與共識，防止問題再度發生，加快檢測和復原速度，此做法可以建立《第五項修煉》中的學習型組織。下圖由左到右分別為病態型組織、官僚型組織以及賦生型組織，以賦生型組織型態為最佳．
- 將日常工作的改善制度化：比日常工作更重要的就是“改善”日常工作( Lean IT, Mike Orzen)。刻意排定時間解決技術債、修復瑕疵，重新建構與改善程式碼和開發生產環境，將修復問題視為日常生活的一部分。
- 將局部發現轉化為全域改善：建立“不怪罪任何人的事後驗證”報告、組織共享的open source，讓這些改善局部系統而產生的新知識可被在全組織內流通以及被查詢。
- 在日常工作中注入韌性模式：
- 低效能製造業組織運用大量囤貨、增加緩衝區、購買更多資本設備和生產人員等方式緩解生產中斷。而高效能組織則透過持續改善日常作業流程，不斷引入緊張局勢來提升績效，同時強化組織韌性。
- 在科技價值流中，可嘗試縮短部署前置時間、增加測試覆蓋範圍、縮短測試執行時間。可舉辦Game day演練大規模故障應變或 Netflix 著名的“搗亂猴”在生產環境中隨機殺死程序和運算server。
- 由領導者強化學習文化：
- 領導者必須深刻認知學習和有效解決問題的珍貴價值。比照科學實驗方法，明確指出欲解決的問題、解決對策的假設、測試假設的方法、對於結果的詮釋，以及下次iteration如何運用。
- 領導者在指導組員時，可提出引導式的問題。
- 你的最後一步是什麼？發生了什麼？
- 學到了什麼？
- 現在的狀況是？
- 下一個目標條件是什麼？
- 你目前正克服什麼障礙呢？
- 下一步打算怎麼做？
- 預期結果是什麼呢？
- 何時可以檢驗成果呢？
(好的開始是成功的一半，下一篇來看看要怎麼開始DevOps....）
////// Reference //////
- https://wiki.mbalib.com/zh-tw/%E4%BB%B7%E5%80%BC%E6%B5%81%E7%A8%8B%E5%9B%BE
- Andon system: https://medium.com/serious-scrum/andon-processes-can-help-your-team-value-fire-prevention-over-fire-fighting-23fdeee504f5
若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。
沒有留言:
張貼留言