案例：保全社區與線上雜貨應用整合#

某保全軟體服務於高級社區，住戶與管理員用它做訪客管制、繳費、申訴與通訊。組織決定併購一家線上雜貨平台，並把雜貨功能整合進保全應用。

規劃階段#

• 由於兩支軟體本身已穩定，主要工作是整合
• 部分原雜貨團隊也加入

實作階段#

• 共用客戶池：資料庫同步
• DevOps 為整合服務建新 CI/CD 管線、雜貨服務沿用既有管線
• SRE 重用部分監控儀表板，整合到統一視圖
• 開發完成兩個軟體整合並上線

測試階段#

• QA 進行回歸與遞增測試
• SRE 執行效能測試

監控階段的問題#

上線數月後事件數爆增到 1000+，SRE 來不及處理，可靠性下滑、客戶流失。

問題分析#

• 多數事件其實只是查詢與一般疑問，不算高衝擊
• 既有事件管理流程針對保全軟體設計：目標客戶單純、規模有限
• 把單純查詢與系統不可用同樣列為 P1，導致 SRE 浪費精力在低價值工單上
• 自動化分派也不存在，因為原本量小不需要

解法：重新設計事件管理流程#

• 把客戶查詢類事件降級到 P2、P3
• 為高量場景建構自動化工具：自動接收、自動分派、自動解決部分事件
• 把所有高優先級事件結合既有 RCA 流程

4 個月內，可靠性回升、事件處理變得可控。問題不在工程能力，而在流程沒跟上業務變化。

教訓#

• 流程要隨應用規模演進：不能假設老流程能套用到新場景
• 事件分級是事件管理的根本：分錯級的話，後面所有努力都會變徒勞
• 自動化是規模量級下的必需品：人工挑單在 1000+ 工單面前必敗

每次重大整合或市場拓展前，重新檢視事件管理流程是否仍與當前客戶基底匹配，是預防同類災難的關鍵。