事件管理 - 模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 監視 | ✅ 警示結構包含嚴重性分類,會將重要事件 (無法使用生產、資料損毀、安全性受到破壞) 立即路由至頁面上呼叫 |
| 平台 | 監視 | ✅ 高嚴重性事件 (效能降低、部分中斷) 會為提示營業時間調查產生立即通知 |
| 平台 | 監視 | ✅ 警告 (即將即將到來,組態漂移) 會彙總至每日摘要以主動修復 |
| 平台 | 監視 | ✅ 警示增強包括診斷內容:受影響的使用者計數、錯誤率百分位數、最近部署、相關警示和直接顯示面板連結 |
| 平台 | 監視 | ✅ 警示內容透過提供立即情況評估,而無須透過個別查詢收集基本資訊,可減少確認的平均時間 |
| 平台 | 監視 | ✅ 警示分組可透過使用彙總統計資料,將單一基本問題中的數百個相關警示合併為一個通知,藉此防止警示風暴 |
| 平台 | 監視 | ✅ 分組警示會顯示計數、匯率和受影響的交易,顯示問題模式,但沒有壓倒性回應者 |
| 平台 | 監視 | ✅ 警示抑制可防止已知暫時狀況在預期的維護期間或自動修復期間產生警示 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 監視 | ⚡️ 整合失敗會在 5 分鐘內產生 100 個個別警示,當通話時的電話壓倒性,每個警示皆相同,時間戳記除外 |
| 平台 | 監視 | ⚡️ 警示缺少範圍、最近變更或問題模式的相關內容;通話工程師必須手動收集基本資訊 |
| 平台 | 監視 | ⚡️ 所有警示都會透過相同的管道路由,無論嚴重性為何;嚴重的生產中斷都會與較小的警告競爭 |
| 平台 | 監視 | ⚡️ 警示會在排程維護期間觸發,產生錯誤陽性,進而破壞監視系統的Trust |
| 平台 | 監視 | ⚡️ 警示分組不存在;每個交易失敗都會在事件期間觸發個別的警示,以建立警示風暴 |
| 平台 | 監視 | ⚡️ 警示不會提供相關顯示面板的連結;回應者在事件回應期間花費時間尋找監視工具 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 作業 | ✅ 通話輪換是每週或每兩週平衡負擔分佈與內容保留 |
| 平台 | 作業 | ✅ 系統會記錄每個警示類型的執行手冊,讓通話工程師無需深入的網域專業知識即可有效回應 |
| 平台 | 作業 | ✅ 執行手冊包含問題描述、診斷步驟、補救程序、升級條件和相關文件連結 |
| 平台 | 作業 | ✅ 執行手冊是版本控制中的即時文件,透過死後動作項目演進 |
| 平台 | 作業 | ✅ Handoff 程序包含輪換轉換期間轉移內容的簡短會議,包括啟用中的問題、最近的變更、已知風險和即將到來的維護 |
| 平台 | 作業 | ✅ 撰寫轉換備註可補充文字轉換,以防止輪替轉換期間遺失資訊 |
| 平台 | 作業 | ✅ 測量頁面頻率、小時後事件計數和假陽性率,以識別需要結構修復的非可持續通話負擔 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 作業 | ⚡️ 不存在執行手冊;臨時工程師依賴部落 Knowledge 並經常升級為主題專家 |
| 平台 | 作業 | ⚡️ 執行手冊會儲存在個人文件中,而非由小組成員存取及更新之共用版本控制 |
| 平台 | 作業 | ⚡️ 通話輪換轉換會在沒有轉接會議的情況下進行;傳入工程師缺少有關啟用中問題和最近變更的內容 |
| 平台 | 作業 | ⚡️ 高的呼叫負擔會透過營運 heroics 無限期持續,而非推動結構改善 |
| 平台 | 作業 | ⚡️ 不會追蹤通話度量 (頁面頻率、營業時間後事件、假陽性),負載模式會保持不可見 |
| 平台 | 作業 | ⚡️ 執行手冊會在初始部署期間建立一次,且不會隨著系統進化或新失敗模式出現而更新 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 作業 | ✅ 技術升級路徑定義主題專家處理特定問題網域 |
| 平台 | 作業 | ✅ 管理升級路徑定義哪些經理會針對超過嚴重性或持續期間的事件收到通知 |
| 平台 | 作業 | ✅ 廠商升級路徑文件 Salesforce 支援個案建立程序和嚴重性條件 |
| 平台 | 作業 | ✅ 主管升級路徑定義哪些主管會收到業務關鍵事件的通知 |
| 平台 | 作業 | ✅ 升級條件明確且目標:嚴重性層級、時限、受影響的使用者計數、業務影響評估 |
| 平台 | 作業 | ✅ 升級路徑會記錄在執行手冊中,且在事件期間無須搜尋連絡人資訊即可存取 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 作業 | ⚡️ 未記錄升級路徑;通話工程師浪費時間在事件期間搜尋適當的連絡人 |
| 平台 | 作業 | ⚡️ 升級條件很模糊 (「如果看起來不佳,請升級」);回應者缺少何時升級的明確指引 |
| 平台 | 作業 | ⚡️ 管理通知會發生太晚,因為嚴重性值未定義;主管會向使用者瞭解事件 |
| 平台 | 作業 | ⚡️ 未記錄 Salesforce 支援升級程序;小組延遲開啟支援個案,失去寶貴的回應時間 |
| 平台 | 作業 | ⚡️ 主題主題專家連絡人已過時;升級到達錯誤的人員或在輪替變更期間失敗 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 作業 | ✅ 在重要營運事件後 5 個工作日內執行無罪的事件後審查 |
| 平台 | 作業 | ✅ 無罪文化著重於系統改善,而非個人責責,為誠實評估建立心理安全 |
| 平台 | 作業 | ✅ 時程表包含從初始條件到第一個訊號、偵測、確認、調查、回應、復原和驗證的詳細順序 |
| 平台 | 作業 | ✅ 時程表會標記每個事件,以啟用偵測、回應和復原階段的持續時間分析 |
| 平台 | 作業 | ✅ 根本原因可識別直接導致事件的技術失敗或條件,與影響因素不同 |
| 平台 | 作業 | ✅ 影響因素分析顯示已啟用或已放大事件影響的組織、程序或結構條件 |
| 平台 | 作業 | ✅ 偵測分析會評估事件的偵測方式,以及偵測是否可以加速 |
| 平台 | 作業 | ✅ 回應評估會識別在回應期間成功的項目,以及超過必要的速度或難度的項目 |
| 平台 | 作業 | ✅ 動作項目是特定的、已指派且已限制時間,可防止重複或改善未來回應 |
| 平台 | 作業 | ✅ 動作項目會避免具體工作的模糊改善 (「改善監視」) (“在超過 10% 的時間範圍內新增 API 錯誤率超過 5% 的警示」) |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 作業 | ⚡️事件後討論結束了「批次工作發生錯誤,我們已修正」但沒有文件或系統改善 |
| 平台 | 作業 | ⚡️ 事件後審查專注於個別故障,而非系統改善,進而破壞心理安全 |
| 平台 | 作業 | ⚡️ 時程表缺少阻止持續時間分析的時間戳記;小組無法識別偵測或回應是否緩慢 |
| 平台 | 作業 | ⚡️ 根原因分析無法區分立即的技術原因與組織或流程影響因素 |
| 平台 | 作業 | ⚡️ 已略過偵測分析;未識別允許使用者先報告事件的監視缺口 |
| 平台 | 作業 | ⚡️ 動作項目不具擁有者或到期日;系統會討論改善方式,但不會實作 |
| 平台 | 作業 | ⚡️ 事件後審查不會在 5 個工作日內執行;內容遺失且改善的緊急程度淡化 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | Knowledge 管理 | ✅ 事件後審查已記錄並廣泛共用,除了立即事件回應者以外,以進行組織學習 |
| 平台 | Knowledge 管理 | ✅ 事件後審查會儲存在共用的維基百科或Knowledge庫中,標記會啟用多個事件的模式分析 |
| 平台 | Knowledge 管理 | ✅ 動作項目完成度會在後續審查中追蹤,以防止追溯內容變成不需要追蹤的重複討論 |
| 平台 | Knowledge 管理 | ✅ 動作項目完成率會測量為營運健康指標,顯示是否已實作改善方式或僅僅是討論改善方式 |
| 平台 | 作業 | ✅ 在多個事件之間分析事件模式,顯示需要結構投資的系統問題 |
| 平台 | 作業 | ✅ 會根據事件後學習更新執行手冊,以確保程序反映實際事件回應體驗 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | Knowledge 管理 | ⚡️ 事件後審查並未記錄;學習內容會保留在事件回應者身上,而非在整個組織中散佈 |
| 平台 | Knowledge 管理 | ⚡️事件後審查會儲存在個人文件中,而非共用 Knowledge 庫,讓小組成員可從歷程記錄中學習 |
| 平台 | Knowledge 管理 | ⚡️ 已定義動作項目,但永不追蹤;完成率不明且未實作改善方式 |
| 平台 | Knowledge 管理 | ⚡️ 低的動作項目完成率會持續存在,而不會承認在沒有後續追蹤的情況下追溯為無效 |
| 平台 | 作業 | ⚡️ 事件模式不會在多個事件之間進行分析;系統問題會保持隱藏,因為每個事件都會個別處理 |
| 平台 | 作業 | ⚡️ 執行手冊不會在事件後更新;程序會隨著系統演進和新失敗模式出現而變為過時 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 作業 | ✅ 追蹤平均偵測時間 (MTTD),測量從事件發生到偵測的持續時間 |
| 平台 | 作業 | ✅ 追蹤確認平均時間 (MTTA) 測量從偵測到通話工程師確認的持續時間 |
| 平台 | 作業 | ✅ 追蹤平均還原時間 (MTTR),測量從偵測到服務還原的持續時間 |
| 平台 | 作業 | ✅ 透過每月趨勢檢閱追蹤事件頻率,顯示穩定性是否改善或降低 |
| 平台 | 作業 | ✅ 追蹤變更失敗率,測量導致生產事件需要補救的部署百分比 |
| 平台 | 作業 | ✅ 變更失敗率一直保持在低的狀態,是所有部署的一小部分 |
| 平台 | 作業 | ✅ 事件度量會在衝刺規劃期間與開發小組共用,告知待處理的優先順序和結構改善 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 作業 | ⚡️ 未追蹤事件度量;小組無法看見回應時間是否改善或降低 |
| 平台 | 作業 | ⚡️ 未測量 MTTD、MTTA 和 MTTR;小組無法識別偵測或回應是否為瓶頸 |
| 平台 | 作業 | ⚡️ 未追蹤變更失敗率;小組不知道品質門是否有效 |
| 平台 | 作業 | ⚡️ 事件頻率趨勢不會每月檢閱;在發生重大事件之前不會偵測到穩定性降級 |
| 平台 | 作業 | ⚡️ 事件度量會保留在作業小組中,而不會對開發小組共用;系統不會解決結構問題 |
| 平台 | 作業 | ⚡️ 度量會追蹤,但絕對不會用來通知決策;沒有動作的測量會浪費精力,且不會提供價值 |