從系統思考角度談 DevOps 三步工作法

Conference: DevOpsDays Taipei 2024.
Date: 2024-07-11.

Description:

DevOps 世界有許多迷人的技術與工具，但若只關注技術與工具，反而可能讓 DevOps 更惡化。你更需要一套流程與原則，引導你辨識出需要改變的個人與團隊心態，引導你在適當時機辨識出最值得逐步導入的技術與工具，才能讓技術與工具成為你推動 DevOps 的助力。

Gene Kim 博士提出的「三步工作法」，就是一個似拙實巧的流程。如果你掌握它的核心原理，懂得哪些地方可以因時因地制宜，哪些地方卻應該堅持，那麼它就是一個很有威力的流程，能夠幫助你在心態上與技術上都走在 DevOps 的正軌，且持續走下去。

此講座將根據《The DevOps Handbook》剖析三步工作法的原理，並分析實施時會遇到的阻力及因應之道，讓你在 DevOps 路上面對眾多挑戰時有個清楚的路標。

Transcript

1. 從系統思考 角 度 談 DevOps 三步 工 作法 Dissecting DevOps Through the Lens of Systems Thinking William Yeh ໢٢ࡪ DevOpsDays Taipei 2024 2024-07-11
2. Elevator pitch in 1 minute
3. 研討會症候群
4. xxx? 2024-07-10 Paul Hammant ＠ DevOpsDays Taipei 「比不上別 人 」的焦慮⋯⋯
5. 「非得做些什麼事情」的焦慮⋯⋯ ➊ • Lead time for changes • Deployment frequency Should we do it first? “1 planned release every day” lengthy process What if we get stuck here? “Our organization is more special than Google”
6. 「遠遠不夠」的焦慮⋯⋯ Jez Humble 在 The DevOps Handbook 2/e 後記 把專注焦點放在 工 具和組織架構上比較簡單—— 這些事情當然很重要，然 而 遠遠不夠。
7. 重劍無鋒， 大 巧不 工 第 一 步：暢流 Flow (forward) 第 二 步：回饋 Feedback 第三步：持續改善 Continuous improvement 這三招就夠了嗎？聽起來也未免太簡單了吧？ 三步 工 作法 “The Three Ways” Continual Learning and Experimentation
8. Dissecting key success factors 關鍵要素 第 一 步：暢流 Flow (forward) 第 二 步：回饋 Feedback 第三步：持續改善 Continuous improvement 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 stock flow dissecting…
9. 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Causal relation (overall and simpli fi ed) ➊
10. 長期主義 因果關係清晰度 內在品質 全局可視化程度 Alternatives are helpful when you get stuck… ➊ lengthy process
11. Elevator pitch in 1 minute • Having heard many ideas at this conference, some of you might feel overwhelmed or confused. • If this aligns with you, it may be time to learn about the renowned "Three Ways" principles of DevOps: fl ow, feedback, and continuous improvement. Despite its apparent simplicity, the material holds signi fi cant value, enriched by my experience across multiple sectors. • In this lecture, we'll analyze the concepts from the perspective of stock and fl ow, ... • ... equipping you to identify essential leverage points for advancing your DevOps journey. • This is an introductory session, so experienced DevOps practitioners may choose to skip it if they prefer. 研討會症候群 重劍無鋒， 大 巧不 工 。 洞察：視 角 & 底層邏輯 ◄ ◄ ◄ 落地：槓桿點 ◄ 通識級講座 原本是投稿在入 門 班 ◄
12. 雖然「三步 工 作法」乍看之下就像達成 DevOps 的三個循 序步驟，但從原 文 的 角 度來看，作者使 用 的並非是 Step (步驟) 這個單字， 而 是使 用 Way ( 方 法、 方 向和途徑)。 這意味著：三步 工 作法更像是三種指導原則，來告訴 DevOps 實踐者可以根據這三個原則來思考如何進 行 或持 續改善 DevOps。 The Three Ways 盧建成 《駕馭組織 DevOps 六 面 向》§7.2 fl ow, feedback, continuous improvement
13. ➊ Continuous improvement Continual Learning and Experimentation 原 文 是更積極的，但今天先談較 小 規模的 “improvement”
14. From 5 years to 46+ years… As originally designed, the Voyagers were to conduct closeup studies of Jupiter and Saturn, Saturn’s rings, and the larger moons of the two planets… Change & fi x • 2023-04-29 / 45 歲還能 工 作！NASA 延長航海家 2 號儀器 3 年壽命 • 2023-08-05 / 發出「星際吶喊」！NASA跟「航海家2號」成功重建全部聯繫 • 2023-10-24 / NASA 開發新的修補程式，讓航海家推進器延壽五年
15. Year 1977 of Voyagers 內在品質 存量 (stock) 如果「內在品質」是 一 個可以計算、可以加減、可以累計的數字⋯⋯
16. Year 1977 of Voyagers 內在品質 存量 (stock) 我們可以 用一 個「浴缸」的「蓄 水 量」來比喻這個可以計算、可以加減、可以累計的數字。
17. Year 1977 → 1990 of Voyagers decay ruin 流入量 (in-flow) improvement 動 力 消耗 原始任務改變 Entropy (熱 力 學第 二 定律) … 電漿 & 宇宙射線 固體撞擊 工 程師 手 殘 … 流失量 (out-flow) debug patch … 這個浴缸的「蓄 水 量」，會流失⋯⋯
18. Stock & fl ow view of software quality 內在品質 存量 (stock) 流失量 (out-flow) 流失量 (out-flow) 流入量 (in-flow) decay ruin improvement
19. Decay over time… 由於混亂和不確定性， 工 作流程會隨著時間益發低迷，直 至 失效。 The DevOps Handbook, 2/e, §4.2 內在品質 decay Environmental change Obsolete hardware Obsolete OS Obsolete PL Obsolete tool chains … 打開 decay 的 水 龍頭⋯⋯
20. “Change” is inevitable… 如果軟體有 人 使 用 ，就很可能需要修改。這是件好事，它 意味著 用戶 找到了從軟體中獲取更多價值的 方 式。 如果軟體會被使 用 ，那麼它便會被修改， 所以它必須被編寫得可以被修改。 《修改軟件的藝術》§4
21. “Change” is inevitable… But may get worse over revision 大 部分軟體，程式碼糾纏不清，雖然正常 工 作，但是由於 其編寫的 方 式導致難以修改，所以 人 們只好蠻 力 修改，讓 它以後的修改成本變得更 高 。 《修改軟件的藝術》§4 內在品質 ruin 打開 ruin 的 水 龍頭⋯⋯
22. A careless fi x’s unforeseen consequences… 如果 一 味逃避解決問題， 而 頻頻仰仗變通措施，持續累積 問題和技術債，最終我們的 日 常 工 作將完全 用 來執 行 這些 臨時變通 手 段， 而 沒有多餘時間進 行生 產性的 工 作。 《修改軟件的藝術》§4.2 內在品質 ruin Problem
23. 內在品質 ruin Problem quick fix issue raised 數字望 大 數字望 小
24. 內在品質 ruin Problem quick fix issue raised 飲鴆 止 渴 Fixes that Fail 飲鴆 渴 後遺症
25. “5S” methodology applied to DevOps Legacy code 的產 生 是因為有 人 認為：程式碼的品質 並不重要，重要的是軟體正常 工 作。但這是個錯誤的 認知。 我遇到過最快速的程式員，特別注意讓他們的程式碼 保持容易維護。他們不會不顧程式碼品質 而 加快速 度，反之，因為他們保持了程式碼的 高 品質，才能保 持快速撰寫程式。 《修改軟件的藝術》§4 Inspired 整理 (SEIRI), 整頓 (SEITON), 清掃 (SEISO), 清潔 (SEIKETSU), 素養 (SHITSUKE) 關鍵存量 關鍵流量
26. Problem issue raised 內在品質 數字望 小 關鍵存量
27. 內在品質 Problem issue raised fundamental fix improvement refactoring aggressiveness 數字望 小 關鍵存量 關鍵流量 數字望 大
28. 長期主義 比 日 常 工 作更重要的，就是『改善』 日 常 工 作。 持續的流程改善、架構演變、 文 化變 革 、產 生 持久影響的 團隊合作，著實不易。把專注焦點放在 工 具和組織架構上 比較簡單——這些事情當然很重要，然 而 遠遠不夠。 The DevOps Handbook, 2/e, §4.2 & 後記
29. https://www.facebook.com/merlionpeng/posts/pfbid02ZsKY8Vag4Bm2WjPRd1dt6WDdsQB9nyhVLthy47EhVhHy69YkFRjB227vXbgJzKpvl
30. 公有地悲劇 Tragedy of the commons workforce capacity emphasis on long term sustainability capacity for feature development to dev capacity for long term improvement to improve capacity for quick fix to quick fix
31. 以「投資組合」 角 度視之⋯⋯ 2024-07-10 Jugg ＠ DevOpsDays Taipei
32. 解法 一 ：保留 一 定比例的額度 為了有效管理技術債，要確保 至 少把 20% 的開發和營運 週期投入到重構、 自 動化 工 作、架構優化以及非功能需求 上。 如果組織連這『20% 的稅』都不願意 支 付，那麼技術債 將會持續惡化，最終消耗組織內所有可 用 資源。 The DevOps Handbook, 2/e, §6.3.3 Inspired
33. 解法 二 ：透過 Error budget 動態調整 As long as the system’s SLOs are met, releases can continue. If SLO violations occur frequently enough to expend the error budget, releases are temporarily halted while additional resources are invested in system testing and development to make the system more resilient, improve its performance, etc. https://sre.google/sre-book/embracing-risk/#xref_risk-management_unreliability-budgets Site Reliability Engineering, §3
34. 內在品質 ruin Problem quick fix issue raised fundamental fix improvement refactoring aggressiveness 關鍵流量 關鍵存量
35. 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Dissecting causal relation (overall and simpli fi ed)
36. What’s DevOps? The authors says… DevOps 是 一 種尋找瓶頸的 方 式，甚 至 是 一 種在公司更 高 層次上尋找瓶頸的 方 式。 Patrick Debois 在 The DevOps Handbook 2/e 後記 長期主義 內在品質 Q: Where is the bottleneck? How to spot the bottleneck?
37. ➋ Flow (forward)
38. Forward fl ow: purpose 浪費和困境是軟體開發過程中導致交付延遲的主要因素。 我們的 目 標是將它們變得可視化， 並從系統層 面 進 行 改善，減輕或消除這些負擔， 實現快速暢流的 目 標。 The DevOps Handbook, 2/e, §2.6 關鍵存量 關鍵存量 關鍵流量
39. 暢流的程度 數字望 大 數字望 小
40. 全局可視化程度 暢流的程度 WIP 排除阻礙因 子 的 力 道 回饋的即時性與 力 道 關鍵存量 關鍵流量 關鍵存量
41. 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Dissecting causal relation (overall and simpli fi ed)
42. ➌ Feedback
43. Feedback: purpose 增加系統內資訊流的多元性、即時性、透明度， 幫助我們更快釐清事務的因果關係， 快速發現並處置任何瑕疵或差錯。 這種作法能夠確保品質、提升安全性， 鼓 勵繼續學習和改 善的風氣。 The DevOps Handbook, 2/e, §3.2 關鍵存量 關鍵流量 關鍵存量
44. 傳遞到下游的 defect 上游的漏網之 魚 預防 數字望 小 fix & rework 修理 數字望 大 數字望 小
45. 因果關係清晰度 傳遞到下游的 defect fix & rework 數字望 大 修理
46. 因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 上游的漏網之 魚 為下游 而 設計 數字望 小 預防 (e.g., 測試左移，資安左移)
47. 因果關係清晰度 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 數字望 小 數字望 大 暢流的程度 ?
48. 回饋的即時性與 力 道 暢流的程度 中斷 短痛 阻礙的現 行 程度 & 排除阻礙流動的 力 道 長效
49. 安燈繩：回饋的短痛 刻意凸顯局部問題，打斷全域整體作業。 此對策可能與常 見 管理實務有所出入。它挑戰了 人 們 普遍持有的信念：開發 人 員和 工 程師的流程不應該被 打斷，會損害個 人 的 生 產 力 。 然 而 ，這正是安燈繩的 目 的，它反 而 促進團隊的 工 作 暢流和 生 產 力 。促進組織不斷學習，避免因為時間流 逝 而 遺忘事件脈絡，或者因為環境改變 而 錯失關鍵資 訊。 The DevOps Handbook, 2/e, §3.3 Inspired e.g., 心 流， context switch 行 灯／あんどん／アンドン Andon
50. 因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 上游的漏網之 魚 為下游 而 設計 fix & rework 暢流的程度 關鍵存量 關鍵流量 關鍵存量
51. 因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 暢流的程度 上游的漏網之 魚 為下游 而 設計 fix & rework 2 Feedback 1 Forward flow 1 Forward flow 3 Continuous improvement
52. ➍ Putting them altogether
53. Summary of systems thinking perspective 關鍵變數：存量 Stock 關鍵變數：流量 Flow 關鍵結構 第 一 步：暢流 Flow (forward) • 全局可視化程度 • 暢流的程度 • WIP • 辨識 力 & 覆蓋率 • 排除阻礙流動的 力 道 第 二 步：回饋 Feedback • 因果關係清晰度 • 傳遞到下游的 defect • 回饋的即時性與 力 道 • 為下游 而 設計 • (類) 捨本逐末 第三步：持續改善 Continuous improvement • 內在品質 • 長期主義 • 飲鴆 止 渴 • 捨本逐末 (略) • 公有地悲劇
54. 1 Forward flow 2 Feedback 3 Continuous improvement Stock and fl ow diagram
55. 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Causal loop diagram (overall and simpli fi ed)
56. 長期主義 Alternatives are helpful when you get stuck… 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 傳遞到下游的 defect WIP 回饋的即時性與 力 道 因果關係清晰度
57. 回饋的即時性與 力 道 長期主義 暢流的程度 排除阻礙流動的 力 道 Alternatives are helpful when you get stuck… 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度
58. What’s DevOps? The authors says… 最初，我認為 DevOps 是 一 種改善開發部和營運部之間 工 作瓶頸的 方 法。 在經營 自己 的企業後，實務經驗使我意識到：DevOps 是 一 種尋找瓶頸的 方 式，甚 至 是 一 種在公司更 高 層次上尋找 瓶頸的 方 式。 Patrick Debois 在 The DevOps Handbook 2/e 後記
59. 理無專在 DevOps 是將製造業和領導 力 這兩個領域中，最值得信賴 的原則應 用 到 IT 價值流的成果。DevOps 的理論基礎被 視為源 自 精實原則、約束理論和豐 田 形學（但也有許多 人 認 為，DevOps 是 2001 年出現的敏捷式軟體開發 方 法之延伸）。 事實上，現在製造業和知識經濟的學習之間，似乎存在 一 個有趣的莫比烏斯循環：我們從製造業演變到知識經濟， 再回到製造業經濟之間的循環。