Download as PDF, PPTX
Uploaded byRick Hwang
SRE CH12 - Effective Troubleshooting
本文探討故障排除的有效方法，強調理解系統運作不等於專家，實際經驗才是關鍵。文中提及了定位問題的步驟、測試與修復的挑戰，以及保持系統健康的重要性，並探討了自動化在故障排除中的誤解與限制。最後，文中提出提高系統可觀察性及設計良好的接口以簡化故障排查的建議。
SRE CH12 - Effective Troubleshooting
- 1.
- 2. 想打世界杯，看清楚以下是你的對手在做的事： ● 線上閱讀：https://landing.google.com/sre/book.html ● SREConference: a. SREcon 2016 - Netflix: 190 Countries and 5 CORE SREs b. SREcon16 - Performance Checklists for SREs c. SREcon16 - The Realities of the Job of Delivering Reliability d. SouthBay SRE: Cloud Capacity Planning - August 9th 2016 e. Site Reliability Engineering at Dropbox 2
- 3.
- 4.
- 5.
- 6. 沒有什麼大神，雷踩得夠多，而且都能解決，就是大神。 Hit mines willmake the guy to be a great geek. -- Rick Hwang 值得警惕的是，理解一個系統應該如何工作，並不能使人成為專家。只能靠調查系統 為何不能正常工作才行。 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 神寫的系統是不會有雷 6
- 7. 系統正常，只是該系統無數異常情況下的一種特例。 Ways in whichthings go right are special cases of the ways in which things go wrong. -- John Allspaw 7
- 8.
- 9.
- 10.
- 11. A process fortroubleshooting 11 Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 Consider re-triaging if situation changes. 如果情況發生改變，考慮重新 定位
- 12. 陷阱 ● 低效率的故障排除原因：定位、檢查、診斷 ○ 對於系統不夠瞭解 ○關注錯誤的系統現象，或者誤解系統現象的含義 ○ 將問題過早歸納極為不可能的因素 ○ 試圖解決與當前問題相關的其他問題 ● 如何避免： ○ 學習系統的運作原理，了解分散式系統的基本模式 ○ 當聽到蹄子聲響時，要先想到馬，而不是斑馬 ○ 所有可能都存在時，要優先考慮做 簡單的解釋 ● 相關性 (Correlation) 不等於因果關係 (Causation) ○ 網路封包遺失，和硬碟損壞可能是同一個原因，例如供電故障 ○ 系統規模越來越複雜，監控指標越來越多，無法避免『純屬巧合』 12
- 13.
- 14.
- 15. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 /修復 Cure 治癒 故障報告 15
- 16. 故障報告 ● 起源： ○ 同事告知 ○系統發起 ● 有效的報告 ○ 如何重現 How to reproducre ○ 預期結果 Expected Result ○ 實際結果 Actual Result ● 報告應該存在可以搜尋的系統，像是 Bug / Issue Tracking ● 報告要有分析工具 16
- 17.
- 18.
- 19. 故障報告 - 自動回報 莎士比亞收尋系統故障實例：過去五分鐘連續搜尋“the forms of things unknow” 無 法得到正確結果： 1. 報警系統自動建立一個 Bug 2. 自動填入測試 URL、on-call 關聯，將 Bug Assign 給相關人員 19
- 20.
- 21. 自動化 XXX -陷阱 ● 不要陷入『自動化 XXX 』的迷思 ○ 自動化測試 ○ 自動化部屬 ○ 自動化維運 ○ 自動化挖礦 ○ 自動化加薪 ● 自動化 != 黑魔法 ○ 不要以為有『自動化』就沒事了、下班了 ● 一般說的『自動化』大多說的是把程序 / 步驟變成程式碼而已。 ○ 自動化：Automation ○ 程序控制：Process Control ○ 步驟：Steps ○ Automation = Process = Steps ?? 21 https://rickhw.github.io/2017/11/12/DevOps/Gossip-Automation/
- 22. 22 電機：自動控制 (Automation Control) ●自動 (v) ⇒ Conditions ⇒ Actions ● 控制 (v) ⇒ 程序 (obj) https://rickhw.github.io/2017/11/12/DevOps/Gossip-Automation/
- 23. 自動化要靠 AI /ML 23
- 24. 24 AWS Summit Series2016: Big Data Architectural Patterns and Best Practices on AWS
- 25. FeedbackActions (Do Something) 25 Conditions (event driven) AI/ ML Log Collection Analyze (realtime) ProcessInput Output Automation https://rickhw.github.io/2017/11/12/DevOps/Gossip-Automation/
- 26. 26 要強調這件事的理由 ● 一般人會以為『自動』是做到 80分的事情 ● 實際上做的『自動』是 -25 分的事情 -- 只是在做程序性 (Process) 任務
- 27.
- 28. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 /修復 Cure 治癒 定位 Triage 28
- 29. 定位 ● 判斷問題的嚴重性 (Severity) ●大型系統 / 重要系統 ○ 盡最大可能讓系統恢復服務 → First Priority ○ 立即開始故障排除過程，試圖找出問題根源 → 不是 First Priority ● 處理方法 ○ 讓流量導向正常服務的 Cluster ○ 關閉系統的某一些功能 ○ 緩解系統是第一要務 ● 快速定位問題 ○ 保留現場 ○ 蒐集 Log 初級飛行員遇到警急事故時，首要任 務保持飛機飛行，而不是保證乘客安 全降落、故障定位排除則是次要的。 29
- 30.
- 31.
- 32. 檢查 ● 透過監控系統了解整個系統是否正常運作 ● time-series是理解系統的好方法，但也要小心虛假相關! ● Log 很重要，透過他了解分散式系統的運作關係 ● 不同產品需要極為不同的 Log 系統 32
- 33.
- 34.
- 35.
- 36.
- 37. Ref: 淺談系統監控與 AWSCloudWatch 的應用 Levels of Health Check ● Light / Static Health Check ● Layer Health Check ● Deep Health Check 37
- 38. Light / StaticHealth Check 38 ASG ELB (Internet-Facing) Route 53 Web App ASG Web Servers ELB (Internal ELB) App ServersThird Party Services Health-Checker Light Health Check Layer Health Check Deep Health Check Service A Service B
- 39. Layer Health Check 39 ASG ELB (Internet-Facing) Route53 Web App ASG Web Servers ELB (Internal ELB) App ServersThird Party Services Health-Checker Light Health Check Layer Health Check Deep Health Check Service A Service B
- 40. Deep Health Check 40 ASG ELB (Internet-Facing) Route53 Web App ASG Web Servers ELB (Internal ELB) App ServersThird Party Services Health-Checker Light Health Check Layer Health Check Deep Health Check Service A Service B
- 41. Levels of HealthCheck 41 ● Light / Static Health Check ○ Application 自己是正常的, 像是: Tomcat, IIS 正常運作 ● Layer Health Check ○ App 跟另一個 App 溝通是正常的, Tomcat to Redis ○ 出問題時，釐清問題的節點 ● Deep Health Check ○ 確認 Service 自身的商務邏輯是正常的：登入、結帳 Ref: 淺談系統監控與 AWS CloudWatch 的應用
- 42. 42 Service A ServiceB Service C Service D Service E (Third Party) Service Dependencies (Internal)
- 43. Levels of HealthCheck 43 ● Light / Static Health Check - Application Self ● Layer Health Check - App to App ● Deep Health Check: Service Self ● Service Health Check: Service to Services Ref: 淺談系統監控與 AWS CloudWatch 的應用
- 44. ● 開發好的應用程式，交給其他單位 (Test、Operation)部署時 ，用來確認部署正確性、確認點 ● CD 時可以自測 ● 跨很多系統時，釐清問題的基本參考點，特別是 Micro Service 架構 ● 系統異常發生時，檢查的起始點 Health Check 的用途 44 Ref: 淺談系統監控與 AWS CloudWatch 的應用
- 45.
- 46.
- 47. 診斷 - 簡化和縮略 ●系統中的介面 (interface) 都有明確的 Input / Output ○ 用黑盒測試 (Blackbox) 檢測 ● Divide and Conquer - 分而治之 ○ 將一個大問題，切割成許多小問題； ○ 將這些小問題解決之後，原本的大問題也就解決了。 ○ 如果小問題還是很難，那就再切成更小的問題就行了。 ○ 分割問題、各個擊破，就是 Divide and Conquer 的精神。 插話一：Unit Test 是測試的最小問題，所以 UT 很重要。 插話三：規劃專案時程的時候，要 “Breakdown” 任務 插話三：Divide and Conquer 在演算法用來分析 Recursive、Merge Sort 47
- 48. 診斷 - Ask“what”, “where”, and “why” 48
- 49. 診斷 - 最後一次修改(What touched it last) ● 正常的系統會持續工作，直到外力因素出現，例如 ○ 配置文件的修改 ○ 用戶流量改變 ● 檢查最近對系統的修改，找問題很有幫助 ● 良好的系統會紀錄完整的部署 (Deployment) 與配置 (Configuration) 異動 ○ 將部署版本資訊，與監控系統整合，有助於比對異常 49
- 50. 診斷 - 最後一次修改(What touched it last) 50
- 51.
- 52. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test /Treat 測試 / 修復 Cure 治癒 測試 / 修復 52
- 53. 測試和修復 ● 理想的測試：互斥性，推翻假設組，讓比較組成立。 ○ 執行較為困難 ●測試產生誤導性結果 ● 執行測試的副作用 ● 測試無法推論結果，只是建議性 53
- 54.
- 55. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test /Treat 測試 / 修復 Cure 治癒 治癒 55
- 56. 治癒 因為以下因素，Production 經常只能發現可能的原因： ● 系統複雜度：可能有很多因素共同影響問題 ●在 Production 重現問題也許是不可能 56
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test /Treat 測試 / 修復 Cure 治癒 神奇的負面效果 63
- 64. 神奇的負面結果 - 沒預期出現的 ●新系統的設計、啟發性算法、工作流程沒有改進試圖取代的就系統。 ● 負面結果不應該被忽略、或者被輕視 ● 試驗中出現的負面結果是要緊的 (Conclusive) ● 工具和方法可能超越目前的試驗，為未來工作提供幫助 ● 公布負面結果有助於提升整個行業的數據驅動風氣 ● 公布結果 64