# 從失敗中吸取教訓的渾沌工程 - 吳菖育 (ChangYu Wu)

{%hackmd @DevOpsDay/BymyqYaeo %}
> 各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
> [name=DevOpsDays Taipei 2022]

> 從這開始

> 混沌工程、渾沌工程錯別字為講者失誤

預防針
做渾沌工程之前記得把 CI/CD 各方面的先做好
基礎設施也記得先使用 IaC 做好
不然只會讓你環境更混沌

Agenda
- 災難演練
- 簡述與傳統災難演練有何不同
- 可靠性/可用性
- 故障
- 混沌工程
- 可觀察性
- 貝氏定理
- 演練一
- 演練二
- 結論

## 災難演練
- 系統遭受異常或是破壞事件後，能在最短時間將事先規劃好的計劃進行復原。
- 演練規劃的重點在於加強
- a
- b
- c
- 災難
- 可預測
- 不可預測
- 最終目的就是 **業務延續性**

可以思考是不是可以縮小服務
或是將部分功能微服務化
來加快復原的速度

IaC
- Consistency
- Safety
- Speed
- Visualization
- Recoverability

還原腳本

常常做演練
差不多每一季就會故意毀掉一台機器，做災難測試

> 災難演練感覺好像跟導入 ISO 要做的事情差不多？
> [name=Mark_Mew]

### 可靠性(Reliability) / 可用性(Availability)
- 平修復時間: MTTR(Mean Time to Repair)
※這是很常用的指標
- 平均故障間隔時間: MTBF(Mean Time Between Failures)
- 平均失效時間: MTTF(Mean Time to Failure)

可靠性
可靠性重視的是系統能維持運行的概率，故障率若能越低，可靠性就越低。
> 講者的投影片是不是打錯
> 故障率越低怎麼可靠性越低
> [name=Mark_Mew]

可用性
Avaliability = MTBF/(MTBF+MTTR)

> Stabilty --> Availability --> Reliability

## 故障

### 硬體故障
伺服器設備故障
機架故障
Cloud 環境

### 通訊層面/應用程式的故障

### 相依性性質
系統越來越大，複雜度越高，會有耦合性的問題

多樣性故障
- 孤立行故障
- 組合性故障
- 傳遞行故障

**傳遞型故障是最可怕的**
可能會造成蝴蝶效應

混沌工程(Chaos)
提高了
識別系統漏洞的嚴格方法
系統的彈性將了解系統的脆落點
本質是主動的，而不是傳統測試的被動行為

unit test之類的沒辦法去幫你測試障礙

混沌工程不一定要殺死或破壞，引入延遲也是一種做法。
比如說：有可能是網路環境壅塞，整個通道被占滿了

做渾沌工程時要記得先知會業務單位
做渾沌工程時要小心不要暴露給攻擊者
***資安需要特別注意，因為你做了結構上的破壞，有可能會把某些東西曝露出來***

可觀察性是做混沌工程最重要的

貝氏定理
應用所觀察到的現象以及過程中獲得的新訊息，
再依據過去的經驗來調整的策略

1. 對一件為之事物有初步的猜測
2. 觀測到跟該事務有關的現象
3. 利用先前跟該現象有端個經驗計算出概度比
4. 重新評估、修正策略
5. 重複 2~5

混沌工程很推薦使用這樣的方式（貝氏定理）
1. 建立關於穩態行為的假設
2. 多樣化地引入現實世界的事件
3. 確保監控的可用性有達到效果
4. 明確 SLO

你是否有做好服務可以降級的準備
所有參與的人都要一起共同討論

***再次強調可觀察性非常重要***

實驗時最好要有實驗組跟監控組

引入類型
-資源故障
-狀態故障
-網路故障

> 感謝各位筆記君們

###### tags: `DevOpsDays Taipei 2022`