# 實踐 BizDevOps 在遺留系統中的挑戰與策略 - 王家駿 James Wang

{%hackmd @DevOpsDay/BJXaW1_k6 %}

簡報連結：[實踐 BizDevOps 在遺留系統中的挑戰與策略](https://speakerdeck.com/jame2408/shi-jian-bizdevops-zai-yi-liu-xi-tong-zhong-de-tiao-zhan-yu-ce-lue)

> 從這裡開始寫

因地制宜
內容為分享維護 **Legacy System**(遺留系統，或稱為祖產) 的經驗談

---
## 維護既有系統 曾經面臨過怎麼問題與挑戰？
既有系統往往對接人只有一人, 但通常需求來的不會那麼急, 要求得更多是穩定.
有時間上的buffer, 應該放寬心來面對(不然會逼死自己)

講者分享的一堆挑戰
有一堆註解並不是壞事！
缺乏持續的更新，導致要改架構或框架時，版本跳躍過多，改動太大，花費力氣太多
upgrade frequnecy是好事, 不然等好幾年後才更新會很痛苦

---
## 歸納問題：三大挑戰

> 上面的黃色方塊是主因,
> 下面灰色方塊是後面的徵狀

- 無法看見全貌
- 嘗試先看見全貌, 別陷入code(細節)的泥沼中

- 缺乏持續更新維護
- 常久沒更新的系統, 通常伴隨著會有安全性的疑慮
- 或者無法使用新的語法或者沒被官方調教效能的程式寫法

- 組織文化與資源和制式的限制
- 不會談論太多
- 組織文化有可能是阻礙系統改善的原因之一

---
## Case Study
15%, 是預估能提供給15％的人提供醫療系統的改善
第一個月只有27000人用到這福利，其他人不是登不進去就是系統當掉
總統民調因此下降6%

遺留系統有效能問題，造成後續無法支撐使用量


因為無法看見全貌或者沒持續更新系統底層版本
因而無法提高系統性能或吞吐量

---
## 策略規劃

了解問題後，思考如何透過規劃去改善問題

> 講者透過旅遊規劃來帶入系統改善規劃時會運用到何種策略


- 決策五件套:
1. 分析當前現況
2. 遇見願景
3. 淺在矛盾
4. 策略行動
5. 執行行動方案

## 定義問題
透過提問來引導團隊的大家找出問題，也呼應上一頁的五件套，也能從中找到團隊或上層的期待，團隊對於每個人提出的問題，都要有共同一致的理解。

## 分析當前現況

### 業務流程
關注**業務流程**與**結構**:目的是看見全貌

補充: [淺談 Domain Driven Design](https://speakerdeck.com/jame2408/qian-tan-domain-driven-design)
> 上面連結為講者以前的演講。

了解業務流程能找到公司內部的各部門員工
透過miro等視覺化工具, 列舉場景與事件出來並討論, 找出業務結構

### 系統架構
右圖為 現在系統, 釐清系統間的相依關係與方向

### 指標
透過指標以及數據來了解系統現況
如果遺留系統無法inject其他監控套件,那能考慮在系統溝通節點之前
透過反向或gateway來蒐集http請求這維度的資訊，來了解請求流向與體驗指標
透過監控來發現哪些功能已經沒有在使用，維護沒有在使用的功能，是一種資源浪費

把技術層面的術語轉換成老闆或客戶的能關注到的問題

將數據視覺化, 並且給出root cause和影響層面
因為上層不清楚影響層面, 但當透過數據呈現報告時, 就能讓上層理解嚴重程度

**!!!配合數據呈現給主管!!!**

(這張圖好像重複了)
ROI(Return On Inveestment,投資回報率) vs COI(Cost of Inaction,不採取行動的代價)

透過指標與視覺化分析, 讓上層知道技術債造成的COI
ＲＯＩ開發團隊難以挖掘, 但COI可以

## 探索未來狀態

### 將業務流程內聚分群

- 參考連結: [DDD 中的橋樑：透過有效建模與設計從戰略走向戰術](https://speakerdeck.com/jame2408/ddd-zhong-de-qiao-liang-tou-guo-you-xiao-jian-mo-yu-she-ji-cong-zhan-lue-zou-xiang-zhan-shu)

### 將每個服務邊界與業務流程串接
透過eventstorming來識別出業務上的邊界

### 讓業務架構與系統架構抱持一致
在系統架構上, 通常也伴隨著非功能性需求的要求

## 潛在矛盾：到底是什麼東西阻礙前進
講者列舉出一些阻礙, 能讓我們反思團隊或自身還缺少什麼

## 結合現狀與未來的視覺化
從看板中找到價值, 並且將價值流程給勾勒出來

透過電子白板結合現狀與未來的視覺化方式

## 策略規劃：重構 vs 重寫

日落系統, 對公司來說價值不大, 但又存在的遺留系統

依據業務流程與價值來做評估做出不同的策略選型

## 具體案例: 遷移計畫 - 絞殺者(Strangler)模式

strangler能做到隔離的效果,來逐步替代新舊模組

測試的重要性

## 遷移方案步驟: 從現有API 歸納收攏

針對服務邊界用API來溝通, 不要透過資料庫共享內容
透過API來交換內容

絞殺者的應用

解決大泥球,透過介接新的API 逐步轉移

能透過對資料的雙寫入道不同資料庫做影響隔離
思考資料庫需要分開嗎？

## 策略規劃: 透過開關切換新舊服務
透過feature flag來切換, 這樣還能提供交付效率

## 策略行動: 新的部分導入開發規範
將流程標準化
將標準規範化

實際可性案例
1. 採用業界標準
2. 實際案例
3. 實戰

## 策略行動: Architecture Decision Record(ADR)
凡事留下紀錄, 讓未來的人能追朔


## 策略行動: 專案架構設計
讓業務架構與軟體專案架構也一致
[參考資料：淺談軟體架構](https://ithelp.ithome.com.tw/articles/10221746)

從痛點開始
別找不痛不癢的專案來改, 會看不到價值

透過ACL防腐層對新舊架構能隔離甚至轉換內容
當遷移完成後就能移除ACL


改良遺留系統不是一係可成
需要持續迭代

技術債不是開發團隊的責任
PO/PM更應該注意, 因為這是會影響後續時程與現在營運的品質

## 執行行動方案

1. 從新架構的共用套件開始轉換
2. 絞殺者模式

先了解全貌，讓改善團隊流程成為團隊持續迭代的流程

---
### 聊天室：

不知道為什麼，感覺講者投影片的架構有點亂亂的
> 怎麼說？
> 還好，遺留系統的現代化改造一書裡面有很詳細內容，我覺得一開始沒接觸過可能覺得訊息量過大
> 每一張投影片資訊量滿滿，但可能是標題的關係？

我覺得還好,小章節一開始有說,只是沒說現在頁面是哪個小章節
> 前面決策五件套那邊很清楚後面確實有點像你說的一樣

看來很緊張，一直「對」
> 對XD
> 說不定是講話習慣

雖然講話卡詞 但內容很棒欸

在泥球旁邊開一個新的 --> 後來就會長成新的泥球 XD

我想到一個超貼切的詞彙：RO逆滲透 😂

團隊開發效率越來越差 --> 錢快燒完惹（講幹話XD