系统分级：把有限的技术投入花在正确的地方
所有系统都想要「高可用」，但多活部署、全链路压测、7×24 值班的成本是实打实的。分级的意义不是给系统贴标签，而是明确每一级必须做到什么、可以不做什么，让评审和排期有据可依。
一、先说结论
- 分级的依据是「坏掉之后会发生什么」，不是流量大小，也不是团队的重视程度。
- 至少要有三档：核心交易链路、重要支撑系统、内部与离线系统。每档对应明确的可用性目标和工程要求。
- 分级必须落到可检查的清单上：部署形态、监控告警、演练频率、变更流程、值班方式。写不出清单的分级就是空话。
- 依赖会传递等级：核心系统依赖的组件至少同级，否则等级只是纸面上的。
- 定级要定期复核：业务变化后，昨天的非核心系统可能已经在关键路径上。
二、怎么定级
判断一个系统的等级，问四个问题：
| 问题 | 说明 |
|---|---|
| 它坏了，用户能不能完成核心动作？ | 下单、支付、登录这类动作被阻断，就是最高级 |
| 影响面有多大？ | 全量用户、部分用户、还是只有内部员工 |
| 有没有兜底？ | 能降级到默认行为、能人工处理，等级可以降一档 |
| 多久必须恢复？ | 恢复时间目标（RTO）以分钟计还是以小时计 |
据此分三档（名字不重要，重要的是要求不同）：
| 等级 | 典型系统 | 故障后果 | 可用性目标示例 |
|---|---|---|---|
| 一级（核心交易） | 下单、支付、登录、商品详情 | 交易中断，直接损失收入 | 99.99%，RTO < 5 分钟 |
| 二级（重要支撑） | 订单管理、库存、优惠券、消息推送 | 部分功能不可用，可短时降级 | 99.9%，RTO < 30 分钟 |
| 三级（内部与离线） | 报表、运营后台、数据同步 | 内部效率受影响 | 99%，RTO < 4 小时 |
可用性目标要写成 SLO 并且可测量：用「成功请求数 / 总请求数」和「p99 延迟」定义，而不是模糊的「高可用」。没有度量的目标无法验收，也无法在事后判断是否达标。
三、每一级的工程要求
分级之所以有用，是因为每一级对应一张明确的清单。下面是一份可以直接拿去裁剪的版本。
3.1 部署与容量
| 项 | 一级 | 二级 | 三级 |
|---|---|---|---|
| 部署 | 多可用区，具备跨机房切换能力 | 多可用区 | 单可用区可接受 |
| 容量水位 | 日常不超过 50%，可承受单机房故障 | 不超过 70% | 不超过 80% |
| 依赖隔离 | 核心与非核心依赖分线程池、分连接池 | 关键依赖隔离 | 不强制 |
| 限流降级 | 必须有，且演练过 | 必须有 | 建议有 |
3.2 数据
| 项 | 一级 | 二级 | 三级 |
|---|---|---|---|
| 备份 | 每日全量 + 增量，定期恢复演练 | 每日全量 | 每周全量 |
| 一致性 | 强一致，必须有对账 | 最终一致 + 对账 | 允许延迟 |
| 恢复演练 | 每季度一次真实恢复 | 每半年一次 | 不强制 |
「备份没有验证过恢复」等于没有备份，这一条对所有等级都成立，只是频率不同。
3.3 可观测与告警
| 项 | 一级 | 二级 | 三级 |
|---|---|---|---|
| 指标与链路 | 全链路追踪，SLO 面板 | 核心接口指标 | 基础存活监控 |
| 告警 | 基于 SLO，配 runbook，7×24 响应 | 基于错误率与延迟，工作时间响应 | 日志告警即可 |
| 变更事件 | 必须接入可观测体系 | 建议接入 | —— |
具体做法见 从「能跑」到「可观测」。
3.4 变更与值班
| 项 | 一级 | 二级 | 三级 |
|---|---|---|---|
| 发布 | 灰度 + 可回滚，禁止高峰期发布 | 灰度发布 | 直接发布 |
| 评审 | 方案评审 + 代码评审 | 代码评审 | 代码评审 |
| 演练 | 每季度故障演练（断依赖、断缓存、杀实例） | 每半年 | 不强制 |
| 值班 | 7×24 轮班，有明确升级路径 | 工作时间响应 | 工单处理 |
四、依赖会传递等级
这是最容易被忽略的一点：一级系统依赖的任何组件，都至少是一级。
举例：下单是一级系统，它依赖的优惠券服务如果是二级，那么优惠券故障时下单也会失败——整条链路的实际等级由最弱的一环决定。
两种处理方式：
- 提升依赖的等级：让优惠券服务也达到一级的要求。
- 降低依赖的强度：给优惠券调用加超时、熔断和降级（查不到优惠券就按原价下单），把强依赖变成弱依赖。
第二种通常更划算。梳理时要给每个依赖标注「强依赖 / 弱依赖」，并且用演练验证：把这个依赖断掉，核心流程是否还能走通。没演练过的「弱依赖」，在故障时往往会暴露成强依赖。
五、把分级落地
- 列出系统清单，逐个按第二节的四个问题定级，结果要有人签字确认。
- 对照清单查差距：每个系统当前状态与目标等级的差距列成待办。
- 排期补差距：差距大的优先补「兜底能力」（限流、降级、备份恢复），再补「优化项」（多活、压测）。
- 画依赖图并标注强弱，通过演练验证弱依赖的真实性。
- 每半年复核一次等级：业务上线、流量变化、组织调整都可能改变系统的重要性。
分级还有一个隐性收益：它让「不做某件事」变得可解释。三级系统不做多活、不做 7×24 值班，不是团队不负责，而是明确的取舍。
六、常见误区
- 「所有系统都按最高标准建设」：成本不可持续，最终结果是核心系统也没做好。
- 「流量大的就是核心」：图片服务流量最大，但它挂了通常只影响体验，不阻断交易。
- 「定级一次就固定了」：业务在变，等级要跟着变。
- 「弱依赖不用管」：没演练过的弱依赖在故障时经常表现为强依赖。
- 「有备份就安全」：没做过恢复演练的备份，恢复时间和完整性都是未知数。
小结
系统分级本质上是一次资源分配的决策：先按「坏了会怎样」把系统分档，再为每一档写出可检查的工程清单，最后用依赖图和演练验证清单是不是真的成立。分级的价值不在于评出等级，而在于让「这个系统要做到什么程度」有据可依，也让「暂时不做什么」变成一个显式的、可以被追问的选择。
参考资料