# 以開發者資料驅動的 CI/CD 優化策略 - 吳明倫
{%hackmd @DevOpsDay/B1cnefOI0 %}

#### [TOC]
#### 》[議程介紹](https://devopsdays.tw/2024/speaker-page/1149)
#### 》[填寫議程滿意度問卷｜回饋建言給辛苦的講者](https://forms.gle/UXVQnDTcscX5MwhS7)

#### 》[本日 Slide](https://docs.google.com/presentation/d/1rZz6Nt2_dIwa1Ox7ZM6D720xfyE2b41SfcSS31A-5po/edit?usp=drive_link)

## 為什麼CICD要被優化
持續迭代可以去優化整個產品，
開發跟去監控指標之後，更進一步來做更多的優化

## pipeline 優化
新工具導入
組織規模變大
效率不佳錯誤率上升 （最難被察覺）

## 可觀測性
提高狀態跟優化方向。
大部分都是app上面，但很少有cicd的可觀測性來做價值討論。

## CICD strategy
CICD在智金處的邏輯都會抽拉掉來做一制性的藍圖，主要是根據一些compliance的需求變更的時候，只要更改腳本剩下的所有團隊就不用個別去變更。

所以這樣可以讓四個DevOps跟80個資料科學家一起來做互動使用，更有效的來運用資源

## 部署流程
流程分成三層。每個角色都做的不同。
團隊只要知道跟自己相關團隊的變更就好，不用知道所有事情。

## Flaky Test
大家最討厭的都是同一個code，但不同的時間執行pipeline卻會有不同的結果。
為什麼會發生這種事情？
因為同一份藍圖，變動的風險就會非常高。
只要有人改動的時候，就可能導致所有人的服務都下線。
DevOps Team是中介層，有時下層的infra改動東西，但上層的開發就會找Devop來處理。

## 狀態不明失去信任
pipeline怪怪的無法信任自動化機制。
對於維護DevOps的人而言，對自己產品穩定也失去信心

## 維運人員缺乏明確的優化方向
但大家講的方向都不同，到底要以誰為準？

這都要回到一個問題，CICD沒有一個可觀測性啊。

## DORA
那用Dora呢？
但這是評估一個團隊的，但若DevOps橫跨太多團隊，要怎樣評估這些東西？

## 數據驅動，建立可觀測性。
### 觀測pipeline要什麼？
- 開發者的使用資料，他們怎樣參與cicd pipeline
- cicd執行狀態，是否觸發，是否成功，執行時間多久
- CICD LOG 執行當下發生什麼事情？

### 資料哪裡來？
很多平台都有內建的視覺化工具啊。
GitLab Azure Github
但可能我們要用這些東西要用他們的開發流程，開發就很沒有彈性
指標數量有限，不一定符合我們要觀測的東西，分析彈性也不好
衡量單一團隊，但跨團隊的開發就很難評估使用這種工具

### 橫跨CICD個階段的原始資料
使用apache airflow來做抓取，用python log抓取之後存到db裡面。
但整理之後要怎樣分析呢？
針對不同的職別來給予不同資料
主管 開發團隊 維運團隊都不同 就可以做不同的收攏方式

### 決策者

希望提升決策效率，希望看到整個組織狀況的CICD
想看到高峰跟低谷
想看到工作分配的狀況是否穩定合理
團隊伍生產狀況

### 開發者
希望透過這些東西提高自己的開發效率或看到insight
或是透過這些東西來評估導入新工具的可行性。

導入之後可以在不同時間看到不同的部署失敗率，看到整個組織整體pipeline狀況有什麼變化？透過圖表知道狀況。

## 開發優化困難
維運在個團隊反應之後不知道要先優化誰的，也不知道到底哪個優化是緊急的且嚴重的。
比較多人反應就比較重要嗎？也未必如此吧。

透過搜集過去的錯誤，可以慢慢分析他的狀況。來釐清那是誰的問題，並把優先的緊急錯誤先處理。

## 導入之後怎樣溝通
有了數據之後更容易來溝通。
有LOG跟數據之後也可以讓個別團隊找到自己需要的資料。


透過擁有的可觀測性 有了數據就可以持續更新 有了受眾分群就可以有資料分析 就可以讓組織跟團隊有更多影響。

## 小結

###### tags: `DevOpsDays Taipei 2024`