# 國泰如何進行金融 SRE 的發展 - 鄭正略 (Louis)

###### tags: `2023`
{%hackmd @sre-conf/H1pCafrG3 %}

SRE 最重要的是經驗的分享，以及如何傳承下去
經驗分享

- Container
- Microservices and APIs
- Scalable cloud infrastructure
- DevOps

開源導入使用規範
透過Scan, 評分
Supply chain security

## 金融為何要 SRE

## 現代化監控中心發展路線圖

## 銀行(金融) SRE 的運作方式

目標效益

1. 強化營運維穩
2. 提升應變速度
3. 降低間接影響
4. 優化協作監控

#### 初期目標效益
- 營運維穩、應變快速為主軸
1. 先提升**營運監控**的能力
2. 輔以監控數據度變化為手段發展
3. 資訊處、數據及中台三位一體**協作**運營下，加速監控集中整合、監控標準化、問題異常排除

降低誤判、在客訴之前發現問題

#### 發展至中期階段
- 導入事件預測模型**模擬預測事件發生**、加快因應能力
- 確認軟硬體關聯性，便於**降低動東壞西**的錯誤發生
- ***SRE團隊***建立相關儀表板建制、整體監控制度建置

#### 運營維穩、首要監控
即時準確告警->分析定位故障->高效快速排障->資源架構優化

階段六 故障規避 MTBF -> infinity
- MTBF：平均故障間隔時間
階段五 協同停損 MTTR -> 0
- MTTR：平均故障恢復時間
階段四 根因定位 故障定位時間 -> 0
- 看到細節後，要持續去跟蹤，不是重啟解決就算了
階段三 監控運營 監控有效率 -> 100%
- 用最效率的方式滿足監控需求，保證需求持續改進並有效
階段二 集中運營 事件即時響應 -> 100%
階段一 基礎營運 專業監控覆蓋率100%

SRE 必須要有plan a,b,c,d

很critical 的系統要注意裝Agent的影響
AP 一定要動，要有Standard，要求AP配合
不要留垃圾資料，最好從源頭就只保留有用的資訊

Zabbix
https://www.zabbix.com/
- 網路設備監控
- 伺服器監控
- Cloud監控
- 應用監控
- 服務監控

### 為何需要SRE/DevOps？

- 透過軟體工程手法解決複雜維運問題
- 釋放人力
- 透過開發自動化工具輔助

#### 可靠性
- 可靠性高低——取決於**服務不可用的時間長短**
> 不可存取的時間越短 = 服務可靠性越高
> Ex: 99%/年 = 每一年中約3.65天無法存取服務為可被允許狀況

##### 重要指標：
- MTBF(平均故障間隔時間)`Mean Time Between Failure`
**越高代表故障機率越低**
- MTTR(平均修復時間)`Mean Time To Repair`
**越低表示每次發生錯誤時影響越小**

### Case
- 壓測
- Memory Leak 現象

- Java 中 Busy Thread 變多示警
- TPS QPS

現代化監控中心的分類

DEM 數位體驗監控
NPMD: 網路性能
ITIM: IT 基礎設施監控
APM 應用性能

IT運營組織的管理成熟度

能力驅動型組織

用戶/市場驅動型組織

關注在 k8s 上，有沒有想過是底層出問題？

### 路線圖

### 階段目標

Ops SRE