SRE 實踐與開發平台指南 書友見面會 (2023 0819 - 0826)

場次：
- 2023 0819 DevOps Taiwan 天瓏書局
- 2023 0826 Agile Taipei 逸空間

Transcript

1. SRE 實踐與開發平台指南 書友見面會 • 2023/08/19 ( 六) DevOps Taiwan 天瓏書 局 • 2023/08/26 ( 六) Agile Taipei 逸空間 1
2. 2 Rick Hwang 軟體開發者 、音樂愛好者 ，超過 20 年專業軟體工程經歷 ，10 年主管經驗，曾任翔威國際駐 IBM 資深軟體工程師、 Oplink SQA Manager / SDET Lead、91APP Operation and Infrastructure Manager / Architect、2021 年獲得 AWS 授予 Community Hero 榮譽稱號。 專注分散式系統架構、系統分析與設計、軟體測試、AWS、 DevOps、SRE、經營管理、產品設計 … 等領域，著有技術部 落格《Complete Think》、個人著作《SRE 實踐與開發平台指 南》、共同著作《軟體測試實務手冊 》、譯著《分散式系統設 計》。 工作之餘喜歡金庸武俠、科幻小說、經典文學、哲學、人文藝 術。同時也是音樂愛好者，涉略涵蓋吉他、鍵盤、編曲、教學， 著有音樂部落格《喝咖啡 聊音樂》。
3. 個人著作《SRE 實踐與開發平台指南 》 共同著作《軟體測試實務手冊 》 第一冊 • CH01 軟體測試工程師的職涯手冊 • CH05 從零開始，軟體測試團隊建立實戰 第二冊 • CH01 Web Service系統容量量測的實務方法論
4. Agenda • 一、寫作動機 • 二、寫作過程 • 三、如何閱讀 • 四、內容摘要 • Q&A 4
5. 一、寫作動機 5
10. 念頭：應該要把這些想法記錄下來 … 有了念頭，下一步是什麼？ 搜集與整理 … 10
11. 11 SRE Conference 2022 - 91APP 在 AWS 上的 SRE 實踐之路 22:16 - 24:34
12. 12 第五章 大樓理論 第六章 服務治理 第七章 第七章 第七章 第七章 第八章 第四章
13. 搜集了， 接下來要，整理目錄 … 13
14. 14 2022/11 目錄草稿 馬賽克
15. 有目錄了，接下來要 … 給自己一個 deadline … 15
17. 二、寫作過程 17
20. 20 喜不喜歡，要親自嘗試， 而且是長時間、持續的進行， 然後才能真的知道， 是喜歡、還是只是幻想 / 空想。
21. 21 成為 台灣 軟體界 的 村上春樹 元素：跑步、寫 (ㄌㄚˇ) 作 (ㄙㄞˋ)、音樂、貓
22. 22 • 2022 / 11: 簽約 • 2022 / 12 ~ 2023 / 04: ◦ 軟體測試實務校稿 ◦ 專注寫作 • 2023 / 05 ~ 2023 / 07: 校稿 • 2023 / 08: 上市
24. 24 把自己當植物，只需要： - 空氣 - 陽光 - 水 但，一樣可以持續成長茁壯 (簡單生活、斷捨離 )
25. 25 關於寫作 • 想法稍縱即逝 • 把想法，留 (寫) 下來 - 聊聊寫 Blog 的想法 • 反覆咀嚼、思考、總結 • 跟朋友用輕鬆的方式 討論 ◦ 俗稱 LDS ◦ 人在安全、放鬆的狀態，最有創意 • 反覆整理
26. 26 寫作原則 … • 寫作原則: 以降低 SRE 的距離感為原則，所以以口語化、容易閱讀、讀起來沒 壓力、拿起來，隨意翻閱都可以讀。 • 生活經驗: 書中的概念，以生活的概念為原則，不管是技術或者方法，應該都 可以在生活當中找到例子，也就是讀者透握自身的生活經歷，就可以理解裡面 的想法。 • 章節關聯性 : 章節的安排，前半段盡量減少關聯性，後半段則有關聯性。
27. 給讀者的話 … 不是希望得到答案，更多是 … 獲得思考的機會，也就是啟發思考； 不是要讀者都同意我的觀點，更多是 … 因為我的觀點，獲得啟發與思考。 27
28. Take a break; 28
29. 三、如何閱讀這本書 29
31. https://rickhw.github.io/2019/03/17/Management/Perspective-in-XYZT/
32. [(產品開發團隊 + 維運團隊) x 產品線 x 系統服務] x 企業階段 (t) (人 x 事 x 物) x 時 (t) ⇒ (X x Y x Z) x t
33. 33 軟體工程的三體問題 (Three-body Problem in Software Engineering)，又稱 XYZT 模型。 • 人和事：也就是組織與產品的交成，找 到目標共識 ，良好的協作模式、溝通 • 事和物：想像成產品與技術的交成，目 標是提高生產力、降低成本 、讓業務 可擴展 • 人和物：則是組織與技術的交成，則要 面對溝通與協作 ，也就是康威定律 ， 以及技術管理
34. 34 錘子現象：考慮企業階段 階段 企業規模 商業模式 獲利狀況 建議閱讀 草創期 少於 100 人 一個產品線，驗證產品可行性階段 尚未獲利 Part 1 成長期 100 ~ 500 人 一到三個產品線已經驗證可行的 產品 損益平衡 Part 1、2 發展期 超過 500 人 至少有三個以上穩定獲利的 產品線，在有 餘裕的狀況下，開啟新的產品線，或者同 一產品持續擴大業務範圍 穩定獲利 Part 1、2、3
35. 35 矩陣思維，而不是標準答案 1. 定義問題，與決策次序 2. 定義 X / Y 軸 3. 展開 X / Y 裡面的值 4. Ｘ * Y 的交乘 a. 排除不合理 b. 找到 Happy Path 5. 把 P3 變成 P0 6. 或者把 P0 變成 P3
36. 36 矩陣思維，而不是標準答案 內部發動的需求 外部發動的需求 功 能 非 功 能 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) A B C D 需求源頭 (Requirement Source) 需求類型 開 發 維 運
37. 37 維運團隊應該跑 Scrum 、看板、Waterfall ？ 內部發動 外部發動 預 期 非 預 期 A B C D
38. Take a break; 38
39. 四、導讀 39
40. 40 Part 2 開發維運治理 第5章 系統架構之大樓理論 第6章 服務治理 第7章 軟體交付的四大支柱 第8章 觀測與監控 從零到一站起來 跨團隊的協作 實際的現象 未來與趨勢 Part 1 真實世界的普遍問題 第1章 維運團隊普遍的現象 第2章 維運時間殺！SRE 需要制度！ 第3章 團隊的介面，合作共創 第4章 事件管理 Part 3 開發平台與平台工程 第9章 開發平台：設計概念與整體藍圖 第10章 平台工程：服務標準化 全公司視野 開發 & 維運 的遊戲規則
41. 41 計畫中 計畫中 非預期 面積代表需要的技能與經驗
42. Source: https://pixabay.com/en/circulatory-system-labels-biology-41523/ 醫學院學生在學期間 要了解人體結構、運作原理 作為醫生 才具備判斷病情的能力 42
43. 以單一服務為主體，描述： • 對象：全公司所有人，也可以對外 • 定義：服務目錄，有哪些服務、邊界， 服務彼此的依賴關係 • 權責：服務與團隊的權責 Product Overview Service A Service B Service C Service D Ninja Service E High Level View • 對象：全公司所有人，也可以對外 • 定義：服務目錄，有哪些服務、邊界， 服務彼此的依賴關係 • 權責：服務與團隊的權責 基於 OOP 的封裝概念而設計
44. 以單一服務為主體，描述： • 對象：給技術團隊、跨部門，給開發 者看，不描述實作 • 定義：利害關係角色 (Roles) • 情境：核心情境 (User Stories / Happy Path)、資料流 (冷、熱) Go Live Functional Test High Level View Service Definition Integration Test Production A Production B • 從 Prodution 開始思考落地 • 對象：給執行的工程師、團隊看 • 重點：技術與實踐 • 目的：如何維運、部署、訓練 • 資源：網路、運算、存儲、維運 • 權限、監控、成本、事件處理 以單一服務為主體，描述： • 對象：全公司所有人，也可以對外 • 定義：服務目錄，有哪些服務、邊界， 服務彼此的依賴關係 • 權責：服務與團隊的權責
45. x=1, y=2, z=3; Process#9527 Global Scope funct1() x=4, y=5, z=6; return x+y+z; Shutdown Procedure Initial Procedure t func2() return x+y+z; func3() return (x+y+z) + ( globals()['x'] + globals()['y'] + globals()['z'] ); 記憶體空間 全域變數 (Global Variables)、區塊變數 (Block Variables) 區塊變數可以細分成： • 區域變數 (Local Variables) • 類別變數 (Class Variables) • 實例變數 (Instance Variables) • 區塊變數 (Block Variables) • 結構變數 (Structure Variables) • 其他 … 變數範圍 (Scope)，在一個 Process 實際上隱含這些概念： • 生命週期的有效範圍 ：變數的操作，應該都在允許的範圍 內。 • 變數具備名稱空間 (Namespace)：為了區別同樣名稱、但在不 同範圍的變數，實際上是透過前綴堆疊出完整的變數名稱，而這 個堆疊名稱的概念，就是名稱空間。 ◦ OOP 的類別本質就是命名空間的概念。
46. Regional B Regional A DC1 Regional A DC1 DC2 Regional A DC1 DC2 策略一 策略二 草創期 成長期、發展期 Regional X: 業務市場 DC X:實體資料中心
47. 7.3 應用程式配置：軟體的 內部介面與依賴反轉 47 應用程式介面規格 (Application Interface Spec) a. 由外而內 (Outside In): 使用者能接觸到的資訊、介面、結構，像是 i. Web API Request、Response Payload … 等業務邏輯資訊 ii. 非功能資訊：HTTP Header / Client Storage / Cookies … b. 由內而外 (Inside Out): 開發團隊能接觸的資訊、介面、結構，像是： i. Configuration、Secret、Environment ii. Database Schema、Storage Structure
48. 48 - Storage: GlusterFS ninja-storage.svt01.abc.com = API: Spring Boot ninja-api.svt01.abc.com - Database: PgSQL ninja-db.svt01.abc.com Service Ninja - SVT TCP: 3306 TCP: NFS HTTP Checker Asimov (Team1) HTTP w/ Token Voyager (Team2) HTTP w/ Token 1. 路徑一：Checker → API 2. 路徑二：Checker → Ninja ( API → Database ) 3. 路徑三：Checker → Ninja ( API → Storage ) 4. 路徑四：Checker → Ninja ( API ) → Asimov ( API ) 5. 路徑五：Checker → Ninja ( API ) → Voyager ( API )
49. 給讀者的職涯思考 … 49
50. 需求與機會 想做的 (Want) 能做的 (Can) 該做的 (Should) 有機會？ (Opportunity) 有技能？ (Skill) 有目標？ (Goal) 個人 持續總結、精練 給自己獎勵 50 決策職涯，複利人生
51. Q&A 51
52. Thank You 52 Rick Hwang 2023/08/19 (Sat)