Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Mehr von Rick Hwang
Mehr von Rick Hwang (20)
SRE CH13 - Emergency Response
- 1. 1
- 2. Chapter 13 Emergency Response 緊急事件回應 2 作者：Corey Adam Baye
- 3. Things break; that’s life. 東西早晚要壞的，這就是生活。 3
- 4. 當系統出現問題時怎麼辦？ ● 大部分不是處理真實的物理危險 ● 問題發生時，不會是一個人單獨面對 ● 如果災難性的問題，公司應該已經有災難應急管理流程 (Ch14) 4
- 7. ● SRE 故意破壞系統、模擬事故 ● 針對失敗模式，進行預防，提高可靠性。 測試導致的緊急事故 7
- 8. 意外發現一系列的系統依賴 ● 細節：在大型分散式 MySQL 中，限制一個測試資料庫的存取 ● 響應： ○ 幾分鐘後，大批回報 內外都無法存取某個關鍵服務 ○ SRE 立即中止測試，但卻 Rollback 失敗 ○ SRE 找到已經測試過的方法，成功恢復服務 ○ SRE 找負責開發的開發者，修復問題，一小時 內恢復 ○ 結果促使開發者進行徹底修復，同時制定週期性測試保證不再發生 測試導致的緊急事故 8
- 9. 測試導致的緊急事故 - 事後總結 ● 好的： ○ 事故在公司內部進行溝通，有足夠信息確認是可控的，測試導致的，立即停止測試。 ○ 一小時內恢復服務 ○ 受影響的團隊，重新配置服務，將測試資料庫移除 ○ 制定週期性測試，保證類似問題不再發生 ● 不好的 ○ 事前有充分審核與準備，但事實證明，對於系統的了解還不 夠 ○ 沒有正確遵守警急處理流程，流程才剛剛建立 9
- 10. 補充：SOP 導入的問題 ● 只有定義的人最清楚 ● 其他人如何清楚 SOP ○ 參與 SOP 定義 ○ 從演練中熟悉 ○ 從異常中學習 SOP 10
- 11. 11
- 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
- 18. 18
- 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
- 27. LATESTCURRENTPREVIOUS v1.0 v1.1 Runtime Current Deploy LATEST Build Swap link Reload 27
- 28. LATESTCURRENTPREVIOUS v1.0 v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 28
- 29. LATESTCURRENTPREVIOUS v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 29
- 30. LATESTCURRENTPREVIOUS v1.1 Runtime v1.2 Current Deploy LATEST Build Swap link Reload 30
- 31. Rollback to Previous Version 31
- 36. 36
- 38. 流程導致的嚴重事故 - 細節 ● 常規自動化測試中，將即將退役的機器群，發送兩次下線請求 ● 第二次的請求中，一個非常隱蔽的 Bug 將全球所有 DC 的機器，加入 diskerase (磁碟銷毀) 清單中 38
- 39. 流程導致的嚴重事故 - 災難響應 ● On-Call 工程師收到一個報警通知，第一個小型資料庫機器都離線了，即將退役 ● 調查後發現，這一群機器已經被移轉到 diskerase 程序中 ● 依照流程，將流量導流到其他地區 (drain) ● 不久後，全球 DC 都發出報警 ● On-Call 停止整個團隊的自動化工具，避免進一步的問題發生 ● 導流後，Latency 拉高，但是服務恢復了 ● 最難的問題：如何復原？ ○ 數據中心網路壅塞，網路工程師調整網路節點，提高吞吐量 ○ 三個小時後，其中一個數據中心恢復服務 ○ 美國團隊將任務交給歐洲團隊，三天 內恢復大部分服務 39
- 40. 流程導致的嚴重事故 - 事後總結 做得好的 ● 反向代理快速將流量從小型資料中心轉到到其他大型資料中心 ● 網路壅塞問題迅速地被排除 ● 小型資料中心離線請求處理得非常高效率和完美 ● 退役自動化迅速將對應的監控系統也刪除了，On-Call 人員很快地將這些改動恢 復，因此有了評估嚴重性的依據 40
- 41. 從中學習到的 ● 自動化系統發出的指令，缺乏合理性的檢查 ● 第二次指令取得空白回應，自動化系統沒有拋棄 ○ 空白有時候等於全部 流程導致的嚴重事故 - 事後總結 41
- 45. 45
- 47. ● 時間和經驗告訴我們：系統一定會出問題 ○ Things break; that’s life. ● Google 學到的關鍵課程：所有問題都有對應的解決方案 ● 找不到方法，就在更大的範圍尋求幫助，找更多團隊成員 ● 最高的優先權是要解決問題的困境 ● 觸發問題的人，對事故了解得最清楚 ● 事件過後，要整理報告 所有的問題都有解決方案 47
- 48. ● 為事故保留紀錄 ● 提出那些大的，甚至是不可能的問題 ○ 如果有人入侵系統了，怎麼發現？ ○ 網路設備泡水了怎麼辦？ ○ 大樓停電了怎麼辦？ ● 鼓勵主動測試 ○ 理論和實踐是不同領域 ○ 系統故障的那一刻，你才真的開始了解他 ○ 不要假設故障的時候，最聰明的同事會在你身邊 跟過去學習，而不是重複他 48
- 49. 49