5.7 KiB
5.7 KiB
#sla #uptime #downtime
SLA Downtime 计算详解
99.9% 与 99.99% 的区别和实际应用
一、SLA 基本概念
SLA（Service Level Agreement，服务级别协议） 是指服务提供商与客户之间约定的服务可用性标准。
SLA 的计算公式
SLA % = (总时间 - 宕机时间) / 总时间 × 100%
反推宕机时间：
宕机时间 = 总时间 × (1 - SLA%)
关键点： SLA 99.9% 意味着允许 0.1% 的宕机时间，99.99% 意味着允许 0.01% 的宕机时间。
二、按月计算的 Downtime 时间
1. 月度总时长（以30天为例）
| 单位 | 数值 |
|---|---|
| 总天数 | 30天 |
| 总小时数 | 30 × 24 = 720小时 |
| 总分钟数 | 30 × 24 × 60 = 43,200分钟 |
| 总秒数 | 30 × 24 × 60 × 60 = 2,592,000秒 |
注：实际应用中，有些公司按月份天数计算（28-31天），此处以30天为标准示例。
三、SLA 99.9% 详解
计算公式
月度允许宕机时间 = 总时间 × (1 - 99.9%)
= 总时间 × 0.1%
= 总时间 × 0.001
具体数值
| Daily | 1m 26s |
| Weekly | 10m 4.8s |
| Monthly | 43m 50s |
| Quarterly | 2h 11m 29s |
| Yearly | 8h 45m 57s |
月度详细计算示例
99.9% SLA 月度允许宕机时间：
方法一（按分钟）：
宕机时间 = 43,200分钟 × 0.001 = 43.2 分钟
方法二（按秒钟）：
宕机时间 = 2,592,000秒 × 0.001 = 2,592 秒 = 43分12秒
结论：一个月内最多可允许约 43分钟的宕机时间
99.9% 的通俗理解
- "三个九" 是常见的说法
- 一年内最长可宕机约 8.76小时（相当于一个工作日）
- 一月内最长可宕机约 43分钟
- 一周内最长可宕机约 1分钟
四、SLA 99.99% 详解
计算公式
月度允许宕机时间 = 总时间 × (1 - 99.99%)
= 总时间 × 0.01%
= 总时间 × 0.0001
具体数值
| Daily | 8.6s |
| Weekly | 1m 0.48s |
| Monthly | 4m 23s |
| Quarterly | 13m 8.9s |
| Yearly | 52m 36s |
月度详细计算示例
99.99% SLA 月度允许宕机时间：
方法一（按分钟）：
宕机时间 = 43,200分钟 × 0.0001 = 4.32 分钟 = 4分19秒
方法二（按秒钟）：
宕机时间 = 2,592,000秒 × 0.0001 = 259.2 秒 ≈ 4分19秒
结论：一个月内最多可允许约 26秒的宕机时间
99.99% 的通俗理解
- "四个九" 是高端服务的标准
- 一年内最长可宕机约 52.6分钟（接近1小时）
- 一月内最长可宕机约 4分23秒（几乎不允许停机）
- 一周内最长可宕机约 1分钟
- 对于银行、支付系统等核心业务系统通常要求此级别
六、Downtime 的统计方法
1. 宕机时间的计算
定义
宕机时间 = 服务不可用的时间段
统计方式
开始宕机时间：用户首次无法访问服务的时刻（UTC时间戳）
结束恢复时间：服务完全恢复可用的时刻（UTC时间戳）
宕机时长 = 结束恢复时间 - 开始宕机时间
实际例子
2024年9月5日 14:30:00 - 服务开始故障
2024年9月5日 14:45:30 - 服务完全恢复
宕机时长 = 15分30秒
2. 月度 SLA 计算
月度SLA% = (总时间 - 月度累计宕机时长) / 总时间 × 100%
例：
总时间 = 43,200分钟（30天）
月度累计宕机时长 = 65分钟（多次故障累加）
月度SLA% = (43,200 - 65) / 43,200 × 100%
= 43,135 / 43,200 × 100%
= 99.85%
结论：该月SLA未达到99.9%的要求
3. 需要注意的统计细节
✅ 应该计入宕机时间
- 完全不可用的时间段
- 部分功能不可用且影响主要业务的时间段
- 包括故障发现到完全恢复的全部时间
❌ 通常不计入宕机时间
- 计划内维护时间（如提前通知的升级）
- 客户端问题导致的无法访问
- 客户网络问题导致的连接失败
- 用户操作错误导致的故障
4. 宕机统计的数据来源
主要来源：
├─ 服务器日志（访问日志、错误日志）
├─ 监控告警（Prometheus、Datadog等）
├─ 负载均衡器日志
├─ CDN日志
├─ 用户反馈/投诉
└─ 自动化探测（Ping、健康检查）
七、实际应用案例
案例1：电商平台（需要99.9%）
月度时间：43,200分钟
允许宕机：43分钟
场景：
- 8月发生2次故障
第一次：15分钟
第二次：28分钟
累计：43分钟
评估：刚好达到99.9% SLA，但已是极限
案例2：支付系统（需要99.99%）
月度时间：2,592,000秒
允许宕机：259秒（约4分钟）
场景：
- 一整月运行无任何宕机事件
- 部分时间段响应缓慢但服务可用
- 计划维护避开业务高峰
评估：完全满足99.99% SLA要求
案例3：内部系统（需要99.5%）
月度时间：43,200分钟
允许宕机：216分钟（3.6小时）
场景：
- 一个月内宕机3小时
- 仍在容许范围内
评估：满足99.5% SLA要求
九、最佳实践
💡 监控和告警
- 使用专业监控工具（Prometheus、Grafana等）
- 设置实时告警机制
- 记录所有故障时间和原因
💡 故障恢复
- 制定明确的恢复流程（RTO/RPO）
- 设置自动故障转移（如主备切换）
- 定期进行故障演习
💡 数据统计
- 使用UTC时间戳，避免时区混淆
- 保存完整的历史日志（建议至少保留1年）
- 定期生成SLA报告，对外透明化
💡 承诺管理
- 清楚标注哪些维护不计入SLA
- 对客户设定合理预期
- 提供赔偿机制（宕机补偿）
更新日期： 2024年 适用范围： SLA管理、性能评估、架构设计