SRE Conf 2022 #1：Google的SRE與17LIVE的實踐篇
分享緣起
今年的第一次線下+這輩子第一次的快篩，就貢獻給了iThome第一次舉辦的SRE大會。會前看到來的講者都是各雲原生公司(e.g. 91App, Line, Maicoin)與大型企業(e.g. Micron and Cathay)的SRE一流之選，也打定主意應該要結合實務與Google SRE的看法原則場次，通過iThome的推波助瀾，讓SRE的種子能在台灣發芽。當時心裡的不二人選就是打造17LIVE的SRE Leader, Sammy，主要原因有三個：
- 之前在IT媒體上就常看17LIVE（前身是17Media)跟大家分享的相關實踐[1][2][3]，
- 再加上17LIVE催生了台灣直播的業務大餅，直播的穩定度，就特別的仰賴SRE來”SAVE THE DAY”，
- 更重要的是，其實Google的SRE 實踐，由於內部系統均是以容器調度(Borg)為主，通過Kubernetes去打造的系統，更容易的落實SRE Workbook上許多的想法。 17LIVE的主系統基本上是全K8S的～完全就是SRE的天菜啊！
跟Sammy聊了一下想法，我們很有效率的就決定了我們的主軸：
『只重其意，不重其招』
Google SRE一直是一個以流程自動化(Reduce Toil)，與認知100%不是一個好的指標的中心思想，所衍生出的一系列最佳實踐，以SLO為指標，來優化Dev & Op之間的合作。Google對外分享的部分，是最適合Google的內部實踐，但不一定是最適合聽眾企業的實踐。Google內部實踐的部分，SRE Workbook的Part II其實都有了，對聽眾更重要的是如何能夠轉化為台灣企業內部的實踐，如Chap3 中美國企業的實踐，因此就有了我們這次的分享。
分享內容
最近我們SRE團隊把『Building Secure & Reliable System』這本書的設計原則，整理成了15項的Reliability Principles, 稱為Reliability Principles，其中Chap6-Chap10的設計原則，濃縮為Principles裡3–7的五個要點，而Chap16–18的維運要點，開展為8–15的八個要點。這種濃縮式的精華摘要，應該蠻適合在短時間的會議裡分享～再加上Sammy之前在iThome發表的SRE實踐，都不但落實了我們8–15，更有很多不錯的獨到之處。就決定以這15個要點為主軸來開展。
SRE中心觀念(1 & 2)：
第一個原則通過SRE的中心任務：維護系統的可靠度，來說明了什麼是好的可靠度：
- Feature & Reliability 不一定是相同的，
- 越靠近使用者使用行為的量測值，才是可信的可靠度
第二個原則：這個可靠度應該足夠維持使用者快樂即可，也就是維護足夠的Error Budget。也藉此推導出SRE最重要的一個公式：
E (Error Budget Burned Rate) ∝ (TTD + TTM) *Impact / TBF
(TTD: Time to Detection, TTM: Time to Mitigate, TBF: Time between Failure)
有趣的是，我在Survey過程，發現Google竟然開源了slo-generator這個專案，裡面有許多後端監控系統的整合(e.g. Prometheus & CloudMonitoring)，可以幫忙SRE帶出SLO～
系統設計的五大原則 (3~7):
一個系統若要讓SRE可以維運，必須具備五個重要的系統特性，包含：
- Design for Redundancy: 這個原則，當天只說到了需要有N+2的設計，並以將服務部署在GKE的Regional Cluster來達成服務跨Zone高可用，或是更高等級的通過MultiCluster Ingress部署跨Region的GKE叢集，通過規劃更大的Fault Domain，有效的隔離區域性的同時失效。
[延伸閱讀 Chap8 Design for Resilience] 說明了延伸Redundancy到資安防禦上，每個Redundancy必須掌握zero trust原則。
- Design for Horizontal Scalability: 這個原則，當天闡述的是服務必須要能橫向擴展，這個能力可以幫助灰度發布，也可以支援臨時性的需求擴充。我們也用Google的Spanner作為例子，分享了Spanner如何通過獨立出Data Sharding這一層機制，來達成資料庫的動態橫向擴充。
[延伸閱讀Chap7 Design for a Changing Landscape] 四個在架構上的設計，讓服務延展更彈性。
- Tolerate Overload: 這個原則，主要說明系統設計時，設計時要特別注意要讓系統能夠具備降載的能力，不然會造成連鎖性的崩潰，崩壞上方的高可用性設計。
[延伸閱讀 Chap6: Design for Understandability] 裡面System Invariants，就說到了系統必須要能獨立承受因環境變化所造成的影響，不能牽累其他系統，包含過大負載、外部攻擊等，這裡也提到了資料庫的分割，才有機會讓。
- Support Rapid Rollback: 這個原則，當天講述的是服務要提供足夠的Rollback能力，才能讓大家安心上版，
資料庫Rollout的部分，可以考慮跟App Binary分開Rollout，通過以下的策略：
(1) Release binary v+1 (v+1版本沒有新功能，但可相容於新的db schema)
(2) Upgrade database schema
(3) Release binary v+2 (v+2版本包含新功能）
Sammy也在後方的說明裡，分享了17LIVE怎麼設計資料庫的上版跟退版。包含兩個很棒的開源專案： rubenv/sql-migrate，跟pt-online-schema-change by Percona.
[延伸閱讀 Chap9 Design for Recovery]
- Prevent Traffic Spokes：這個原則是要在Client的呼叫邏輯中，加上Exponential retries + Jitter的機制，避免類似DDoS的海嘯呼叫，造成整體系統的連鎖失效。如果Client/Server都是同一個企業開發，也可以加入特殊的protocol，作為Traffic control使用。
[延伸閱讀 Chap10 Mitigating Denial-of-service Attack] 我們所說的主要涵蓋在該章節的Dealing with Self-inflicted Attacks，同章節裡也提供了其他Defend Denial-of-Service的手法給大家參考。
SRE Conf 2022我的分享主要涵蓋上面的七大部分～想想自己(和聽眾）也蠻厲害的，用24分鐘要表達(聽懂）上面的資訊～ 後面Sammy的17LIVE實戰篇其實更加精彩，當天沒來的捧油，可以看之前Sammy跟iThome訪談的報告～來想像一下 :)
我們的Deck分享在此。
[作者特別感謝: 17 LIVE的Sammy Lin & Brent Chang的Brain Storming 與準備上的建議]
