背景
做了 15 年技术产品，签 B 端合同签多了之后，我发现 SLA 里最容易被忽视、但一出事就炸的条款，不是"可用性 99.9%"那个百分比，而是**"故障时长"怎么算**。
上个月刚处理完一个真实案例：客户投诉"你们系统昨天下午挂了 30 分钟，我们损失了 20 万，按合同该赔"。我们拉了监控——服务端所有接口从 14:03 到 14:06 返回都是 200，CPU/内存/GC 全正常，数据库连接池也正常。但客户那边说"页面一直转圈，下单按钮点了没反应，30 分钟才有 3 单成功"。
差出来的 27 分钟，谁都不认：
- 工程说：服务端没挂，是你们网络/CDN/浏览器的事；
- 客户说：我用户下不了单，就是你们挂了；
- 法务说：合同里写的是"服务不可用"，但没定义什么叫"不可用"。
最后按"友好协商"赔了一笔，但心里都清楚：下次再遇到，就是打官司。
常见的三种口径（也是三种阵营）
-
服务端心跳派：以监控/探针为准，接口返回 200 就算活着，5xx/超时才算故障。最"客观"，但问题是客户买的不是"服务器活着"，是"能下单"——你的服务活着，但用户下不了单，客户照样投诉。而且这个口径对工程最有利，客户法务一眼看穿，签合同时就会卡。
-
用户侧 RUM 派：以客户侧埋点为准，用户打开页面、完成关键操作才算"可用"。最贴近客户感受，但问题是数据在客户手里，客户说"挂了 30 分钟"你就没法反驳——除非你也接了客户的 RUM，或者合同里约定了第三方监测。而且 RUM 噪声大：用户网络差、手机卡、浏览器插件冲突，都会污染数据，真出争议时扯皮空间巨大。
-
业务闭环派：不看 HTTP 状态码，看"关键业务动作是否成功"——下单、支付、查询。只要"下单成功率"掉到阈值以下（比如 95%），就算故障，时长从"成功率跌破阈值"到"恢复"。最贴近客户真实损失，但要求合同里明确写出"关键动作"的定义、成功率阈值、采样窗口，条款写得越细，签得越慢，客户法务越挑剔。
我的倾向（一个我越来越信的原则）
「SLA 里的"可用"，应该等于客户买的业务价值，而不是服务器的心跳。」
客户付钱买的是"能下单、能支付、能查账"，不是"你的 Nginx 活着"。所以合同里的"故障时长"口径，应该锚定在业务闭环的成功率上，而不是 HTTP 200 的比例上。
具体来说，我现在的合同模板里会写三样东西：
- 关键动作清单：下单、支付、查询订单、退款申请，每个动作单独定成功率阈值（下单 99.5%、支付 99.9%、查询 99.9%）；
- 采样口径：按 5 分钟滚动窗口，成功率跌破阈值即开始计时，连续两个窗口恢复到阈值以上才停止计时（避免抖动误判）；
- 数据来源：双方都认可的第三方监测（比如阿里云拨测、AWS CloudWatch Synthetics），或者双方各自埋点但争议时以第三方为准。
这样做的好处是：出争议时不用吵"你挂没挂"，直接看第三方数据"下单成功率从几点几分掉到几点几分"，数字说话。
但我也见过反例，而且很痛：
有一次我们按"业务闭环"口径赔了一笔，事后复盘发现——客户自己的前端有个 bug，把下单请求发到了错误的环境（staging），staging 没配支付网关，所以"下单成功率"掉到 0。按合同口径，这算"故障"，我们赔了。但根因是客户自己的，跟我们服务端没关系。
那次之后我在合同里加了一条："因客户侧配置、网络、终端导致的失败，不计入故障时长"，并要求客户提供侧的埋点日志作为佐证。
想听大家聊的（三个具体问题）
- 你签过的合同里，"故障时长"的口径是怎么写的？是服务端心跳、用户侧 RUM、还是业务闭环？出过争议吗？最后怎么裁决的？
- 你觉得"用户侧 RUM"这个口径，到底该不该作为合同里的判据？它数据在客户手里，是不是天然对工程不利？
- 有没有那种"按合同口径算不算故障、但按常理该赔"或者"按合同口径算故障、但按常理不该赔"的灰色地带？你最后怎么处理的？
我特别想听听做客户侧（采购方）的朋友怎么看——你们在签合同时，最希望对方 SLA 里写什么口径？是越细越好，还是越粗越好？我感觉两边对"口径细"的理解可能完全相反：工程希望细到能免责，客户希望粗到能兜底。