如果你正在把代理网络投入生产管道，采购或平台工程团队里迟早会有人问 SLA 是多少。这是个正确的问题，但你得到的答案通常没有看上去那么有信息量，因为像 99.9% 这样的数字，在你不知道它是相对什么衡量、在多长的时间窗口内、以及未达标时会发生什么之前，是没有意义的。
这个领域还有一个特定的陷阱。代理 SLA 承诺的是网关可达，它不承诺你采集的目标网站会放行你的请求，这是两件截然不同的事。理解这个边界，几乎就是签约前你需要知道的全部内容。
正常运行时间数字究竟意味着什么
每个百分比背后都有三个变量，如果一个供应商只给你百分比数字，那他给你的其实是最没有用的部分。
第一个是测量窗口。按月计算的 99.9% SLA 允许每月大约 43 分钟的宕机时间。同样的 99.9% 如果按年计算，则允许大约 8 小时 45 分钟，而且这些时间可以是连续的。按月计算明显更严格，而报出年度数字的供应商，实际上是用相同的措辞承诺了更弱的保障。
第二个是宕机的定义。是当网关拒绝连接时才算服务中断，还是当它在技术上仍在响应、但错误率飙升，或者延迟已经差到没法用的地步时也算？许多 SLA 只计算彻底的不可用，这意味着一段时间内每个请求都返回错误、但端点仍在接受连接的情况，可能根本不会被记为宕机。
第三个是谁来测量。如果供应商是唯一的信息来源，且不公开任何独立记录，那这个数字就是自我报告的。一个带有事件历史记录的公开状态页面，才是可以核实的东西。
最重要的区别：网关正常运行时间不等于成功率
这是让团队栽跟头的地方，值得直说清楚。
正常运行时间 SLA 覆盖的是供应商的基础设施：网关接受你的连接、对你进行认证、并路由你的请求。这是他们能控制的部分，也是他们所承诺的部分。
它不覆盖的是目标网站是否接受该请求。如果一个网站屏蔽了出口地址、返回验证挑战页面、或者返回一个空结果，这不算宕机。代理完成了它的工作，但你的采集依然失败了。没有任何代理供应商能对第三方网站的成功率做出承诺，因为决定权在网站那边，它们会在没有通知的情况下改变防御机制，同一个 IP 池周一还能通过某个目标的检测，周五就可能受阻。任何声称能保证对任意目标的成功率的供应商，承诺的都是他们控制不了的东西。
所以对采购而言，实际的结论是：SLA 保护你免受供应商自身故障的影响，而你自己的监控保护你免受其他一切影响。你两者都需要，把它们混为一谈会导致团队在合同上受到保护，但在运营上却处于盲区。这正是监控你的管道的意义所在，即按目标和地区衡量经过验证的成功率，而不是假设 SLA 已经覆盖了这一点；这也是为什么检测被屏蔽或伪造的内容很重要：一个返回 200 状态码的验证挑战页面，既符合 SLA 又同时是一次数据失败。
服务信用额度，以及它们真正的价值
当未达到 SLA 标准时，标准的补救措施是服务信用额度，通常是月费的某个百分比，按未达标程度进行调整，应用于未来的账单。
对此要保持清醒的认识。信用额度是根据你付给供应商的费用来计算的，而不是根据故障给你造成的损失来计算的。如果一次四小时的网关中断使你自己用来做商业决策的定价数据源陷入停滞，信用额度只会是月度代理账单的一小部分，而业务影响则由你自己承担。信用额度是一种问责机制，也是供应商认真对待承诺的信号；它们不是保险。
有两个机制上的细节值得留意。信用额度通常不是自动发放的：许多合同要求你在一个时间窗口内（通常是 30 天）提出申请，并提供自己的证据。而且信用额度通常有上限，一般是月费的某个百分比。这两点都很正常，但你应该在需要用到之前就了解清楚。
需要仔细阅读的免责条款
免责条款部分才是真正定义 SLA 的地方。标准且合理的免责条款包括提前公告的计划维护、不可抗力，以及供应商不运营的网络中出现的故障。要警惕以下几种情况：
没有上限或没有提前通知期的计划维护，这实际上让供应商可以排除任何它提前宣布的宕机时间。“客户配置错误”的免责条款，范围宽泛到足以涵盖正常使用情况。第三方免责条款的措辞过于宽泛，以至于上游网络问题（这恰恰是实际故障中最常见的部分）被排除在承诺之外。以及把服务降级和不可用区分开来的免责条款，这正是一个运行缓慢但仍存活的服务用来避免被计入统计的手法。
还要检查 SLA 是否覆盖了你实际依赖的组件。一个代理业务通常有几个部分：网关、面板与认证、账单以及任何 API。一个只覆盖网关、却排除认证的 SLA 起不到多大保护作用，因为你无法使用一个你连认证都无法通过的、可达的网关。
如何在签约前核实一个说法
SLA 是对未来的承诺；而可以核实的东西是现在和过去。
从状态页面开始。实时状态，更重要的是公开的事件历史记录，能告诉你故障发生的频率、多快被确认，以及事后分析是否诚实。一个没有公开状态页面的供应商，是在要求你凭信任来接受它的正常运行时间。Shifter 在 status.shifter.io 上公开了这些信息，将网关、ISP IP、API、面板与认证、以及账单作为独立的子服务进行追踪，这正是你想要的那种细粒度，因为它能让你看清楚哪个组件出了故障。
然后在评估期间自己进行测量。在试用期内，通过你自己的基础设施对网关进行低频可用性检测，你就会拥有一份独立的记录，而不是一个营销数字。再结合针对你真实目标的正规成功率测试，如测试速度、成功率和位置准确性中所述，这样你就能同时了解两个数字：服务是否在线，以及它对你是否有效。
最后，看看支持团队的响应时间，因为在实践中它比信用额度更重要。当凌晨两点出问题时，决定你恢复速度的是人工响应的快慢，而不是下个月账单上出现的百分比。
Shifter 公开的内容
作为参考，公开的层级如下：Starter 到 Growth 层级为尽力而为，通常为 99.5% 或更高；Business 到 Pro 层级为按月计算的 99.9% 正常运行时间，没有正式的信用额度机制；Enterprise 层级为 99.9%，按已签署合同提供服务信用额度，根据月度支出计算，并以账户信用的形式计入下一期账单。支持响应时间也相应分层，从入门套餐的尽力而为聊天支持，到 Enterprise 套餐的专属通道和指定客户经理。详情见支持与 SLA 文档。
之所以直白地说明这一点，是因为分层在这个行业中很正常，值得理解：一份正式的、有信用额度支持的 SLA 通常是企业合同才有的功能，如果你的采购流程要求这一点，这应该是提前谈清楚的事情，而不是假设某个自助套餐就包含它。
采购时应该问的问题
问清测量窗口，是按月还是按年。问清宕机的定义，特别是错误率升高或延迟降级是否算数。问清 SLA 覆盖哪些组件，网关、认证、面板、API，以及它们是否分别测量。问清信用额度是自动发放还是需要申请，申请窗口是多久，上限是多少。要求提供过去十二个月的事件历史记录。问清对于生产中断事件，支持响应承诺是什么，通过哪个渠道。以及，问清明确排除的内容是什么。
一个愿意就以上所有问题以书面形式作答的供应商，无论数字本身如何，都在向你传达一些有用的信息。
结论
把百分比数字当作 SLA 中信息量最少的部分。测量窗口、宕机的定义、覆盖的组件以及免责条款，才是决定这份承诺是否有意义的因素，而服务信用额度是一种问责机制，而不是对你损失的补偿。最重要的是，要记住这个边界：正常运行时间 SLA 覆盖的是网关是否可用，而绝不涉及第三方目标是否接受你的流量，所以你仍然需要自己的成功率监控，才能知道你的采集是否真正在起作用。通过公开的事件历史记录和你自己在试用期间的测量来验证，并且把支持团队的响应速度看得至少和数字本身一样重要。
如果你正基于此进行评估，套餐层级的选择在选择合适的住宅代理套餐中有介绍，供应商层面的评判标准则在如何选择代理网络中有介绍。相关服务本身是住宅代理，其层级和按 GB 计费的定价从自助套餐一直扩展到签约的 Enterprise 条款。