從系統思考 角 度 談 DevOps 三步 工 作法 Dissecting DevOps Through the Lens of Systems Thinking William Yeh ໢٢ࡪ DevOpsDays Taipei 2024 2024-07-11

Elevator pitch in 1 minute

研討會症候群

xxx? 2024-07-10 Paul Hammant ＠ DevOpsDays Taipei 「比不上別 人 」的焦慮⋯⋯

「非得做些什麼事情」的焦慮⋯⋯ ➊ • 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”

「遠遠不夠」的焦慮⋯⋯ Jez Humble 在 The DevOps Handbook 2/e 後記 把專注焦點放在 工 具和組織架構上比較簡單—— 這些事情當然很重要，然 而 遠遠不夠。

重劍無鋒， 大 巧不 工 第 一 步：暢流 Flow (forward) 第 二 步：回饋 Feedback 第三步：持續改善 Continuous improvement 這三招就夠了嗎？聽起來也未免太簡單了吧？ 三步 工 作法 “The Three Ways” Continual Learning and Experimentation

Dissecting key success factors 關鍵要素 第 一 步：暢流 Flow (forward) 第 二 步：回饋 Feedback 第三步：持續改善 Continuous improvement 回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 stock flow dissecting…

回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Causal relation (overall and simpli fi ed) ➊

長期主義 因果關係清晰度 內在品質 全局可視化程度 Alternatives are helpful when you get stuck… ➊ lengthy process

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. 研討會症候群 重劍無鋒， 大 巧不 工 。 洞察：視 角 & 底層邏輯 ◄ ◄ ◄ 落地：槓桿點 ◄ 通識級講座 原本是投稿在入 門 班 ◄

雖然「三步 工 作法」乍看之下就像達成 DevOps 的三個循 序步驟，但從原 文 的 角 度來看，作者使 用 的並非是 Step (步驟) 這個單字， 而 是使 用 Way ( 方 法、 方 向和途徑)。 這意味著：三步 工 作法更像是三種指導原則，來告訴 DevOps 實踐者可以根據這三個原則來思考如何進 行 或持 續改善 DevOps。 The Three Ways 盧建成 《駕馭組織 DevOps 六 面 向》§7.2 fl ow, feedback, continuous improvement

➊ Continuous improvement Continual Learning and Experimentation 原 文 是更積極的，但今天先談較 小 規模的 “improvement”

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 開發新的修補程式，讓航海家推進器延壽五年

Year 1977 of Voyagers 內在品質 存量 (stock) 如果「內在品質」是 一 個可以計算、可以加減、可以累計的數字⋯⋯

Year 1977 of Voyagers 內在品質 存量 (stock) 我們可以 用一 個「浴缸」的「蓄 水 量」來比喻這個可以計算、可以加減、可以累計的數字。

Year 1977 → 1990 of Voyagers decay ruin 流入量 (in-flow) improvement 動 力 消耗 原始任務改變 Entropy (熱 力 學第 二 定律) … 電漿 & 宇宙射線 固體撞擊 工 程師 手 殘 … 流失量 (out-flow) debug patch … 這個浴缸的「蓄 水 量」，會流失⋯⋯

Stock & fl ow view of software quality 內在品質 存量 (stock) 流失量 (out-flow) 流失量 (out-flow) 流入量 (in-flow) decay ruin improvement

Decay over time… 由於混亂和不確定性， 工 作流程會隨著時間益發低迷，直 至 失效。 The DevOps Handbook, 2/e, §4.2 內在品質 decay Environmental change Obsolete hardware Obsolete OS Obsolete PL Obsolete tool chains … 打開 decay 的 水 龍頭⋯⋯

“Change” is inevitable… 如果軟體有 人 使 用 ，就很可能需要修改。這是件好事，它 意味著 用戶 找到了從軟體中獲取更多價值的 方 式。 如果軟體會被使 用 ，那麼它便會被修改， 所以它必須被編寫得可以被修改。 《修改軟件的藝術》§4

“Change” is inevitable… But may get worse over revision 大 部分軟體，程式碼糾纏不清，雖然正常 工 作，但是由於 其編寫的 方 式導致難以修改，所以 人 們只好蠻 力 修改，讓 它以後的修改成本變得更 高 。 《修改軟件的藝術》§4 內在品質 ruin 打開 ruin 的 水 龍頭⋯⋯

A careless fi x’s unforeseen consequences… 如果 一 味逃避解決問題， 而 頻頻仰仗變通措施，持續累積 問題和技術債，最終我們的 日 常 工 作將完全 用 來執 行 這些 臨時變通 手 段， 而 沒有多餘時間進 行生 產性的 工 作。 《修改軟件的藝術》§4.2 內在品質 ruin Problem

內在品質 ruin Problem quick fix issue raised 數字望 大 數字望 小

內在品質 ruin Problem quick fix issue raised 飲鴆 止 渴 Fixes that Fail 飲鴆 渴 後遺症

“5S” methodology applied to DevOps Legacy code 的產 生 是因為有 人 認為：程式碼的品質 並不重要，重要的是軟體正常 工 作。但這是個錯誤的 認知。 我遇到過最快速的程式員，特別注意讓他們的程式碼 保持容易維護。他們不會不顧程式碼品質 而 加快速 度，反之，因為他們保持了程式碼的 高 品質，才能保 持快速撰寫程式。 《修改軟件的藝術》§4 Inspired 整理 (SEIRI), 整頓 (SEITON), 清掃 (SEISO), 清潔 (SEIKETSU), 素養 (SHITSUKE) 關鍵存量 關鍵流量

Problem issue raised 內在品質 數字望 小 關鍵存量

內在品質 Problem issue raised fundamental fix improvement refactoring aggressiveness 數字望 小 關鍵存量 關鍵流量 數字望 大

長期主義 比 日 常 工 作更重要的，就是『改善』 日 常 工 作。 持續的流程改善、架構演變、 文 化變 革 、產 生 持久影響的 團隊合作，著實不易。把專注焦點放在 工 具和組織架構上 比較簡單——這些事情當然很重要，然 而 遠遠不夠。 The DevOps Handbook, 2/e, §4.2 & 後記

https://www.facebook.com/merlionpeng/posts/pfbid02ZsKY8Vag4Bm2WjPRd1dt6WDdsQB9nyhVLthy47EhVhHy69YkFRjB227vXbgJzKpvl

公有地悲劇 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

以「投資組合」 角 度視之⋯⋯ 2024-07-10 Jugg ＠ DevOpsDays Taipei

解法 一 ：保留 一 定比例的額度 為了有效管理技術債，要確保 至 少把 20% 的開發和營運 週期投入到重構、 自 動化 工 作、架構優化以及非功能需求 上。 如果組織連這『20% 的稅』都不願意 支 付，那麼技術債 將會持續惡化，最終消耗組織內所有可 用 資源。 The DevOps Handbook, 2/e, §6.3.3 Inspired

解法 二 ：透過 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

內在品質 ruin Problem quick fix issue raised fundamental fix improvement refactoring aggressiveness 關鍵流量 關鍵存量

回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Dissecting causal relation (overall and simpli fi ed)

What’s DevOps? The authors says… DevOps 是 一 種尋找瓶頸的 方 式，甚 至 是 一 種在公司更 高 層次上尋找瓶頸的 方 式。 Patrick Debois 在 The DevOps Handbook 2/e 後記 長期主義 內在品質 Q: Where is the bottleneck? How to spot the bottleneck?

➋ Flow (forward)

Forward fl ow: purpose 浪費和困境是軟體開發過程中導致交付延遲的主要因素。 我們的 目 標是將它們變得可視化， 並從系統層 面 進 行 改善，減輕或消除這些負擔， 實現快速暢流的 目 標。 The DevOps Handbook, 2/e, §2.6 關鍵存量 關鍵存量 關鍵流量

暢流的程度 數字望 大 數字望 小

全局可視化程度 暢流的程度 WIP 排除阻礙因 子 的 力 道 回饋的即時性與 力 道 關鍵存量 關鍵流量 關鍵存量

回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Dissecting causal relation (overall and simpli fi ed)

➌ Feedback

Feedback: purpose 增加系統內資訊流的多元性、即時性、透明度， 幫助我們更快釐清事務的因果關係， 快速發現並處置任何瑕疵或差錯。 這種作法能夠確保品質、提升安全性， 鼓 勵繼續學習和改 善的風氣。 The DevOps Handbook, 2/e, §3.2 關鍵存量 關鍵流量 關鍵存量

傳遞到下游的 defect 上游的漏網之 魚 預防 數字望 小 fix & rework 修理 數字望 大 數字望 小

因果關係清晰度 傳遞到下游的 defect fix & rework 數字望 大 修理

因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 上游的漏網之 魚 為下游 而 設計 數字望 小 預防 (e.g., 測試左移，資安左移)

因果關係清晰度 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 數字望 小 數字望 大 暢流的程度 ?

回饋的即時性與 力 道 暢流的程度 中斷 短痛 阻礙的現 行 程度 & 排除阻礙流動的 力 道 長效

安燈繩：回饋的短痛 刻意凸顯局部問題，打斷全域整體作業。 此對策可能與常 見 管理實務有所出入。它挑戰了 人 們 普遍持有的信念：開發 人 員和 工 程師的流程不應該被 打斷，會損害個 人 的 生 產 力 。 然 而 ，這正是安燈繩的 目 的，它反 而 促進團隊的 工 作 暢流和 生 產 力 。促進組織不斷學習，避免因為時間流 逝 而 遺忘事件脈絡，或者因為環境改變 而 錯失關鍵資 訊。 The DevOps Handbook, 2/e, §3.3 Inspired e.g., 心 流， context switch 行 灯／あんどん／アンドン Andon

因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 上游的漏網之 魚 為下游 而 設計 fix & rework 暢流的程度 關鍵存量 關鍵流量 關鍵存量

因果關係清晰度 傳遞到下游的 defect 回饋的即時性與 力 道 內在品質 全局可視化程度 WIP 暢流的程度 上游的漏網之 魚 為下游 而 設計 fix & rework 2 Feedback 1 Forward flow 1 Forward flow 3 Continuous improvement

➍ Putting them altogether

Summary of systems thinking perspective 關鍵變數：存量 Stock 關鍵變數：流量 Flow 關鍵結構 第 一 步：暢流 Flow (forward) • 全局可視化程度 • 暢流的程度 • WIP • 辨識 力 & 覆蓋率 • 排除阻礙流動的 力 道 第 二 步：回饋 Feedback • 因果關係清晰度 • 傳遞到下游的 defect • 回饋的即時性與 力 道 • 為下游 而 設計 • (類) 捨本逐末 第三步：持續改善 Continuous improvement • 內在品質 • 長期主義 • 飲鴆 止 渴 • 捨本逐末 (略) • 公有地悲劇

1 Forward flow 2 Feedback 3 Continuous improvement Stock and fl ow diagram

回饋的即時性與 力 道 長期主義 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 Causal loop diagram (overall and simpli fi ed)

長期主義 Alternatives are helpful when you get stuck… 內在品質 全局可視化程度 暢流的程度 排除阻礙流動的 力 道 傳遞到下游的 defect WIP 回饋的即時性與 力 道 因果關係清晰度

回饋的即時性與 力 道 長期主義 暢流的程度 排除阻礙流動的 力 道 Alternatives are helpful when you get stuck… 因果關係清晰度 傳遞到下游的 defect 內在品質 全局可視化程度

What’s DevOps? The authors says… 最初，我認為 DevOps 是 一 種改善開發部和營運部之間 工 作瓶頸的 方 法。 在經營 自己 的企業後，實務經驗使我意識到：DevOps 是 一 種尋找瓶頸的 方 式，甚 至 是 一 種在公司更 高 層次上尋找 瓶頸的 方 式。 Patrick Debois 在 The DevOps Handbook 2/e 後記

理無專在 DevOps 是將製造業和領導 力 這兩個領域中，最值得信賴 的原則應 用 到 IT 價值流的成果。DevOps 的理論基礎被 視為源 自 精實原則、約束理論和豐 田 形學（但也有許多 人 認 為，DevOps 是 2001 年出現的敏捷式軟體開發 方 法之延伸）。 事實上，現在製造業和知識經濟的學習之間，似乎存在 一 個有趣的莫比烏斯循環：我們從製造業演變到知識經濟， 再回到製造業經濟之間的循環。

No content