CH02 API Governance

Continuos API Management

Transcript

1. 1 達摩祖師傳
2. CH02 API Governance Rick Hwang 2021/10/05 2
3. In fact, we’ll go as far as saying that it’s impossible to manage your APIs without governing them. 不治理 API，就無法管理 API 3
4. API 治理三元素： 決策、治理、複雜度 治理是 API 管理的核心，本書其餘章節都 以本章介紹的概念為基礎。 4
5. 內容結構 • 1. 了解 API 治理 ◦ 1.1 決策 ◦ 1.2 決策治理 ◦ 1.3 治理複雜的系統 ▪ 1.3.1 複雜的自我調整系統 • 2. 決策治理 ◦ 2.1 權力的集中與下放 ▪ 2.1.1 優化範圍 ▪ 2.1.2 作業規模 ◦ 2.2 決策元素 ▪ 2.2.1 啟動 ▪ 2.2.2 選項生成 ▪ 2.2.3 選擇 ▪ 2.2.4 授權 ▪ 2.2.5 實作 ▪ 2.2.6 挑戰 ◦ 2.3 決策對應 ▪ 2.3.1 決策分配案例：選擇程式語言 ▪ 2.3.2 決策分配案例：工具的選擇 5 • 3. 設計你的治理系統 ◦ 3.1 治理模式#1：介面監控 ◦ 3.2 治理模式#2：機器導向治理 ◦ 3.3 治理模式#3：合作治理 • 4. 總結
7. 7 1.1 決策 • API 的 URI 要使用 /payments 還是 /PaymentCollection？ ◦ URL Path: Service First or Version First ◦ Version Convention: v1 or 2021-08 ◦ 內部使用的話，x-api-key 要法幾把？ • API 要放在哪一朵雲上？
8. 治理是一種程序： 1) 管理決策 2) 實施決策 Governance is the process of manaing decision making and decision implementation. 原文：P21, 中文：P17 8 1.2 決策治理
9. 9 • 治理與控制、權力無關，與改善人員的決策品質有關。 ◦ Governance itn’t about power. It’s about imporving the decision-making quality of your people. • 在 API 領域中，高品質的治理代表製作協助機構成功的 API ◦ In the API domain, high-quality governance means producing APIs that help your organization successed. • API 實施治理方法的案例： ◦ 要求所有 API 團隊必須使用同一個技術堆疊 (Tech Stack) ◦ 要求所有 API 團隊必須通過一組標準的品質測試才可以推出 -- 比較嚴格 • 治理 必定需要成本：溝通、執行、維持約束力 ◦ 鼓勵決策行為必須有價 值、有吸引力 ◦ 必須記錄、教導，更新標準、政策、與程序。 ◦ 甚至需要聘請更多人來執行治理工作
10. 管理 (Management) vs 治理 (Governance) 10
11. Governance (治理) Government (政府) https://zh.wikipedia.org/zh-tw/%E6%B2%BB%E7%90%86 11
12. 1.3 治理複雜的系統 12 • 如何確保系統有品質？ => 如何確保現場執行的結果有品質 • 烤海綿蛋糕： ◦ 有明確的食譜 ◦ 食材、用量 ◦ 標準化的溫度、時間 • 現場通常比海綿蛋糕複雜多
13. 1.3.1 複雜的自我調整系統 (Complex Adaptive Systems) “複雜適應性系統” 的意思： 1. 有很多部分是交互依存的，像是人、技術、程序、文化 …. 2. 這些部分可以改變他們的行為去適應系統的改變。 a. 導入容器化的時候，改變部署方法 13
14. 個 人 見 解 14
16. • 2.1 權力的集中與下放 ◦ 2.1.1 優化範圍 ◦ 2.1.2 作業規模 • 2.2 決策元素 ◦ 2.2.1 啟動 ◦ 2.2.2 選項生成 ◦ 2.2.3 選擇 ◦ 2.2.4 授權 ◦ 2.2.5 實作 ◦ 2.2.6 挑戰 • 2.3 決策對應 ◦ 2.3.1 決策分配案例：選擇程式語言 ◦ 2.3.2 決策分配案例：工具的選擇 2. 決策治理 16
17. 2. 決策治理 17 生態系統：池塘裡的生態圈
18. 集中與放下？ 1. 資訊的透明度：是否容易取得 2. 資訊的正確性：是否正確 3. 決策人才：決策的品質 4. 協調成本：溝通成本 18 取得決策共識的品質 訊息的最終一致性
19. 資訊透明度背後的問題： 如何有效理解複雜得資訊？ 白話文：即使看見全貌（資訊全都給你），你也看不懂。 • 資訊的組織與管理能力 -> 寫文件 • 表達能力：技巧 • 資訊的解讀與吸收能力 -> 閱讀能力 ◦ 共同的詞彙（文化）：你說的訂單 和 我的訂單 是一樣 的？ 個 人 見 解 19
20. 2.1 優化範圍 (Socpe of Optimization) • 中央集權 Optimize for system scope (Global) ◦ centrialized decision -> entire organization ◦ 中央決策 -> 整個公司的範圍 ▪ API 規則 ◦ 決策人才： 中央單位 -> Arch Team • 地方自治 Optimize for local scope ◦ 團隊、部門層級的範圍 ▪ 部門使用什麼程式語言？工具？ ◦ 決策人才：部門主管、 TL 20
21. 2.2 作業規模 (Scale of Operation) 21 • 怎麼決策，以及後續的協作規模 • 中央集權 ◦ 決策人才 ◦ 協調成本：要協調哪一些人？ • 地方自治 ◦ 決策人才： ◦ 協調成本：Gissop
22. 溝通的複雜度（效率、成本）： • 星狀：月會、週會 ◦ Postman Shopping？ • 網狀：以訛傳訛、八卦演算法 (Gossip) 個 人 見 解 22
23. 中央集權 • AoP (Aspect-Oriented Programming) • Cross-Cutting: ◦ Log, Security, Tracing, API Key, • 管理、控制 Cross-Cutting 的：CI / CD 個 人 見 解 23
24. 中央卡地方怎麼辦？ 24
25. 作業規模 (Scale of Operation) 25 • 中央集權 ◦ 決策人才： ◦ 協調成本： • 地方自治 ◦ 決策人才： ◦ 協調成本： OO 市長政績優良，改作 行政院長，參選總統 地方如果有好的做法，這個做法可 以規模化 => 就可以到中央推廣
26. 26 2.2 決策元素 啟動 選項生成 (Enum) 選擇 授權 實作 挑戰
28. 4. 授權：地方自理，主管說了算。回報給 Arch • 但書：不能超出範圍，抓到就請全 UPD 喝快樂水 5. 實作：個團隊自己用決策的語言開發專案 6. 挑戰：招募、訓練、人才調度 (調部門) 程式語言的決策元素 28 1. 發起：Arch 發起，大家都用 C# (.NET Core) 開發 2. 產生選項：C#、Node.JS、Golang … (Rust, Erlang, Kotlin) …. 3. 選擇： a. UPD1: C# b. UPD2: C# c. Infra: Golang
29. 工具的選擇 29 4. 授權：中央集權 -> Arch 決策，讓大家自己選擇 5. 實作：個團隊自己部門的 IDE 6. 挑戰：招募、訓練、人才調度 (調部門) 1. 發起：各部門發起 2. 產生選項：VS、VSCode、JetBrain、Vim 3. 選擇： a. UPD1: VS b. UPD2: VS c. Infra: VSCode d. Arch: vim
30. 1. 啟動：Log 要怎麼收集啊？ a. 習慣性決策：Elmah b. 決策盲目性：丟到 S3 就好啦 c. 地方發起 2. 選項生成：地方提供 a. ELK b. CloudWatch c. StackDriver d. Elmah e. … 省略兩百個 3. 選擇：中央選擇 a. Managed Service 4. 授權：中央決策 a. Infra Team 5. 實作：中央執行 a. Hans 表示 QQ 舉例 30 1. 挑戰：中央執行 a. 寫不完的文件、整天算錢、 b. 又是 Windows 又是 K8s …. c. 又要溝通、又要教學 d. 又要被問為啥不用 EFK ….
31. 1. 內部服務證認 2. 內部服務監控？問題排查（Tracing) 3. 容器化？ 舉例：需要決策的問題 31
33. • 3.1 治理模式#1：介面監控 • 3.2 治理模式#2：機器導向治理 • 3.3 治理模式#3：合作治理 3. 設計你的治理系統 33
34. • 根據影響力、範圍與規模來分配決策權 → 被依賴的程度 • 執行系統約束與實作驗證（來自集中決策） • 刺激決策制定（來自集中決策） • 頻估影響與持續改善來適應變化 良好的 API 應該具備的特徵 34
35. 何時要強制？何時該鼓勵？ • 不討論權威部分，系統中必須要建立一套約束機制 ◦ 連分散權力，也必須遵守規則 • 沒有權力的時候： ◦ 利用鼓勵取代約束力 35
36. 3.1 治理模式#1：介面監控 (Interface Supervision) 36 強制實施與鼓勵 • 由中央設計團隊審核 • 地方決定實作與部署 • 不符合介面，中央可以移除 它 (砍惹！ 人才分配 • 設計在中央 • 實作與營運再地方 成本與效益 • 中央的人力瓶頸 • 設計與實作的落差 影響評估 • API 易用性 • 產品與專案進度指標 • 實作與營運問題
37. 強制實施與鼓勵 • 中央提供標準選項，設計工 具驗證實作與部署 • 用 Lint 驗證 人才分配 • 中央：設計、實作、架構師 在中央，確保做出好的決策 成本與效益 • 機器的設計、實作、維護成 本高，需要前期投入 • 透過自動化提高決策數量 • 提供足夠的選擇數量，吸引 優秀人才 影響評估 • 產品與專案進度指標 • 選項受歡迎程度 • API 團隊指標 3.2 治理模式#2：機器導向治理 (Machine-Driven Governance) 37
38. 強制實施與鼓勵 • 大部分都下放 • 結果導向 • 沒有達標，就是除役或解散 • 決策透過鼓勵影響，直接給 予經濟上的獎勵 人才分配 • 人才密集 • 分權中要有適當水準的人 才 成本與效益 • 高度熟練的分權團隊 產生 高品質的 API • 主要成本在於人才 影響評估 • API 產品指標 • API 團隊指標 • 可用性指標 38 3.3 治理模式#3：合作治理 (Collaborative Governance)
40. 總結 40
41. 41 • 治理的定義：管理策略的決定，以及決策的實作 • 要意識到，治理的系統是複雜的自我調整系統 • 決策的分權：集中、分權 (中央、地方) ◦ 透過優化的範圍、操作的擴展比較 • 決策分解的基本元素：啟動、選項生成、授權、實作、挑戰 • 治理是 API 管理的核心，本章講的是概念與手段
42. 42 達摩祖師傳