owned this note   changed 7 years ago  
Linked with GitHub

12/28 SRE 讀書會共筆
場地提供：PIXNET

===

第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
  • 分類工具：從內圈分析到外圈，問題分析

測試

測試猜的原因是不是對的

  • 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 代打)

東西早晚要壞的，這就是生活 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

  • 何種狀況需要撰寫

    • 對使用者造成一定影響 (downtime)
    • Data loss
    • 需要 on call 人工介入
    • 解決問題超過一定時間
    • 監控系統沒能夠發揮作用的問題
    • 受影響的部門的要求

  • 如何撰寫？

    • 協作撰寫 (google doc)
    • 有固定的範本
    • 即時協作
    • 邀請多人一起協助提供經驗
    • 接受公開評論，歡迎更多人提供經驗與解決方案
    • 需要經過資深者 review
      • 重要的數據/資料是否收集齊全
      • 造成的影響評估是否完整
      • 問題分析是否夠深入
      • 因應動作是否合宜，是否按照合適的優先順序處理
      • 是否有確實將資訊分享給別人

  • 如何建立不咎責的文化？

    • 由上而下，但由工程師自主更好
    • 透過學習性活動
      • 好文共享
      • 內部社群
      • 讀書會
      • 沙盤推演
    • 逐步導入，持續改善
      • 先有成功案例
      • 建立對應的獎勵制度
      • 高層參與，發揮影響力
      • 問卷、意見反饋

  • 可能是倒楣的人出事，但可能是硬體或其他問題

    • 需要解決 root cause
    • 如果無法解決 root cause，那就需要有方法快速處理
Select a repo