SRE CH33 Lessons Learned from Other Industries SRE CH34 Conclusion

1. 1

2. Authors: Jennifer Petoff
Chapter 33
Lessons Learned from Other Industries
其他行業的實踐經驗
Rick Hwang
2018/03/07
2

3. 3

4. 不同的行業
如何對待可靠性？
4

5. Google 其他背景的 SRE
● 國防部供應商，負責空運設施 GPS 系統
● 救生員教練
● 雷射視網膜手術演算法實踐
● 維護 E911 警急呼叫系統
● 軍用飛機地勤管理系統
● 生產流程工程師
● 財務交易系統
● 核工業安全顧問
● 核潛艇工程師
● 空中交通軟體系統開發
5

6. 警急事件 (Emergency Response)
● 電影：薩利機長
6
https://rickhw.github.io/2018/01/07/DevOps/Emergency-Response/

7. 『警急事件反應』代表以下
● 扎實的基本功 - 原理
● 平常的訓練 - 熟練度
● 事件當下的反應
● 過往的經驗
● 態度
7

8. 日本的地震演練：從小做起
8

9. 台北市如何面對核災？
9

10. (台灣政府) 沒有危機意識
(台灣人) 沒有危機意識
(台灣企業) 沒有危機意識
(你/我) 沒有危機意識
10
換個主詞，結果都一樣
日常談危機意識，會被討厭、覺得小題大做
這邊沒有強調受詞，請自己補上

11. 資安圈討論風險的建議：
『用案例恐嚇老闆 / 人民』
11
但很容易變成：狼來了效應
Rick 的看法：這跟民族性有關

12. 『預防勝於治療』
12

13. 你我的日常有『預防』？
13

14. 貴司的系統有『預防』？
能動就好？
只處理眼前問題？
14

15. 前述都是『台灣企業』的『文化』
15

16. 『台灣企業』
『跟民族性有關』
16

17. 17

18. 談『生死』、『民族』太嚴肅
換個行業來談
18

19. Stevie Ray Vaughan, SRV
00:36: the strings break!
00:52: 換琴
閉上眼，你不會有中斷的感覺
19
SRV 是傳奇藍調歌手、吉他手，百大吉他手第 7 名
1990 一場空難意外驟逝，得年 37 歲。

20. 練樂器很難嗎？九成九的時間都在練 基本功
● 個人
○ 很扎實的演奏功力 → 基本功
○ 臨危不亂 → 信心、現場掌握
● 團隊
○ 鼓手、Bass：信任、相信你沒問題 (也可能沒發現)
○ 技師：
■ 發現吉他出問題了、準備備用琴
■ 在對的時間幫忙換琴，不影響表演
● 聽眾
○ 相信，因為他們是專業的藝術家
20

21. 21

22. ● 從組織架構上對安全進行關注
○ 從上到下都是嚴格要求，例如在核動力行業、軍用飛機，軟體安全規範是明確定義的
● 關注任何細節
○ 海軍的潛艇，潤滑油沒有補充，造成連鎖性故障
● 冗餘容量
○ 2005 年某個明星電話洩漏，數以萬計粉絲打電話，通信系統 DDoS
● 模擬以及進行線上災難演習
○ 航空業的飛行模擬、航太科技的無重力模擬
○ 環境建置很重要！
應對災難的策略
22

23. 災難 預備與演練
● 不能把願望當作是一種策略 -- CH1
● SRE 文化：
○ 永遠保持警惕
○ 不停地提出疑問：什麼可能故障？故障之前如何避免？
● 年度災難演練，確保在 Production 創造出真正的問題：
○ 確保系統按照預想的方式發生故障
○ 尋找系統中未知的弱點
○ 尋找其他提高穩健性的方式，避免事故發生
23

24. 應對 災難 的策略
24
● 培訓與考核
○ 救生員證照很難考
○ 日本汽車駕照很難考
● 超乎尋常的關注對細節要求的蒐集與系統設計
○ 雷射視網膜手術設備被設計得極為簡單，因為太複雜的設計，出了狀況就瞎了
● 縱深防禦
○ 每個主系統背後都要有備用系統
○ 核電廠的輻射物理屏障

25. 事後總結的文化
● 究竟發生什麼？
● 影響的有效程度
● 下次可以採用其他解決問題的方法
● 如何確保這次故障不會再發生
25

26. 將重複的工作自動化
● SRE 是軟體工程師
● 錯誤的自動化配置：
○ 造成股票交易錯誤：美國股票交易所 2010 歷經一次閃電崩潰 (Flash Crash)， 30 分鐘內所失千
億美金
● 好的自動化：提高效率、產能
26

27. 結構化和理性的決策
團隊透過以下方式保障決策過程：
● 決策基本方向是事前決定的，不是事後產出的
● 決策考慮的信息是清楚的
● 任何假設都應該事先說明
● 數據驅動決策
27

28. 結論
● 核動力、民航、醫療，事故都是會有生命損失，保守是必然的
● SRE 核心思想在很多行業都可以獲得驗證
28

29. 29

30. Google VP: Benjamin Lutch (SRE)
Chapter 34
Conclusion
30

31. ● Google 的系統，十年來有了大幅度成長
● SRE 的根本職責 (CH1) 十年來沒有改變，關注的重點沒有改變
31

32. Recap 灌水 CH1
32

33. 33
SRE 核心指導思想
● 災難備案與演習
● 事後總結
● 自動化
● 結構化、理智的決策

34. Google 的解決之道：SRE
SRE is what happens when you ask a software engineer to design an operations team.
(翻譯：自己開發、自己維運 )
● SRE 有兩種工程師：
1. 團隊中 50% ~ 60% 是標準的軟體工程師。就是通過 Google 面試的人
2. 40% ~ 60% 滿足基本的軟件工程師 (85% ~ 99%)，但同時具有一定程度的其他技能的工程師，
主要是 UNIX 內部系統和網路 (Layer 1 - 3) 的知識
● SRE 成員的特點：
○ 對於重複、手工性的操作有天然的排斥感
○ 有足夠的技術能力快速開發軟件系統，取代手工
● SRE 團隊 50% 的精力放在開發工作上
● 將常見的維運工作，交給 產品研發部門操作，或者從 產品研發部門抽調人力參與團隊輪 值工作。
○ 只有管理階層主動維護 SRE 團隊的工作平衡，SRE 才能有精力做開發工作
● 整個產品研發部門，都有機會參與大規模維運部署活動
34

35. SRE 方法論
承擔以下職責：可用性改進、延遲優化、性能優化、效率優化、變更管理、監控、緊急事
故處理、容量規劃與管理
In general, an SRE team is responsible for the availability, latency, performance, e
ciency, change management, monitoring, emergency response, and capacity
planning of their service(s)
此方法論也規範了如何與產品研發部門、測試部門、終端用戶進行有效溝通。
35

36. SRE 方法論
● 確保長期關注研發工作 (Ensuring a Durable Focus on Engineering)
● 在保障服務 SLO 的前提下，最大化迭代速度 (Pursuing Maximum Change
Velocity Without Violating a Service’s SLO)
● 監控系統 (Monitoring)
● 緊急事件處理 (Emergency Response)
● 變更管理 (Change Management)
● 需求預測與容量規劃 (Demand Forecasting and Capacity Planning)
● 資源部署 (Provisioning)
● 效率與性能 (Efficiency and Performance)
36

37. 37

38. 以下是 幹話 時間
38

39. 一百年前的飛機
● 單引擎
● 只能載一些貨物
● 一個飛行員，同時擔任機械師
● 從一個城市，飛到另一個城市
39

40. 安全性
容量
40
速度
可靠性

41. 現在的飛機
● A320 / 波音 747 飛機
● 數百名旅客，一堆隨行行李
● 兩個飛行員，同時擔任機械師
● 從一個洲，飛到另一個洲
41

42. 安全性
容量
42
速度
可靠性

43. 一百年的差異是什麼？
43

44. 44
飛機的能力提升了 → 技術提升了 → 乘載容量變高了
人員素質變高了 → 因為飛機變複雜了 → 乘載容量變高了
機組人員沒有變多

45. 開飛機最難的是什麼？
平貼水面五公分公尺飛行 2000 公里。
45

46. 維持系統最難的是什麼？
不管外在流量如何改變，商業需求如何異動，系統都能穩定的運行
46

47. 能動就好?
47

48. MVP?
48
這要考慮企業文化、組織、 產品面向、系統架構 ...
只看這三個字硬上，一點意義都沒有

49. 不要想用二十世紀的技術
來解決二十一世紀的問題
49

50. 50

51. ● Site
○ *.google.com
○ gmail, driver, calendar, cloud ...
● Reliability:
○ 某個系統在指定的環境下，在指定的時間 內，成功持續執行某個功能的機率。
● Engineering:
○ 工程方法、軟體工程、流程
Site Reliability Engineering
51

52. Site Reliability Engineer
● 是一種角色 (Role)、職務，像是 Manager, Developer, Tester/QA, SysOps,
DevOps Engineer
52

53. ● 重點在可靠性 (Reliability)
● 基本概念：任何系統如果沒有人能夠穩定的使用，就沒有存
在的意義。
Site Reliability Engineering
53

54. 站在巨人的肩膀 - 基本功
● 演算法, 資料結構, 計算機組織, 科幻概論
● Design Pattern, Thinking in Java
● Building Microservices
● Continuous Delivery, CC2E
● How Google Tests Software
● AWS Whitepapers
○ AWS Well-Architected Framework
○ Architecting for the Cloud: AWS Best Practices
○ ...
54

55. 55
感謝參與 SRE 讀書會
Since 2017/07/05 - 2018/03/07 (漫漫長路)

56. FB 社群 DevOps Taiwan 與 SRE Taiwan 同步舉辦讀
書會中，有興趣的同學歡迎找我報名。
● https://www.facebook.com/groups/sre.taiwan/
工商服務
56