波仔
🛡️ 第六章 组织机构的安全防范对策
📄 一句话概括

SLA 里每一档赔偿都是写死的数字，但也是最容易在签约时被跳过的几页——它决定的是【服务真的出问题时，你手里到底有什么】。

📝 本节和前面几节的关系

6-16 讲的是【自己怎么做冗余】，这一节讲的是【把可用性外包出去时，怎么把它写进合同】——两者是同一件事的两条路：一条是自己建，一条是买别人的承诺并且知道这份承诺的实际边界在哪里。 它也和 6-7 接得很紧：供应商依赖是 BIA 里最常被忽略的那一类【单点】，而 SLA 是处理它的主要手段。 作为本章最后一节，它把一个主题收回来：前面十六节讲的控制措施，最终大多要落实在【谁来做、做到什么程度、做不到怎么办】——而这三句话的书面形式就是合同。

一、SLA 的共同结构

国内云厂商的 SLA 口径互不相同，但结构高度一致。先把这个结构看明白，再去看具体条款就不容易被绕进去：

要素 典型写法
服务周期 一个自然月
可用性公式 1 - 不可用时间 / 总时间
统计粒度 常见按每 5 分钟的请求错误率汇总
赔偿形式 代金券或赠送余额，不可折现、不开票、不可转让
申请时限 通常要求在该月结束后 2 个月内提出
除外情形 维护、割接、升级、客户自身原因、不可抗力等一长串

这张表里有两行是【读了会松一口气、实际上最该警惕的】：

【申请时限】这一行则是执行层面的坑：赔偿不会自动到账，需要你自己提出申请。两个月看起来不短，但现实中【发现中断 → 确认影响 → 收集证据 → 内部走流程 → 提交申请】这条路走完，两个月并不宽裕——尤其是跨部门协作的情况下。

二、三家云厂商的参数对照

把三家的参数并排放在一起，才看得出【同样叫 SLA，实际差别在哪里】：

项目 百度智能云专线 阿里云 OSS 金山云 KENC
承诺可用性 99.95% 99.99%（标准型） 99.9%
冗余形态 多路接入不同接入点 同城冗余 99.995% 见产品说明
第 1 档 ≥99.00% 赔 10% ≥99.90% 赔 10% ≥99.0% 赔 10%
第 2 档 ≥95.00% 赔 25% ≥95.00% 赔 30% ≥95% 赔 25%
最低档 <95.00% 赔 100% <95.00% 赔 50% <95% 赔 50%
赔偿上限 按月度服务费计 该存储类型月费 50% 该实例月费 100%
生效日期 2026-05-27 2026-03-01 2026-02-19

这张表里有几处对比值得逐一看：

两个定义上的细节也值得记：阿里云 OSS 把可用性按每 5 分钟的错误率统计（每 5 分钟错误率 = 失败请求数 / 有效总请求数 × 100%，月度可用性 = 1 - 各 5 分钟错误率之和 / 5 分钟总个数）；金山云 KENC 对【服务不可用】的定义是：一台设置好出入允许规则的实例，与任一 IP 的双向出入都无法联通，且持续 5 分钟以上。 这两个定义决定了【什么算停机】——比如短暂几秒的抖动、部分地域的故障、或者只影响某个 API 的问题，可能都不计入不可用时间。

三、动手 Demo：算一次赔偿

这是本节最实用的一段：把一次真实的中断换算成应得的赔偿：

month_min = 30 * 24 * 60                # 43,200 分钟
bad_min = 92                            # 不可用时长
avail = (1 - bad_min / month_min) * 100 # 99.787%
fee = 120000                            # 当月月度服务费
tiers = [(99.95, 100.01, 0.00, "未触发赔偿，可用性达到承诺"),
         (99.00, 99.95, 0.10, "低于承诺 99.95%，但不低于 99.00%"),
         (95.00, 99.00, 0.25, "低于 99.00%，但不低于 95.00%"),
         (0.0, 95.00, 1.00, "低于 95.00%，按顶格赔偿")]

实跑输出：

三、算一次：这个月到底该赔多少
  当月总时长              43,200 分钟（按 30 天算）
  不可用时长              92 分钟
  实测可用性              99.787%
  当月月度服务费          120,000 元（示例）
  命中档位                低于承诺 99.95%，但不低于 99.00%
  赔偿比例                10%
  赔偿金额                12,000 元
  → 92 分钟的中断，换回来的是月度费 10% 的代金券，
     而且必须在该月结束后两个月内自己提出申请，过期不补。

读这个输出：

四、签合同前必须追问的六个问题

把这六个问题打印出来，在评审 SLA 时逐条问：

最后两问的关系需要点明：SLA 只管【运行中的可用性】，不管【退出时能不能把数据带走】。 这两件事要写在别的条款里（数据导出、迁移协助、终止过渡期）。一个具体的风险场景：当你决定从某个云服务迁走，如果合同里没有约定【数据导出需要多少天、以什么格式、收不收费】，那么谈判地位会完全不对等——因为你的数据在对方手里。 这一类条款的谈判时机有一个特点：签约时最容易谈，迁走时最没有筹码。

五、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 翻开你正在用的任意一个云服务的 SLA，直接跳到【除外情形】那一节，数一下有几条。多数人会发现条目数量比自己预期多——然后问自己一个问题：【这几条里，哪些是攻击者最可能触发的？】 答案通常是好几条。这就是为什么【有 SLA】和【有保障】不是一回事。
  2. 检查一下你有没有在做两件事：① 每月看一次上个月的可用性记录；② 把厂商的公告接进内部流程。这两件事的成本都是几分钟，但它们分别决定了【能不能拿到赔偿】和【会不会被突然变更打到】。 如果两件都没做，那这份 SLA 目前只起到了一个作用：让你在采购单上有个理由。

这一节要带走的一句是：SLA 的价值不在那个百分数，而在【承诺附了什么条件、赔偿封了多少顶、除外情形挖了哪些洞、以及退出时数据带不带得走】——看懂这四件事，比记住那个 9 更重要。

常见误区

  1. 错误：SLA 承诺 99.99%，就等于不会停机。——纠正：99.99% 本身对应每年约 53 分钟，而且这个数字的统计口径决定了它的实际含义。要问三个问题：① 【不可用】的定义是什么（是【完全无法访问】，还是【错误率超过某阈值】？——金山云 KENC 的定义是【双向都无法联通且持续 5 分钟以上】，这意味着短暂抖动不计入）；② 统计粒度是多细（阿里云 OSS 按每 5 分钟的错误率汇总，那么一次持续 3 分钟的中断可能完全不进统计）；③ 含不含计划维护（含与不含差别很大，因为大量停机是计划内的）。这三个问题问完，你会发现同一个 99.99% 在不同厂商那里对应的实际体验可能差出好几倍。 顺带说一句：SLA 里的可用性通常是针对【单个服务或单个实例】承诺的，而你的业务可能依赖多个服务组成的链条——链条的整体可用性是各环节的乘积，会低于任何一个环节（三个 99.99% 串起来约是 99.97%）。

  2. 错误：出了故障，厂商会自动赔付。——纠正：SLA 的赔偿基本都需要你主动申请，而且有严格条件和时限。需要做四件事：① 自己发现并记录（厂商不会替你判断你是否触发了赔偿条件）；② 在时限内提出（通常是该月结束后 2 个月内）；③ 提交证据（很多条款要求提供能证明不可用的记录，这就要求你自己的监控口径与 SLA 的定义一致）；④ 受赔偿上限约束（有的封在月度服务费的 50%，有的可以到 100%）。这里最容易出问题的是第 ③ 步：如果你的监控粒度和定义与 SLA 不一致，就会出现【你有记录但对方不认】的情况。所以正确做法是：在签约后、正式使用前，就按对方的统计口径把自己的监控配好——这件事越早做越省事，因为它决定的是以后每一次争议里的证据强度。

  3. 错误：合同条款是法务的事，技术团队不用看。——纠正：SLA 里最有技术含量的部分，恰恰需要技术团队来判断。举三个具体例子：① 【多路接入不同接入点】这个前提——只有技术人员知道自己的线路是不是真的接到了不同接入点、不同物理路由；② 【统计粒度按每 5 分钟错误率】这个定义——只有技术人员知道自己的业务监控能不能对齐这个口径；③ 【服务不可用的定义】（比如【与任一 IP 双向都不通且持续 5 分钟以上】）——这类定义会直接影响【哪些故障算故障】，而它需要结合自己的业务形态去判断是否够用。换句话说：法务能判断条款是否完整、风险是否可控，但只有技术能判断【这条承诺在我们的实际架构上意味着什么】。 一个务实的流程是：SLA 评审时技术、法务、业务三方一起过一遍——技术看可行性、法务看风险、业务看影响。

  4. 错误：SLA 是采购时关注的事，签完就不用管了。——纠正：SLA 是【持续动作】，不是【一次性文件】。原因有三：① 条款会变——厂商保留提前 30 天通知即可修改条款的权利，所以不订阅通知就会错过变更；② 你的用量与形态会变——比如从单路接入改成多路接入，承诺的适用条件就变了，或者反过来：你以为有多路冗余，实际上并没有；③ 赔偿要主动申请——如果没人定期检查上个月的可用性记录，那么赔偿就永远不会发生。所以务实做法是把三件事写进日常流程：订阅公告、每月检查可用性记录、每年复核一次关键条款。这三件事合起来每年花不了几个小时，但它们决定的是【这份合同到底有没有在起作用】。（这也是 6-3 那套监督思路在合同管理上的延伸：固定的周期、明确的指标、有记录的动作。）

自测三问（点开对答案） 1. 为什么说 SLA 不是【保险】？ —— 因为**它赔的是【服务费的一部分】，而不是【你因此遭受的损失】**。**从结构上看**：**赔偿形式通常是代金券（不可折现、不开票、不可转让）、有赔偿上限（比如封在当月服务费的 50% 或 100%）、并且有申请时限与除外情形**。**Demo 里那个例子很直观**：**92 分钟的中断，按 12 万元月费算，赔偿是 1.2 万元——而同一段时间里，业务损失可能远高于这个数。** **这个定位带来的实际影响是**：**SLA 适合用来管理【服务质量下滑】这件事（让对方有动力维持服务、让你在长期体验不佳时有议价依据）**，**但不适合用来覆盖【业务中断导致的收入损失】**——**后者要靠保险、合同违约责任条款，或者自己建冗余（6-16）。** **把这两件事分开，谈判时的预期就会清楚很多**：**SLA 部分谈【承诺值与赔偿档位】，损失覆盖部分谈【违约责任与数据取回】。** 2. 为什么【除外情形】比【赔偿档位】更值得先读？ —— 因为**赔偿档位回答【赔多少】，而除外情形回答【赔不赔】**。**如果一次中断恰好落在除外情形里，那么档位设计得再慷慨也一分不赔**。**从实践看，除外情形里常见的几类刚好是事故高发区**：**用户未遵循使用文档、用户口令或密钥泄漏、用户自行安装或修改的活动、用户应用遭攻击导致被限流**。**这些表述的覆盖面可以很宽**——**比如【用户应用遭攻击】这一条，恰恰对应了很多被 DDoS 或被入侵的场景**。**所以正确的阅读顺序是**：**① 先看【什么算不可用】（定义与统计粒度）；② 再看【哪些情况不算】（除外情形）；③ 最后才看【赔多少】（档位与上限）。** **这个顺序还有一个好处**：**它让你在签约时就能判断【这份 SLA 对我们的实际业务有没有意义】**——**如果除外情形覆盖了我们最可能遇到的那几类故障，那这份承诺的价值就很有限，谈判时应该聚焦在别处（比如服务响应时限、数据取回条款）。** 3. 为什么【数据取回】条款值得在签约时就谈？ —— 因为**谈判地位在签约时最好，在迁走时最差**。**签约时你是潜在客户，对方有动力答应条件；等你要迁走时，数据已经在对方系统里，迁移的时间、格式、费用、协助程度都成了对方的筹码。** **这一条要写清楚四件事**：**① 导出的数据范围（是全部数据还是部分？含不含历史版本与日志？）**；**② 导出的格式（是不是标准格式、能不能被别的系统直接读取）**；**③ 时间承诺（在多少个工作日内完成、有没有过渡期）**；**④ 费用（是否额外收费、按什么标准计）**。**这四件事里最容易出问题的是第 ② 和第 ④ 项**：**不标准的数据格式会把迁移成本推高好几倍；而【迁移协助按工时收费】这类条款，可能在迁走时变成一笔不小的支出。** **从更广的视角看**，**这一条其实是本章反复出现的那个主题的一个具体形态**：**安全和可控性不仅取决于【服务运行得好不好】，还取决于【你有没有退出的能力】**——**而【退出能力】必须在还有谈判地位的时候预留。**

相关笔记