DevOps
協調正式環境事故應變
協調處理事故:安全恢復服務、讓關係人知情,並留下有證據的後續紀錄。
流程
照這個順序做。
- 確認影響、依適當嚴重程度宣告事件、開啟事件頻道與紀錄,並指定事件指揮官。
- 指派營運、溝通與紀錄角色;陳述目前使用者影響、已知事實與下次更新時間。
- 用最低風險緩解穩定系統,例如回復、流量轉移、停用功能或增加容量,並盡量保全證據。
- 追蹤假設、行動、負責人、時間戳與結果;用面向使用者的訊號驗證恢復,而不只看單一內部指標。
- 溝通解決,並在約定觀察時窗監控復發後,才結束主動應變。
- 建立不究責時間線、找出促成條件、指定有邊界的後續行動與負責人,並安排檢討。
先準備
貓會向你要的輸入。
- 警示或影響通報
- 服務作業手冊與可觀察性存取
- 升級與溝通窗口
- 授權緩解邊界
路由器 + 一份 playbook
先路由。只選一份。
Cat Paw 每次任務只載入一份 playbook,不合併多份。先走這個路由器;其餘路徑是此 workflow 可檢查的候選。
- 路由器:
engineering-pack skills/engineering/addyosmani/observability-and-instrumentation/SKILL.mdskills/engineering/mattpocock/triage/SKILL.md
界線
界線跟著提示一起走。
- 在影響持續時,優先恢復安全服務,而不是先證明根本原因。
- 破壞性或不可逆緩解需明確授權。
- 對客戶溝通保持事實;區分已確認事實與假設,並避免歸咎。
完成代表
一個可核對的終點。
面向使用者的服務在約定時窗內已驗證穩定,利害關係人已收到結案,事件時間線完整,後續行動有負責人與到期日。
來源
這個流程從哪來。
- sre.google/resources/practices-and-processes/incident-management-guide/
- sre.google/sre-book/managing-incidents/
- sre.google/workbook/postmortem-culture/
來源確立 workflow 的模式。若有 Reddit 或社群貼文,視為實務軼事,不是普遍事實。