SRE CH12 - Effective Troubleshooting
•
2 gostaram•1,938 visualizações
SRE CH12 - Effective Troubleshooting
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a SRE CH12 - Effective Troubleshooting
Semelhante a SRE CH12 - Effective Troubleshooting (20)
Mais de Rick Hwang
Mais de Rick Hwang (20)
SRE CH12 - Effective Troubleshooting
- 1. 1
- 2. 想打世界杯，看清楚以下是你的對手在做的事： ● 線上閱讀：https://landing.google.com/sre/book.html ● SRE Conference: 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. 3
- 6. 沒有什麼大神，雷踩得夠多，而且都能解決，就是大神。 Hit mines will make 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 which things go right are special cases of the ways in which things go wrong. -- John Allspaw 7
- 9. 9
- 10. 理 論 10
- 11. A process for troubleshooting 11 Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 Consider re-triaging if situation changes. 如果情況發生改變，考慮重新 定位
- 12. 陷阱 ● 低效率的故障排除原因：定位、檢查、診斷 ○ 對於系統不夠瞭解 ○ 關注錯誤的系統現象，或者誤解系統現象的含義 ○ 將問題過早歸納極為不可能的因素 ○ 試圖解決與當前問題相關的其他問題 ● 如何避免： ○ 學習系統的運作原理，了解分散式系統的基本模式 ○ 當聽到蹄子聲響時，要先想到馬，而不是斑馬 ○ 所有可能都存在時，要優先考慮做 簡單的解釋 ● 相關性 (Correlation) 不等於因果關係 (Causation) ○ 網路封包遺失，和硬碟損壞可能是同一個原因，例如供電故障 ○ 系統規模越來越複雜，監控指標越來越多，無法避免『純屬巧合』 12
- 13. 13
- 14. 14 開始今天的主題
- 15. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 故障報告 15
- 16. 故障報告 ● 起源： ○ 同事告知 ○ 系統發起 ● 有效的報告 ○ 如何重現 How to reproducre ○ 預期結果 Expected Result ○ 實際結果 Actual Result ● 報告應該存在可以搜尋的系統，像是 Bug / Issue Tracking ● 報告要有分析工具 16
- 19. 故障報告 - 自動回報 莎士比亞收尋系統故障實例：過去五分鐘連續搜尋 “the forms of things unknow” 無 法得到正確結果： 1. 報警系統自動建立一個 Bug 2. 自動填入測試 URL、on-call 關聯，將 Bug Assign 給相關人員 19
- 20. 插播 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 Series 2016: 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. 27
- 28. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 定位 Triage 28
- 29. 定位 ● 判斷問題的嚴重性 (Severity) ● 大型系統 / 重要系統 ○ 盡最大可能讓系統恢復服務 → First Priority ○ 立即開始故障排除過程，試圖找出問題根源 → 不是 First Priority ● 處理方法 ○ 讓流量導向正常服務的 Cluster ○ 關閉系統的某一些功能 ○ 緩解系統是第一要務 ● 快速定位問題 ○ 保留現場 ○ 蒐集 Log 初級飛行員遇到警急事故時，首要任 務保持飛機飛行，而不是保證乘客安 全降落、故障定位排除則是次要的。 29
- 30. 30
- 31. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 檢查 31
- 32. 檢查 ● 透過監控系統了解整個系統是否正常運作 ● time-series 是理解系統的好方法，但也要小心虛假相關! ● Log 很重要，透過他了解分散式系統的運作關係 ● 不同產品需要極為不同的 Log 系統 32
- 33. 33
- 34. Health Check 34
- 36. 36
- 37. Ref: 淺談系統監控與 AWS CloudWatch 的應用 Levels of Health Check ● Light / Static Health Check ● Layer Health Check ● Deep Health Check 37
- 38. Light / Static Health 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) 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
- 40. Deep Health Check 40 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
- 41. Levels of Health Check 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 Service B Service C Service D Service E (Third Party) Service Dependencies (Internal)
- 43. Levels of Health Check 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. 45
- 46. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 診斷 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. 51
- 52. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 測試 / 修復 52
- 53. 測試和修復 ● 理想的測試：互斥性，推翻假設組，讓比較組成立。 ○ 執行較為困難 ● 測試產生誤導性結果 ● 執行測試的副作用 ● 測試無法推論結果，只是建議性 53
- 54. 54
- 55. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 治癒 55
- 56. 治癒 因為以下因素，Production 經常只能發現可能的原因： ● 系統複雜度：可能有很多因素共同影響問題 ● 在 Production 重現問題也許是不可能 56
- 58. 58
- 59. 59
- 61. 61
- 62. Backup 62
- 63. Triage 定位 Problem Report 故障報告 Examine 檢查 Diagnose 診斷 Test / Treat 測試 / 修復 Cure 治癒 神奇的負面效果 63
- 64. 神奇的負面結果 - 沒預期出現的 ● 新系統的設計、啟發性算法、工作流程沒有改進試圖取代的就系統。 ● 負面結果不應該被忽略、或者被輕視 ● 試驗中出現的負面結果是要緊的 (Conclusive) ● 工具和方法可能超越目前的試驗，為未來工作提供幫助 ● 公布負面結果有助於提升整個行業的數據驅動風氣 ● 公布結果 64