真正有意义的可用性 SLA

可用性 SLA 看上去像一句承诺，实际运作起来却更像一份退款政策。供应商很清楚这一点。客户往往并不清楚，于是在签署服务级别协议时以为自己买到了可用性，而真正买到的，只是万一没拿到时的一点折扣。

这不一定是笔糟糕的交易。它只是与大多数人以为自己在签的那笔交易不同，而这个差别恰恰在系统宕机、有人追问合同究竟怎么写的那一刻显现出来。

三个九听上去接近完美，却允许每月 43 分钟的停机。 四个九允许四分钟。如果你的业务能吸收工作日下午 43 分钟的中断，99.9% 就足够了，不必为更高的数字付费。如果吸收不了，再多的九也帮不上忙，因为协议给你的是一笔积分，而不是阻止这次中断。

可用性 SLA 用分钟兑现的承诺

百分比把一个非常大的区间压缩成看起来很小的差别。换算成时间写出来，差距立刻一目了然。

由此可以得出两点。从 99.9% 到 99.99% 这一步，把允许的停机时间压到十分之一，而成本上涨通常远不止十倍，因为它要求用冗余消除每一个单点故障，连部署流程本身也不例外。这里说的冗余不是再加一台服务器，而是把数据库、网络链路和认证层全部做成双份，并且把发布本身改成不会中断服务的无停机部署。而任何达到或超过五个九的水平，都低于人类察觉异常并作出反应所需的时间，因此只能由无人介入、自动切换的系统来维持。

数字应该由一次中断每小时真正让你损失多少来决定，而不是由听上去是否气派来决定。把那一小时的损失额认真算一遍，多数公司会发现，它比升到上一档所要多付的费用还要小。绝大多数业务系统，99.9% 已经足够诚实地够用。

服务积分不是赔偿

几乎每一份可用性 SLA 里写明的救济方式，都是从未来费用中扣抵的积分，通常是月费的某个百分比，而且常常以当月账单总额封顶。Google Cloud 的计算 SLA 就是一个有代表性的例子：只有积分、由客户自行申报、并且有上限。

这意味着你能拿回来的上限，大致就是你为这段时间支付的金额，而对多数服务来说，这个数字远低于一次中断造成的损失。一个每月几百英镑的平台，无法补偿一天的营业额损失，也没有任何供应商会同意让自己承担这种条款。此外，积分往往只按出问题的那一项服务的费用计算，依赖它而被连带拖停的其他系统所产生的损失，根本不进入计算。

积分通常还需要主动申请，而不是自动发放。你得自己发现违约、自己算出金额，并在有时短到三十天的窗口内提交申请。举证责任完全落在你这一侧：你得拿得出自己的监控记录，才能说明中断确实发生过、从几点持续到几点。供应商没有义务主动告诉你他们没达标，绝大多数也确实不会主动说。

实际的结论是，不要再把积分当成保护。它只是一个信号，说明供应商对自己给出的数字有多认真。真正保护你的是架构，以及我们在灾难恢复指南中讲过的恢复规划。

真正起决定作用的条款

什么才算停机。 只有完全不可用，还是性能下降也算？一个三十秒才响应的服务实际上没法用，但按多数定义仍算作可用。如果响应时间对你重要，就要把延迟阈值写进定义里。

由谁测量、怎么测量。 几乎总是供应商自己，用他们自己的监控，从他们自己的网络去测。那测的是他们的基础设施，而不是你的体验。谈定测量点，同时无论如何都要自己跑一套独立监控，因为你没有观测过的数字，你无从争辩。

免责与例外。 计划内维护通常被完全排除，也就是说供应商每月停机数小时也不算违约。要查清需要提前多久通知，以及有没有上限。计划维护一旦被全面排除，合同上写的百分比和你实际能用的时间之间，差距会明显拉开。此外，凡是归因于你的配置、第三方或不可抗力的情况同样被排除，而这几类能吸收掉相当多的事故。

测量窗口。 按月是通行做法，也对你有利。按年测量则允许供应商发生一次长时间中断却依然达标，因为在 99.9% 之下，整整一天的停机仍在全年额度之内。

响应还是解决。 许多协议只承诺在某个时限内响应，对修复只字不提。一小时响应加上不设期限的修复，是很常见的写法，也远比读起来要弱。

与其争数字，不如要这些

把力气用在那些真正改变行为的条款上，而不是首页那个数字。百分比在谈判桌上很难挪动，而下面这几项几乎都谈得下来，并且它们改变的是供应商在出事那天真正会做什么。

计划维护的上限，附带提前通知和避开你高峰时段的窗口。它对真实可用性的影响，往往超过百分比本身。

状态透明，也就是一个公开的状态页，以及及时发布事故的承诺。一个愿意公开自己故障的供应商，其实是在告诉你他们是怎么做事的。

明确的升级路径，写明姓名或角色以及时间，这样事故处理就不会从寻找该联系谁开始。

重大中断后的事故报告，说明发生了什么，以及因此改了什么。这是供应商能给你的信息量最大的一份文件，而不愿意给这件事本身也很说明问题。

反复失约时的解约权。 长期达不到水平，就应当允许你无违约金离开。这项权利比任何积分都值钱，因为它是唯一与损害相称的救济。

如果提供 SLA 的是你

给出一个你在最差的月份也守得住的数字，而不是平均月份的数字，并且在承诺之前自己先测一遍。合理的做法是先连续测几个月，把其中最差的那个月拿出来看，再决定要不要把这个数字写进合同。承诺了一个从未验证过的数字的供应商，最后会在公开场合发现那个差距。

诚实地定义计划维护，并守住那个时间窗。公开状态页。哪怕没人要求，也把事故报告写出来，因为留下来的客户，正是那些相信你知道究竟发生了什么的客户。

各档的定价，要按交付它们实际花掉的成本来算。四个九不是一个市场部的决定，而是冗余的基础设施、自动故障切换，以及一套不会把系统弄停的部署流程，这些都各自附带账单。其中大部分的运维基础，都从我们的 CI/CD 流水线指南开始。

Mecanik 在服务器安全分析工作中，按可用性承诺构建并运维系统。值得作出的承诺，几乎总是那个你在糟糕的一周里也能守住的承诺。

常见问题

99.9% 的可用性允许多少停机时间？ 每年 8.76 小时，或者说每月 43.2 分钟。提升到 99.99% 会把它压到每年 52.6 分钟、每月 4.32 分钟，也就是十分之一；由于必须消除包括部署流程在内的每一个单点故障，交付成本通常远超十倍。

服务积分算是对停机的真正赔偿吗？ 不算。积分通常是月费的一个百分比，并以当月账单封顶，所以你最多拿回大致等于已付金额的钱，这远低于一次中断的通常代价。它们往往还需要在很短的窗口内主动申请，而供应商很少主动承认自己没有达标。

看一份可用性 SLA 时应该检查什么？ 什么算停机、性能下降是否计入，由谁测量、从哪里测量，免责条款覆盖了哪些情形，计划维护有没有上限和提前通知，测量窗口是按月还是按年，以及承诺的是响应还是解决。

测量窗口为什么这么重要？ 按月测量对客户有利。按年测量则允许供应商发生一次长时间中断却仍然达标，因为在 99.9% 之下，整整一天的停机仍在全年额度之内。同样一次故障，放在按月的协议里就是直接违约。

比起更高的数字，更值得谈的是什么？ 计划维护的上限并附带避开高峰时段的通知、及时发布事故的公开状态页、写明姓名与时间的升级路径、重大中断后的书面事故报告，以及反复失约时的解约权。最后一项是唯一与损害相称的救济。