你有没有遇到过这种情况？公司买的云存储服务说“全年无休”，结果半夜系统崩溃，客服电话打不通，工单响应要等八小时。嘴上说着高可用，实际体验却像拼运气。问题出在哪儿？很可能就是服务级别协议（SLA）里的服务时间没写明白。
SLA 不是营销口号，是白纸黑字的承诺
很多用户把 SLA 当成宣传材料看，其实它应该是双方认可的技术契约。尤其是媒体行业，做视频直播、在线点播、内容分发，一旦服务中断，损失的不只是流量，还有观众信任。这时候，SLA 里的“服务时间”就成了关键指标。
比如一家视频平台和 CDN 服务商签协议，如果 SLA 写的是“每月可用性不低于99.9%”，听起来很美，但换算下来，相当于每个月允许停机约43分钟。要是这43分钟正好撞上黄金时段直播，那可就麻烦了。
服务时间怎么算？不是“开机就算”
真正的服务时间要看具体定义。有的厂商把“能 ping 通”就算服务正常，但实际上接口响应超时、上传卡顿都不算中断。这种偷换概念的做法得警惕。
更合理的做法是把服务时间细化到核心功能。比如：
- 视频上传接口响应时间小于2秒
- 点播请求95%在1秒内返回
- 直播推流中断不超过10秒
这些才真正影响用户体验。签协议前，一定要确认服务时间的测量方式是谁来定、怎么定。
别忽略“排除时段”这个坑
有些 SLA 明明写着“99.95% 可用”，但脚注里悄悄加上一句：“计划内维护、不可抗力不计入”。结果一查，每月固定凌晨2点到4点做升级，节假日还可能临时维护。等于变相缩短了实际服务时间。
建议在合同里明确：计划维护需提前72小时通知，且每年累计不超过8小时。超出部分应按比例折算赔偿。
举个真实例子
某地方电视台用第三方媒资管理系统，合同约定服务时间为工作日9:00-18:00。结果有次周末编辑需要紧急调片，系统无法访问，联系技术支持被告知“非服务时间，周一处理”。最后只能手动翻备份硬盘，耽误了新闻播出。
后来他们重新谈判，把服务时间改成7×24，哪怕响应慢点，至少有人接电话。这种调整看似成本上升，实则避免了更大风险。
技术对接时也得留一手
现在很多媒体软件通过 API 对接，SLA 里最好加上“接口调用成功率”条款。比如：
GET /api/v1/videos/{id} \nHTTP/1.1 200 OK \n{\n "status": "success", \n "data": { ... } \n}规定这类请求在服务时间内失败率不得超过0.5%。否则按次数阶梯计罚。这样一来，服务商才真有动力保障稳定性。
说到底，服务时间不是越长越好，而是要跟业务节奏对得上。搞清楚自己最怕什么场景出问题，再拿这个去谈 SLA，才能把纸面承诺变成实际保障。