签IT外包合同，那个叫SLA的东西到底该写点啥？

说真的，每次谈到IT外包合同，最让人头秃的往往不是价格，而是那个叫“服务等级协议”（Service Level Agreement，简称SLA）的玩意儿。它就像一份婚姻保证书，只不过对象是冷冰冰的服务器和一群不知道长啥样的运维工程师。很多人在签合同的时候，销售说啥就是啥，密密麻麻的条款看也不看，等到服务器宕机了、数据丢了，才发现自己手里那份SLA就是一张废纸。

作为一个在IT圈里摸爬滚打多年的老油条，我见过太多因为SLA没写好而扯皮的案例。今天咱们不整那些虚头巴脑的理论，就用大白话聊聊，一份靠谱的IT外包SLA，到底应该包含哪些硬核指标。这不仅仅是给外包公司看的，更是给咱们自己买的一份“保险”。

一、 先把“地基”打牢：可用性与响应时间

任何服务，最基础的诉求就是“你得在”和“你得理我”。这对应了SLA里最核心的两个指标：可用性和响应时间。

1. 系统可用性 (Availability)

这是最最最基本的，也是最容易玩文字游戏的地方。

别光听他们拍胸脯说“99.99%的可用性”。你得问清楚，这个“可用”是怎么定义的？是只要服务器通着电就算可用，还是你的网站能正常打开才算可用？是工作时间算，还是7x24小时都算？

通常，可用性是按“分钟”来计算的。我们来算笔账：

• 99% 可用性：一年大概有87.6小时（约3.65天）是不可用的。对于一个稍微重要点的业务，这简直没法忍。
• 99.9% 可用性（也就是所谓的“三个九”）：一年不可用时间降到8.76小时。这算是及格线。
• 99.99%（四个九）：一年不可用时间只有52.6分钟。这通常被认为是高可用的标准。
• 99.999%（五个九）：一年不可用时间只有5.26分钟。这种通常是金融级或者核心基础设施的级别，成本极高。

避坑指南：一定要在SLA里明确“不可用”的定义。比如，是系统完全瘫痪才算，还是性能下降到某个阈值（比如响应时间超过10秒）也算？另外，计划内的维护（比如系统升级）通常不计入不可用时间，但这个维护窗口必须提前通知，而且不能太频繁。

2. 响应时间 (Response Time)

光系统开着还不行，得快。没人愿意等一个转个不停的圈圈。

响应时间不能笼统地写“要快”。必须量化。通常我们会关注几个点：

• 平均响应时间：在特定时间段内（比如一小时）的平均值。
• 峰值响应时间：在业务高峰期（比如双十一抢购）的最慢响应时间。
• 错误率：在所有请求中，返回错误（比如500错误）的比例。

举个例子，你可以要求：“在95%的业务时间内，核心页面的平均加载时间必须小于2秒；在任何情况下，单次请求的响应时间不得超过5秒，否则计入服务故障。”

这里有个细节，测试点的选择很重要。你是只测服务器的吐出速度，还是包括了网络传输、数据库查询、前端渲染的完整链路？我的建议是，尽可能模拟真实用户的访问路径来定义这个指标。

二、 事儿来了怎么办：故障处理流程

系统永远不出问题是不可能的，关键在于出了问题怎么办。这部分是SLA的灵魂，也是最能体现外包公司专业度的地方。

1. 故障分级 (Incident Priority)

不能一出事就鸡飞狗跳地把所有工程师都叫起来。得把故障分个三六九等。

优先级	定义	场景举例
P1 - 紧急	核心业务完全中断，大量用户受影响，造成重大经济损失或声誉损害。	整个网站打不开，支付功能瘫痪。
P2 - 高	核心业务功能严重受损，但未完全中断，或非核心业务完全中断。	用户能登录，但无法下单；或者后台管理系统挂了。
P3 - 中	业务功能受影响，但有替代方案，或影响范围较小。	某个非核心的报表导出失败。
P4 - 低	轻微问题，不影响业务主流程。	页面上有个错别字，或者UI显示有点小瑕疵。

每一级故障，都应该有对应的响应和处理时限。这不仅仅是技术问题，更是管理问题。

2. 响应时间与解决时间 (Response Time & Resolution Time)

这部分是SLA里最硬的数字，也是最容易产生纠纷的地方。必须白纸黑字写清楚。

这里要区分两个概念：响应时间和解决时间。

• 响应时间 (Response Time)：从你报障，到外包公司确认收到并开始处理的时间。比如，P1级故障，要求15分钟内电话响应，30分钟内给出初步分析。
• 解决时间 (Resolution Time)：从报障到问题彻底解决的时间。比如，P1级故障，要求4小时内恢复服务，24小时内给出根本原因分析报告。

一个真实的坑：我曾经见过一份合同，只写了“P1故障4小时内解决”。结果有一次数据库挂了，外包工程师花了3小时59分钟把服务重启了，然后就说“解决了”。但实际上数据一致性已经出了问题，业务逻辑是乱的。所以，SLA里不仅要写解决时间，还要写“恢复服务”的标准是什么。是服务进程起来就算，还是必须经过业务验证流程才算？

3. 根本原因分析 (Root Cause Analysis, RCA)

问题解决了就完了吗？不。对于P1和P2级别的故障，外包方必须在问题解决后的一定时间内（比如48小时），提供一份详细的RCA报告。

这份报告至少得包含：

• 故障发生的直接原因。
• 故障的详细时间线（Timeline）。
• 为了防止此类问题再次发生，他们具体做了什么改进（比如修改了代码、增加了监控、优化了流程）。

如果一个外包公司只会救火，从不写RCA，那他们就是在不断地埋雷，迟早有一天会把你炸得体无完肤。

三、 钱的事儿：惩罚与赔偿

谈钱伤感情，但不谈钱，感情和生意都得完蛋。SLA里必须有违约的代价，这叫“服务信用金”或“罚则”。

1. 服务信用金 (Service Credit)

这是最常用的惩罚方式。它不是直接赔你钱，而是减免你下个月的服务费。

比如，合同里可以这样写：

• 如果当月可用性未达到99.9%，但高于99.5%，减免当月服务费的5%。
• 如果当月可用性低于99.5%，但高于99%，减免当月服务费的10%。
• 如果当月可用性低于99%，减免当月服务费的25%。

注意：这个惩罚应该是有上限的，比如单月赔偿不超过总服务费的50%。毕竟，服务商也要生存，过犹不及。

2. 免责条款 (Exclusions)

这一点对双方都公平。有些情况下的故障，确实不能全怪外包公司。比如：

• 你（客户方）自己乱操作导致的。
• 你的代码本身有Bug，不是运维环境的问题。
• 不可抗力，比如地震、洪水、战争（虽然概率小，但得写）。
• 骨干网运营商（比如电信、联通）的网络中断。

把这些写清楚，可以避免很多无谓的争吵。

四、 看不见的功夫：日常运维与变更管理

除了救火，日常的“保健”工作同样重要。这部分指标往往被忽略，但决定了系统的长期健康度。

1. 日常巡检报告

服务商是不是真的在干活？不能只靠感觉。要求他们提供日报或周报。报告里应该包含：

• CPU、内存、磁盘使用率。
• 关键服务的运行状态。
• 安全补丁的更新情况。
• 备份执行状态。

别小看这个报告，它能让你对系统的健康状况心里有数，也能在出问题时快速定位时间点。

2. 变更管理 (Change Management)

系统环境的任何变动，都可能是风险。所以，必须有严格的变更流程。

SLA里应该规定：

• 所有变更（比如升级软件、修改配置）必须提前提交变更申请（Change Request）。
• 变更必须有回滚方案。
• 高风险变更必须在业务低峰期（比如凌晨）操作。
• 变更完成后必须有验证测试。

如果服务商随随便便就登录服务器改个配置，第二天你的系统就崩了，你连是谁干的都不知道。

3. 备份与恢复 (Backup & Recovery)

这是数据安全的最后一道防线。这里的指标必须非常具体：

• 备份频率：每天增量，每周全量？
• 备份保留时间：保留最近7天的，还是30天的？
• 恢复测试：光备份不测试，等于没备份。必须要求服务商定期（比如每季度）做一次恢复演练，并提供演练报告。
• 恢复时间目标 (RTO)：从灾难发生到系统恢复运行，允许的最长时间。比如4小时。
• 恢复点目标 (RPO)：灾难发生后，允许丢失多少数据。比如最近15分钟的数据。

我见过最离谱的，是某公司把备份策略写得天花乱坠，结果真出事了才发现，备份脚本早就失效了，根本没备份上。所以，恢复测试报告是必须的硬性要求。

五、 人和安全：那些软性但致命的指标

技术指标说完了，还有一些关于“人”和“安全”的指标，同样重要。

1. 人员稳定性与资质

你肯定不希望你的系统由一群刚毕业的实习生练手。SLA里可以要求：

• 核心运维人员的资质（比如有多少年的经验，有什么认证）。
• 服务团队的稳定性，比如核心接口人不能频繁更换（建议合同期内更换不超过1次）。
• 7x24小时的值班电话，必须是真人接听，不能是语音信箱。

2. 安全性指标

数据泄露可不是闹着玩的。这部分指标包括：

• 漏洞扫描：要求服务商定期（每月或每季度）做系统漏洞扫描，并提供报告，对高危漏洞限期修复。
• 访问控制：所有对生产环境的访问都必须有记录（谁、在什么时间、做了什么操作）。这个操作日志必须对你开放审计权限。
• 渗透测试：对于重要系统，可以要求每年至少进行一次第三方渗透测试。

3. 服务报告与会议

沟通是合作的润滑剂。SLA里要约定好定期的沟通机制：

• 月度服务报告：总结上个月的服务情况，包括SLA达成率、故障统计、优化建议等。
• 季度/年度回顾会议：双方坐下来复盘，讨论服务改进计划。

别觉得这是形式主义。很多时候，很多潜在的风险，就是在这些定期的沟通中被发现的。

六、 总结一下（虽然说好不总结，但还是忍不住唠叨两句）

写到这里，你会发现，一份好的SLA，其实是在用数据和流程来管理风险和预期。它不是为了惩罚谁，而是为了让双方都清楚自己的底线和责任。

在实际谈判中，你可能没法把上面提到的所有指标都谈到最严格，因为那意味着极高的成本。你需要根据你的业务重要性、预算，去跟外包公司博弈，找到一个平衡点。

记住，SLA不是签完字就锁进抽屉里的文件。它是你后续服务管理的尺子。你要拿着这把尺子，去量他们的服务，去要求他们的改进。如果他们做不到，合同里写的那些服务信用金，就是你应得的补偿。

最后，别忘了，再完美的SLA也替代不了人的责任心。找一个靠谱的、沟通顺畅的合作伙伴，有时候比合同里多几个“九”的可用性更重要。但话说回来，如果连合同里的“九”都保证不了，那责任心这东西，也就无从谈起了。所以，还是擦亮眼睛，一条一条地抠吧。

企业高端人才招聘