# 平臺工程為何是企業 IT 現代化新關鍵 - 王宏仁 iTHome 副總編輯 ###### tags: `2023` {%hackmd @sre-conf/H1pCafrG3 %} 2022企業技術雷達圖： ![](https://s4.itho.me/sites/default/files/files/%E3%80%90%E5%85%A7%E6%96%87%E5%9C%96%E8%A1%A8-%E8%B6%85%E9%80%A3%E7%B5%90%E5%A4%A7%E5%9C%96%E3%80%91%E5%B0%81%E9%9D%A2-1P-%E8%B1%86%E5%AD%90-%E5%9B%9B%E5%A4%A7%E6%8A%80%E8%A1%93.png)https://s4.itho.me/sites/default/files/files/%E3%80%90%E5%85%A7%E6%96%87%E5%9C%96%E8%A1%A8-%E8%B6%85%E9%80%A3%E7%B5%90%E5%A4%A7%E5%9C%96%E3%80%91%E5%B0%81%E9%9D%A2-1P-%E8%B1%86%E5%AD%90-%E5%9B%9B%E5%A4%A7%E6%8A%80%E8%A1%93.png 非典型 SRE ➡ 服務內部團隊而非單純面對顧客. 工作內容： - 服務內部團隊 - 打造平台 - 將服務模組化，微服務化 去年，國外出現了一個專有名詞，來形容這種非典型 SRE 的做法：Platform Engineering 2023 108 位 CIO 年度優先目標 Top 10 服務的穩定性 ESG：ESG分別是環境保護（E，Environmental）、社會責任（S，Social）以及公司治理（G，governance）的縮寫 CIO 因應 ESG 就是要上雲, Top2 GreenIT 提高上雲的比重(41%) CIO 因應後疫情的新常態 數位化、自動化(45%) 提高上雲的比重(41%) 提高敏捷性、模組化、彈性化(40%) 為什麼 SRE 需要更細分? IT需要專責的Support 團隊(Platform Engineer) 功能性需求： 與企業商業邏輯相關(Functional Requirement) 非功能性需求： 與業務邏輯無關，如可觀察性 / 資安 / 流量 / 網路 / 擴充性 / 分散式優化等等 70% 時間用於無法創造差異化價值的非功能性需求 功能性需求才能創造差異化、才能創造企業競爭力 要將非功能性需求變成可重複使用的平台能力 非功能性需求是提高用戶體驗的課題 不同的服務都有各自的非功能性需求 把各部門的非功能性的需求蒐集後實踐 平台工程團隊負責這些與商業創新無關，但又是企業必要的非功能性需求。 平台工程工程師與SRE工程師 > 運用雲端原生技術打造平台與微服務等等 > 兩者類似但實際工作內容不同 從平台工程的思維, 來打造企業內部應用，與用傳統 IT 服務的思維相比，兩者有很大的不同。 平台工程思維與傳統思維不同 ➡ 互動是自動或是派工 ➡ 顧客為中心 / 流程為中心(平台工程的顧客為開發者) ➡ 導入是自主還是強制 ➡ 責任共享制還是分工 ➡ 延伸是開放還是封閉 平台工程希望使用者自發性的想要去使用 Gregor Hohpe - The Magic of Platforms: https://platformengineering.org/talks-library/the-magic-of-platforms * [【2023年CIO必看10大趨勢：趨勢3】數位轉型帶動維運現代化需求，平臺工程開始崛起](https://www.ithome.com.tw/news/155033) #### 自助式服務 vs 工單派工 以長期，大規模發展為前提去打造後端服務，所以更容易擴充，成長性也較高，容易降低邊際成本 平台工程：自助式降低採用阻力 傳統IT：表單申請、派工形式(員工Waiting、IT 抱怨工單做不完) 自助式服務的好處：減少例行性、重複性、無聊的開發工作，也能加快開發團隊交付應用的速度 有些平台工程團隊的目標是， 連非技術專業的一般員工也能用，減少更多工作小事的開發負擔 e.g. 不再是接 Ticket 來一張做一張，而是將工作做完由 Developer 自主操作 減少更多「**工作小事的開發負擔**」 開放性的作法，去整合第三方的應用，嵌入或提供API，建立一個開放或半開放的應用體系 導入策略：平台思維更容易採取激勵、自我學習的自主導入推廣方式，不必由上而下的強制使用。 e.g. 國泰金控針對外部開源軟體的使用建立自動審查規則 #### 自助服務如何更進化？ 整合 No Code, ChatGPT like 的服務 #### 責任分攤，讓IT更專注於業務服務 → 平台工程做法能讓業務團隊也能承擔高度客製化的小需求，讓開發團隊可以專注於核心業務 平台工程 CaseZ →平台工程導入目的 1. 降低認知附載錯誤主力 2. 改善團隊生產力，減少等待時間以提高部署平率與 Commit to production 3.發布系統和產品擁有權整合的時間 平台工程導入目的 1. 降低認知附載/錯誤/阻力 2. 改善工程團隊生產力，減少互相等待，提高佈署率 3. 發布系統和產品擁有權整合 Zalando 歐服圈 的 Amazon Sunrise 日出平台(雲原生技術自行研發) - What's new 是自助服務平台重要的特徵 - 發展技術雷達圖 https://opensource.zalando.com/tech-radar/ - 做為可用技術的參考，提供導入的指引（是否可以大規模導入等） - 技術會有template，用過的部門，引導 - 持續交付平台 - 高度自動化GitOps - DORA指標衡量DevOps績效 1. 平台產品化（Platform as a Product) 2. 重視使用者體驗/開發者體驗 3. 4. 5. 盡可能降低認知負載 6. 提供選擇與組合能力 7. Security by default 思維 平臺團隊基本任務 平台團隊要有自己的產品經理 2. 研究平台使用者 IDP 內部開發平台指南 IDP 的五大核心 [Internal Developer Platform](https://internaldeveloperplatform.org)