# Google SRE 分享：17LIVE 的 SRE 太極拳

###### tags: `SRE2022`

---
Charlie

2019 打造 SRE team

google sre = software programer
dev:sre 比例 10:1
心法

SRE 心法
google why 做 SRE: dev / ops 常常會是衝突，google 也有類似的問題
思考: 能不能有一個 OKR 讓大家 follow
心法1: reliability defined by user
reliability 跟 quality 是兩個不同 team 要負責的方向
心法2: 沒有 100% 的穩定，也很困難成本極高(SLI/SLO/Error budget) CUJ(要測量的是 user 的快樂而飛CPU / Memory)

設計原則：要求 SWE
- Design for Redundancy (高可用設計)
- Enable horizontal scalability (橫向擴展) ，DB 怎麼做橫向擴展：spanner and shading (工商)
- Tolerate overload: 要求 AP 要能降載服務 (例如只 load 出第一頁結果，不能影響其他橫向 AP)
- support rollback 快速
- traffic spikes

17~~~~怎麼實踐 SRE part

google 做法就是參考
中華對外連線跟 google LB壞掉，monitor 看不出來，但 user 在抱怨
SRE 比例 1:20 （Yoga 好幸福是 google 的比例誒~）

榜單是 17 最重要的 CUJ (從 user 角度)，可靠性是來自用戶定義不是 SRE 定義的
建立以 CUJ 為主的加權警示去做 SLO 定義，要跟 stackholder（PM或行銷） 一起定義，要找到自己的 CUJ

capacity planning
預估上限並提前採取措施(壓測模擬當下可能會發生的事情)
需要考慮第三方服務的乘載量
自動降載避免服務崩潰
- (rate limit by ip)
- 關掉不重要的服務
- 限制用戶數全站上限 (ex: 100w)

打雜
- 開關機器
- 開權限
- 盤點雜事半自動化
- rubenv/sql-migrate

緊急阻礙處理流程
1.首要讓 SWE 能專心查找問題
2.讓 Stackholder 能快暸解狀況

user 是最重要的

---
**Brian**

overview
1. google sre 心法
2. 面像google sre的服務設計
3. 17live的sre實踐
4. take away

## google sre 心法
[googe sre](sre.google)

客戶的快樂指數 dev+ops要買單

Principle
1. reliability
- reliability defined by user
- 客戶：很慢. dev: cpu,ram都沒問題 （x）
- quality 交集 reliability => user unhappy bugs
- 圖
- 越早發現服務down，客戶越開心
2. 100% is the wrong reliability target for basically evething
- sli: a well-defined measure of success
- slo: a top-line target for fraction of success interaction
- sla: business consequences
- error budget: porpotion of "affordable" unreliability: one minus the slo
- cuj: specific steps that a user takes to accomplish a goal

## 面像google sre的服務設計
SRE會要求5大要素
- design for redundancy
- enable horizontal scalability
- cloud spanner and sharding
- spanner can dynamicly sharding
- tolerate overload
- 可以跑，人變多可以變慢，但不能crash
- ap 必須能夠降載服務
- support rapid rollback
- prevent traffic spikes
- jitter
## 17live sre

### overview
- reliability is defined by user
- google lb crash
- 中華電信對外連線有問題
- sre:swe
- google: 1:10
- 17live: 1:20
- 先建立sli跟測量slo
- error budget不要太早被老闆發現
- sre swe 要聽懂人話

reliabiliyt definne by user

- 以cuj為主的加權警示

- cuj下的關鍵監控：observability dashboard

- capacity planning
- 與pm行銷人員確認預估人數
- preproduction 以1:1測試＋locust
- 以測試結果推測資源增加的趨勢
- 自動降載機制：避免服務崩潰
- 減少重複工作（toil reduction）：
- 活動資源優化流程 (slack bot, scheduler)
- 快速簽核
- 定期盤點toil => 半自動化(一鍵啟動) => 自動化（scheduler）=> AI
- 打造incremental change: 資料庫Schema更新的竅門
- migration cicd上
- percona => pt tool
- p0處理自動化\手動流程
- 緊急障礙處理流程
- 首要工作：
- sre swe處理，解釋給麻瓜
- postmoderm

---

**Gimmy**

> 何宗憲 Shawn Ho Customer Engineer, Google
> 林毅民 Sammy Lin Engineering Director, 17LIVE

AP 要有五個特性才適合被維運

- Design for redundancy
- Horizontal Scalability 是 reliability 中是很重要的功能
- Tolerate Overload AP 要可以降載
- Rapid Rollback 要可以快速 rollback
- Traffic Spike

### 一：Reliability is defined by user

- Quality vs Reliability 不是相同的方向
- ex: 500 error 屬於 reliability domain
- 越早發現服務掛了越好，而不是等 User 回報才發現

### 二：100% is the wrong reliability

- SLI, SLO, SLA, Error Budget, CUJ

### 17LIVE 實戰

- 遇過外部 Google LB 壞掉，比較難以檢測
- SRE : SWE = 1 : 20
- CUJ: 找出使用者認為最重要的功能，而不是 SRE 覺得最重要的東西
- Capacity Planning：溝通流量預估 + 壓力測試，以測試結果去評估資源增加的根據
- 自動降載：Rate Limit，關閉次要功能，限制用戶數
- 減少重複工作(Toil Reduction)：自動化

---
## Chris

只重其意，不重其著

### Google SRE心法

dev 重開發速度 / op 重服務穩定

引進新OKR：顧客滿意指數

#### Reliability is Defined by the User

Quality vs Reliability

越早發現，顧客滿意指數掉越少

#### 100% Reliability 是錯誤的，成本也太高
- SLI: Service-level Indicator
- SLO: Service-level Objective
- SLA: Service-level Agreement
- Error Budget
- CUJ: critical user journey

### 面向Google SRE的服務設計

#### Reliability 設計五大要素
- Design for Redundancy
- Enable Horizontal Scalability
- Cloud Spanner and sharding
- Tolerate Overload
- 可以降載，不能Crash
- Support Rapid Rollback
- Prevent Traffic Spikes
- Jitter

### 17LIVE的SRE實踐
- 實戰
先建立SLI和量測SLO
Error Budget不要太早對老闆揭露

- 以CUJ為主的加權警示
- CUJ的關鍵監控：Observability Dashboard
- Capacity Planning 預估上限並提前採取措施
- 先預估人數
- PreProduction 1:1 壓測
- 以測試結果推測資源增加趨勢
- 自動降載機制：避免服務崩潰
- Rate Limit: 對不同功能API進行合理的限制
- 關閉次要功能: 在不同場景只開重要功能
- 限制用戶數
- 關閉非關鍵服務，擴充關鍵服務
- Workaround
- 減少重複工作(Toil Reduction)：活動資源優化流程、快速簽核
定期盤點 -> 半自動化(一鍵) -> 全自動化
- 打造Incremental Change：資料庫Schema更新的竅門
- 處理自動化/手動流程
- 緊急障礙處理流程(Coordinated Emergency Response)

### Take Away
客戶體驗為尊
100%不可能
Dev+Op共同的目標
準備好Undo、Rollback的按鈕
不要累死SRE: 分配好troubleshooting