Running a Service in Production without Losing Your Sanity
•
10 j'aime•1,505 vues
Designing Web Service and Reliability Engineering
Recommandé
Contenu connexe
Similaire à Running a Service in Production without Losing Your Sanity
Similaire à Running a Service in Production without Losing Your Sanity (20)
Plus de Poga Po
Running a Service in Production without Losing Your Sanity
- 1. Running a Service in Production without Losing Your Sanity poga 2019/10/24
- 2. Service? • 24/7 • 持續不斷的更更新 • Web Service 為主，其他領 域也可適⽤用 • 衛星上的軟體很多概念念也相同 • Computer Science 不會教
- 3. Service! • 早已是社會的⼀一部份 • Uber, Food Panda, Google, Facebook, Github, Slack, Telegram • ⼀一個開發完成的 service： • 在 production (real-world) 裡會動 • 能有效率的在 production (real-world) 中維護
- 4. Service Team Performance • Time to Delivery • Time to Recovery • # of Failed Deploys • Frequency of Deploys
- 7. Service 101 • 永遠先訂 Service-Level Objective • SLO = 願意花多少資源維護 • Define SLO likes a User
- 10. SLO 不可以 100% • 永遠不能出錯的系統 = 永遠沒辦法更更新的系統 • 極度保守 = 僵化 = 無法⾯面對變化 = 死亡 • SLO ＝ 成本，⼯工程問題永遠是在有限的資源下做 trade off • ⼈人⼒力力、成本、時程、邊際效應 • 你跟客⼾戶的距離，其實很遠 • 海海纜斷掉、天災、⾰革命、宇宙射線
- 11. 「系統不應該出錯」？
- 12. 「系統不應該出錯」？
- 13. Error Budget • SLO = 99.5%, Error Budget = 0.5% • 每年年有 1.83 天可以出包 • 就應該拿來來出包 • ⽤用來來⾯面對風險 • 架構調整，實驗、升級，各種改善
- 14. 「SLO 是 Engine Team 的事」？
- 15. 「SLO 是 Engine Team 的事」？
- 16. Production = Real World • 開發產品 • 在真實世界中給⽤用⼾戶⽤用 • 在真實世界中維護 • SLO don't matter when USERS aren't HAPPY • Developer 要能維護⾃自⼰己的產出
- 17. 瞭解你的⽤用⼾戶 • 流量量的形狀狀 • 售票系統：peak 極⾼高，平時沒有流量量 • 2B：下班時間沒⼈人⽤用 • 2C：穩定的流量量？是否定期舉辦活動？ • 發佈的⽅方式 • 盛⼤大記者會？⼩小規模漸進式發佈？2B or 2C？
- 18. 瞭解你的⽤用⼾戶 • 流量量「塑形」Traffic Shaping • 把 peak traffic 攤平、打散 • Message Queue • Load Balancing • 直接篩選流量量：Cache • QoS... etc
- 19. Design for Chaos • 出錯是正常 • 系統出錯是⼀一件平凡無奇的事情 • 實作時就要考慮
- 20. Design for Chaos • 爆炸範圍 Blast Radius • 如果這個 component 出錯，會有多少其他 component ⼀一起被拖下⽔水？ • DNS = Blast Radius 極⼤大 • Blast Radius 越⼩小越好 • Blast Radius 越⼤大，越難除錯
- 21. Design for Chaos • Service State • 200：運作正常 • 500：爆炸了了 • 常被忽略略的 Lame Duck State • Service 還在運作，但是已經不能接受更更多的負載 • 讓上游知道，才能作對應處置
- 22. Design for Chaos • Back pressure / cancellation • 下游撐不住了了，上游該怎麼辦？ • 取消 • 暫時等⼀一陣⼦子，retry • exponential fallback • thundering herd • 50%+ 的 global outage 都是因為 back pressure 沒做好⽽而發⽣生的 cascading Failure • 這類 outage 非常難解決，會像葡萄串串⼀一樣⼀一個⼀一個把系統拉垮
- 23. 瞭解你的資料 • Transactional • semi-realtime，不能錯 • 銀⾏行行、售票、⾦金金流 • Analytical • batch、資料量量⼤大、可以重試 • 資料分析、訓練模型 • Design for WRITE or READ
- 24. Security • 70% 的 CVE 都是 memory safety 問題
- 25. Security • 太多了了講不完 • OWASP top 10 • SQL Injection • select * from users where id = {} • {} = "105 or 1 = 1" • 少寫 C/C++
- 26. Designing Service • 訂定 SLO • 瞭解你的⽤用⼾戶 • Traffic Shaping • Design for Chaos • 瞭解你的資料 • Security RECAP
- 28. Service Reliability Engineering (SRE) • Reliable Service = Observable Service • SRE Team IS NOT Operation Team
- 29. Capacity Planning • 永遠不準 • N + 2 原則
- 30. Observability • 從外部變量量推測內部系統運作 • 控制理理論 • or「沒有 log 就不⽤用想 debug 了了，都是通靈」
- 31. Dashboard?
- 32. Dashboard • 幾乎沒有實際⽤用處 • 架起來來很簡單，看起來來很酷 • 「dashboards are the devil. they make you a passive consumer of static data, not an engineer constructing falsifiable hypotheses」 • 「If you are debugging with aggregates you are screwed. You gotta have that source of truth to drill down to」
- 33. ⽤用 alert 發現問題 ⽤用 log 除錯
- 34. Alert • 從使⽤用者的⾓角度發 Alert - E2E alert • Only Actionable Alerts • e.g. • Alert: 80% Disk Usage - 無法得知是否會影響 User • Alert: LB 500 rate > 10% - 會影響 User，立刻開始處理理
- 35. Alert ~= Incidents • First Step: Don't Panic • 通常沒有⼈人會受傷 • 頂多就是整個 Internet 掛了了，⼩小事 • 深呼吸
- 36. Incidents • Incident Management Process • 分⼯工、分⼯工、分⼯工 • 所有修改跟診斷都要共享 • 不可以有⼈人⾃自⼰己 ssh 進去亂改 • 溝通、溝通、溝通 • Incident Commander • 寫 Postmortem - Learning from Failure
- 37. Log Everything • 沒有 log 就不⽤用想 debug • Tracing、Logging、Feature Flag • 不光只是存 log，還要能向 log 問問題
- 38. Tracing
- 39. Log for Answering Questions • 「我們最⼤大的客⼾戶的 request failure rate 是多少？」 • 「Latency 突然變⾼高，是影響所有⽤用⼾戶，還是只是某個⽤用⼾戶 撞到 edge case？」 • 「機器負載很重，是該加機器，還是有某個⽤用⼾戶在 abuse 我們的服務，應該 ban 他？」
- 40. Feature Flag • 不改變程式的情況下改變系統⾏行行為 • 透過外部變數開啟/關閉某些功能 • if (ENABLE_SUPER_FEATURE) { ... }
- 44. Production = Real World • 沒有進 Production 前，所有測試都是假的 • 只有在真實世界才能測到真實世界的狀狀況 • Test in Production • Service 永遠都在改變，永遠都在 Release
- 47. 「週五不能 Deploy」
- 48. 「週五不能 Deploy」
- 50. First Step • Faster Deploy • Easier Rollback • Feature Flag
- 51. Reliability Engineering • 建立 actionable alert • Log everything • Faster Deploy • Easier Rollback • Test in Production RECAP
- 52. Service Team Performance • Time to Delivery • Time to Recovery • # of Failed Deploys • Frequency of Deploys
- 54. SRE is Highly Creative SRE is Disciplined
- 55. People are fighting for freedom with web services
- 56. How can we help?
- 57. Thanks