事件分级定义
| 等级 | 判定标准 | 首次响应 | 状态更新频率 | 目标解决 |
|---|---|---|---|---|
| P1 紧急 | 生产业务完全不可用，或核心功能大面积失效，无临时方案 | 优先响应 | 持续同步 | 尽快恢复 |
| P2 高 | 生产业务部分受损，性能显著劣化，有临时方案 | 快速响应 | 定期同步 | 1 个工作日 |
| P3 中 | 非核心功能异常，不影响主流程 | 工作时间响应 | 每工作日 | 3 个工作日 |
| P4 低 | 咨询、配置变更请求、优化建议 | 工作时间响应 | 按需 | 排期处理 |
P1 与 P2 为 7×24 响应，P3 与 P4 在工作时间（工作日 09:00-18:30）响应。
关于可用性目标
具体的可用性目标与责任范围，需要结合你的架构现状与业务重要程度来定，在服务协议里逐条写清楚。我们不在网站上给统一数字，因为单可用区部署和多可用区部署能达到的水平差别很大，笼统承诺一个百分比对双方都没意义。以下情形通常不计入可用性统计：客户自行变更导致的故障、计划内维护窗口、AWS 平台级故障（按 AWS 官方 SLA 处理）、不可抗力。
计算方式说明
- 可用性 =（月度总分钟数 − 不可用分钟数）÷ 月度总分钟数 × 100%
- 不可用时间从告警触发或客户报障（取更早者）开始计算，到服务恢复确认为止
- 计划内维护提前 7 天书面通知，且安排在业务低谷，不计入不可用时间
- 补偿以服务费抵扣形式在次月账单结算，需在事件发生后 30 日内提出
- 月度可用性报告由我们主动出具，含每次事件的时间线与根因
SLA 常见问题
如果是 AWS 平台自身故障导致的不可用，算你们的责任吗？
不算，但我们负责协调 AWS 支持、提供故障期间的应急处置，并协助你申请 AWS 官方 SLA 的补偿。如果是因为架构设计缺陷（比如单可用区部署）放大了平台故障的影响，那属于我们的设计责任。
客户自己改了配置导致故障，怎么算？
不计入 SLA 统计，但我们依然按 P1 流程响应并协助恢复。托管服务里我们建议关键变更走我们的变更流程，避免这类情况。
响应时间从什么时候开始算？
从监控告警触发，或你通过任一渠道（电话、企微群、工单）报障，以更早的时间点为起算点。我们的值守是主动监控，多数情况下告警会早于你发现。