從緊急事件 談 SRE 應變能力的培養 - DevOpsDays Taipei 2018

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

Transcript

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
10. 10 開始之前 用電影說『緊急事件』
11. Ref: 緊急應變 (Emergency Response) 改編自 2009 年一月真實的事件: 全美航空 1549 號班機事故。講述 Sally 機長在一次 飛行中，遇到鳥擊事件，A320 兩具引擎同時失效，機長在 208 秒之內，依靠豐富的飛 行經驗、高超技術、豐富的飛安事故調查，最後飛機順利迫降在哈德遜河，拯救了全 部 155 人的故事。 事後的飛安調查中，國家傳輸委員會 (NTSB) 拿當時的飛行參數、用電腦模擬降落在 附近機場，結果可以順利降落在機場，以此作為 Sally 誤判的依據。 11 電影：薩利機長：哈德遜奇蹟
12. 12 飛安調查對話 • 副機長： ◦ 飛機之所以能夠順暢運作，最後成功降落，是 因為機長啟動了輔助動力系統 • 調查委員： ◦ 他只是遵照快速檢查手冊 • 副機長： ◦ 他完全沒有遵照標準程序，我很清楚，因 為手冊在我手上 ◦ 發動機熄火後，他立刻啟動輔助動力系統，那 是手冊上的第十五道步驟 ◦ 如果遵守該手冊的規定，我們都死了
13. Titanic 13 2015/02/04: 復興航空235號班機空難
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
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 Group Batch DB 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
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. Storage Web API Database 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 Storage Web API Database 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 Storage Web API Database 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
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
136. 136 第一年 第二年 第三年 第四年 第五年 新創事業的發展階段 有產品雛型，測試 市場反應 調整方向，邁向成長 階段，損益平衡 擴大規模，開始獲利， 注重可靠性 進入市場，驗證商業模 式，Burn Rate 降低
137. 哪個階段要有緊急應變流程？ • 看產業性質：EC、Blockchain、直播 … 都不一樣 • 看資金來源： ◦ 有些新創 Day1 團隊就兩百人了 ◦ 有些新創燒了五年才規模化，可靠性直接引響商業 • 看老闆背景： ◦ 有些老闆自己就是工程背景 ◦ 看主管 137
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
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
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 今天沒提到的