物联网项目 SLA 怎么签？可用性、响应时间、赔付条款三条线

SLA（Service Level Agreement，服务等级协议）在物联网项目里经常写得很虚：「提供 7×24 小时技术支持，响应时间不超过 2 小时」。

这句话有三个漏洞：什么叫「响应」？2 小时是从什么时候开始算？没做到怎么赔？

这一篇把三条核心线讲清楚。

第一条线：可用性怎么定义

可用性的计算公式

可用性 = (总时间 - 不可用时间) ÷ 总时间 × 100%

关键在「不可用时间」怎么定义。常见定义方式：

• 系统无法登录：所有用户都无法访问
• 核心功能不可用：如数据无法上报、无法查看实时数据
• 性能严重下降：响应时间超过阈值（如 10 秒）

不同定义下的可用性差别巨大。只看第一条（完全无法登录），可用性可能 99.9%；把第三条也算上（响应慢），可能只有 98%。

建议：明确写出「不可用的判定标准」，最好列出具体场景。

99.5% 和 99.9% 的实际差别

• 99.9%：一年允许不可用 8.76 小时（每月 43 分钟）
• 99.5%：一年允许不可用 43.8 小时（每月 3.6 小时）
• 99.99%：一年允许不可用 52.6 分钟

99.9% 需要双机热备 + 自动故障切换。99.99% 需要多机房 + 异地容灾，成本高一个数量级。

物联网项目的合理承诺：

• 一般业务系统：99.5%
• 核心生产系统（如水务调度、交通信号）：99.9%
• 99.99% 只用于极少数关键系统，且成本极高

哪些情况可以免责

必须写清免责情形，否则所有故障都要乙方背：

• 计划内维护（提前 48 小时通知，每月不超过 4 小时）
• 不可抗力（自然灾害、疫情、政策管制）
• 甲方原因（擅自修改配置、断电、网络中断、未按约定提供环境）
• 第三方原因（运营商网络故障、云服务商故障）
• 设备自然老化（超出质保期的硬件故障）

「计划内维护」的时间是否计入不可用，双方常有争议。建议明确写「计划内维护不计入不可用时间，但每月不超过 X 小时」。

第二条线：响应时间和修复时间

两个概念完全不同

• 响应时间：从甲方报障到乙方确认并开始处理的时间
• 修复时间：从确认故障到故障恢复的时间

「响应 30 分钟」只意味着 30 分钟内有人回你，不代表 30 分钟修好。

很多合同只写响应时间，没写修复时间，结果故障拖了三天也没违约。

分级响应

按故障严重程度分级，不同级别不同时限：

• P1（致命）：系统整体不可用、数据丢失、安全事故。响应 15-30 分钟，修复 2-4 小时
• P2（严重）：核心功能不可用、性能严重下降。响应 30-60 分钟，修复 4-8 小时
• P3（一般）：非核心功能异常、个别设备故障。响应 2-4 小时，修复 24-48 小时
• P4（轻微）：界面问题、优化建议。响应 1 个工作日，修复下个版本

关键是「分级标准要客观」。不能由甲方随口定级（会把所有问题都定成 P1），也不能由乙方定级（会都定成 P3）。

建议：列出每一级的具体情形清单，双方确认。

服务时间

• 7×24：全年无休，成本最高
• 5×8：工作日 8 小时，非工作时间只接 P1
• 5×8 + 值班：工作时间全支持，非工作时间 P1 电话值班

物联网项目通常涉及生产运行，建议至少「5×8 + P1 值班」。

第三条线：赔付条款

按比例赔付

常见做法：可用性未达标，按未达标程度扣减服务费。

• 可用性 99.5%-99.0%：扣减当月服务费的 10%
• 99.0%-98.0%：扣减 30%
• 98.0%-95.0%：扣减 50%
• < 95.0%：扣减 100%，且甲方有权解除合同

赔付上限

必须设上限，否则一次大故障可能赔到破产。

常见上限：

• 年度服务费的 20%-100%
• 合同总额的 5%-20%

甲方希望上限高，乙方希望上限低。合理区间是「年度服务费的 30%-50%」。

间接损失免责

这一条极其重要。要明确写「乙方不承担因系统故障导致的间接损失、利润损失、商誉损失」。

如果不写，甲方可能主张「因为系统故障导致我损失了 500 万营收」，这个风险无法承受。

赔付的执行方式

• 直接从服务费中扣减（最容易执行）
• 以服务时长补偿（如故障 4 小时，延长服务 8 小时）
• 现金赔付（最难执行，容易扯皮）

建议用「服务费扣减」或「服务时长补偿」，执行成本低。

甲乙方博弈要点

甲方要争取的

• 可用性定义要严（把「性能严重下降」也计入不可用）
• 分级标准要客观（列清单，不由乙方定级）
• 修复时间要有承诺（不只响应时间）
• 赔付要可执行（直接扣款）
• 连续不达标可解约

乙方要守住的

• 免责条款要全（不可抗力、甲方原因、第三方原因）
• 赔付上限要设（年度服务费的 30%-50%）
• 间接损失免责（必须写）
• 计划内维护不计入不可用
• 甲方未按约定提供环境（电力、网络、机位）导致的问题不担责

三个容易埋雷的表述

雷一：「保证系统稳定运行」

「稳定」没有量化标准，出任何问题甲方都可以说「不稳定」。

改成：「系统可用性不低于 99.5%，按本协议第 X 条方式计算」。

雷二：「7×24 小时随叫随到」

「随叫随到」意味着 24 小时现场驻守，成本无法承受。

改成：「7×24 小时电话/远程支持，P1 故障 4 小时内到达现场（同城）」。

雷三：「因乙方原因造成的一切损失由乙方承担」

「一切损失」包含间接损失，风险无限。

改成：「因乙方原因造成的直接损失由乙方承担，赔偿总额不超过本合同总额的 X%。乙方不承担间接损失、利润损失、商誉损失」。

SLA 之外还要约定什么

• 服务报告：每月/每季度提供服务报告（可用性、故障统计、处理情况）
• 例会机制：每月一次服务例会，复盘问题
• 变更管理：系统变更要提前通知、要有回滚方案
• 知识转移：文档、培训、源码（如涉及）的交付
• 退出机制：合同终止时如何交接（数据导出、文档移交、过渡期支持）

「退出机制」经常被忽略。真到换供应商时，数据拿不出来、文档没有，会非常被动。

项目全周期的成本可以看 物联网项目运维成本，验收环节看 验收争议怎么处理。

最后一句

SLA 的价值不在于「写得多严」，在于「双方对标准有共识」。签得时候糊里糊涂，出问题时必然扯皮。所以宁可花两天把可用性定义、分级标准、赔付计算方式一条条对清楚，也不要套个模板签字。

正在签物联网项目 SLA 或运维合同，说一下项目类型、系统重要性和服务要求，可以帮你审一版条款。项目成本参考可以看 运维成本怎么算，整体交付流程看 项目分期方法。