在业务发展初期，尽快抢占市场，尽可能快的完善产品的功能，往往会背上不小的技术债务，随着业务发展业务上要精细化，技术上也需要有精细化的策略，控制问题的程度；业务人群分层，技术故障分层。
这个时候就要考虑，技术系统中的故障该如何处理。
常见的划分方式：
- 影响的用户数
- 影响的时长
- 功能的重要性；核心功能还是非核心功能
- 给公司造成了多少损失
| 影响用户少 | 影响用户多 | |
|---|---|---|
| 影响时间短 | 系统抖动；特殊用户；一般不考虑故障，但是要有解决方案 | 秒杀场景；高QPS的场景；有相对充足的时间解决问题 |
| 影响时间长 | 低频功能，如提现、商品评价；有相对充足的时间解决问题 | 核心功能，首页不可用，支付不可用，尽管很短的时间都有很大的影响。 |
一般来说：资损 > 核心功能 > 非核心功能
- 核心功能具备用户多的特点，只要核心功能出了问题，就会影响到大量用户，严重的问题就是持续影响用户
- 有资损场景的功能出了问题也很严重，可能少量用户就是严重问题。
- 对非核心功能场景又要看功能特点，非核心功能要结合业务核心功能看。
非核心功能，比如Push：
- 发错了是严重的问题；看覆盖范围有多大，是配置问题，还是系统问题？ 因为覆盖的用户量比较大
- 发不出去是问题，看持续时长有多久，配置问题，还是系统问题？
- 给用户重复发同一个内容，也是问题，但是要看影响了多少人。
可能的系统问题：
- 占位符计算
- 数据库不稳定
- 系统负载瓶颈
- 代码bug，应用挂掉
影响的用户量，最终的行动：
- MAU的1%： 警告
- MAU的5%：复盘
- MAU的20%：深度复盘
网友评论