4. SLA 等级划分：基础版、标准版、企业版与定制化
聊完了 SLA 的核心指标和计算方式，接下来咱们得面对一个现实问题：不是所有业务都需要 99.999% 的可用性。
你想想看，一个内部 OA 系统和一款金融交易系统，它们的 SLA 能一样吗？显然不能。我这些年见过不少团队，上来就照着大厂的标准抄，结果运维成本翻了几倍，业务方还不买账。说白了，SLA 的等级划分，本质上是在成本、复杂度和业务价值之间找平衡。
核心原则： SLA 等级不是越高越好，而是「够用就好」。每提升一个 9，运维成本可能翻 3-5 倍。
4.1 四层 SLA 模型总览
我个人习惯把 SLA 分成四个等级，从轻到重，覆盖不同场景。下面这张图能帮你快速建立整体认知：
4.2 基础版 SLA：够用就行
基础版 SLA 适合什么场景？我举个例子：你们公司的内部 Wiki、打卡系统、项目管理系统。这些系统挂了，大家会抱怨，但公司不会倒闭。
| 维度 | 基础版指标 | 说明 |
|---|---|---|
| 可用性 | 99.5% | 每月允许宕机约 3.6 小时 |
| 响应时间 | 4 小时 | 工作日工作时间响应 |
| 解决时间 | 24 小时 | 不要求连夜修复 |
| 监控覆盖 | 基础存活监控 | Ping + 端口检测 |
| 备份策略 | 每日全量备份 | 保留 7 天 |
我的建议： 基础版 SLA 的监控可以做得「糙」一点。我曾经给一个内部 OA 系统只配了 5 分钟的 Ping 监控和日志采集，运行了两年没出过大问题。别在这种系统上浪费 Prometheus 的告警规则，不值得。
4.3 标准版 SLA：大多数业务的标配
标准版 SLA 是市面上最常见的。电商网站、SaaS 平台、API 服务，基本都落在这个区间。99.9% 的可用性，意味着一年宕机不超过 8.76 小时。
嗯，这里要注意：99.9% 看起来不高，但实际运维中，想稳定达到并不容易。我见过太多团队，上线时拍胸脯说能做到 99.9%，结果每次发布都出问题，年底一算只有 99.5%。
| 维度 | 标准版指标 | 说明 |
|---|---|---|
| 可用性 | 99.9% | 每月宕机不超过 43 分钟 |
| 响应时间 | 1 小时 | 7×24 小时响应 |
| 解决时间 | 8 小时 | 需要安排值班 |
| 监控覆盖 | 全链路基础监控 | CPU、内存、磁盘、网络、应用日志 |
| 备份策略 | 每日全量 + 增量 | 保留 30 天 |
避坑指南： 我曾经给一个标准版 SLA 的客户只配了单节点部署，结果硬件故障导致宕机 3 小时。后来我学乖了——标准版至少要做双节点冗余，哪怕只是主备模式，也能把恢复时间从小时级降到分钟级。
4.4 企业版 SLA：真金白银的承诺
企业版 SLA 是分水岭。99.99% 的可用性，一年宕机不超过 52.56 分钟。到了这个级别，每一分钟的宕机都意味着真金白银的损失。
我参与过一个金融支付系统的 SLA 设计，客户要求 99.99%。当时我们做了三件事：多活架构、自动故障转移、全链路压测。说实话，那段时间我几乎住在机房里。
| 维度 | 企业版指标 | 说明 |
|---|---|---|
| 可用性 | 99.99% | 每月宕机不超过 4.38 分钟 |
| 响应时间 | 15 分钟 | 自动告警 + 值班工程师 |
| 解决时间 | 2 小时 | 需要预案和自动化工具 |
| 监控覆盖 | 全链路 + 业务指标 | APM、用户行为、事务成功率 |
| 备份策略 | 实时同步 + 异地容灾 | RPO ≤ 5 分钟，RTO ≤ 30 分钟 |
关键认知： 企业版 SLA 的监控不再是「出了事再告警」，而是「在出事之前预警」。你需要配置趋势告警和容量预测，比如磁盘使用率超过 70% 就开始告警，而不是等到 95% 才通知你。
4.5 定制化 SLA：没有模板，只有合同
定制化 SLA 是最有意思的。它没有固定模板，一切取决于你和客户之间的合同。我遇到过几种典型场景：
- 金融交易系统： 可用性要求 99.999%，但允许在特定时段（如凌晨 2-4 点）进行计划内维护，不计入 SLA 统计。
- 医疗影像系统： 对响应时间要求极高（P95 < 200ms），但对可用性要求反而没那么苛刻（99.9%）。
- 政务平台： 要求 100% 数据不丢失，但可以接受较长的恢复时间（RTO ≤ 4 小时）。
定制化 SLA 的监控策略也需要「量身定制」。举个例子，我曾经给一个客户做定制化 SLA，他们的核心诉求不是「系统不挂」，而是「挂了之后数据不能丢」。所以我们把监控重心从可用性转移到了数据一致性校验和备份完整性检查上。
我的经验： 定制化 SLA 一定要在合同中明确排除项。比如「因第三方云服务商故障导致的不可用，不计入 SLA」、「因客户自身变更导致的故障，不计入 SLA」。否则你会被坑得很惨。
4.6 如何选择适合的 SLA 等级？
最后，我分享一个实用的决策框架。每次做 SLA 设计时，我会问自己三个问题：
- 业务影响有多大？ 系统挂了，公司会损失多少钱？是几千块还是几百万？
- 用户容忍度有多高？ 用户能等 5 分钟还是 5 秒？
- 运维预算有多少？ 你有多大的团队？多少服务器？多少自动化工具？
根据这三个问题的答案，你可以快速定位到合适的 SLA 等级：
| 业务影响 | 用户容忍度 | 运维预算 | 推荐 SLA 等级 |
|---|---|---|---|
| 低 | 高 | 低 | 基础版 |
| 中 | 中 | 中 | 标准版 |
| 高 | 低 | 高 | 企业版 |
| 极高 | 极低 | 充足 | 定制化 |
记住，SLA 等级不是一成不变的。随着业务发展，你可能需要从基础版升级到标准版，甚至企业版。我建议每半年 review 一次 SLA 等级，看看是否需要调整。