2. 数据平台稳定性风险清单与优先级评估
从架构与业务依赖出发建立风险清单
稳定性风险清单不是泛泛罗列“可能出问题的地方”，而是把平台架构中的关键组件、业务依赖链路和运维约束逐项映射为可评估的风险条目。对典型数据平台，建议按六类风险源扫描：单点故障、容量瓶颈、依赖脆弱性、变更风险、数据一致性风险、可观测性缺口。每条风险必须落到具体对象（组件/链路/接口）和具体失效模式，否则无法评估优先级。
风险矩阵：概率 × 影响
采用 5×5 风险矩阵，发生概率 P 与影响程度 I 各分 1~5 级，风险值 R = P × I。概率依据历史故障频次、架构脆弱度和变更频率判断；影响依据受影响业务、SLO 违约程度、数据损失范围和恢复时长判断。R ≥ 15 为高优先级（P0），8 ≤ R < 15 为中优先级（P1），R < 8 为低优先级（P2）。
风险条目与优先级清单
下表为基于上述矩阵的示例评估结果。每条风险包含风险源、具体对象、失效模式、P/I 评分、风险值 R 和治理优先级。评分依据为教学示例假设，实际评估需结合平台真实监控数据与业务影响分析。
| 编号 | 风险源 | 具体对象 | 失效模式 | P | I | R | 优先级 |
|---|---|---|---|---|---|---|---|
| R1 | 单点故障 | Kafka 单 Broker 承载核心 Topic | Broker 宕机导致采集链路中断，数据积压 | 4 | 5 | 20 | P0 |
| R2 | 容量瓶颈 | HDFS 集群使用率 85% | 写入失败，计算任务无法落盘 | 3 | 4 | 12 | P1 |
| R3 | 依赖脆弱性 | 外部数据源 API 无降级策略 | API 超时导致采集任务阻塞，影响下游 | 4 | 4 | 16 | P0 |
| R4 | 变更风险 | 调度器升级无灰度发布 | 升级引入 Bug 导致批量任务失败 | 3 | 3 | 9 | P1 |
| R5 | 数据一致性 | 跨集群同步延迟 | 报表数据滞后，业务决策依据过期 | 2 | 4 | 8 | P1 |
| R6 | 可观测性缺口 | 核心链路无分布式追踪 | 故障定位耗时增加，MTTR 上升 | 3 | 2 | 6 | P2 |
治理优先级排序与行动建议
按 R 值降序排列，P0 风险需在 1 个迭代周期内启动治理，P1 在 2~3 个迭代内完成，P2 纳入季度改进计划。治理动作应直接对应失效模式：
- R1（R=20）：将核心 Topic 副本数提升至 3，增加 Broker 节点，配置最小同步副本数 ≥ 2。
- R3（R=16）：为外部 API 调用增加超时、重试和熔断降级，降级时写入本地缓冲队列。
- R2（R=12）：清理过期数据，扩容 DataNode，设置 80% 告警阈值和 90% 写入限流。
- R4（R=9）：调度器升级采用灰度发布，先 10% 节点验证再全量。
- R5（R=8）：同步延迟纳入 SLO 监控，超过阈值触发告警并通知下游。
- R6（R=6）：接入链路追踪，覆盖采集→传输→计算→查询全链路。
风险矩阵的评分不是一次性工作。建议每季度结合故障复盘、容量趋势和架构变更重新评估，动态调整优先级。P0 风险治理完成后应降级为常规监控项，新出现的风险及时纳入清单。