1. 数据平台稳定性与容灾全景
数据平台承载着采集、传输、存储、计算、调度、服务这条完整链路，任何一环抖动，都会沿着依赖关系向上放大，最终表现为报表延迟、指标失真、接口超时甚至业务决策中断。因此，稳定性不是某一个组件的属性，而是整条数据链路的整体属性。理解这一点，是后续所有容量规划、故障演练与容灾设计的前提。
先厘清几个核心概念。可靠性指系统在规定时间内、规定条件下持续提供正确服务的能力，通常用 MTBF（平均无故障时间）衡量；可用性指系统在任意时刻处于可服务状态的概率，用 A = MTBF / (MTBF + MTTR) 表达，其中 MTTR 是平均修复时间；容灾则是在灾难性故障（机房断电、区域网络中断、存储集群整体不可用）发生时，仍能恢复数据与服务的工程能力。三者关系可以概括为：可靠性决定故障发生的频率，可用性决定故障发生后多快恢复，容灾决定恢复的边界能覆盖多大的灾难范围。
稳定性目标必须量化，否则无法验收。业界常用“几个 9”表达年度可用性，但数据平台更应关注业务可感知的 SLO。例如某离线数仓核心链路约定：T+1 核心报表在每日 08:00 前产出率 ≥ 99.5%，单任务 P95 完成时间 ≤ 40 分钟，数据质量校验通过率 ≥ 99.9%。这些指标比笼统的“99.99% 可用”更贴近真实体验，因为它们直接对应业务方的等待时间与数据可信度。设定目标时遵循“可测量、可归因、可分解”原则：总目标拆到链路，链路拆到任务，任务再拆到资源与依赖。
容灾等级通常按 RTO（恢复时间目标）与 RPO（恢复点目标）划分。RTO 是从故障发生到服务恢复的最长可接受时间，RPO 是允许丢失的最大数据时间窗口。下表给出常见分级与典型手段，参数为教学示例，实际取值需结合业务容忍度确定。
| 等级 | RTO（示例） | RPO（示例） | 典型手段 |
|---|---|---|---|
| L1 本地高可用 | ≤ 5 分钟 | ≈ 0 | 多副本、主从切换、进程守护 |
| L2 同城双活 | ≤ 30 分钟 | ≤ 1 分钟 | 同城双机房、同步/半同步复制 |
| L3 异地灾备 | ≤ 4 小时 | ≤ 15 分钟 | 异地异步复制、定期快照 |
| L4 异地多活 | ≤ 30 分钟 | ≤ 5 分钟 | 单元化、双向同步、流量调度 |
性能指标方面，数据平台需要区分吞吐（每秒处理记录数、每日调度任务数）、延迟（端到端时延、任务排队时长）、资源效率（CPU/内存利用率、存储放大比、Shuffle 数据量）与稳定性指标（任务失败率、重试率、长尾任务占比）。一个常见误区是只盯平均延迟，而忽略 P95/P99 长尾——恰恰是长尾任务拖垮了整条链路的产出时间。因此监控面板上应同时呈现均值与分位数，并对长尾任务单独建看板。
下面这张图把数据平台的稳定性与容灾全景串起来：左侧是业务 SLO，中间是链路各环节及其对应的容灾手段，右侧是贯穿始终的监控与演练闭环。它帮助你在面对一个具体故障时，快速定位“这是哪一层的问题、该用哪一级容灾手段、影响哪个 SLO”。
本课程围绕这条全景链路展开，共 30 章，最终落地为一个可运行的实战项目：“某电商数据平台稳定性与容灾改造”。项目设定为教学示例：平台日均调度任务约 12 万，核心链路 8 条，存储总量约 2 PB，当前存在三个典型问题——核心报表偶发延迟至 10:30 后、同城机房切换从未演练、长尾任务占比约 7%。你将依次完成：稳定性目标与 SLO 定义、链路依赖梳理与单点识别、容量与性能基线测量、任务长尾治理、同城双活与异地灾备方案设计、故障演练脚本编写、监控告警体系搭建，以及最终的复盘与改进闭环。