---
# System prepended metadata

title: Google SRE 分享：17LIVE 的 SRE 太極拳
tags: [SRE2022]

---

# 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
