SRE CH13 - Emergency Response (20171228)

SRE Study Group: https://study-area.sre.tw/01_SRE/CH12-15/

Transcript

2. Chapter 13 Emergency Response 緊急事件回應 2 作者：Corey Adam Baye
3. Things break; that’s life. 東西早晚要壞的，這就是生活。 3
4. 當系統出現問題時怎麼辦？ • 大部分不是處理真實的物理危險 • 問題發生時，不會是一個人單獨面對 • 如果災難性的問題，公司應該已經有災難應急管理流程 (Ch14) 4
5. 緊急事故 一、測試導致的緊急事故 二、變更部署帶來的緊急事故 三、流程導致的嚴重事故 5
6. 一、測試導致的緊急事故 (Test-Induced Emergency) 6
7. • SRE 故意破壞系統、模擬事故 • 針對失敗模式，進行預防，提高可靠性。 測試導致的緊急事故 7
8. 意外發現一系列的系統依賴 • 細節：在大型分散式 MySQL 中，限制一個測試資料庫的存取 • 響應： ◦ 幾分鐘後，大批回報 內外都無法存取某個關鍵服務 ◦ SRE 立即中止測試，但卻 Rollback 失敗 ◦ SRE 找到已經測試過的方法，成功恢復服務 ◦ SRE 找負責開發的開發者，修復問題，一小時 內恢復 ◦ 結果促使開發者進行徹底修復，同時制定週期性測試保證不再發生 測試導致的緊急事故 8
9. 測試導致的緊急事故 - 事後總結 • 好的： ◦ 事故在公司內部進行溝通，有足夠信息確認是可控的，測試導致的，立即停止測試。 ◦ 一小時內恢復服務 ◦ 受影響的團隊，重新配置服務，將測試資料庫移除 ◦ 制定週期性測試，保證類似問題不再發生 • 不好的 ◦ 事前有充分審核與準備，但事實證明，對於系統的了解還不 夠 ◦ 沒有正確遵守警急處理流程，流程才剛剛建立 9
10. 補充：SOP 導入的問題 • 只有定義的人最清楚 • 其他人如何清楚 SOP ◦ 參與 SOP 定義 ◦ 從演練中熟悉 ◦ 從異常中學習 SOP 10
12. 二、變更部署帶來的緊急事故 (Change-Induced Emergency) 12
13. 變更部署帶來的緊急事故 • Google 系統的配置 (Configuration) 很複雜 • 每次都需要大量針對配置做測試 13
14. 變更部署帶來的緊急事故 - 細節 • 某個星期五，一個防濫用的基礎服務 (anti-base) 新版配置推送到所有機器 • 這服務和對外服務有聯繫 • 新版配置觸發一個 Bug，導致外部服務進入崩潰循環 (crash-loop) • 內部很多基礎服務也依賴這個服務 14
15. 變更部署帶來的緊急事故 - 事故響應 • 幾秒內，監控系統開始報警 • On-call 人員發現公司內部網路出問題 • 災難安全屋 (panic room) - 很多人都來了 • 五分鐘後，部署配置的工程師發現問題，Rollback ，各項服務逐漸恢復 • 問題發生 10 分鐘後，on-call 人員依照流程，宣告進入警急狀態 • 部署配置工程師告知 on-call 人員，但是最初的事故導致另外的 Bug，一小時後 才恢復 15
16. 變更部署帶來的緊急事故 - 事後總結 做得好的 • 監控、檢測即時回報狀況 → 但是一直吵，on-call 難以應對，過程中充滿 noise • 問題確認後，相關人得到清晰和即時的狀態 • 系統可以很快 rollback 從中學習到的 • 部署前有完整的 Canary 部署驗證，卻沒有觸發 Bug • 測試配置文件，用了一個很特別、很少用的關鍵詞 16
17. http://www.ithome.com.tw/news/116559 17 2017/08/30
19. Highlight • 連鎖反應 • Rollback • 警急應變的層級 19
20. 連鎖反應 B C D A v1.0 v2.0 Q Z S W Tips: 每個圈代表 Service or Bug 20
21. 如果每個圈代表 Service • 你知道 Service 的相依性嗎？ • 你要如何知道？ 如果每個圈代表 Bug • 要如何發現這些 Bug? • 要如何知道他們的相依性？ 連鎖反應 - 問題 21
22. 所以 Unit Test 要不要做？ 測試重不重要？ 22
23. Architecting for the Cloud (AWS Whitepaper) https://d0.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf 23
24. Highlight • 連鎖反應 • Rollback • 警急應變的層級 24
25. Rollback to Previous Version 25
26. Regular Deployment Procedure 26
27. LATEST CURRENT PREVIOUS v1.0 v1.1 Runtime Current Deploy LATEST Build Swap link Reload 27
28. LATEST CURRENT PREVIOUS v1.0 v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 28
29. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 29
30. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 30
31. Rollback to Previous Version 31
32. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Rollback (Swap link) Reload 32
33. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Rollback (Swap link) Reload 33
34. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Rollback (Swap link) Reload 34
35. LATEST CURRENT PREVIOUS v1.1 Runtime v1.2 Rollback (Swap link) Reload 35
37. 三、流程導致的嚴重事故 (Process-Induced Emergency) 37
38. 流程導致的嚴重事故 - 細節 • 常規自動化測試中，將即將退役的機器群，發送兩次下線請求 • 第二次的請求中，一個非常隱蔽的 Bug 將全球所有 DC 的機器，加入 diskerase (磁碟銷毀) 清單中 38
39. 流程導致的嚴重事故 - 災難響應 • On-Call 工程師收到一個報警通知，第一個小型資料庫機器都離線了，即將退役 • 調查後發現，這一群機器已經被移轉到 diskerase 程序中 • 依照流程，將流量導流到其他地區 (drain) • 不久後，全球 DC 都發出報警 • On-Call 停止整個團隊的自動化工具，避免進一步的問題發生 • 導流後，Latency 拉高，但是服務恢復了 • 最難的問題：如何復原？ ◦ 數據中心網路壅塞，網路工程師調整網路節點，提高吞吐量 ◦ 三個小時後，其中一個數據中心恢復服務 ◦ 美國團隊將任務交給歐洲團隊，三天 內恢復大部分服務 39
40. 流程導致的嚴重事故 - 事後總結 做得好的 • 反向代理快速將流量從小型資料中心轉到到其他大型資料中心 • 網路壅塞問題迅速地被排除 • 小型資料中心離線請求處理得非常高效率和完美 • 退役自動化迅速將對應的監控系統也刪除了，On-Call 人員很快地將這些改動恢 復，因此有了評估嚴重性的依據 40
41. 從中學習到的 • 自動化系統發出的指令，缺乏合理性的檢查 • 第二次指令取得空白回應，自動化系統沒有拋棄 ◦ 空白有時候等於全部 流程導致的嚴重事故 - 事後總結 41
42. http://www.ithome.com.tw/news/112375 42
43. https://aws.amazon.com/message/41926/ 43
44. https://www.bnext.com.tw/article/42985/gitlab-suffers-major-backup-failure-after-data-deletion-incident 44
46. Recap：緊急事故 一、測試導致的緊急事故 二、變更部署帶來的緊急事故 三、流程導致的嚴重事故 46
47. • 時間和經驗告訴我們：系統一定會出問題 ◦ Things break; that’s life. • Google 學到的關鍵課程：所有問題都有對應的解決方案 • 找不到方法，就在更大的範圍尋求幫助，找更多團隊成員 • 最高的優先權是要解決問題的困境 • 觸發問題的人，對事故了解得最清楚 • 事件過後，要整理報告 所有的問題都有解決方案 47
48. • 為事故保留紀錄 • 提出那些大的，甚至是不可能的問題 ◦ 如果有人入侵系統了，怎麼發現？ ◦ 網路設備泡水了怎麼辦？ ◦ 大樓停電了怎麼辦？ • 鼓勵主動測試 ◦ 理論和實踐是不同領域 ◦ 系統故障的那一刻，你才真的開始了解他 ◦ 不要假設故障的時候，最聰明的同事會在你身邊 跟過去學習，而不是重複他 48