# 4/26 SRE 讀書會共筆
---

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

# 第26章資料完整性 by Jui-Nan Lin

## 從使用者出發的資料完整性定義
- 因為 UI Bug 導致資料還在，只是不顯示

- 因為 meta data 遺失導致出現維修公告

- 「正常維持服務與資料的存取」

## 範例
- 能在使用者發現資料不見前恢復是比較好的
- 如果使用者先發現資料不見，對系統或品牌的印象會打折扣
- Google SRE 主張如何主動看見資料異常、快速修復

## 服務定位會影響資料完整性
- 五個服務最佳化的面向
- 可用率
- 使用者操作前台速度多快？
- 延遲
- 規模
- 創新速度
- 如何只有三天可以作新專案，通常會選最熟悉的技術，例如 MySQL
- 如果時間充裕，就可以根據要最佳化的面向去找到適合的新技術
- Time to market v.s. Availability
- 隱私

## 備份與封存
- 備份並沒有用，重點是恢復
- 當資料不見的時候，要有個地方可以在最短時間復原
- 設計的復原系統
- 當發現不見的時候，多久可以復原？
- 假設無法復原，有多少資料遺失？
- 能夠遺漏的資料越少，相對的成本通常會增加

## SRE 目標
- 資料完整性＆資料可用性
- 就算每天作備份，如果無法滿足使用者需要的資料，就會被認為無用武之地

## 備份就像納稅
- 消防隊 警察局
- 長期消耗時間與資源，但沒辦法帶來立刻可看到的好處
- 沒有備份、沒有還原計畫，出問題的時候就需要很長的時間才能恢復
- 不需要強調納稅是國民義務，應該是聚焦在可以提供什麼保障，例如人身物產安全
- 設計產品的時候應定義失敗的情境，資料的可用度仍維持多少 (例如網路斷線 工程師寫錯程式或錯誤操作)

## 造成資料遺漏的事故類型
- 分為六個問題根源
- 使用者錯誤操作
- 工程師/員工錯誤操作 例如客服刪錯帳號
- 程式瑕疵 例如 race condition
- 基礎建設弱點 例如 網路
- 硬體故障
- 天災 例如颶風
- scope 範圍
- 使用者可能不小心刪掉少數或大量文章
- rate 一次不見很多或是慢慢流失
- 有可能不小心寫錯程式刪掉數萬個資料或是刪錯範圍（一週 -> 一年）

## 分級備份與時間點恢復
- 軟體瑕疵在正式環境過了數個月後才發現資料遺漏
- 時間點恢復，例如蘋果的 time machine ，但在大規模的系統成本會很高
- 分級備份，例如 shapshot ，備份到光碟 磁帶 網路硬碟等等

## 複製機制與冗餘不代表可恢復性
- 程式寫錯了，複製機制執行程式刪除的指令
- 匯出仍然要驗證匯出的資料正確性
- google 的作法會準備多種的恢復副本，例如使用者不小心刪掉的就準備某種恢復方式
- 影響可恢復性：例如很久才發現寫錯程式，就得儲存很長時間的備份，使用複製機制成本就很高。所以必須準備多種恢復策略方案

## google SRE 保障資料完整的手段
- Gmail 垃圾桶：讓使用者犯錯時可以自己恢復資料
- 第二層的保障：實作 soft-delete，避免操作者（員工）錯誤操作時仍可恢復
- 第三層：從備份挖回資料

## soft delete
- 常見的實作手法：標記刪除，只是在前台看不到，仍然在資料庫裡
- 情境
- 使用者誤刪
- 帳號被盜取
- 裝了有問題的外掛插件
- 不熟悉的開發人員處理刪除資料的工作
- 其他機制：
- 懶刪除 lazy-delete (資料的刪除是透過定時定期排程, e.g. cronjob)
- 修訂歷程 例如 Git

## 備份與相關復原方法
- 本書仍強調重要的是復原而非備份
- 關鍵問題：再一次復原中，允許損失多少資料，要花多久時間恢復資料
- Google 的備份政策是 30 ~ 90 天，使用預警系統檢查資料是否存在，有無問題，如果資料有問題，必然在九十天內發現。
- 分級備份：用合理成本滿足資料復原的需求
- 可以快速恢復的資料，十分鐘內
- 需要好幾小時恢復的資料（資料複製），可能存在別的機房機櫃
- 冷儲存：需要好幾天恢復的資料（離線儲存）

## 資料量大小造成的問題
- 700 PB 用 SATA 的效能，檢查基本資料完整性，確定這份備份可用就得花 80 年
- 要保證每個 segment 之間獨立不影響
- 避免平行作業不搶佔資源
- 限制垂直資料量，例如 700 PB 量級不應該每天都做完整備份，可能是一個月才作一次，平時都做 incremental 的備份與還原

## 早期預警
- Google 作 out-of-band 資料校驗器
- 寫程式需要自動化測試
- 資料也需要自動化的檢驗器
- RDBMS 的 FK 例子，雖然可保證另一端的資料表不會不一致，但是 scale 上升後可能變成效能瓶頸
- Gmail 的資料校驗
- 一系列的手冊，提供值班人員如何處理某個校驗失敗的警告
- 類似 BigQuery 的查詢工具
- 監控儀表板：alert / 指標
- 團隊負擔不起成本
- 後來的作法改為打造一隻專業團隊，提供框架，由產品團隊負責業務邏輯
- 資料化恢復機制
- 也要是自動的，不能是人工去找出備份資料來操作
- 持續測試恢復機制，例如故意刪掉一些檔案，每年作一次大規模演習
- checklist
- 備份資料是否完整且正確
- 是否有足夠運算資源來正確完成恢復過程
- 恢復過程時間是否合理
- 有無相依性，某些元件未必是 7x24 可用

## 案例分析 Gmail
- 2011/2/27
- 大量元件同時失效，導致資料遺失
- GTape：為 Gmail 量身打造的磁帶備份系統
- 可以計算出大部分使用者恢復的時間
- 計算需要多久才能恢復全部使用者
- 計算恢復超過 99% 的資料時間

## 案例分析 Google Music
- 2012/3/6
- 使用者回報音樂無法讀取
- SRE 檢測發現有60萬資料遺失，影響 2.1 萬使用者
- 資料量超過 1.5 PB
- 包含音檔以及 metadata
- 超過五千卷磁帶
- 系統回報分別在哪些倉庫
- 還得確定磁帶沒有發霉等等
- 同時找問題並嘗試回復資料
- 分兩組人進行，一組拿磁帶，一組找問題
- 只有 3600 卷找得到
- 資料量太大導致 race condition
- 有 16 萬筆音樂在磁帶中沒有備份
- 商店出售的音樂，有原始檔案
- 透過自動重新上傳機制解決
- 另一組人發現是資料刪除作業造成的問題
- A功能執行完才能執行B功能，但卻是兩隻程式，通常採用定時按照順序執行，但遭遇前者功能執行時間超時
- 沒有使用 lock 保護導致 race condition 誤刪資料
## 小結
- 資料可用性是重點
- 自動化方式測試恢復程序
- 關注目標是復原使用者的資料，而非備份，多層防護涵蓋最廣的失敗場景
- 持續執行與演練
- 自動資料檢測是否仍存在，在使用者發現之前完成恢復作業

---

# 第28章 - 迅速培養 SRE 加入 on-call by Winnie

## outline
- 新手報到
- 培訓初期，重視系統，而非混亂
- 培養逆向工程
- 五項實踐
- 結業儀式與實踐教育
-

## 新手報到
- 新手需要學習哪些知識？
- 如何評估新手準備好可以 on-call 了
- 如何利用新人的好奇心與熱情 使現有成員從中受益？
- 哪些活動能增進團隊知識，並受大家喜愛？

## 訓練計畫藍圖
- 實際面 vs 抽象面
- 讀文件
- 觀察旁人
- 一開始責任較輕，ownership 逐漸變大
- 強調持續學習

## 培訓初期
- 浴火重生，在錯誤中學習，第一天收到一堆工單
- 這是比較被動的方式，只關注維運
- 建議有順序的學習路徑
- 專注在有目標的任務，而非瑣碎的事情
- 完整的任務都被老人拿走，新人只能打雜
- 初階專案，在服務中加入一點新東西

## 範例 即時，直接面向使用者的服務
- 請求怎麼進系統
- 中層服務 例如快取
- 基礎設施 例如伺服器
- 全部串在一起時，如何錯誤排查
- 緊急狀況如何處理

## on-call 學習檢核
- 前端有哪些服務
- 後端呼叫哪些元件
- 遇到問題可以找哪些人
- 下一關要能回答像是服務如何被 deploy 的，到哪裡
- 如何還原系統
- 如何修復不對的 push

## 培養逆向工程師和隨機應變能力
- 強大的逆向工程能力，因為總是會遇到沒看過的系統
- 統計的思維能力，資料會越來越大量，不是使用流程化方式發現問題，要在壓力下堅持科學方法
- 標準的流程有時會失效，需要有隨機應變的能力
- 把知識串連起來，逆向工程正式服務，搞清楚端到端的原理，自行摸索，資深人員從旁協助，這可能是更好的學習模式

## 有抱負的五項實踐
- 能夠參與 on call 足夠了解可自行學習其他部分
- 對事故的可望，閱讀與分享事後檢討
- 災難角色扮演
- 破壞真實系統，修復真實系統
- 文件維護是學徒任務的一部分
- 盡早儘快見習 on-call
- 反向見習
- 不要把事後檢討的整個撰寫過程都交給新手！

## on-call 結業儀式與實踐持續教育

## 培訓實踐錯誤與建議
- 從錯誤中學習 vs 提供延續學習的方式
- 照流程執行 vs 鼓勵反向工程、統計科學思考
- 避免責難 vs 慶祝並分析問題
- 準備好了才讓他 on-call vs 在可控的真實環境讓新人可修復
- 直接當主要 on-call 人員之一 vs 先觀察資深人員的 on-call 從旁學習
- 把訓練計畫固定 聖經化 vs 新手與老手配對，激盪不同火花
- 把有貢獻的任務留給資深人員，菜鳥拿雜事 vs 循序漸進讓菜鳥建立 ownership