91APP 電商技術大解密 (2020 線上分享系列)：DevOps 的金字塔原理與技術

主題：DevOps 的金字塔原理與技術
講師：李智樺（Ruddy Lee）敏捷教練

實行 DevOps 的前提不在你表現得如何？你的 Release 有多快？換句話說，就是你「不能只看見自己的病」，需要能夠知道自己在市場競爭同業之間的處境才是重點。人人稱讚的「持續改善」也不是萬靈丹，換句話說，就是你不能患了「瞬間讀心術症候群」，也就是你一直以為別人是這麼想的，但其實不然。需要運用到系統思考 System Thinking 裡的時間延遲效應，才能看到事態真正的面貌。本 Session 旨在說明企業實踐 DevOps 的種種誤區，和闡述應該有的正確邏輯思考與技術。

Youtube: https://youtu.be/iAbnXE7uvEA

91APP Tech Network: https://www.91app.tech/
91APP Tech Group: https://www.facebook.com/91apptech/

Transcript

1. DevOps的金字塔原理與技術 Ruddy Lee, 李智樺
2. • 由 Doing DevOps 邁向 Being DevOps • DevOps 的本質 • 如何解決溝通的問題 大綱 • 總結 • 附件 P51 …
3. DevOps 的本質 DevOps( Development和Operations的組合詞) 是一種重視 「軟體開發人員（Dev）」和「IT運維技術人員（Ops）」 之間溝通合作的文化、運動或慣例。 DevOps 是溝通上的問題
4. 運用「金字塔原理」來解決溝通的問題 一種重點突出、邏輯清晰、主次分明的邏輯思路、表達方式和規範動作。 The pyramid principle 訊息金字塔 你的結論、主張就是你的主要訊息，你的關鍵作業、根據就是你的關鍵訊息。 次要訊息
5. 金字塔原理 金字塔原理 金字塔的基本結構是：中心思想明確，結論先行，以上統下，歸類分組， 邏輯遞進。 先重要後次要，先全局後細節，先結論後原因，先結果後過程。 溝通 清晰邏輯 溝通的問題 邏輯思維的原理
6. 金字塔原理 歸納、演繹 橫向 縱 向 總 結 、 問 題 階層一 階層二 根據 方法 結論 金字塔原理 芭芭拉·明托 女士 於1966年所發明。 為階層解題的原理。 結論先行， 以上統下， 先重要後次要， 先全域後細節， 先結論後原因， 先結果後過程。 結論 一種重點突出、邏輯清晰、主次分明的邏輯思路、表達方式和規範動作。 3
7. DevOps 金字塔 快速交付 開發作業 維運作業 需求 測試案例 客戶 DOR 發佈計畫 環境調適 自動化測試 反覆運算 測試 自動化部署 階層一 階層二 階層三 ? 歸納、演繹 橫向 縱 向 總 結 、 問 題 階層四 衝刺目標 開發 風 險 約束
8. 这合乎逻辑吗? 看起来没问题， 但实质上都没有先说原因或需要解决的问题是什吗? 實行敏捷 Doing~Being AGILE 目的: 解決需求變來變去的問題 我們在哪裡?
9. 这合乎逻辑吗? 看起来没问题， 但实质上都没有先说原因或需要解决的问题是什吗? 實行敏捷 實行DevOps與精實 Doing~Being AGILE Doing~Being LEAN 我們在哪裡? 目的: 解決效能、浪費 …的問題
10. 这合乎逻辑吗? 看起来没问题， 但实质上都没有先说原因或需要解决的问题是什吗? 實行敏捷 實行DevOps與精實 Doing~Being AGILE Doing~Being LEAN Doing ~ Being DEVOPS Being DevOps 我們在哪裡? 目的: 解決 Bus - Dev - Ops 的溝通問題
11. 如何解決溝通的問題 - 從「人」開始 人 + 事 + 人
12. 溝通 訊 息 漏 接 漏 接 掉 球 掉 球
13. 訊 息 漏 接 、 掉 球 = 溝通不良 溝通不良的主要原因是；模糊的前言與跳躍、不連續的思考方式。 傳達者 對方 1 2 溝通
14. 訊 息 1 . 問 題 2 . 答 案 3 . 反 應 溝通訊息三要素: 傳達者 對方 溝通
15. PO 對工程師說 我需要一個更大的按鈕， 客戶反應按鈕太小了。 這合乎邏輯嗎? 聽起來沒問題， 但實質上都沒有先說明原因或需要解決的問題是什嗎? 講的是 答案，屬於不良的溝通方式。 產品負責人PO 開發工程師 運維工程師 問 題 答 案 反 應 範例 溝通 溝通
16. PO 對工程師說 我需要一個更大的按鈕， 客戶反應按鈕太小了。 開發對運維說， 我需要佈署到雲端 Docker上， 需要10G等級的伺服器... 產品負責人PO 開發工程師 運維工程師 溝通 這合乎邏輯嗎? 聽起來沒問題， 但實質上都沒有先說明原因或需要解決的問題是什嗎? 講的是 答案，屬於不良的溝通方式。 問 題 答 案 反 應 溝通
17. 問題 傳達者 對方 確認一 確認二 良好溝通的二項確認 期望得到的 反應 答案 確定問題是什麼? 不一定只有一個原因. 優良溝通
18. 問題 答案 • 理解 • 決策的結果、意見、 建議等待回饋 • 行動 良好溝通的二項確認 期望得到的 反應 確認二 希望對方 確認一 傳達者 對方
19. 問題 答案 • 理解 • 決策的結果、意見、 建議等待回饋 • 行動 確認一 答案需有清晰的結構 確認二 結論 根據 方法 傳達者 對方 結論 根據A 根據B 方法1 方法2 方法4 方法3 期望得到的 反應
20. 這合乎邏輯嗎? 看起來沒問題， 但實質上都沒有先說原因或需要解決的問題是什嗎? 溝通
21. 這合乎邏輯嗎? 看起來沒問題， 但實質上都沒有先說原因或需要解決的問題是什嗎? 溝通 DevOps: 解決Dev跟Ops的溝通問題 敏捷 Agile: 解決 需求變來變去 的問題 精實 Lean: 解決效能、浪費 … 的問題 系統思考: 解決複雜系統 CAS 的問題 問 題
22. 溝通上的二個Gap 產品負責人PO 開發工程師 運維工程師 客戶 業務 PO 測試工程師 運維工程師 Help Desk 開發工程師 共 通 語 言 豐 富 性 元 件 瓶 頸 DevOps
23. 產品負責人PO 開發工程師 運維工程師 測試案例 發佈計畫 As …,I want...so that Given - When - Than Release Plan • 環境限制 • 相依性 • 風險、約束 … 客戶 業務 PO 測試工程師 運維工程師 Help Desk 開發工程師 情境示意圖 ? 共 通 語 言 豐 富 性 元 件 1 2 瓶 頸 ? 溝通上的二個Gap DevOps
24. Dev 跟Ops 之間需要一種好的共同語言? ? 開發人員 產品 PO 開發人員 測試人員 開發人員 運維人員 呼籲
25. 歸納、演繹 橫向 縱 向 總 結 、 問 題 階層一 階層二 階層三 《 溝通時的重點不是你說了什麼，而是對方意會了什麼? 》 金字塔原理 顧 問 : 客 觀 清 晰 的 邏 輯 思 考 問題 - 答案 – 反應
26. 橫向關係： 在同一層的同一組思想中，在這個層次的思想組織方式上有歸納和演繹兩種方式。 演繹法引導聽眾走過你的思路。歸納法組成思想在邏輯上的共同點。 縱向關係： 採用疑問/回答模式，這種表達方式；容易引導讀者或者聽眾的思路，讓聽眾從 一個中心思想或者一個疑問開始，逐層向下分解和回答上面的疑問。 歸納、演繹 橫向 縱 向 總 結 、 問 題 階層關係
27. DevOps 金字塔 快速交付 開發作業 維運作業 需求 測試案例 客戶 DOR 發佈計畫 環境調適 自動化測試 反覆運算 測試 自動化部署 階層一 階層二 階層三 ? 歸納、演繹 橫向 縱 向 總 結 、 問 題 階層四 衝刺目標 開發 風 險 約束
28. 快速交付 開發作業 維運作業 需求作業 客戶拜訪 需求 Breakdown 發布計畫 DevOps金字塔 使用者情境 產品 MVP 風險控管 胡夫金字塔 DevOps 金字塔
29. 產品 MVP 業務作業 快速交付 開發作業 維運作業 需求作業 客戶拜訪 需求 Breakdown 發布計畫 使用者情境 產品 MVP 風險控管 Business -DevOps金字塔 主要訊息 關鍵訊息 次要訊息 次次要訊息
30. 需求 Doing Being 發佈 開發 單元測試 敏捷 精益 DevOps 風險 相依 測試 自動化測試 整合 需求 用戶 故事 測試案例 接受度測試 回饋 衡量 改善 系統思考 合理的 DevOps 進化過程 約束 自動化 影響 地圖
31. 解決 溝通問題 加強 邏輯思考 個 人 團 隊 瞭解 多解題 寫 blog 敏捷 精實 DevOps 顧問守則 案例 金字塔 說故事 參考 Scrum 看板 持續交付 不遺漏、不重複 溝 通 金字塔原理 MECE (學習) (簡單規範)
32. So what / Why so? 所謂「邏輯」，就是一種推論，它是推理與論證的結合。用來驗證因果關係。 • 一個符合邏輯的答案，必定要提出結論、方法和根據，並分別回應: 「該怎麼做才能解決問題?」 「要達到的話，有哪些方法可行?」 「要什麼根據，證明這些方法真的有效?」 - • 「So what/Why so?」是用來檢視結論與根據之間是否存在因果關係。 「So what?」意指「這些東西代表什麼?」，檢視證據能否支持這樣的結論? 「Why so?」則是「為什麼會這樣?」 - 《 檢視結論與根據之間是否存在因果關係 》
33. 運用影響地圖分析 加強 邏輯思考 個人 團隊 解題 簡報 寫Blog 敏捷 精實 DevOps 誰 Who？ 怎樣 How？ 什麼 What？ 為什麼why? 每週2篇 技術研討會 讀書會 改 Bug So what/Why so? MECE SCRUM 看板 持續交付 問題 角色 影響 30% 10% 5% 5% 交付 里程碑 35% 替代路徑 溝通 問題 影響路徑 衡量 OKR OKR
34. 問題 與 回答 【問題】 【分析】 【回答】 【確認】 【完成】 Low High 《 Q&A 看板 》 10 1 3 3 ※ 有任何問題，請在影片下方留言。
35. 一旦；當你把眼光投注在哪一個要項的時候，實際上你就只看到那一部分， 你的思緒將被那一部分的內容所牽動，很難再看見其他的事… 所以我們要退後一步， 不! 有時要退後很多步，才能比較清晰地看見全貌。 (好有趣喔! 退遠了卻反而看得更清晰…) 所以要調整範圍，試圖把我們在意的事放進視線可及之處， 淡淡的審視它，不帶一點情緒，就是這樣，我們看見了全貌。 專案開始之初，首重看見全貌
36. WE ARE HERE! 我們在哪裡?
37. WE ARE HERE! 我在哪裡? 客戶的真正問題? 小增量、反覆運算、回饋 Agile
38. 給客戶有價值的東西 敏捷=小增量、反覆運算、回饋 反覆運算 回饋 給客戶合約上的東西 依照計畫行事，執著而不知變通! 階段 VS.
39. WE ARE HERE! 我在哪裡? 「穩定、快速交付」 DevOps 在客戶無感之下 告知 告知
40. 由 Doing DevOps 邁向 Being DevOps - 前10年做事，後10年注重人為
41. DevOps 的金字塔原理與技術 講這個題目的原委: • 溝通；才是施行 DevOps 真正要解決的事。 題 目 開發 運維 溝 通 屏 障 組織 任務 (人) (事) 三步工作法 C.A.L.M.S 快速交付 看清問題 》 D e vOps Doing DevOps
42. 講這個題目的原委: • 溝通；才是施行 DevOps 真正要解決的事。 題 目 邏輯思考 溝通的問題 組織 任務 (人) (事) 三步工作法 C.A.L.M.S 快速交付 D e vOps Doing DevOps Being DevOps DevOps 的金字塔原理與技術 開發 運維 溝 通 屏 障
43. Doing DevOps Doing Agile Doing Lean 邏輯思考 DevOps 時時思考這樣做事敏捷嗎? 依據敏捷的規範行事 零庫存思維 依據價值流減少浪費(看板方法) 依客戶所需超前發布 持續提升CI/CD速度
44. Logical thinking Development & Operations 金字塔原理、影響地圖 概述 DevOps 的金字塔原理與技術
45. Logical thinking Development & Operations 金字塔原理、影響地圖 不合邏輯 顧問思維 概述 DevOps 的金字塔原理與技術
46. Logical thinking Development & Operations 金字塔原理、影響地圖 不合邏輯 大部分的組織都知道自己的問題在哪裡，但依然持續的在增加問題的嚴重性，很不合邏輯?! 顧問思維 DevOps 的金字塔原理與技術
47. DevOps 的邏輯思維與技術 溝通的問題 組織 部門 團隊 個人 協助邏輯思考 工具 團隊解題的邏輯思考 個人對問題的邏輯思考 不能只看見自己的病 瞬間讀心術症候群 誤區 原理 金字塔原理 參考 麥肯錫思維系列 存量、流量 動態系統 DevOps 的邏輯思維與技術 金字塔原理、影響地圖 1 2 3 4 概述 邏輯思維
48. 簡報的金字塔說明 金字塔原理 溝通: 工具: MECE 分析法 不重複、不遺漏 加強 邏輯思考 瞭解 多解題
49. 一、正確的DevOps思考；應該是先審視你現在組織的狀態， 再去尋求此時此刻應該克服的既有障礙是什麼? 二、由 Doing Agile 走到 Being DevOps，就是一種系統思維， 它是在客戶回饋或更早之前就自覺的發佈更新的方式。 三、在解決「溝通」上的問題；藉由麥肯錫顧問公司的金字塔原理， 以清晰的邏輯思考來克服組織溝通上的障礙。 你將會聽到的是… 事 時 人
50. 芭芭拉．明托 照屋華子 岡田惠子 大前研一 2019 2006 1966. 狂銷30萬冊 大前研一最具影響力的著作。 本書的目的是要提供在這個新世界中的businessman 生存下去的必要商業思考方法，向讀者傳達培養這個 思考途徑的 know how。 ．麥肯錫式的解決問題超強思考法！ ．本書在日本，四年創下30刷紀錄，不斷再版熱賣！ 麥肯錫三十年經典培訓教材！ 提升寫作、簡報能力的必讀好書！ 廿一世紀是寫作的時代，不論是寫作文、寫情書、寫e-mail、 交報告，這本書都可以幫助你。 參考書籍
51. 附件 ◆ 何謂「邏輯思維」? ◆ 金字塔原理 The Pyramid Principle ◆ MECE分析法 -不重複、不遺漏 ◆ 由邏輯思維邁向系統思維 ◆ 加強心智靈活性的方法 • 非單一解，多種解答。 • SLIP 法則。 • Doing DevOps 到 Being DevOps. (如何做到一天release 100 次?)
52. 何謂邏輯思維? 就是將結論與根據，或結論與方法的多個要素，以結論為頂點， 縱向以So what?/Why so? 的關係形成階層，橫向以MECE關係連接。 So what? 究竟是怎麼一回事? Why so? 為什麼這麼說? MECE 沒有重複、遺漏或 離題。 金字塔原理
53. 金字塔原理 The Pyramid Principle 以階層形式 Hierarchical分類資訊，進而架構或論述複雜的想法，應用於思考、寫作以 及解決問題時的邏輯推演。分類原則；就是選擇最適當的切入點作為支援結論的根據、 方法。 「相互獨立，完全窮盡」是麥肯錫思維顧問過程的一條基本準則。“相互獨立”意味著問題的細 分是在同一維度上並有明確區分、不可重迭的，“完全窮盡” 則意味著全面、周密。作法: 一、將某個主題先做母集合的思維 二、然後再思考對此母集合做區分成沒有遺漏、重複、離題的子集合。 作法: 收集資訊→ 描述發現 → 得出結論 → 提出方案。 MECE分析法 - Mutually Exclusive Collectively Exhaustive
54. 由邏輯思維邁向系統思維 心得
55. 簡潔合理的邏輯思考 系統組成三要素: 元素、連接及目標。 問題 結論 根據1 方法1 根據2 方法2 方法3 階層一 階層二 階層三 結構分明 金字塔的基本結構： 結論先行，以上統下， 歸類分組，邏輯遞進。 先重要後次要，先全域後細節， 先結論後原因，先結果後過程。 金字塔原理 由芭芭拉·明托, 1966年發明 Barbara Minto 由清晰的邏輯思維 邁向 系統思維 心得
56. 由清晰的邏輯思維 邁向 系統思維 簡潔合理的邏輯思考 清晰的元素定義 明確的互動行為 達成系統思維的目標 找到施力的杠杆點 系統組成三要素: 元素、連接及目標。 元素 連結 目標】 Input Output 問題 結論 根據1 方法1 根據2 方法2 方法3 System 心得 階層一 階層二 階層三 【 時間延遲
57. 加強心智靈活性的方法 一、非單一解，多種解答。 二、SLIP 法則 三、Doing DevOps 到 Being DevOps (如何做到一天release 100 次?)
58. SLIP法則 Sort 分類、Label 標注、Integrate 整合、Prioritize 排序 分類 Sort 標注 Label 整合 Integrate 排序 Prioritize 就是把需要整理的物件按照某種屬性進行分類劃分，比如我們電腦上 的功能表列上的功能表命令，就是按照各自功能進行分類，屬於編輯 功能的放在一起，屬於查看功能的放在一起。 就是給分類好的每一組取名標識，比如windows系統中的一級功 能表，編輯和查看。 對第一步分類後的結果進行優化，可能對現有的分類結果進行合 併、拆分或再重新分類。 指的就是分類有多個，該怎麼顯示，按照什麼樣的順序進行排列， 比如複製，剪切，粘貼命令他們得按一定的優先次序進行排列。
59. 如何做到一天release 100 次? 一天工作8小時，8 X 60= 480，480/100=4.8，每 4.8分鐘 就進行一次 release. • 請問，你的團隊編譯一次手上的 source code 需要多少時間? • 訣竅是 … D e vOps
60. 一天工作8小時，8 X 60= 480，480/100=4.8，每 4.8分鐘就進行一次 release. 微服務 就是這樣誕生的 Microservice • 請問，你的團隊編譯一次手上的 source code 需要多少時間? • 訣竅是 … 如何做到一天release 100 次?
61. 具體一點的思維是這樣的: 微服務 是神話嗎 ?! 它是一種漸進的過程
62. 具体一点的思维是这样的: 微服务 是神話吗 ?! • 先思考你每次 release 分成几包档案( .pak ) ? • 如果是 5 包的话，就给团队订一个计划，下一次要 release 10 包。 •
63. 具體一點的思維是這樣的: • 先思考你每次 release 分成幾包檔案( .pak )? • 如果是 5 包的話，就給團隊訂一個計畫，下一次要 release 10 包。 • 如果是 10 包的話，就給團隊訂一個計畫，一次 release 50 包。 • .. • … 微服務 是神話嗎 ?!
64. 具體一點的思維是這樣的: 微服務 • 先思考你每次 release 分成幾包檔案( .pak )? • 如果是 5 包的話，就給團隊訂一個計畫，下一次要 release 10 包。 • 如果是 10 包的話，就給團隊訂一個計畫，一次 release 50 包。 • .. • … • 當你作到一次 release 500 包的時候，你就作到了! Microservice 架構
65. 用戶可以接受你多久release一次呢 ?! 系统思考 …
66. 系统思考 … 用戶可以接受你多久release一次呢 ?!