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

===

# 第12章：Effective Troubleshooting by Eric Chen

* 開宗明義，只能意會，不能言傳。如果自己的組織 troubleshooting 已經很有效率了，就不用參考。
* 從錯誤中學習，累積大量經驗。
* 遇到問題時，當下的壓力會非常高，需要能保持冷靜。

問題回報->分類->資訊收集->診斷->測試->復原

## 問題回報

預期行為 vs 真正的問題

* how to reproduce

## 分類
判斷事件的嚴重性有多高。(好比急救的檢傷分類)

趨勢分類：
P0 4hr (on call 即時處理)
P1 8hr (可等到上班時段處裡)
P2 36hr

用問題多快需要被解決，來跟業務、PM溝通嚴重性

* 發生問題時，先止血讓服務可以恢復，再去找根本原因

## 趨勢經驗 workaround
* rollback
* reboot/restart 重開治百病
* deploy new node
* scale up/out the instance ((一方面可以保留意外現場))
* failover database
* shutdown the service (假如狀況真的嚴重，避免 DB 繼續被弄亂，不如先把服務關掉)

## 收集資訊
* graphing time-series metrics
* logging
* structured binary format
* searchable
* Exposing current state

## 診斷
* simplify and reduce
* Divide and conquering
* Ask "what", "where", and "why"
* What touch it last
* 通常都是前10分鐘的改變造成的問題
* 半夜的話，通常都是 infrastructure 造成的，例如網路壞掉、硬碟壞掉
* Diagnose tool
* 如果有常發生的問題，可以做成工具來檢查
* [Linux Performance Tools](http://www.brendangregg.com/linuxperf.html)
* 分類工具：從內圈分析到外圈，問題分析

## 測試
測試猜的原因是不是對的
* Mutually exclusive
* 測試一個測試項目之後，就能夠馬上排除某一個因素，可以很快縮減可能因素
* consider the obvious first
* 相信直覺，不要懷疑太過罕見的因素
* experiment may providing misleading results
* 測試手法可能會帶來額外的錯誤，Ex. 測試 k8s 問題時，在本機起 container 測試，但是本機無法和 db 連線，以為是 db 問題，但其實不是。
* active test may have side effect
* 測試需要把 Log 打開，但可能會造成系統不穩定
* take clear notes before performing actice testing
* 詳細的紀錄測試的結果，讓接手的人可以很快了解
* 對作 case study 也會有很大的幫助

## 治療
* Prove the root cause may be hard
* 有時候系統太複雜，不容易重製出這個問題
* 可能只會在 Production 上才會發生，但是不能到 Production 上故意再玩一次
* Postmortem is important
* Problem Report
* Business Impact
* Workaround Fix
* Root cause
* Technical detail
* Action Items

問題總是無法避免發生，讓 recovery 回復速度快比較重要。
Ex. 薩利機長，在 3 分鐘內做出正確的判斷，跳過許多正常步驟。

Rick: Design 系統不是專家，但是 Trouble shooting 之後才是專家。雷踩的多就是大神了
從 Business 的角度來判斷重要程度，例如影響很多 user/$$ 的就是最嚴重的問題

# 第十三章 - 緊急事件響應 by Rick Lin (請假，臨時由 Rick Hwang 代打)

* Slide: [SRE CH13 - Emergency Response](https://www.slideshare.net/rickhwang/sre-ch13-emergency-response)

東西早晚要壞的，這就是生活 Things break; that’s life.
不要以為放在雲端就不會壞！

* 大部分不是處理真實的物理危險
* 問題發生時，大部分都不是自己一個人面對
* 團隊處理
* 如果大規模災難發生，應該已經有 Plan 處理 (Chap 14)

## 緊急事故
* 測試導致的緊急事故
* 變更部署導致的緊急事故
* 流程導致的緊急事故

## 測試導致的緊急事故
* SRE 故意破壞系統，模擬事故
* 針對失敗模式，進行預防。
* 案例：在大型分散式 mysql 中，限制一個測試資料庫的存取
* 響應
* 幾分鐘後，大批回到內外無法存取某個關鍵服務
* SRE 立刻終止測試，但服務仍然沒回來
* 後續找到以前的方法，讓服務回來
* 事後總結
* 好的
* 事故在公司內部進行溝通，有足夠訊息確認是可控的，測試導致的，立即停止測試。
* 一小時就恢復
* 受影響的團隊，重新配置服務，將測試資料庫移除
* 制定週期性測試，保證類似問題不在發生
* 不好的
* 事前有充分審核與準備，但證明對系統仍然不夠了解
* 沒有正確遵守緊急處理流程，流程才剛剛建立
* 緊急流程：發生問題要找「誰」
* 當事情發生的時候，可能還是找到「人」

* Rick 補充：SOP 導入的問題
* 只有定義的人最清楚
* 其他人如何清楚 SOP
* 參與 SOP 定義
* 從演練中熟悉
* 從異常中學習 SOP
* 一定要通報

## 變更佈署帶來的緊急事故
* google 系統的配置很複雜
* 每次都需要大量針對配置做測試
* 經驗分享：
* deploy 時，忘記還在上一個專案的 config，導致把上一個專案都砍掉
* config 配置錯誤，導致壓測時使用到 production 的服務，導致延遲大幅上升

* 變更佈署帶來的緊急事故-案例

* Panic Room
* 所有人發現問題，可以到那邊拿 Log
* 禮拜五不要佈署！！！

* GCP 的案例
* deploy config 導致服務爛掉
* 後來 rollback 解決，花了一個小時

* 連鎖反應
* 如何知道 Service 的相依性？
* 如何知道 Bug 的相依性？

一旦發生連鎖反應，就很難處理，相依性彼此串連導致問題複雜化。

Service 不要連太緊 (Loose Coupling)，避免連鎖反應

## 流程導致的嚴重事故
* 將全球的系統 disk erase
* 做得好的
* 快速將流量從小型資料中心移到大型
* 網路壅塞問題迅速被解決
* 從中學習
* 自動化系統發出的指令，缺乏合理性的檢查
* 第二次指令取得空白回應，自動化系統沒有拋棄
* 經驗分享：特殊字元導致問題產生

## 所有問題都有解決方案
* 找不到方法，就在更大的範圍內尋求協助
* 最高優先全是要解決問題的困境
* 觸發問題的人，對事故了解最清楚

## 跟過去學習，而不是重複他
* 為事故保留紀錄
* 提出那些大的，甚至不可能的問題
* 如果有人入侵系統了，該怎麼辦
* 網路設備跑水了該怎麼辦
* 大樓停電了該怎麼辦
* 鼓勵主動測試
* 系統故障的時候，才會真正了解他
* 不要假設故障的時候，最聰明的同事會在你身邊

附錄：異常報告撰寫

# 第十四章 - 緊急事故管理 by Rick Hwang

## 無流程管理的緊急事故
* 太關注於技術
* 溝通不流暢：訊息不流暢傳遞
* 不請自來

再次重申，先止血（讓服務恢復），再來找根本問題

## 緊急事故的流程管理要素

* 職權分離
* 總控：掌握訊息摘要，組建團隊，按照優先級分配任務
* 處理團隊：與總控溝通
* 發言人：對關心事故的人發送週期性訊息
* Planner：支援團隊，如紀錄報告、定餐點、安排交接，紀錄事故

* 控制中心，戰情室
* 事故狀態文件，事故總控負責維護，紀錄事件的歷程、狀況
* google 使用 google doc
* 明確公開的職責交接
* 工作超時之後，公開交接任務
* 透過電話、視訊會議說明事故狀況
* 負責人聲明：現在由AAA交接給BBB

經驗分享：確實要有一個明確地交班流程！

## 何時對外宣布事故

* 先宣布異常，同時找到簡單的解決方法，再宣告事故結束
* 比在事故結束後幾個小時宣布好
* 以下狀況，事故要被即時宣布
* 是否需要找第二個團隊協助
* 事故是否影響最終用戶
* 集中分析一小時後，問題依然無解
* 事故流程不常使用，會萎縮的很快，該如何讓大家熟悉？
* 跨區域團隊常規維運變更
* 使用變更管理，實踐流程
* 災難演習

經驗分享：
* 不要以為雲端不會壞！
* 當問題發生處理時間過長，需要交班時，交班、交接記錄一定要詳盡。
* 需要演練！因為弔詭的是有時候就是有人 on-call 時就是沒事，這樣他就沒機會熟悉事故處理流程。
* 7/24 輪班，最基本不讓同一個人連續值夜班。
* 異常會有 Guidebook，看手冊來解決問題。如果無法解決問題，就開VPN給負責人進來解決問題。
* 有發言人很重要！有一個應付外部的窗口，讓內部可以專心處理問題

# 第十五章 - 事後總結：從失敗中學習

## 哲學
* 學習
* 找出/清理根本原因
* 避免問題重現
* 紀錄當事人在當下情境的思維過程、判斷
* 學習是避免錯誤的最好辦法
* 對事不對人 / 不咎責 Blameless
* 源自於航空與醫療領域（沒弄好就會死人）
* 不是為了懲罰（獵巫）
* 為了改善系統與流程，以便後人能夠做出正確的判斷
* Double Confirm 確認，回到理性思考
* 咎責文化，只會導致人們過度保護自己，掩蓋問題，資訊無法分享流通
* 好文必讀：[Blameless PostMortems and Just Culture](https://codeascraft.com/2012/05/22/blameless-postmortems/)
* 何種狀況需要撰寫
* 對使用者造成一定影響 (downtime)
* Data loss
* 需要 on call 人工介入
* 解決問題超過一定時間
* 監控系統沒能夠發揮作用的問題
* 受影響的部門的要求
* 如何撰寫？
* 協作撰寫 (google doc)
* 有固定的範本
* 即時協作
* 邀請多人一起協助提供經驗
* 接受公開評論，歡迎更多人提供經驗與解決方案
* 需要經過資深者 review
* 重要的數據/資料是否收集齊全
* 造成的影響評估是否完整
* 問題分析是否夠深入
* 因應動作是否合宜，是否按照合適的優先順序處理
* 是否有確實將資訊分享給別人
* 如何建立不咎責的文化？
* 由上而下，但由工程師自主更好
* 透過學習性活動
* 好文共享
* 內部社群
* 讀書會
* 沙盤推演
* 逐步導入，持續改善
* 先有成功案例
* 建立對應的獎勵制度
* 高層參與，發揮影響力
* 問卷、意見反饋

* 可能是倒楣的人出事，但可能是硬體或其他問題
* 需要解決 root cause
* 如果無法解決 root cause，那就需要有方法快速處理