# 以產品思維驅動的 DevOps 策略：金融業 AI 團隊的實踐之旅 - 吳明倫

{%hackmd @DevOpsDay/BJXaW1_k6 %}

>講者背景：DevOps Engineer

講者個人網站：https://minglunwu.com/about/

## Table of contents

- 多團隊的 CI/CD 策略選擇
- 產品思維的建立
- 我們遭遇了什麼樣的挑戰？
- 結論與反思

### 關於玉山銀行智能金融處
- ML Engineers
- Data Engineers

### 多團隊的 CI/CD 策略選擇

- Centralized Strategy
- 好處：
- 一致性高
- 快速啟動
- 目前使用此架構
- Why?
- 因為金融業需要確保 CI/CD 流程皆符合規範
- 進到 staging 之前，要做 unit testing, link check 等
- 希望 MLE 團隊專注於建模，透過共通的 CI/CD pipeline 部署機器學習服務
- Decentralized Strategy
- 好處：
- 靈活度高
- 擁抱 DevOps，成長性比較高


### 產品思維的建立

滿足組織內部的需求

> "Satisfy the needs of users internal to your organization or enables your organization to satisfy the needs of its customers."

### 我們遭遇了什麼樣的挑戰？

- 挑戰 1. 無力優化產品 - 維運成本過高
- 初始化階段，除了 Yaml 之外
- 還需要設定成員權限
- service connection
- branch policy
- 建立一個專案，需要經歷 14 個步驟，30 分鐘的時間
- 解決方案：建立自動化流程
- 梳理既有流程: 建立「手動」的標準作業程序
- 封裝 Azure DevOps 的 API，將原本的 UI 操作改成半自動的 Runbook
- 混亂時期/建立手動 SOP/半自動化腳本
- 效益:
- 降低例行性的維運工時 30min -> 30sec
- 提供作業正確率，不再出現人為設定錯誤的事件
- 挑戰 2. 產品使用者的客服需求多 - 溝通成本高
- MLE 可透過 Git Tag 選擇執行不同類型的任務
- 使用者如果有任何問題，會直接找 CI/CD Core Team，導致人力不足
- 解決方案：來寫文件！Documentation System
- [Documentation System](https://documentation.divio.com) 由 DIVIO 提出，將技術文件依照『目的』和『目標客群』劃分為四大類
- 使用者真的透過文件解決問題
- 使用者完全不看文件，還是來問問題
- 看完文件之後，還是來問問題
-
- 挑戰 3. 內部產品缺乏量化指標
- 解法: 建立 CI/CD 可觀測性
- 掌握產品現況
- 辨識錯誤情境
- 定位用戶痛點
- 尋找錯誤根因
- 透過排程工具，收集 Azure DevOps 的使用數據
- Why not DORA?
- 每個專案對於成功的定義都不同
- 衡量的是 Project 的 DevOps 效率
- 站在 Core Team 的角度，需要「產品該如何修正」的指標
- 收集指標的步驟
- Step 1. 掌握產品現況
- 取得產品當前的使用狀況，各個環境 CI/CD 失敗率
- 失敗率
- 部署次數
- 失敗細節
- Step 2. 識別錯誤情境
- 識別用戶在什麼情境下出現錯誤
- Step 3. 定位用戶痛點
- 了解現況之後，深入尋找用戶的功能痛點
- 失敗任務統計
- 失敗詳細任務
- Step 4. 尋找錯誤根因
- 針對功能痛點，找出原因
- Reactive
- Active
- Proactive
（Core Team的角色變化）

### 結論
- 多團隊情境下的 CI/CD 部署策略
- Centralized Strategy
- Decentralized Strategy
- CI/CD Core Team 在優化產品過程中遭遇的挑戰
- 維運成本高：例行性、重複性高的維運工作
- 溝通成本高：重複性的使用者客服
- 缺乏量化數據


---

## 聊天區

老笑話一則:
工程師四大討厭
- 討厭寫文件
- 討厭別人不寫文件
- 討厭看文件
- 討厭別人不看文件