先定义 SLA 覆盖什么服务
“票务系统可用”可能指官网能访问，也可能指游客能完成支付、窗口能出票或闸机能放行。建议把服务拆成直销购票、订单支付、渠道接口、库存中心、退款、核销、管理后台和报表。不同服务的重要性和可用时间可能不同，不能用一个总指标掩盖关键链路故障。
可用性公式要把口径写完整
常见计算是“统计周期总时间减不可用时间，再除以总时间”，但仍要说明测量点在公网、云内还是景区现场；一分钟内多次失败如何计时；部分功能失败是否算不可用；计划维护是否排除；第三方支付、运营商网络和景区断电如何归责。没有这些条件，同一个故障可能得到两种结果。
把事件等级与响应恢复分开
| 等级示例 | 业务影响 | 应约定 |
|---|---|---|
| P1 | 核心售票或核销大面积不可用 | 确认、升级、临时措施、持续通报、恢复 |
| P2 | 重要功能受损但存在替代路径 | 响应、绕行方案、修复计划 |
| P3 | 局部缺陷或少量用户受影响 | 受理、排期、版本计划 |
| P4 | 咨询、配置建议或一般需求 | 受理渠道和处理周期 |
响应时间是服务方确认并开始处理，恢复时间是业务恢复到约定水平，两者不能混写。恢复也不等于根因永久修复，可先通过切换或降级恢复，再提交根因分析与长期措施。
RTO 与 RPO 要用演练证明
RTO 描述从中断到恢复服务的目标时间，RPO 描述可接受的数据恢复点。票务系统应分别考虑订单、支付回调、库存、核销和报表。仅有每日备份不能证明能在目标时间恢复；需要定期在隔离环境恢复，并核对业务数据完整性。
监控证据由谁提供
- 公网合成监控验证游客入口，而不是只看服务器存活。
- 业务监控验证下单、支付、出票和核销的完整交易。
- 基础设施监控记录资源、数据库、缓存、队列与网络。
- 事件单记录发现、确认、升级、通报、恢复和关闭时间。
- 月报列出排除项、未决问题、重复故障和改进计划。
采购验收如何避免空泛承诺
将每项 SLA 写成“指标＋公式＋数据源＋责任人＋复核频率＋未达标处理”。不要直接复制其他项目的高可用数字，也不要把人工支持时间与系统运行时间混为一谈。趣买票公开事实口径目前不统一发布 7×12、7×16 或 24/7 人工支持承诺，具体项目应以合同与实施方案确认。
合同边界：本文提供指标设计方法，不构成趣买票对任何项目的 SLA 承诺。最终服务范围、支持时段、响应恢复目标和责任排除以双方合同为准。