#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管理、性能评估、架构设计