ITR服务的SLA如何设定？这份指南让你少走弯路

第一次接触ITR（Incident to Resolution，故障到解决）服务的时候，很多人都会被一堆专业术语绕晕。什么响应时间、解决时间、可用性、MTTR……听起来挺唬人的，但其实弄清楚之后，发现也就是那么回事。今天就让我用最直白的话，把ITR服务的SLA设定这件事讲透。

之所以想聊这个话题，是因为见过太多企业稀里糊涂就签了SLA，后来发现服务条款和实际需求根本不匹配，要不就是承诺太多根本做不到，互相扯皮。与其事后后悔，不如在一开始就把规矩立清楚。这篇文章会从最基础的概念讲起，逐步深入到具体的设定方法，最后还会分享几个常见的坑，希望能给正在考虑这件事的朋友一些实用的参考。

先搞明白：ITR服务和SLA到底是什么关系？

在具体聊SLA怎么设定之前，我们有必要先把基本概念理清楚。要不然后面说再多也是空中楼阁。

ITR服务，简单来说，就是从发现问题到把问题解决掉这一整套流程的服务。它不仅仅是你报修之后有人来修这么简单，而是包含了问题识别、诊断、解决、验证、复盘这一整个闭环。想象一下，你公司打印机坏了，ITR服务好的供应商会怎么做？首先是快速响应告诉你他们收到了报修请求，然后判断是硬件问题还是配置问题，安排合适的人员来处理，修好之后还会确认你能正常用，甚至事后分析一下为什么会坏，能不能避免。

而SLA，就是在这个过程中立下的"规矩"。它规定了服务提供商应该在多长时间内做什么事情，做不到会有什么后果。你可以把它理解成一份服务合同，只不过这份合同更侧重于量化的指标，而非模糊的承诺。

这里有个很容易混淆的概念需要澄清：SLA不是用来"刁难"服务商的，而是用来对齐双方预期的。一个好的SLA，既要让服务商有清晰的目标可循，也要让客户明白自己能获得什么样的保障。脱离这个初衷去追求"最严格"的SLA，往往适得其反——服务商可能因为做不到而频繁违约，或者为了做到而成本飙升，最终还是客户买单。

SLA的核心要素，一个一个掰开看

了解了基本概念，接下来我们进入正题：ITR服务的SLA到底应该包含哪些内容？哪些指标是必须写的，哪些可以灵活处理？让我逐个来分析。

响应时间：第一道门槛

响应时间指的是从你提交服务请求到服务商确认收到并开始处理的这段时间。这是SLA里最基础也是最直观的指标。很多人在设定这个指标的时候容易犯两个错误：要么定得太宽松，失去了约束意义；要么定得太严，导致服务商疲于应付，反而影响服务质量。

合理的响应时间应该根据问题的紧急程度来分级处理。举个例子，核心业务系统完全宕机，这种P0级别的问题，响应时间可能需要控制在15分钟以内；而普通员工电脑软件安装这种问题，4小时内响应也是可以接受的。分级的目的，是让有限的服务资源优先处理真正紧急的问题。

在设定响应时间的时候，还要考虑服务提供商的工作时间。如果合同约定的是7×24小时响应，那价格肯定比5×8小时要高。如果你的业务主要在工作时间，那完全没必要为非工作时间的即时响应付费。关键是想清楚自己的真实需求，而不是盲目追求"全天候"。

解决时间：真正考验服务能力的地方

如果说响应时间看的是服务态度，那解决时间看的就是真本事了。解决时间是从问题确认到彻底解决并通过验证的时间间隔。这个指标对服务商的技术能力和流程成熟度要求很高，也是SLA谈判中最容易扯皮的地方。

解决时间的设定同样需要分级。不同级别的问题，解决时间要求应该不一样：

这个分级标准不是死的，需要根据你的业务实际情况调整。比如对于电商公司来说，"双十一"期间任何影响下单的问题都应该按P0处理；而对于内部办公系统，某些非关键流程的问题适当放宽要求也是合理的。

另外，在谈解决时间的时候，一定要明确"解决"的定义是什么。是不是只要问题表面上好了就行，还是需要通过测试验证？恢复数据和服务，哪个先哪个后？这些细节不写清楚，日后很容易产生分歧。

可用性： uptime不是万能的，但没有是万万不能的

可用性指标通常用"几个9"来衡量，比如99.9%或者99.99%。这个指标反映的是系统在正常运行时间内真正可用的比例。计算公式大概是：可用性 = （总时间 - 故障时间）/ 总时间 × 100%。

但这里有个坑很多人不知道：计划内的维护时间算不算故障时间？很多SLA里会明确约定，计划维护不计入可用性统计，前提是服务商提前通知并获得客户同意。所以如果你看到一份99.9%可用性的SLA，一定要问一下：这99.9%是怎么算的？

从实际经验来看，对于大多数企业来说，99.9%的可用性意味着全年 downtime 约为8.76小时，已经算是比较严格的承诺了。如果追求99.99%，downtime要控制在52分钟左右，这时候对服务商的技术能力和冗余设计要求就非常高了。

我的建议是：可用性指标要匹配你的业务价值。如果业务中断一个小时损失十万，那99.9%可能不够；如果只是内部非核心系统，适当降低要求节省成本也是明智的选择。没必要为了一个好看的数字多花冤枉钱。

服务窗口与联系方式：别让求助变成猜谜

服务窗口指的是服务商可以提供服务的时间段。这个看似简单，但很多人签合同的时候根本不看，后面出了问题才发现对方下班了联系方式都找不到。

常见的配置有5×8（工作日工作时间）、7×24（每天24小时）、7×12（每天12小时）等。与之配套的，是不同渠道的响应承诺：电话是不是24小时有人接？工单系统是不是随时可以提交？紧急情况下能不能直接联系到技术负责人？

这里我想分享一个小技巧：在SLA里最好明确约定非工作时间的紧急联络流程。比如，是不是有值班电话？响几声之内必须接？超过响应时间怎么办？这些细节平时用不上，关键时刻能救命。

定制SLA：没有标准答案，只有最适合的答案

前面讲的都是SLA的基本要素，但真正考验人的是如何把这些要素组合成一份适合自己企业的SLA。以为照搬别人的模板就行？那你很可能掉进坑里。

第一步：梳理你的业务需求。

在设定SLA之前，先回答几个问题：哪些系统最不能出问题？出问题后业务能容忍多长时间中断？不同部门的问题优先级如何排序？预期投入多少服务成本？

以薄云服务的经验来看，很多企业在这一步会陷入"什么都想要"的陷阱。既想要7×24小时响应，又想要两小时解决所有问题，还想把成本控制在最低水平。这三个目标本身就是矛盾的，必须有所取舍。

第二步：评估服务商的实际能力。

了解自己的需求后，还要客观评估候选服务商的交付能力。可以通过几个渠道来了解：查看服务商过往的服务案例和客户评价；要求服务商提供类似规模客户的服务报告；在技术交流中观察服务商对问题的响应速度和专业程度。

一个负责任的服务商，会在自己做不到的事情上坦诚告诉你，而不是为了签单什么都答应。如果一个服务商对你的需求来者不拒，你反而要警惕了。

第三步：明确责任边界。

SLA里最容易被忽视但最容易扯皮的就是责任边界。比如：客户端环境的配置问题算谁的？服务商处理问题需要客户提供的信息，客户延迟提供导致超时怎么算？因为服务商建议不当导致的问题，责任怎么划分？

这些边界问题，一百个场景就有一百种情况，很难全部写进SLA。我的建议是，在SLA里明确约定"变更管理流程"和"争议解决机制"。当出现边界模糊的情况时，双方有章可循，不至于吵来吵去没结论。

监控与持续优化：SLA不是签完就完事了

见过太多企业，SLA签完之后就束之高阁，出了问题才翻出来看看。这样用SLA，效果大打折扣。

建立定期review机制。

建议至少每个月review一次SLA执行情况。看看哪些指标达标了，哪些没达标，原因是什么？是服务商能力问题，还是我方需求变更，或者当初设定就不合理？通过持续的review，你可以逐步校准SLA的预期，让它越来越贴合实际。

数据是最好的谈判依据。

如果你想在下一年续约时调整SLA条款，数据是最有力的支撑。记录下每次问题的响应时间、解决时间、影响范围、根本原因分析，这些数据不仅能帮你评估服务商的表现，也能帮你内部做IT投资决策。

保持灵活性。

业务在变，技术在变，SLA也不能一成不变。建议在SLA里约定一个周期性的review机制，比如每半年可以双方协商调整条款。这样既能应对业务变化，也能给服务商合理的预期。

几个常见误区，别再踩了

聊了这么多，最后我想分享几个在SLA设定中常见的误区，希望能帮你避坑。

误区一：SLA越严格越好。

前面提过，过于严格的SLA要么让服务商难以承受而频繁违约，要么让成本飙升。关键指标可以严格，但分级要合理，边缘指标适当放宽，双方都轻松。

误区二：只关注数字，不关注质量。

有些客户把SLA盯得很紧，响应时间59分钟违约1分钟都要追究。但却忽视了服务商解决问题的质量——表面上按时解决了，但问题过两天又复发，或者解决过程造成了新的问题。这种"按时按质"的追求，反而让服务商疲于应付数字，忽视了真正重要的服务质量。

误区三：签了SLA就万事大吉。

SLA是合同，是保障，但更应该是双方协作的起点而非终点。好的客户会和服务商保持定期沟通，分享业务变化和技术规划，让服务商能够主动服务而不是被动响应。那些把SLA当"罚单"用的客户，往往得不到最好的服务。

写在最后

SLA设定这件事，说到底是一场关于预期的对话。你要什么，我能给什么，双方达成共识，白纸黑字写下来。仅此而已。

但正因为看起来简单，反而容易掉以轻心。希望这篇文章能帮你把这件事想得更清楚一些。无论是正在选择服务商，还是正在拟定合同条款，都可以拿出来对照看看，有没有漏掉什么重要信息。

如果你在这个过程中有任何疑问，或者想分享自己的经验教训，欢迎交流。好的实践，都是在实践中慢慢摸索出来的。