update

Cloud DevOps/Index.md

@@ -27,7 +27,7 @@ Product Trial/PoC Procedure
 ## **Deployment & Configuration**
 [[ITOM Cloud AWS Account Overview]]
 [[ITOM ESM Cloud Farm Information]]
-[[Cloud DevOps/ITOM APM AppPluse Cloud Farm Information]]
+[[ITOM APM AppPluse Cloud Farm Information]]
 
 Cloud Deployment Automation
 Product Provision Automation
@@ -57,6 +57,7 @@ Audit Compliance
 Incident Management
 Change Management
 Service Health Page
+Cloud DevOps
 
 ## **Customer Support**
 

Cloud DevOps/Uptime 99.9% vs 99.99%.md

@@ -0,0 +1,280 @@
+#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管理、性能评估、架构设计