# 5/24 SRE 讀書會共筆
---

場地提供：PIXNET
- 誠徵 [SRE 服務可靠度工程師](https://gist.github.com/jnlin/8329bea1c1ed92a1924da7e032304261)，有興趣的朋友可聯繫 [e-mail]

# SRE 參與模型的演進過程 by 小明

## 維運前與維運後
* SRE 是開發前進入專案，還是開發後才進入專案？
* 維運的優先順序？
* 越早越好 （多早？）
* Google 設計了一個 Model 來處理這個問題

## PRR model
* 製造業的 PRR (看不懂...)
* 軟體業的 PRR
* 越晚參加，維運的成本越高

## SRE 參加專案的時候要作什麼？
* 了解系統架構與服務相依性
* 監控方式：指標定義與量測方法
* 如何救火！！ (RD要進來)
* Capacity planning
* 開發時期與流量進來的時候，會不會有問題
* 變更管理
* 效能調校
### SRE什麼都要會，什麼都要管
* RD人數 >> SRE人數
* 排除高可靠度與非高可用性的服務
* 文件
* 諮詢工作
* 小服務：上線前建議
* 大服務或大怪物：長期支援

### 問題：在大家的公司，SRE 與 RD 如何對話？

## PRR for SRE
* 條件
* 該服務值得 SRE 支援
* SRE 團隊和研發團隊同意人力調動
* PRR 目標
* 確認符合正式環境的佈署和維運方式
* 確認 PO 需要與 SRE 共事
* SRE 提供經驗與建議
* 提升服務可靠度
* 最小化可預期的問題與影響程度
* PRR 模型
* Simple PRR Model
* Early Engagement Model

## Simple PRR Model
* 初期參與
* 由管理階層決定 1~3 位 SRE 參與
* 建立 SLO/SLA
* 可能需要執行破壞性設計變更計畫
* 制定交接計畫與培訓計畫
* 分析
* 很重要且為主要項目
* SRE 需要了解該服務，並提供缺陷分析
* 確保遵循正式環境的實踐規範並製作檢核表
* 培訓
* Design overview
* 深入探討系統中各項處理流程
* 了解正式系統佈署設定
* 練習各式維運狀況
* 改進/重購
* 依照影響而制定優先順序
* 與研發團隊討論，協商，取得共識
* 重購與功能改善
* 接手維運
* SRE 逐漸取得服務維運權限
* 研發團隊當 SRE 團隊之後備支援及提供建議
* 持續改進
* SRE配合新功能、新需求、技術升級等維持服務可靠度
* 緊急事件處理、事後檢討（學習成長紀錄）、根源問題分析
* 回饋研發團隊、紀錄文件

### 限制與成本
* 適合已進入發行階段之服務
* 團隊之間額外的溝通成本
* SRE 須在原本任務下，另外參與PRR流程
* SRE 成為研發團隊之一份子，而非外部參與單位
* SRE 因於後期加入，維護成本比較高 -> Early Engagement Model

## Early Engagement Model
* 初期確定服務重要性與商業價值
* 該服務的功能，將成為原系統的一部分
* 進行原系統重寫或替代品
* 研發團隊曾尋求 SRE 建議，或後期給 SRE 接管

### 服務生命週期各階段
* 設計階段：預防勝於治療
* 開發及建置：SRE 提早取得為運經驗
* 上線：導入部分流量到新服務
* 上線之後：SRE 早期參與經驗可幫助重購或重新設計
* 從服務脫離：服務足夠可靠、穩定或服務未能達到預估需要 SRE 長期參與之服務水平

### Lessons Learn / External Factors

* Lessons Learn
* Project vs PRR vs SRE，SRE 人數永遠不夠，優先順序很重要
* Code 沒有被重複使用
* 重複出現類似的問題，無法自動化或正式修復
* SRE 的貢獻再不同專案的方式不盡相同
* External Factors
* 服務、專案變多，SRE 需要更多人手
* 不易尋找到合適的 SRE
* 培訓 SRE 所需時間比一般 RD 更長

### 解決方案

* Codified best pratices
* Reusable solutions
* A common production platform with acommon control surface
* 統一介面、監控、Log及服務設定
* Easier automation and smarter systems

### 框架優點
* 降低維運開銷
* 使用框架、通用平台如同 SRE 直接支援
* 更快、更低的參與成本
* 一種分擔責任的新模型
* SRE 專注於底層架構
* 研發團隊負責服務功能問題

Q: SRE 人力有限，如何支援這麼多不同的團隊
PIXNET 經驗分享：
* 我們的 SRE 支援會有比例限制，不可能讓 SRE 全部的工時都拿去支援其他團隊，而忽略的本職工作。
* 支援其他團隊會由固定人員擔任窗口，然後回來會與其他 SRE 共享資訊。

John 經驗分享：
* 還是要早期預防勝於治療
* SRE 的人才還是難找，因為需要不只一個領域的知識與經驗
* 聽過有公司的 SRE 會分四個面向 infra、release、monitoring、on-call
* SRE 也許可以成為 RD 與其他工程領域之間的潤滑劑（中間人）
*

瑞男：
* 相對於 RD，SRE 確實比較難找到合適的人才。
* 又要願意 on-call、又要懂廣泛領域。
* 做產品的公司，SRE 是重要的基石。
* 好的 RD 不會被工具綁住，非使用某種技術不可，而是解決問題導向，因此 SRE 越早參與架構是有意義的，因為可以早點取得共識。

正瑋：
* 在 Effective DevOps 書中也有提到，跨團隊溝通時，單一窗口是很重要的，減少溝通成本。

Rick:
* 工作推進一定是不同團隊皆同時並進的，對其一致的目標，思考在每個時間點各自可以做些什麼事情，不會說 RD 在開階段時，其他團隊沒事幹都在爽。

# Ch 33 其他產業的實務經驗 by Rick

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

### Google 其他背景的 SRE
* 很多種不同背景，核電、航空、醫療⋯⋯

### 警急事件反應代表以下
* 紮實的基本功 - 原理
* 平常的訓練 - 紮實度
* 訓練很重要，舉例：滑雪教練，滑雪並不是一個安全的環境，因此要先讓學員有安心感，營造一個安全的環境。
* 日本人從小就有防震演練，其中當然也有文化因素，因此全民都具備此種意識。
* 你有危機意識嗎？
* 你的電腦有在備份嗎？
* 你有保險嗎？
* 事件當下的反應
* 過往的經驗
* 態度

重點：預防勝於治療
* 你有危機意識嗎？你有在「預防」嗎？
* 樂團就是一種 Live，一個人出包，音樂就毀了（類比 SRE、Ops 工作）
* 如果在演奏中間吉他斷弦了，音樂是中斷？還是有辦法繼續演奏讓表演繼續下去？
* 臨危不亂、組員彼此信任⋯⋯

災難的預備與演練
* 不能把願望當成一種策略
* SRE 文化
* 如何模擬正式環境進行演練

決策的過程要理性化、標準化
* 決策基本方向是事前決定的
* 決策考慮的信息是清楚的
* 任何假設都應該事先說明
* 數據驅動決策
(補充：你能多理性取決你擁有多少知識與經驗)

結論：
* SRE 的思想在很多行業都可以獲得驗證

# Ch 34 總結 by Rick

軟體是有機的，是會成長，也會產生垃圾。