在業務發展初期，儘快搶佔市場，儘可能快的完善產品的功能，往往會背上不小的技術債務，隨着業務發展業務上要精細化，技術上也需要有精細化的策略，控制問題的程度；業務人羣分層，技術故障分層。
這個時候就要考慮，技術系統中的故障該如何處理。
常見的劃分方式：
- 影響的用戶數
- 影響的時長
- 功能的重要性；核心功能還是非核心功能
- 給公司造成了多少損失
| 影響用戶少 | 影響用戶多 | |
|---|---|---|
| 影響時間短 | 系統抖動；特殊用戶；一般不考慮故障，但是要有解決方案 | 秒殺場景；高QPS的場景；有相對充足的時間解決問題 |
| 影響時間長 | 低頻功能，如提現、商品評價；有相對充足的時間解決問題 | 核心功能，首頁不可用，支付不可用，儘管很短的時間都有很大的影響。 |
一般來說：資損 > 核心功能 > 非核心功能
- 核心功能具備用戶多的特點，只要核心功能出了問題，就會影響到大量用戶，嚴重的問題就是持續影響用戶
- 有資損場景的功能出了問題也很嚴重，可能少量用戶就是嚴重問題。
- 對非核心功能場景又要看功能特點，非核心功能要結合業務核心功能看。
非核心功能，比如Push：
- 發錯了是嚴重的問題；看覆蓋範圍有多大，是配置問題，還是系統問題？ 因爲覆蓋的用戶量比較大
- 發不出去是問題，看持續時長有多久，配置問題，還是系統問題？
- 給用戶重複發同一個內容，也是問題，但是要看影響了多少人。
可能的系統問題：
- 佔位符計算
- 數據庫不穩定
- 系統負載瓶頸
- 代碼bug，應用掛掉
影響的用戶量，最終的行動：
- MAU的1%： 警告
- MAU的5%：覆盤
- MAU的20%：深度覆盤