Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Running a Service in Production without Losing Your Sanity

640 views

Published on

Designing Web Service and Reliability Engineering

Published in: Technology

Running a Service in Production without Losing Your Sanity

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

×