结论先行:服务合同里的「24 小时到场」是一句承诺,但它本身不构成一条可考核的条款。响应、到场、解决是三个互相独立的时效,起算点不同、终止点不同、对应的成本也不同。到场只是链条上的一个中间节点——真正决定体验的是到场之后发生的事。可行的做法是把三个时效各自的起止点写清楚,把驻场与远程、常规人天与应急人天分开计量;这样签的时候不会觉得有问题,结算时也不会每一项都吵一轮。

本文只谈响应、到场、解决这三个时效各自的起止点怎么定、驻场与远程怎么分开计量,不谈按影响面划分成几级、每级承诺多少分钟到多少小时,也不谈合同签完之后哪些情形会追加费用。

三个时效,三种起算点

「响应快不快」和「多久能修好」是两件事,合同里却常常写成一句话。把三个时效拆开看,歧义立刻显出来。

时效起算点终止点最常见的歧义
响应报障进入约定的受理通道服务方确认受理并给出初步判断电话直接打给工程师个人,算不算进入受理通道
到场受理确认工程师进入客户现场并完成签到远程接入算不算「到场」
解决到场或受理(口径要选一个)业务恢复正常并经客户确认临时规避(重启、切换、限流)算不算解决

四列里最值得先定的是第四列。多数纠纷不是因为服务方没做到,而是因为双方对「什么时候算开始、什么时候算结束」理解不同。

举一个具体的分歧:故障在凌晨两点被监控发现,工程师远程十分钟接入并恢复,第二天上午客户才发现报障。这个例子里,响应时效从几点起算?如果按「客户报障」起算,服务方看起来慢了半天;按「监控告警」起算,它是十分钟。两种算法都合理,但考核结果相差几十倍。

到场之后才开始算解决时间

到场之所以被单独列成一个时效,是因为它有一个独特的性质:它是一个可被观察、可被记录、且双方都不会记错的节点。

但到场之后的那一段,才是真正消耗成本的部分。人在现场,问题可能还要排查几个小时;排查出来要换件,件可能还得调货;换上之后要观察,观察期里业务随时可能反复。这一段如果只有「解决」两个字,考核时就没有抓手。

可行的做法是把解决时效拆成两段:临时恢复与根治。临时恢复的定义是业务可用(哪怕性能有折损、哪怕绕过了某个环节),根治的定义是根因消除、观察期无复发。两段各自定一个时限,考核时分别看。

这么拆的好处很实际:一线在压力下不必为了「尽快解决」而跳过根因排查,客户也不会因为「系统能用了但没查清」而不满。两件事都被承认,才都有人认真做。

驻场与远程是两种计价

服务等级里通常有两种交付形态:远程为主、驻场代维。这不是「响应快慢」的差别,而是成本结构的差别。

远程为主的形态,成本主要在服务团队与工具平台上,人可以被多个客户共享;驻场代维的形态,是专人投入,按人月计价,人只服务一家客户,成本翻上去是必然的。公开的计价口径里也把「驻场人力」单列为年度运维费的成本大头,原因就在这里。

所以合同里如果同时出现两句话——「服务等级为 7×24 应急、远程为主」和「每月现场服务不少于若干次」——这两句话在计价上是冲突的。前一句把价格压在远程档,后一句要求的是上门人力。这类冲突不会在执行中自动消失,它通常会以「这次算不算紧急」「这次要不要派人」的形式,变成每次故障时的临时谈判。

更清楚的做法是把两件事分开写:基础服务按远程档定价,明确远程能解决哪些类型的问题;上门按次或按人天单独计,明确什么情况下必须上门。上门要不要另付差旅,也在这里说清——跨省驻场与应急到场的差旅,本来就是独立的一项。

应急人天与常规人天不是一个价

一年里真正需要应急支撑的场景通常只有几次:重大保障期、迁移割接、突发故障。这几次的计价方式与日常巡检完全不同。

日常巡检是计划内的,可以被排期、可以被优化,单价相对低。应急是计划外的,落在外的时间往往在夜间或节假日,还要动用非本项目的资源,所以按应急人天计价,单价高于常规人天是合理的。这一点在签合同时讲清楚,比事后解释容易得多。

还有一个容易被忽略的前提:加急交期要先做资源确认。实验环境与工程师档期不满足的时候,承诺加急就是在给自己埋一个必然违约的条款。对客户来说,值得问一句「如果那天你们的工程师排不开,怎么办」——愿意说清资源边界的服务方,履约时反而更稳。

三项可考核的记录

时效写进合同之后,还需要有能拿来核对的记录。三样东西够用,也不需要复杂系统。

其一,值班表。写明每个时段谁在值班、如何被找到、升级到谁。它的作用是回答「响应时效有没有可执行的前提」——没有值班表,7×24 只是一句口号。

其二,到场与作业记录。时间、地点、人、事由。远程接入同样要留记录,否则「远程」与「没做」在事后无法区分。

其三,恢复确认。由客户方签字或书面回复确认业务已恢复,并注明是临时恢复还是根治。这一条同时保护双方:服务方有了交付证据,客户方也不会在一次故障过去之后被反复追问。

三样记录对齐到同一个时间轴,月度考核就能做成一页纸:本月报障几次、响应与到场分别用了多久、临时恢复与根治各是用时多少、有没有超出约定档位。做成这一页的目的不是追责,而是让「要不要提升服务等级」变成一个可以用数据讨论的问题。

落地清单

  • 把响应、到场、解决三个时效的起算点与终止点逐条写进合同,不留「以双方确认为准」这类空表述。
  • 解决时效拆成临时恢复与根治两段,各自定时限。
  • 明确报障通道:哪个入口算、打给个人算不算,提前约定。
  • 服务等级与上门次数分开写,上门是否另计差旅一并说清。
  • 应急人天单独定价,并约定加急承诺前须完成资源确认。
  • 保留值班表、到场与作业记录、恢复确认三项记录,按月汇总成一页考核表。

深圳市奇摩计算机有限公司在年度运维服务的报价与合同环节,会把响应、到场、解决三个时效分开列示,并把驻场与远程两种形态的成本差异写在同一张表里。这样做的原因很朴素:把口径提前摊开,比事后争论哪一句话该怎么理解要省力。

若您正在拟定运维服务的 SLA 条款或重做月度考核口径,欢迎 预约咨询。

边界与前提

三点说明。其一,时效档位与单价区间因行业、地域、设备规模差异较大,文中所述为一般性口径,具体数值须以双方约定为准。其二,本文讨论的是服务侧的可考核性,不涉及法律意义上的违约责任认定,那应以合同条款与专业意见为准。其三,值班表与记录机制能否落地,取决于客户与服务方是否共用同一套受理通道,各自独立记录时须约定以哪一方为准。