3. 高可用业务平台需求分析与SLA定义
在基于 AMD EPYC 构建高可用业务平台之前，必须先回答一个根本问题：业务到底需要多高的可用性？这个问题不能由运维团队凭经验拍板，也不能简单照搬"99.99%"这类口号式指标。需求分析的本质，是把业务方的连续性诉求翻译成可量化、可验证、可写入合同的技术参数，再反向约束架构设计。本节围绕业务连续性指标、RTO/RPO、可用性等级、容量与性能需求、合规约束五个维度展开，并给出可直接用于项目立项的SLA定义方法。
一、业务连续性指标：从业务语言到技术语言
业务连续性（Business Continuity）描述的是组织在遭遇故障、灾难或计划外中断时，维持关键业务功能的能力。业务方通常用"不能停""停一小时损失多少"来表达，而技术团队需要将其拆解为三类可测量指标：
- 可用性（Availability）：一段时间内系统可正常提供服务的时间占比，通常以"几个9"表示。
- 可靠性（Reliability）：系统在给定时间内不发生故障的概率，常用 MTBF（平均无故障时间）衡量。
- 可维护性（Maintainability）：故障后恢复的速度，常用 MTTR（平均修复时间）衡量。
三者关系为：可用性 ≈ MTBF / (MTBF + MTTR)。这意味着提升可用性有两条路径——延长无故障时间，或缩短修复时间。对于 AMD EPYC 平台，前者依赖冗余设计（双路电源、ECC 内存、多网卡绑定、RAID/分布式副本），后者依赖快速故障检测、自动切换与标准化恢复流程。实际项目中，缩短 MTTR 往往比追求极低故障率更具性价比。
二、RTO 与 RPO：恢复目标的两个坐标
RTO（Recovery Time Objective，恢复时间目标）指故障发生后，业务恢复到可接受服务水平所允许的最长停机时间；RPO（Recovery Point Objective，恢复点目标）指故障发生时，允许丢失的数据时间窗口。二者共同定义了容灾方案的"时间坐标"：RTO 决定切换与恢复速度，RPO 决定数据复制方式。
举例说明：某订单系统要求 RTO ≤ 15 分钟、RPO ≤ 5 分钟。这意味着故障后 15 分钟内必须恢复服务，且最多丢失最近 5 分钟的数据。对应技术选择：数据库需采用同步或半同步复制（RPO 接近 0～秒级），或每 5 分钟一次增量日志归档；应用层需具备健康检查与自动故障转移能力，将切换时间压缩到分钟级。若 RPO 要求为 0，则必须使用同步复制，但会带来写延迟上升，需要在性能与数据安全之间权衡。
三、可用性等级：几个9对应什么架构
可用性等级是 SLA 的核心量化表达。业界常用"几个9"划分，不同等级对应不同的年停机时间与架构复杂度。下表给出参考对照（按 365 天计算）：
| 可用性等级 | 年停机时间（参考） | 典型架构特征 |
|---|---|---|
| 99%（2个9） | 约 87.6 小时 | 单机 + 定期备份 |
| 99.9%（3个9） | 约 8.76 小时 | 关键部件冗余、本地高可用 |
| 99.95% | 约 4.38 小时 | 双机热备、自动切换 |
| 99.99%（4个9） | 约 52.6 分钟 | 同城双活、集群化、自动化运维 |
| 99.999%（5个9） | 约 5.26 分钟 | 异地多活、全链路冗余、秒级切换 |
需要强调：可用性等级不是越高越好，而是与成本强相关。从 3 个 9 提升到 4 个 9，往往需要引入负载均衡、共享存储、集群仲裁、自动化切换等组件，投入可能翻倍。AMD EPYC 平台的优势在于单颗 CPU 核心数多、内存带宽高，可在较少节点数下承载更高并发，从而在同等可用性目标下降低节点数量与授权成本，但冗余设计本身不可省略。
四、容量与性能需求：为高可用预留余量
高可用架构必须建立在容量充足的基础上——一个已经跑满的集群，故障切换时剩余节点无法承接流量，高可用就是空谈。容量分析需覆盖 CPU、内存、存储 IOPS、网络带宽四个维度，并遵循"N+1"或"N+M"冗余原则。
以某虚拟化业务平台为例（以下为教学示例参数，非实测数据）：现有 6 台 AMD EPYC 双路服务器，每台 64 核、512GB 内存，承载 200 台虚拟机，平均 CPU 利用率 55%、内存利用率 60%。若要求单节点故障时业务不降级，则剩余 5 台需承接全部负载，单台 CPU 利用率将升至约 66%、内存升至约 72%，仍在安全水位内，满足 N+1。若平均利用率已达 75%，则单节点故障后剩余节点将超过 90%，必须扩容或降级运行。因此容量规划要按"故障后峰值"而非"日常均值"计算。
故障后单节点利用率估算（示例）：
CPU：55% × 6 / 5 ≈ 66%
内存：60% × 6 / 5 ≈ 72%
判断：均低于 80% 告警线，满足 N+1 冗余
五、合规约束：不可协商的边界条件
合规要求往往直接决定架构形态，且优先级高于性能优化。常见约束包括：数据本地化（如金融、政务数据不得出境）、等保分级（二级/三级对日志留存、访问控制、审计的要求不同）、行业监管（如支付卡行业对密钥管理与网络隔离的要求）、审计留痕（操作日志保存 6 个月以上）。这些约束会影响备份策略、加密方式、日志存储位置与跨站点复制范围，必须在 SLA 定义阶段一并明确，避免架构定型后返工。
六、SLA 定义模板与落地要点
将上述分析固化为文档，建议采用如下字段结构（可直接用于项目立项评审）：
| 字段 | 示例值 | 说明 |
|---|---|---|
| 业务系统名称 | 订单交易平台 | 明确范围 |
| 可用性等级 | 99.99% | 年停机 ≤ 52.6 分钟 |
| RTO | ≤ 15 分钟 | 含检测、切换、验证 |
| RPO | ≤ 5 分钟 | 数据复制/归档周期 |
| 容量冗余 | N+1 | 故障后利用率 ≤ 80% |
| 性能基线 | P95 响应 ≤ 200ms | 峰值 QPS 5000 |
| 合规要求 | 等保三级、数据本地化 | 日志留存 6 个月 |
| 演练频率 | 每季度一次切换演练 | 验证 RTO/RPO 达成 |
最后强调三个落地要点。第一，SLA 必须可测量：每一项指标都要有对应的监控采集点与统计口径，否则无法验证。第二，SLA 必须可演练：RTO 和 RPO 不能只写在文档里，要通过定期故障切换演练验证，演练结果反哺架构优化。第三，SLA 必须与成本挂钩：在立项阶段就应评估不同可用性等级对应的硬件、软件与人力投入，由业务方在成本与连续性之间做出知情决策。对于 AMD EPYC 平台，其高核心密度与内存带宽优势可以在满足性能基线的前提下减少节点数量，但冗余节点、复制链路与自动化工具的成本仍需单独核算，不能因单机性能强而削减冗余设计。