More Related Content Similar to 從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018 (20) More from Rick Hwang (20) 從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 20183. 3
● class SRE implements DevOps
● SLIs, SLOs, SLAs
● 如何寫程式自動化處理異常
● 不會把 SRE 整本書拿出來講
● 不會講工具
今天不會講這些,跑錯棚,可以快逃 ~
5. ● Dev / QA
● SRE / DevOps / Ops / Infra
● PM / PO / Manager
● Director / VP / Co-Founder / CXO
現場調查
5
8. ● Site: *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下,在指定的時間 內,成功持續執行某個功能的機率。
● Engineering:
○ 工程方法、軟體工程
● Site Reliability Engineer: 是一個職務、角色
○ 他是軟體工程師,同時會寫程式,也懂系統
○ 開發軟體解決系統維運的任務
○ 50% 的時間在開發自動化工作上,必須值班
○ 他是系統架構的顧問
○ 他的薪資平均比 SWE 高 25%
Site Reliability Engineering
8
11. Ref: 緊急應變 (Emergency Response)
改編自 2009 年一月真實的事件: 全美航空 1549 號班機事故。講述 Sally 機長在一次
飛行中,遇到鳥擊事件,A320 兩具引擎同時失效,機長在 208 秒之內,依靠豐富的飛
行經驗、高超技術、豐富的飛安事故調查,最後飛機順利迫降在哈德遜河,拯救了全
部 155 人的故事。
事後的飛安調查中,國家傳輸委員會 (NTSB) 拿當時的飛行參數、用電腦模擬降落在
附近機場,結果可以順利降落在機場,以此作為 Sally 誤判的依據。
11
電影:薩利機長:哈德遜奇蹟
21. ● 網站、手機出現不穩定的白頁
○ 商品頁不穩定
○ 登入頁正常
● Load Balancer 背後機器的狀況
○ 00m: 50% Unhealthy
○ 02m: 40% Unhealthy
○ 05m: 25% Unhealthy
○ 07m: 60% Unhealthy
21
28. S1, P0
t
Event
怎麼決定嚴重性與優先序
28
嚴重性影響優先序
PM 23:30 Friday
AM 03:34 Monday
AM 11:30 Sunday
AM 10:34 Tuesday
10m 30m 60m 120m
S1, P? S1, P1 S1, P1 S1, P2
S1, P?
S1, P1
S1, P1
S1, P2
S1, P1
PR
S1, P2
S1, P0
PR
S1, P1
PR
S1, P1
S1, P0
PR
S1, P1
PR
Severity: S1, S2, S3
Priority: P0, P1, P2, P3
PR: 公關對外公告
確認是否是緊急
30. 止血
● 目的:
a. 讓系統盡快恢復服務
b. 減少營運損失
● 作法
a. 從現象,依據架構、指標,找問題點 (Part II)
b. rollback, rollback, rollback
c. 用最簡單的方法:加資源、移除有問題的節點、增加新節點、蓋防火巷
● 同步
a. 聯繫相關的人:Backend、Frontend、DBA、Networking
b. 蒐集現象、指標
30
33. 事件中的反模式
33
● 開始找 root cause,忽略持續中的異常
● 開始加程式寫更多 Log
● 直接改配置 (Config), Live Testing
● 還在持續部署
不要製造額外的變因
移除不必要的變因
38. ● 根據架構圖
○ 在辦公室:用白板畫,團隊溝通
○ 非上班時間在家:用線上協作工具的白板,手畫貼圖討論,直接 Concall
● 蒐集系統指標
○ 依據系統架構,整理所有指標
● 整理事件紀錄
○ 梳理事件的狀況、症狀 (Symptom)、外在環境資訊
● 找 Root Cause
現場調查
38
40. LB
Web API ES Node
Service API and ES GroupBatchDB
Sync commodities,
categories
Service A
Search
Service C
Add commodities, categories
Web API ES Node
Web API ES Node
Service B
Search
40
問題發生當下的架構
48. 溝通時要注意的 (口語、白板、IM)
● 主詞
○ 具象化
○ 不要用代名詞(它祂宅)
○ 物件:機器、服務
● 時態
○ 過去式、現在式、進行式
○ 完成式、未來式
● 確認 (Ack)
○ 收到
○ Roger that
48
多用數字描述形容詞:
● 流量很大,每分 50,000 requests
● 反應時間從 50ms 變成 5000ms
● 機器負載很重,CPU 平均 90%
● 訂單突然很多,以前每小時 500 張,突
然變成每小時 5000 張
53. ● 時間點:
○ 上班時間
○ 下班中、下班後、晚上、深夜
○ 週末、國定假日、特定節日(聖誕節)
● 體力、食物、精神支持與鼓勵
● 交班、團隊、協作對外的溝通
在事件當下要考慮人性
53
68. 系統架構的抽象概念
68
● 隱藏實作:圖不會有 ELB、Kubenetes、S3、MySQL … 等實作技術
● 具體角色的可視性、存取性:公開 (Public)、私有 (Private)、保護 (Protected)
● 關注的是服務跟服務之間的相依性
● 必須要有清楚的角色定義:客戶使用者、內部使用者(後台管理)
● 能用上述的抽象元素,講故事、拍廣告、講出商業價值
● 平常關注溝通,換句話說:平常就是這樣溝通,天然的。
物件導向?
請點這裡看 OO 概念
70. 架構的治理:配置管理
● 目的:
○ 服務的依賴關係
○ 服務樹
● 實踐:
○ ITIL - CMDB (Configuration Management DataBase)
○ Service Discovery
70
微服務的基礎建設 - Service Discovery
79. 環境就是現場,現場就要面對技術
最新、最潮、最噴的技術
K8s, K9s, K10s … AWS, Azure, GCP, …
DevOps, AIOps, NoOps, GitOps, DataOps, RickOps
Microservices, Nanoservice, Service Mesh, Istio
Service Discovery, Consul, API Gateway,
Terraform, EKS, Vault, Golang, SRE, Node.js, Java,
C#, .Net Core, Agile, Jekins, GitLab, VSTS, Drone
想知道最新、最潮的技術,請 Follow 小城 (推坑)
79
81. 環境建置的考量
81
Production Functional Test (Biz Logic) System Test
1. Security
2. Reliability
3. Performance
4. Operational
5. Loose Coupling
6. Cost
7. Testability
1. Security
2. Testability
3. Cost
4. Loose Coupling
5. Operational
6. Reliability
7. Performance
1. Security
2. Testability
3. Cost
4. Reliability
5. Performance
6. Loose Coupling
7. Operational
Non-Functional Test,
including Regression、
Performance、Capacity
大量、使用時間短
用完就刪
Verify Biz Logic
用完就關、低成本
小容量、使用時間長
96. ● The network is reliable (網路是可靠的)
● Latency is zero (網路沒有延遲)
● Bandwidth is infinite (頻寬是無限的)
● The network is secure (網路是安全的)
計算計科學家 Peter Deutsch 在九零年代就提出 Fallacies of distributed
computing (分散式系統的謬論),點出以下容易被忽略、或者輕忽的觀點:
分散式系統的謬論
96
● Topology doesn’t change (網路拓墣不會改變)
● There is one administrator (網路上有個管理員)
● Transport cost is zero (傳輸沒有成本)
● The network is homogeneous (網路是同質的)
118. 在事件當下的 SOP,通常不會考慮這些
118
● 人性
○ 時間點:上班時間、下班中、下班後、晚上、深夜、週末、國定假日、特定節日(聖誕節)
○ 場景:辦公室、家裏
○ 體力、食物、精神支持與鼓勵
○ 誤動作
○ 交班、團隊、協作對外的溝通
● 在事件當下 SOP 是參考用
○ 平常沒有訓練
○ SOP 太多,太瑣碎、沒維護
○ 缺少相關資源:環境變數、權限、找不到 script
136. 136
第一年 第二年 第三年 第四年 第五年
新創事業的發展階段
有產品雛型,測試
市場反應
調整方向,邁向成長
階段,損益平衡
擴大規模,開始獲利,
注重可靠性
進入市場,驗證商業模
式,Burn Rate 降低
153. Stevie Ray Vaughan, SRV
00:36: the strings break!
00:52: 換琴
閉上眼,你不會有中斷的感覺
153
SRV 是 90 年代傳奇藍調歌手、吉他手,百大吉他手第7 名。1990
一場空難意外驟逝,得年37 歲。
154. 練樂器很難嗎?九成九的時間都在練 基本
功
● 個人
○ 很扎實的演奏功力 → 基本功
○ 臨危不亂 → 信心、歌曲進度掌握
● 團隊
○ 鼓手、Bass、Keyboard:信任、相信你沒問題 (也可能沒發現)
○ 技師:
■ 發現吉他出問題了、準備備用琴
■ 在對的時間幫忙換琴,不影響表演
● 聽眾
○ 相信,因為他們是專業的藝術家
● 溝通
○ 眼神,因為有默契
154
158. 相關資料
1. 推薦:Site Reliability Engineering (SRE, 網站可靠性工程)
2. Conclusion SRE
3. Study Notes - SRE Opening
4. Slogan in SRE
5. 邁向 API 經濟 - API Gateway 導入之旅,
6. Serverless All-Star - Ops as Code using Serverless
7. Monitoring Tools 大亂鬥 - AWS CloudWatch
8. 淺談系統監控與 CloudWatch 的應用
9. 如何有效的回報問題
10. 你的靈魂 - 談產品名稱的命名
158