Date: 2018/09/12 DevOpsDays Taipei 2018 Blog: https://rickhw.github.io/2018/09/12/DevOps/DevOpsDaysTaipei2018-Emergency-And-Incident-Management/

1. Rick Hwang
Sr. Manager, 91APP
Sep 12, 2018
1
從緊急事件
談 SRE 應變能力的培養

2. 2
Rick Hwang
https://www.gtcafe.com
● Sr. Manager @ 91APP
● 經營管理
● Cloud / AWS / GCP
● DevOps / SRE
● Distributed Systems
● 音樂 吉他 鍵盤 編曲
● 哲學 科幻 金庸 喇賽

3. 3
● class SRE implements DevOps
● SLIs, SLOs, SLAs
● 如何寫程式自動化處理異常
● 不會把 SRE 整本書拿出來講
● 不會講工具
今天不會講這些，跑錯棚，可以快逃 ~

4. 4
緊急、嚴重
吐血、加班
負面、熱情
安全、沒事
喝水、下班
淡定、吃素
警告、有事
吞水、調查
思考、老成
技術、探索
吃肉、激盪
工程、科學
顏色是有意義的

5. ● Dev / QA
● SRE / DevOps / Ops / Infra
● PM / PO / Manager
● Director / VP / Co-Founder / CXO
現場調查
5

6. 簡介 SRE
6

7. 軟體工程有的時候和育兒類似：雖然 生育過程痛苦、艱辛 ，但是養育成人的過程才是真
正耗費心力之處。傳統的軟體工程花費很多精力討論軟體開發的過程，而不是其後的
維護過程。統計顯示， 一套軟體系統的 40% ~ 90% 成本，其實是花費在建置之後，不
斷維護的過程。
業界流行的一個說法：一套系統如果已經開發完成，部署在正式環境上，那麼他就是
『穩定的』，不需要那麼多工程師花費精力去最佳化、維護。
我們認為這樣的說法是錯的，從這個角度來看，如果軟體工程主要專注於設計和建構
軟體系統，那麼應該有另一個種職業專注於 整個軟體系統的生命週期管理 ：從其設計
一直到部署，經歷不斷改進，最後順利除役。這樣的職業必須具備非常廣泛的技能，並
且和其他職業的專注點不同， Google 把這個職位稱為 網站可靠性工程師 (SRE, Site
Reliability Engineering)。
7
摘錄自 SRE 序

8. ● Site: *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下，在指定的時間 內，成功持續執行某個功能的機率。
● Engineering:
○ 工程方法、軟體工程
● Site Reliability Engineer: 是一個職務、角色
○ 他是軟體工程師，同時會寫程式，也懂系統
○ 開發軟體解決系統維運的任務
○ 50% 的時間在開發自動化工作上，必須值班
○ 他是系統架構的顧問
○ 他的薪資平均比 SWE 高 25%
Site Reliability Engineering
8

9. 9

10. 10
開始之前
用電影說『緊急事件』

11. Ref: 緊急應變 (Emergency Response)
改編自 2009 年一月真實的事件: 全美航空 1549 號班機事故。講述 Sally 機長在一次
飛行中，遇到鳥擊事件，A320 兩具引擎同時失效，機長在 208 秒之內，依靠豐富的飛
行經驗、高超技術、豐富的飛安事故調查，最後飛機順利迫降在哈德遜河，拯救了全
部 155 人的故事。
事後的飛安調查中，國家傳輸委員會 (NTSB) 拿當時的飛行參數、用電腦模擬降落在
附近機場，結果可以順利降落在機場，以此作為 Sally 誤判的依據。
11
電影：薩利機長：哈德遜奇蹟

12. 12
飛安調查對話
● 副機長：
○ 飛機之所以能夠順暢運作，最後成功降落，是
因為機長啟動了輔助動力系統
● 調查委員：
○ 他只是遵照快速檢查手冊
● 副機長：
○ 他完全沒有遵照標準程序，我很清楚，因
為手冊在我手上
○ 發動機熄火後，他立刻啟動輔助動力系統，那
是手冊上的第十五道步驟
○ 如果遵守該手冊的規定，我們都死了

13. Titanic 13
2015/02/04: 復興航空235號班機空難

14. 14

15. 事後補救事前預防
t
Abnormal
Bug
止血 止傷 治療
警急
事件
管理
教育訓練
觀測
(Observability)
量測
(Measurement)
Event
效能
(APM)
異常演練
架構優化
效能測試
趨勢預測
(Forecast)
救災事件管理 探索 SOP
SRE
檢傷
分類
異常
報告
檢討
改進
防火巷
SLA
淺談系統監控
https://twitter.com/pczarkowski/status/1006208448101535745/photo/1
SLOs,SLIs

16. 16
Part I 事件當下的應變
行動與策略

17. 事後補救事前預防
t
Abnormal
Bug
止血 止傷 治療
警急
事件
管理
教育訓練
觀測
(Observability)
量測
(Measurement)
Event
效能
(APM)
異常演練
架構優化
效能測試
趨勢預測
(Forecast)
救災事件管理 探索 SOP
SRE
檢傷
分類
異常
報告
檢討
改進
防火巷
SLA
SLOs,SLIs

18. 想像以下的情境
18
先不考慮發生的時間、地點

19. ● 網站、手機出現不穩定的白頁
○ 商品頁不穩定
○ 登入頁正常
● Load Balancer 背後機器的狀況
○ 00m: 50% Unhealthy
19

20. ● 網站、手機出現不穩定的白頁
○ 商品頁不穩定
○ 登入頁正常
● Load Balancer 背後機器的狀況
○ 00m: 50% Unhealthy
○ 02m: 40% Unhealthy
○ 05m: 25% Unhealthy
20

21. ● 網站、手機出現不穩定的白頁
○ 商品頁不穩定
○ 登入頁正常
● Load Balancer 背後機器的狀況
○ 00m: 50% Unhealthy
○ 02m: 40% Unhealthy
○ 05m: 25% Unhealthy
○ 07m: 60% Unhealthy
21

22. 22

23. 23
現在請大家
請閉上眼睛，深呼吸

24. Things break; that’s life.
SRE CH13 Emergency Response
24

25. 止血是事件當下的第一行動
25
Image Source

26. t
Event
從發生到發現
26
零時差時間
發生 發現
主動發現：主動了解、掌握現場
被動通知：On Call

27. t
Event
PM 23:30 Friday
AM 03:34 Monday
AM 11:30 Sunday
AM 10:34 Tuesday
假日夜間
上班時間
發現的時間點
27
協作方式與溝通

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: 公關對外公告
確認是否是緊急

29. Manager
PM, Boss
Customers
t
Event
事件持續的時間
29
溝通的對象
PM 23:30 Friday
AM 03:34 Monday
AM 11:30 Sunday
AM 10:34 Tuesday
10m 30m 60m 120m
SRE Manager Manager Boss
SRE
SRE
SRE
SRE
Manager
PM, Boss
SRE
Manager
PM, Boss
Customers
Customers
Manager
Manager
PM, Boss
Customers
Customers

30. 止血
● 目的：
a. 讓系統盡快恢復服務
b. 減少營運損失
● 作法
a. 從現象，依據架構、指標，找問題點 (Part II)
b. rollback, rollback, rollback
c. 用最簡單的方法：加資源、移除有問題的節點、增加新節點、蓋防火巷
● 同步
a. 聯繫相關的人：Backend、Frontend、DBA、Networking
b. 蒐集現象、指標
30

31. 止血原則
減法、減少變因、分而治之
31

32. ● 快速製造防火牆、防火巷
○ 網路層：限流
○ 服務層：水密隔艙
○ 應用層：功能斷路器
● 用資源緩解系統壓力
● 拆分、排除不必要的因子
常用止血法
32

33. 事件中的反模式
33
● 開始找 root cause，忽略持續中的異常
● 開始加程式寫更多 Log
● 直接改配置 (Config)， Live Testing
● 還在持續部署
不要製造額外的變因
移除不必要的變因

34. 超過一段時間
止血無效怎麼辦？
34
Image Source

35. 35
請閉上眼睛，深呼吸

36. 超過一段時間止血無效
36
1. 止血時間：依據對客戶承諾的 SLA
○ 例如超過 30m 止血無效
2. 蒐集現象
○ 確認影響範圍
○ 判斷嚴重等級
3. 確認溝通與公告對象
4. 進入現場調查程序

37. 什麼叫現場調查程序？
重症病患
死馬當活馬醫
37

38. ● 根據架構圖
○ 在辦公室：用白板畫，團隊溝通
○ 非上班時間在家：用線上協作工具的白板，手畫貼圖討論，直接 Concall
● 蒐集系統指標
○ 依據系統架構，整理所有指標
● 整理事件紀錄
○ 梳理事件的狀況、症狀 (Symptom)、外在環境資訊
● 找 Root Cause
現場調查
38

39. 案例：從架構拆分，分而治之
39

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
問題發生當下的架構

41. LB
Cluster1 Cluster2
LB
LB
Index1 Index2
Service B, C
Search API
Service A
ELB3
LB
Cluster3
Index3
41
問題的拆分案例：分而治之

42. 42
當下的痛點
● 當下我們不清楚架構的全貌
● 經過一個月的分析、拆解，得到前面的圖
● 經過拆解、分析，找到真正的火點，做防火巷隔離

43. 43
2018/07/07: 泰國洞穴救援

44. 44
值得警惕的是，理解一個系統應該如何工作，並不能使人成為專家。
只能靠調查系統為何不能正常工作才行。
Be warned that being an expert is more than understanding how a
system is supposed to work. Expertise is gained by investigating
why a system doesn’t work.
-- Brian Redman
SRE CH12 Effective Troubleshooting

45. 現場溝通：對內、對外
45

46. 公 司
產品開發團隊
46
Team A
現場指揮官
對外溝通
PR
客戶
高層
管理層
媒體
Team B
Team C
客服
你們家出了什麼事？
上班時間、在辦公室

47. 釐清問題時：請用圖來溝通
紅色：Actions (尾)
黑色：現況 (頭)
綠色：方向、未來 (希望)
藍色：問題點、討論 (科學)

48. 溝通時要注意的 (口語、白板、IM)
● 主詞
○ 具象化
○ 不要用代名詞（它祂宅）
○ 物件：機器、服務
● 時態
○ 過去式、現在式、進行式
○ 完成式、未來式
● 確認 (Ack)
○ 收到
○ Roger that
48
多用數字描述形容詞：
● 流量很大，每分 50,000 requests
● 反應時間從 50ms 變成 5000ms
● 機器負載很重，CPU 平均 90%
● 訂單突然很多，以前每小時 500 張，突
然變成每小時 5000 張

49. 事件中溝通的反模式
● 一直不斷問：找到問題沒？
● 主管
○ 下指導棋
○ 吹噓當年的做法
● 業務：不分青紅皂白開罵
● 沒有統一對外溝通的公關 (Public Relation, PR)
○ 此 PR 非比 PR
○ Developer 寫對外溝通信
49

50. 對外溝通的案例
50
https://status.slack.com/2018-06/142edcb9e52c7663

51. 策略劇本
51
● 問題一直沒有辦法有效排除怎麼辦？
● 最糟的狀況是什麼？
● 損失會多嚴重？
● 下一個 Check Point？
● 有沒有外部資源可以協助？
要想三個劇本

52. 如何有效的回報問題
整理事件紀錄
● 商業影響層次
● 事件時間軸，完整的始末
● 系統數據、指標紀錄
● 事件分析紀錄
● 相關人員
● 成員 Review
52
不管是否完成止血，請一定要整理事
件報告，整理的過程，等於在整理事件
的始末，等於在釐清現況。整理報告的
人，也會學到最多東西。

53. ● 時間點：
○ 上班時間
○ 下班中、下班後、晚上、深夜
○ 週末、國定假日、特定節日（聖誕節）
● 體力、食物、精神支持與鼓勵
● 交班、團隊、協作對外的溝通
在事件當下要考慮人性
53

54. t
Down
Time
Part I 事件當下的應變：行動與策略
54
工程
管理
Up
Time
策略 溝通 策略 溝通
止血 調查 調查
MTTR
SLA

55. 神寫的系統是不會有雷，除了索爾
55
沒有什麼大神，雷踩得夠多
而且都能解決，就是大神。
-- Rick Hwang

56. 現場調查
● 現場曾經處理過線上異常的朋友，請舉手。（手請不要放下）
● 這個異常是在晚上處理的朋友，請舉手。（手請不要放下）
● 這個異常是在週末凌晨處理的朋友，請維持。
我們為這些還舉著手的朋友，掌聲鼓勵一下！
56

57. 事中的推演 + 思考
● 得到：壓力、責任、(難忘的) 經驗
● 失去：業績、商譽、信任
57

58. 58

59. 59
Part II 應變能力的培養
架構、探索、管理

60. 事後補救事前預防
t
Abnormal
Bug
止血 止傷 治療
警急
事件
管理
教育訓練
觀測
(Observability)
量測
(Measurement)
Event
效能
(APM)
異常演練
架構優化
效能測試
趨勢預測
(Forecast)
救災事件管理 探索 SOP
SRE
檢傷
分類
異常
報告
檢討
改進
防火巷
SLA
SLOs,SLIs
工程、科學
技術、探索

61. 61
Hope is not a stategy.
SRE CH01 Introduction
不能把運氣當做策略

62. 平常應該思考以下
● 永遠保持警惕
● 不停地提出疑問：什麼可能故障？故障之前如何避免？
● 揭露問題，並解決他 - 混沌工程 (Chaos Engineering)
○ 確保系統按照預想的方式發生故障
○ 尋找系統中未知的弱點
○ 尋找其他提高穩健性的方式，避免事故發生
62

63. 這裏談的不是設計架構的議題：
● 面對不確定性
● 適合原則、簡單原則
這裡談的是，如何理解已經落地的架構
要面對外在因素與內在變化的問題。
了解系統架構
63

64. 系統架構
抽象概念
64
Source: https://pixabay.com/en/violin-music-score-mozart-1085606/
(Music in Score)

65. ● 商業目的：
○ 使用者故事
○ 功能的資料流：路徑
● 範圍：權責、依賴性
● 抽象概念：不談技術細節，談關係權責
系統架構：抽象概念
65

66. StorageWeb
APIDatabase
Internal GW
External LB
End User
Private
Public
Protected
ACL
系統架構：抽象、範圍、依賴關係、角色 (理想)
Service A
66
Service B
Service C
Whatever Service
Internal Users
Production (SaaS)

67. 系統架構的抽象概念
67
● 隱藏實作：圖不會有 ELB、Kubenetes、S3、MySQL … 等實作技術
● 具體角色的可視性、存取性：公開 (Public)、私有 (Private)、保護 (Protected)
● 關注的是服務跟服務之間的相依性
● 必須要有清楚的使用者定義：客戶使用者、內部使用者（後台管理）
● 能用上述的抽象元素，講故事、拍廣告、講出商業價值
● 平常關注溝通，換句話說：平常就是這樣溝通，天然的。

68. 系統架構的抽象概念
68
● 隱藏實作：圖不會有 ELB、Kubenetes、S3、MySQL … 等實作技術
● 具體角色的可視性、存取性：公開 (Public)、私有 (Private)、保護 (Protected)
● 關注的是服務跟服務之間的相依性
● 必須要有清楚的角色定義：客戶使用者、內部使用者（後台管理）
● 能用上述的抽象元素，講故事、拍廣告、講出商業價值
● 平常關注溝通，換句話說：平常就是這樣溝通，天然的。
物件導向?
請點這裡看 OO 概念

69. 架構與團隊
69
StorageWeb
APIDatabase
Internal GW
External LB
Whatever Service
架構
Backend APP
QA SRE
PO / PM
Mission Impossible Team
團隊
Manager

70. 架構的治理：配置管理
● 目的：
○ 服務的依賴關係
○ 服務樹
● 實踐：
○ ITIL - CMDB (Configuration Management DataBase)
○ Service Discovery
70
微服務的基礎建設 - Service Discovery

71. End User
Private
Public
Protected
ACL
架構與團隊
BlackForest
71
SwordBearer
ShelterEra
Internal Users
Production (SaaS)
ThreeBody
ChaoticEra
Gravity
Naming: 三體中英文對照表
Dweller

72. 72
http://bonkersworld.net/organizational-charts
有人的地方就有江湖

73. 架構與團隊的溝通
73
● 架構角色之間怎麼溝通，團隊就怎麼溝通
○ 某個加一個新功能，要把所有依賴服務的負責人 都問過一輪
○ 某個一個功能出問題，要把所有依賴服務的負責人 都問過一輪
● 如果架構角色的關係不清楚：
○ 某個加一個新功能，根本不知道怎麼問 …
○ 某個一個功能出問題，根本不知道怎麼查問題 …
● 團隊成員怎麼溝通，架構就怎麼溝通
● 跨團隊怎麼溝通，跨服務就怎麼溝通

74. 架構與團隊
74
StorageWeb
APIDatabase
Internal GW
External LB
Whatever Service
架構
Backend APP
QA Ops
PO / PM
Mission Impossible Team
團隊
Manager
康威定律？
每个架构师都应该研究下康威定律

75. 抽象架構的目的
75
● 跟商業目標有連結
● 幫助溝通，協助其他角色了解系統
○ 不見得能夠完全了解
○ 實體架構會更難說

76. 76
有了抽象，那的具象呢？

77. 系統架構
現場實踐
(Rock on Live!)
77
Source: https://pixabay.com/en/concert-rock-music-band-stage-497182/

78. 系統架構：現場的實踐
78
● Live 就是現場，環境就是現場
● 實踐如何把抽象架構用最可靠、最新、最潮、最噴的技術，做出來，能落地
● 架構要思考更多本質性的問題
○ 資料流的分佈與溫度
○ 分散式系統的謬論
● 實踐的技術要跟商業目標、解決問題有連結

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

80. 80
不管用什麼架構，要能用最少資源
把邏輯架構組出來，落地變實體架構

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
用完就關、低成本
小容量、使用時間長

82. 有了實體架構圖，能夠建置環境了
來看看 SRE 一定要面對的問題
82

83. 83
https://www.ettoday.net/news/20180908/1254517.htm

84. 84
https://den.ncdr.nat.gov.tw/CitySubj
ect?cityid=64&type=CityDesc

85. 降雨量的概念
85
https://www.cwb.gov.tw/V7/observe/rainfall/define.htm?

86. 當豪雨灌進城市的時候
86
● 各地區的雨量是多少？
● 排水系統哪裡會出問題？
● 這些積水多久會退去？

87. 網路流量是什麼？
87

88. 88
為瞬間巨量做好準備 (P32) by Earou Huang

89. 89
High
Low
High
Medium

90. 90
High
Low
High
Medium
NAT
DNS
8.8.8.8

91. 91
Service A
Service B
ServiceD
ServiceC
CDN
LB
Client: Desktop / Mobile
Private
Public
Protected
Access Control
Common
Services
/login
資料流的分佈與溫度

92. 92
Service A
Service B
ServiceD
ServiceC
CDN
LB
Client: Desktop / Mobile
Private
Public
Protected
Access Control
/category
/theme
Common
Services
資料流的分佈與溫度

93. 93
Service A
Service B
ServiceD
ServiceC
CDN
LB
Client: Desktop / Mobile
Private
Public
Protected
Access Control
/order
Common
Services
資料流的分佈與溫度

94. 94
Service A
Service B
ServiceD
ServiceC
CDN
LB
Client: Desktop / Mobile
Private
Public
Protected
Access Control
/order
/category
/theme
Common
Services
/login
資料流的分佈與溫度

95. Source: https://pixabay.com/en/circulatory-system-labels-biology-41523/
商業動能像心跳
● 如果流量就像血液，心跳表示商業的動能
● 那麼了解系統每個之間的流量，就等於了解人體
系統的健康
● 大動脈、靜脈
● 心血管疾病：
○ 高血壓
○ 肥胖
○ 中風
○ 心律不整
○ 心肌梗塞
● 人體很複雜，原因也很複雜
● 系統很複雜，原因也很複雜
95

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 (網路是同質的)

97. 再厲害的樂手 表演前
都會看著樂譜練過
再有經驗的 SRE 上線前
都要看著架構圖演練過
97

98. 98
架構跟 SRE 有什麼關係？

99. 探索
99
Source: https://pixabay.com/en/map-navigate-explore-adventure-846083/
值得警惕的是，理解一個系統應該如何工作，並不能
使人成為專家。只能靠調查系統為何不能正常工作才
行。
Be warned that being an expert is more than
understanding how a system is supposed to work.
Expertise is gained by investigating why a system
doesn’t work.
-- Brian Redman
SRE CH12 Effective Troubleshooting

100. 思考：SOP 怎麼來的？
100

101. 以下摘自 淺談系統監控
101
思考：監控指標怎麼來的？

102. 2017/06 淺談系統監控
102

103. 103
2017/06 淺談系統監控

104. 104
2017/06 淺談系統監控

105. 105
2017/06 淺談系統監控

106. 106
2017/06 淺談系統監控

107. Again：SOP 怎麼來的？
107

108. CPU 滿百
ELB 機器不穩定
108
行為與動作的
排列組合
產生的
現象與症狀
反覆操作、驗證
行為的集合與次序
透過探索與實驗
揭露現象，定義問題
顏色是有意義的

109. SOP 背後的意義
● 他只是眾多行為集合之下，所產生的現象
● 當事件發生時（現象），需要有 SOP
● 當系統越複雜的時候
○ 現象會越難預測
○ 行為的路徑會越複雜
109

110. 110
Event
現象、症狀 問題
t
SOP
找到 SOP
Fixed
1. 依據現象，做出判斷
2. 很快找到 SOP
3. 依照 SOP 解決問題
顏色是有意義的

111. 111
Event
現象、症狀 問題
t
SOP
找到 SOP
Fixed
這叫做理想
真實的世界不是這樣的

112. 112
Event
現象、症狀 問題
t
SOP
找不到 SOP
根本走不下去
不完整、有誤
Fixed
顏色是有意義的
� 直到世界盡頭
SOP
直到世界盡頭

113. 113
這才是真實的世界

114. 114
Event
現象、症狀 問題
t
SOP
找到 SOP
Fixed
探索
定義問題
事件報告
推演
Cloud Migration
推演 10 次！
顏色是有意義的

115. 透過推演，讓思路越來越完整
115

116. 116
事前的推演 + 思考
得到：SOP + 信心 + 可靠的系統

117. 117
Event
現象、症狀 問題
t
推演與探索
參考 SOP
Fixed
做出
判斷
顏色是有意義的

118. 在事件當下的 SOP，通常不會考慮這些
118
● 人性
○ 時間點：上班時間、下班中、下班後、晚上、深夜、週末、國定假日、特定節日（聖誕節）
○ 場景：辦公室、家裏
○ 體力、食物、精神支持與鼓勵
○ 誤動作
○ 交班、團隊、協作對外的溝通
● 在事件當下 SOP 是參考用
○ 平常沒有訓練
○ SOP 太多，太瑣碎、沒維護
○ 缺少相關資源：環境變數、權限、找不到 script

119. 在事件當下，一百條 SOP 等於沒有
119

120. https://www.bnext.com.tw/article/42985/gitlab-suffers-major-backup-failure-after-data-deletion-incident120

121. 121
Event
現象、症狀 問題
t
SOP
Fixed
� 直到世界盡頭
SOP
直到世界盡頭
找不到 SOP
根本走不下去
不完整、有誤

122. 備份只是手段
能還原才是目的
122

123. 在事件當下『調查系統為何不能正常工作』
那是一種煎熬與痛苦
123

124. 在事件之前『調查系統為何不能正常工作』
那是一種樂趣與成就。
124

125. 125

126. 126
管理
建立標準化：基礎架構、溝通模式

127. 推動基礎架構標準化
127
● 以 Reliability 為前提，制定基礎架構標準化作業
● 標準化是溝通效率與品質的依據
● 標準化是維運自動化的前置條件
● 架構師與 SRE 共同制定，從上往下落實， 從商業應用，到現場實踐
● 標準化架構的識別對象 (參考物件導向原則)

128. 溝通的標準模式
● 注意主詞、受詞、代名詞
○ 你、我、他、這個、那個
○ 用圖溝通腦海裡的東西
○ 產品的名稱很重要
● 用顏色代表溝通的共識
● 時間 + 數據呈現問題 ⇒ 指標
128
代名詞的笑話：
我只有兩個不會：這個也不
會，那個也不會。

129. Again，請用圖來溝通
紅色：Actions (尾)
黑色：現況 (頭)
綠色：方向、未來 (希望)
藍色：問題點、討論 (科學)

130. 如果你是管理者
● 釐清一件事情、一個功能，需要跟幾個人溝通？
● 提升溝通的效率：讓溝通有最短路徑、最少節點
○ 工具：Email、Slack、Wiki、JIRA
○ 團隊：Team A、Team B、Team C
● 提升溝通的品質：
○ 商業情境、用故事
○ 架構圖、團隊
溝通的品質
130

131. 溝通的品質
標準化名稱、代號很重要
● 產品名稱：
○ 不要取一般名詞，例如 VM，溝通會錯亂
○ 取具備象徵意義的名稱
● 開發代號：
○ 要有開發代號，像 Android 糖果系列
○ 取具備象徵意義的名稱
● 軟體版本：Semantic Versioning
131

132. 132
分享過往的異常報告
● 如何找問題的思路
● 探究背後的根本因素

133. 標準化先行
標準化先行
標準化先行
133

134. Part II 應變能力的培養
134
架構
探索 管理
商業需求、抽象架構、實踐架
構、環境建置、分散式謬論
標準化先行、基礎架構標
準化、溝通標準化、溝通品
質、異常報告SOP 探索、測試、逆向思
考、混沌工程、Game Day

135. 135

136. 136
第一年 第二年 第三年 第四年 第五年
新創事業的發展階段
有產品雛型，測試
市場反應
調整方向，邁向成長
階段，損益平衡
擴大規模，開始獲利，
注重可靠性
進入市場，驗證商業模
式，Burn Rate 降低

137. 哪個階段要有緊急應變流程？
● 看產業性質：EC、Blockchain、直播 … 都不一樣
● 看資金來源：
○ 有些新創 Day1 團隊就兩百人了
○ 有些新創燒了五年才規模化，可靠性直接引響商業
● 看老闆背景：
○ 有些老闆自己就是工程背景
○ 看主管
137

138. 138

139. 139
Recap
從緊急事件，談 SRE 應變能力的培養

140. 事後補救事前預防
t
Abnormal
Bug
止血 止傷 治療
警急
事件
管理
教育訓練
觀測
(Observability)
量測
(Measurement)
Event
效能
(APM)
異常演練
架構優化
效能測試
趨勢預測
(Forecast)
救災事件管理 探索 SOP
SRE
檢傷
分類
異常
報告
檢討
改進
防火巷
SLA

141. t
Down
Time
Part I 事件當下的應變：行動與策略
141
工程
管理
Up
Time
策略 溝通 策略 溝通
止血 調查 調查
MTTR
SLA

142. 142
開始止血前
請閉上眼睛，深呼吸

143. Part II 應變能力的培養
143
架構
探索 管理
商業需求、抽象架構、實踐架
構、環境建置、分散式謬論
基礎架構標準化、溝通標準
化、溝通品質、異常報告
SOP 探索、測試、逆向思
考、混沌工程、Game Day

144. 144
Event
現象、症狀 問題
t
推演與探索
參考 SOP
Fixed
做出
判斷
顏色是有意義的

145. 請在白板用圖來溝通
紅色：Actions (尾)
黑色：現況 (頭)
綠色：方向、未來 (希望)
藍色：問題點、討論 (科學)
顏色是有意義的

146. t
Event
降低平均修復時間 MTTR
146
右移 ∞

147. t
Event
降低平均修復時間 MTTR
147
右移 ∞
Event

148. t
Event
降低緊急程度（換個顏色）
148
Event

149. 事件的發生是必然的
但可以不用是緊急
149

150. 預防勝於治療
治療只是手段，預防才是目的
150

151. 151

152. 152
結束之前
用音樂說『緊急事件』

153. Stevie Ray Vaughan, SRV
00:36: the strings break!
00:52: 換琴
閉上眼，你不會有中斷的感覺
153
SRV 是 90 年代傳奇藍調歌手、吉他手，百大吉他手第7 名。1990
一場空難意外驟逝，得年37 歲。

154. 練樂器很難嗎？九成九的時間都在練 基本
功
● 個人
○ 很扎實的演奏功力 → 基本功
○ 臨危不亂 → 信心、歌曲進度掌握
● 團隊
○ 鼓手、Bass、Keyboard：信任、相信你沒問題 (也可能沒發現)
○ 技師：
■ 發現吉他出問題了、準備備用琴
■ 在對的時間幫忙換琴，不影響表演
● 聽眾
○ 相信，因為他們是專業的藝術家
● 溝通
○ 眼神，因為有默契
154

155. 延伸思考
標題：從緊急事件，談 SRE 應變能力的培養
請把 SRE 換成其他角色，例如：個人、團隊、企業、組織、國家
155

156. 156

157. 157
簡報構思原由
● 系統維運的精神
● 跨領域的緊急應變 - SRV 斷弦事件
● 緊急應變 (Emergency Response)

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

159. ● 如合面對陌生的系統
● 培養逆向工程的思考與想像力
● Game Day
159
今天沒提到的