定义
SLA（Service Level Agreement）即服务等级协议，约定平台可用性、响应时间、MTTR 等服务质量指标。设备管理平台通过监控、告警、Work Order 等能力保障 SLA 达成。
典型指标与监控
SLA 常见指标包括：平台可用性（如 99.9%）、API 响应时间（P95/P99）、设备连接成功率、OTA 升级成功率、告警响应时间、MTTR 平均修复时间等。设备管理平台通过 Device Monitoring 设备监控、NOC 运营中心大屏实时跟踪 SLA 达成情况；未达标时触发告警并驱动 Work Order 工单处理。SLA 指标通常按月度或季度统计，作为服务计费与赔偿依据。
与 DMP 的保障机制
平台通过多可用区部署、负载均衡、数据库主从、消息队列冗余等保障高可用；通过 Maintenance Window 维护窗口管理计划内停机；通过告警升级、值班轮换、自动化运维缩短故障恢复时间。SLA 承诺需与客户协商确定，不同服务等级对应不同价格与保障级别；企业级客户可要求定制化 SLA 及专属支持。
应用场景
适用于 SaaS 设备管理平台与客户的合同约定、内部运维团队的 KPI 考核、云服务商的可用性承诺。明确 SLA 可提升客户信任，驱动平台持续优化稳定性与响应能力。
协议里写的是可度量的服务项
服务等级协议约束的是双方事先同意测量的项目，不是一句“保证稳定”。每一项都要写明指标定义、统计周期、排除项和未达成时的处理方式。接口时延要说明是从接入层收到请求到发出响应，还是包含了调用方网络；要说明取哪一个分位，而不是只写“平均很快”。故障响应要说明从哪一个事件开始计时：监控发现、客户报障，还是工单被接单。计时起点不同，同一起事件会得到两个时长。
设备侧的业务指标和平台侧的服务指标应分成不同条款。平台能承诺的是接入、存储、接口和通知链路；单台设备的传感器是否漂移、现场电源是否稳定，不属于平台条款，除非合同明确把现场巡检也算进服务。条款里引用的数字必须能从报表分析的同一口径复现。无法复现的承诺，月底对账时只能靠口头解释。
计划内停机是否计入可用性
可用性是否扣除计划内停机，必须写在协议里，不能到统计时再选择更有利的算法。若扣除，就要事先公布窗口、影响的功能和通知方式；窗口内的失败不计入，窗口外的任何中断都计入，包括超时未结束的维护。若不扣除，则维护窗口只是降低影响的安排，中断仍然进入统计。两种算法不能在同一个月里切换。
多区域部署时还要写明按区域分别统计还是按全局统计。一个区域中断而其他区域可用，全局比例可能仍好看，但该区域的客户已经无法使用。按客户或按区域单列，才能对应到真正受影响的范围。部分接口可用、管理面不可用时，要约定这算不算中断：如果客户无法登录完成协议中的操作，通常应视为该功能不可用，而不是因为数据面还在就整月记为正常。
把设备离线率算进平台可用性
设备离线多数发生在现场链路、供电或设备自身。把它直接减进平台可用性，会使平台为不可控的现场因素承担责任；反过来，平台接入层故障导致大批设备同时掉线时，若只看单台离线、不看是否集中在接入故障窗口，又会漏掉真正的平台事件。正确的分法是：先标记平台组件的故障窗口，窗口内的批量断连计入平台条款；窗口之外的单台断连进入设备运维指标。
通知延迟也不能用“后来补发了”抹掉。协议若约定告警在时限内送达，补发成功只说明最终到达，不说明按时。统计应保留首次尝试时间和成功时间。把未按时的记录从分母删除，比率会被抬高。与外部系统的对接若在协议范围内，对方拒收要单独分类，不能算成平台未发送，也不能算成平台已按时完成。争议月份以原始计数和口径说明为准，不以截图上的汇总百分比为准。需要抽查时走接口导出明细，而不是只看大屏上的一个颜色。
月度对账前把原始事件导出冻结，冻结之后的补录不改写已经用于协议计算的那一版，只记入下一期或记入调整项。调整项单独列出原因，例如补报的中断、从统计中剔除的计划维护。没有冻结版本时，谁最后刷新大屏，谁就决定了这个月的结果。客户可见的报告与内部报告使用同一冻结版本，内部可以附加注释，但不能换成另一个分子。争议处理只讨论冻结版本里的事件是否符合条款，不临时更换统计脚本。