「我们的系统要做到 99.99% 可用」——这个目标听起来合理，但很少有人说清它意味着什么。99.99% 意味着全年停机时间不超过 53 分钟。要实现它，架构复杂度与成本会显著上升。
本文提供一个分层框架，帮你判断业务真正需要哪一级。
先算清楚：可用性等级对应多少停机时间
| 可用性 | 年停机时间 | 月停机时间 | 典型场景 |
|---|---|---|---|
| 99%（2 个 9） | 约 3.65 天 | 约 7.2 小时 | 内部系统、非核心业务 |
| 99.9%（3 个 9） | 约 8.76 小时 | 约 43 分钟 | 一般商业网站 |
| 99.95% | 约 4.38 小时 | 约 22 分钟 | 标准云产品 SLA |
| 99.99%（4 个 9） | 约 53 分钟 | 约 4.4 分钟 | 电商、在线服务 |
| 99.995% | 约 26 分钟 | 约 2.2 分钟 | 跨可用区高可用 |
| 99.999%（5 个 9） | 约 5 分钟 | 约 26 秒 | 金融核心、电信级 |
关键认知：每提升一个 9，成本通常翻倍。所以第一步不是「追求最高」，而是「确定业务真正需要几级」。
Level 0：单机部署（99% 以下）
一台 ECS 承载所有服务。任何硬件故障、系统崩溃、误操作都会导致业务中断。
适用：开发测试环境、个人项目、内部工具。
必需配置：至少配置自动快照，把「数据丢失」降级为「回滚恢复」。
Level 1：应用层冗余（99.9%）
两台以上 ECS + 负载均衡 SLB，配合健康检查。任一实例故障时 SLB 自动摘除，业务不中断。
要点：
- 应用必须无状态（会话存 Redis/Tair 而非本地内存）
- SLB 配置健康检查，探测失败自动摘除异常节点
- 数据库暂可用单实例 RDS（这是当前的单点）
适用：大多数中小企业网站与 SaaS 应用。这个级别投入不大，但已能消除绝大多数单点故障。
Level 2：数据库高可用（99.95%）
在 Level 1 基础上，把数据库也做高可用：
- 使用 RDS 高可用版（主备自动切换）或 PolarDB（多节点）
- 缓存使用 Tair 主从版或集群版
- 对象存储使用 OSS 标准型（本身就是多副本高可用）
此时数据库故障可在 30 秒内自动切换，业务只需处理重连。
适用：有真实业务收入的在线服务。这是性价比最高的高可用级别。
Level 3：多可用区部署（99.99%+）
把资源分布到同一地域的多个可用区，实现「单个可用区故障不影响业务」。
架构要点：
- ECS 实例分布在至少 2 个可用区，挂在同一个 SLB 后端
- RDS 选择多可用区（主备在不同 AZ）
- 开启「同可用区优先调用」，减少跨 AZ 网络延迟
- OSS 使用同城冗余存储类型
可用区的物理距离通常在几公里到几十公里，网络延迟增加很小（1–3 ms），但容灾能力显著提升。
适用：电商、在线服务、有明确可用性承诺的业务。这是绝大多数业务应该追求的最终目标。
Level 4：异地多活（99.995%+）
在多个地域（城市）部署完整业务单元，用户就近访问，任一地域故障时流量切换到其他地域。
这需要解决几个难题：
- 数据同步：用 DTS 做跨地域双向同步，但存在延迟与冲突问题
- 流量调度：用全局流量管理 GTM 或全球加速 GA 做智能调度
- 数据分片：通常按用户维度分片，同一用户的数据只在一个地域写入，避免冲突
适用：全国性或全球性业务，对可用性有极高要求。成本与复杂度都很高，不建议一般业务追求。
别忘了「非技术」因素
架构只是可用性的一部分。实际事故中，很大比例来自：
- 变更引入的故障：上线新版本导致。对策：灰度发布、可回滚。
- 容量不足：流量突增导致。对策：弹性伸缩、压测。
- 依赖故障：第三方服务挂了。对策：降级预案。
- 人为误操作：删库、改错配置。对策：权限管控、审批流程、备份。
- 攻击：DDoS 与入侵。对策：DDoS 防护、WAF。
把架构做好只解决了「基础设施故障」这一类，还需要配套的流程与预案才能达到真正的可用性目标。
选型建议
| 业务类型 | 建议级别 | 年成本量级 |
|---|---|---|
| 个人项目 / 测试 | Level 0–1 | 百元级 |
| 企业官网 | Level 1 | 千元级 |
| SaaS / 在线工具 | Level 2 | 万元级 |
| 电商 / 在线交易 | Level 3 | 数万元级 |
| 金融 / 全国性平台 | Level 4 | 数十万元级+ |
核心建议：不要盲目追求高可用等级，而要匹配业务的真实损失模型。如果一小时停机损失 100 元，花 10 万元/年做 5 个 9 是不理性的。