服务器 SLA 上写的 99.99% 到底意味着什么：先读排除项，再读百分比

采购单上印着 99.99% 的时候，很多人直接把它翻译成一句话：一年只停 52 分钟。业务方拿到这个翻译，会顺势推出第二个结论——既然一年才停不到一小时，那我们就不必再花钱做冗余了。等到真出事，服务中断了好几个小时，走完申报流程拿到的，是按当月服务费比例折算出来的一笔时长抵扣，金额往往还不够覆盖一次全员故障复盘和客诉处理的成本。

落差不在服务商骗人，而在读法错了。百分比只是整个服务等级条款里最显眼、也最不重要的一项。真正决定你能不能拿到补偿、能拿到多少的，是前面那些不起眼的定义、计量方式、排除项、计算基数和取证规则。把这些读完，再看那个数字，才知道自己买的到底是什么。

把百分比直接当成"一年只停这么久"，是采购环节最常见的误读

绝大多数采购评审会上，服务等级条款是被这样处理的：翻到承诺那一页，找到"99.9%"或者"99.99%"，对比两家供应商的数字，数字高的中标。整份文件剩下的几十页——定义、排除、计量、赔偿分档、索赔流程——基本没人读，因为它们是法律语言，读起来费劲，而且看起来"只是走个形式"。

问题在于，这两个数字之间折算出来的实际差距，比你想象的小；而这两份条款之间在排除项和赔偿基数上的差距，比你想象的大。换句话说，你花在比较数字上的精力，投错了地方。

更要紧的是，百分比描述的是一个统计期内的累计时长，它不描述任何一次事故的形态。一年允许停 8.76 小时，可以是分 10 次每次 50 分钟，也可以是一次 8 小时 45 分钟——对业务的杀伤力完全不同。前者你可能只是收到几条告警，后者可能直接触发监管报送和客户索赔。同一个 99.9%，两种结局。

先把百分比换成分钟：年 365 天、月 30 天口径下的完整换算

读任何服务等级条款之前，先把百分比换成时间单位。人脑对"99.99%"没有直觉，但对"52 分钟"有直觉。以下按年 365 天、月 30 天的口径换算，这是行业里最常见的计算基准：

99%：一年允许不可用约 3.65 天，也就是 87.6 小时；折算到单月约 432 分钟。

99.5%：一年允许不可用约 1.825 天，也就是 43.8 小时；折算到单月约 216 分钟。

99.9%：一年允许不可用约 8.76 小时，也就是 525.6 分钟；折算到单月约 43.2 分钟。

99.95%：一年允许不可用约 4.38 小时，也就是 262.8 分钟；折算到单月约 21.6 分钟。

99.99%：一年允许不可用约 52.6 分钟；折算到单月约 4.32 分钟。

99.999%：一年允许不可用约 5.26 分钟。

把这张换算表放在手边，再看条款里那个百分比，你会发现一件有意思的事：从 99% 提到 99.9%，年停机时长从 87.6 小时压到 8.76 小时，减少了整整 79 小时，这是量级上的改善；但从 99.9% 提到 99.99%，年停机时长从 525.6 分钟压到 52.6 分钟，减少的是 473 分钟——不到 8 小时。数字上多了一个"9"，实际减少的停机时间是不到八小时。

99.9% 与 99.99% 之间，差的只是每年约 473 分钟

473 分钟这个数值得单独说。很多采购决策里，"四个九"被视为显著优于"三个九"的核心卖点，甚至愿意为此支付明显更高的单价。但从纯时长角度看，它换来的是每年少停 473 分钟、每月少停 38.9 分钟。

这 473 分钟值不值那个差价，取决于你的业务形态。如果你的系统是内部报表平台，白天有人用、夜里没人用，一次 40 分钟的中断几乎没有成本，那么为这 473 分钟付溢价并不划算。但如果你的系统是交易链路的一环，每分钟都在产生订单，那么这 473 分钟的分布方式比总量更重要——它是一次集中发生，还是分散在十二个月里？条款不会告诉你答案。

这里还有一个常被忽略的算术问题：如果一次事故就耗尽了全年的额度，剩下的十一个月即便全部达标，年度可用性也已经被这一次的时长锁定了。也就是说，年度口径会把单次重大故障的影响"摊平"到全年，让百分比看起来没那么难看，但业务当时承受的冲击是实打实的。看月度口径的条款，对业务方通常更友好一些。

四个九依然允许一年停 52.6 分钟，而这 52 分钟可能正落在你最难承受的时点

再往上一个台阶看 99.99%。每年 52.6 分钟，听上去已经接近于"不会停"。但对一个做实时交易的系统而言，52.6 分钟意味着什么？

假设你的业务有明显的波峰——电商的大促开场、票务的放票瞬间、游戏的活动开启、金融的开市撮合。这些窗口通常只占全年时间的极小一部分，却贡献了相当比例的营收。而故障并不挑时间发生：硬件故障、网络设备异常、存储抖动、机房电力切换，都不会因为你正在做大促而回避。

于是会出现一个很现实的局面：全年 52.6 分钟的额度，正好在大促开场那 20 分钟里一次性用完。从条款角度看，服务商完全达标，年度可用性甚至还有富余；从业务角度看，你损失的是全年最密集的一批订单。这两套账永远不会对上，因为条款计量的是时长，业务计量的是时点价值。

所以"四个九够不够用"这个问题没有通用答案，只有结合业务时间分布才能回答。评估方法很简单：把全年的营收按小时铺开，找出价值密度最高的那几个时段，然后问一句——如果故障正好落在这里，损失是多少？把这个数字和你为更高等级多付的费用对比，判断才有依据。

"什么算停机"比百分比更决定结果：不可用是怎么被定义的

现在进入条款的主体部分。第一道关口是不可用的定义，它决定了后面所有计算的前提。

行业常见写法是：把"不可用"定义为服务在一个持续时段内完全无法访问，或者关键性能指标低于某个约定阈值。这里有两个关键词需要注意。

第一个是"完全无法访问"。这个措辞把"慢"和"抖"排除在外了。现实中大量业务事故并不是彻底断连，而是响应从 200 毫秒劣化到 8 秒、丢包率从 0.1% 跳到 15%、连接成功率从 99.9% 掉到 60%。对用户来说这已经是严重故障，但如果条款只认"完全无法访问"，这类降级可能压根不计入不可用时长。部分条款会把性能下降单独列出来处理，也有条款直接不提——遇到后者，你要意识到自己买的是"连通性承诺"，不是"性能承诺"。

第二个是"关键性能指标低于阈值"。如果条款采用了这种写法，那么阈值本身就成了核心条款内容：阈值定在哪个数值、用什么指标衡量（可用性、响应时间、丢包率、错误率）、在哪个位置测量（机房出口、服务商网络边界、实例内部）、用什么频率采样。这几个变量任何一个松动，定义就形同虚设。比如阈值定在错误率 50%，那意味着一半请求失败仍然算"可用"；比如在实例内部测量，那么服务商网络侧的问题可能测不出来。

还有一层：多数条款会写明"由服务商的监控系统判定"。这不是一句话带过的程序性表述，它直接决定了事故责任的认定权归属，后面在取证那一节会展开。

连续 5 分钟才计一次，与按分钟累计，是两套完全不同的结果

第二道关口是计量粒度和计入门槛。同样的物理故障，用不同口径算出来的不可用时长可以差好几倍。

行业常见写法有两种。一种是"连续 N 分钟以上才计一次停机"，N 通常是 5 分钟；另一种是"按分钟累计"，只要监测到不可用就累加实际分钟数。

举个具体的对照：某台设备在一个月里发生了 20 次抖动，每次持续 90 秒，物理上累计中断 30 分钟。按分钟累计的口径，记 30 分钟不可用；按"连续 5 分钟以上才计一次"的口径，这 20 次里没有一次达到门槛，记 0 分钟。

这两种口径各自对应不同的故障形态，没有绝对的优劣，但你必须知道自己签的是哪一种。频繁短抖的故障模式——比如链路质量不稳定、负载突刺导致进程反复重启、健康检查震荡——在"连续 N 分钟"口径下几乎不会留下任何记录，而在按分钟累计口径下会被完整统计。

反过来，如果你的业务对单次长中断敏感、对短抖不敏感，按分钟累计的口径对你意义不大，你真正该争取的是"单次中断超过 X 分钟即触发更高档赔偿"这类条款。

除了门槛，还要看测量位置和时间基准。测量点在服务商侧还是在你的实例侧，是否扣除客户端到服务商之间那段网络，是否按月结算还是按年结算，是否允许把多个月份的额度合并计算——这些都会改变最终数字。按月结算通常比按年结算更容易触发低档赔偿，因为单月的分母小、波动影响相对更大。

排除项才是条款的主体，逐条看它们的谈判点

如果说定义和粒度决定了"什么算停机"，那么排除项决定了"什么情况服务商不负责"。这一节的篇幅，往往比承诺那一页长得多，也重要得多。下面逐条拆开看，每一条都附一个可以争取的方向。

计划内维护窗口。行业常见写法是：提前通知的维护不计入不可用。这一条的合理性在于，硬件更换、系统升级、补丁修复本来就是必须做的；风险在于，通知的形式和提前期如果不受约束，"计划内维护"会变成一个可以无限使用的免责通道。谈判点很具体：提前通知期要写死（比如不少于若干个工作日）、单次窗口时长要封顶、每月或每年的窗口总时长要封顶、窗口安排的时段要约定（比如限定在业务低峰期）、通知渠道要写明确认方式。这几个参数不写，条款就是开口的。

不可抗力。自然灾害、战争、极端天气、市政电力中断等通常被排除。这一条本身争议不大，但边界需要留意：上游电力中断算不算不可抗力，取决于服务商是否有冗余供电义务；区域性网络管制算不算，需要看措辞。可以争取的是把"虽属不可抗力但服务商未尽到合理减损义务"的情形排除在免责之外，以及明确不可抗力期间的信息通报义务。

客户自身原因。客户的操作失误、错误配置、应用缺陷、未及时打补丁、账号权限管理不当，都属于这一类。这一条合理，但要注意它经常被扩大解释：一次故障里如果既有客户配置问题也有基础设施问题，责任怎么划分？建议争取"按主要原因划分"或"双方原因并存时按比例分担"的表述，避免出现"只要沾上客户原因就全部免责"的写法。

客户侧网络与用户接入网络。用户到你机房出口之间的公网路径，服务商通常不负责。这一条的责任边界相对清晰，但对业务的影响很实在：用户访问不了，不管问题出在哪一段，损失都算你的。这一条很难谈，能做的是要求服务商提供故障期间的路由与质量数据，帮你向其他责任方追责。

上游骨干与运营商。这一条是争议高发区。服务商的网络本身正常，但它依赖的上游链路或运营商出了问题，导致你的服务不可达，算不算不可用？行业常见写法是把它列入排除项。谈判点在于：服务商是否承诺多路由冗余、是否承诺在上游故障时自动切换、切换时长是否有约定。也就是说，你无法要求服务商为上游的故障负责，但可以要求它为"应对上游故障的能力"负责。

攻击流量。因 DDoS 等攻击导致的不可用，很多条款明确排除在外。这一条的逻辑是攻击不可预见、超出服务商控制。但对业务而言，被攻击期间服务停摆是真实的损失。可以争取的方向有两个：一是把服务商未启用合同约定的防护措施的情形排除在免责之外；二是明确清洗或缓解动作的启动时延承诺，这个承诺本身可以单独成条，不依附于可用性百分比。

监管或司法要求。因法律法规、监管指令、司法协助导致的中断，通常被排除。这一条基本没有谈判空间，但需要明确的是通知义务和数据可携带性——被要求中断时，服务商应在允许的范围内及时告知，并保证你的数据可以完整导出迁移。

读完这一节的感受应该是：排除项不是"细则"，它才是条款真正的主体。承诺那一页说的是理想情况，排除项说的是现实情况。

赔偿的基数是"受影响服务的当期费用"，不是整单也不是业务损失

进入赔偿计算部分，先说最容易被误解的一点：基数是"受影响服务的当期费用"。

行业常见写法是：赔偿金额按发生故障的那一项服务在当期的费用计算，而不是按你的整张订单金额，更不是按你的业务损失。这三个口径的差别极大。

举一个结构化例子说明差别：假设你采购了一整套资源，包含计算、存储、带宽、备份、安全等多个计费项，当期总账单记为 1000 个单位，其中出故障的那一项当期费用是 100 个单位。那么即便赔偿比例高达 100%，拿到的上限也是 100 个单位，而不是 1000 个单位。很多采购在心里默认按整单计算，等到实际索赔时才发现基数只有十分之一。

还有一种口径是按"不可用时长占当期总时长的比例"计算，即当期费用乘以中断比例。这种算法下，43 分钟中断对应一个月 43200 分钟里的千分之一，赔偿基数再小的话，算出来的金额可能低到不足以走完一次财务流程。

与"受影响服务当期费用"直接相关的一个问题是：服务之间怎么切分。如果你的多台设备共享一个订单，其中一台故障，是按整单算还是按那一台的月费算；如果故障的是网络而计算资源正常，网络部分在账单里怎么计价。这些切分规则不写清楚，索赔时会出现两套算法各执一词的情况。

假设演算：月费记为 100 个单位时，一次 216 分钟中断大概能赔多少

以下为假设演算，仅为说明计算方式，不构成任何报价或承诺。

设定一个纯粹用于演示的场景：某项服务的月费记为 100 个单位（这里的"单位"是抽象计量单位，不代表任何真实币种和金额），合同承诺的可用性是 99.9%，对应每月允许不可用 43.2 分钟。该月实际可用性为 99.5%，对应不可用时长约 216 分钟，超出承诺额度约 173 分钟。

按行业常见的分档赔偿结构，即"赔偿比例为受影响服务当期费用的某一档比例"，216 分钟这个量级可能落在 10%–25% 这一档。以 100 个单位计算，赔偿金额在 10 到 25 个单位之间。

把这个结果放到业务侧看：216 分钟等于 3.6 小时。对一个有稳定营收的系统来说，3.6 小时的中断损失通常远高于 10 到 25 个单位——尤其是当这 3.6 小时落在营收高峰时段时。差距的来源不是比例定得低，而是两个数字根本不在同一个量纲上：一个是资源租赁费用的百分比，一个是业务营收的绝对值。前者由机房的成本结构决定，后者由你的商业模式决定，两者之间没有任何换算关系。

这个演算要说明的结论只有一句：赔偿是对服务费的折扣，不是对损失的补偿。把它当成风险管理手段，方向就错了。真正能对冲业务中断风险的，只有架构上的冗余和流程上的演练。

索赔时限与取证依据，往往比赔偿比例更能决定结果

赔偿条款写得再好看，走不完流程也是一纸空文。这一节的两个变量——时限和证据——在实践中卡掉的索赔，比比例高低要多得多。

行业常见写法是：客户需在事件发生后的若干天内提交工单及证明材料，逾期视为放弃。这个"若干天"在不同条款里差别很大，短的可能只有几天，长的可以到一个月。关键不在于具体天数，而在于你要知道自己签的是多少天，并且把这个日期写进运维值班手册——故障处理期间所有人都在忙着恢复服务，最容易忘的就是按时提交索赔申请。

更根本的问题是取证。多数条款会规定，可用性的计量以服务商的监控系统数据为准。这句话的含义是：服务商既是服务提供方，也是判定方。第三方监测机构、你自己的拨测系统、用户的投诉记录，在这些条款下未必被采信。

这不是说服务商会故意造假，而是两套系统天然会给出不同的结果。你的拨测从公网发起，中间经过多跳网络，任何一段的问题都会被计入；服务商的监控通常在其网络内部或实例侧发起，路径更短、更可控。故障期间，两套数据出现不一致是常态而非例外。

可以争取的方向有三个，难度从低到高：一是要求服务商在故障发生后主动提供其监控的原始数据与计算过程，而不是只给一个结论；二是约定当双方数据不一致时的复核机制，比如引入双方认可的第三方监测作为参考；三是在条款中明确，若服务商未在约定时限内提供其监控数据，则以客户提供的证据为准。第三条最难谈，但它解决的是最核心的不对称——如果对方不提供数据，你连争的依据都没有。

另外，把运维动作做好本身就是取证准备：故障期间的告警记录、工单往来时间线、影响范围统计、用户侧反馈截图、恢复操作的执行记录，都要留存。这些材料在索赔时的价值，不亚于监控数据本身。

单实例、单可用区与多活：条款的适用单位决定了你能拿到哪一档

还有一个结构性问题：服务等级条款承诺的对象是谁。行业常见写法是，可用性按单个实例或单个可用区计算。这个"适用单位"直接决定了条款的实际意义。

按单实例计算，意味着你部署了十台设备，其中一台故障，只有那一台的可用性下降，其余九台正常，整体统计下来可用性仍然很高。但对你的业务来说，如果这十台是对外提供同一服务的集群，一台故障意味着整体容量下降，甚至可能触发雪崩。

按单可用区计算，情况类似但影响更大。同一可用区通常共享电力、制冷、网络汇聚等基础设施，一个区域内的多台设备可能同时受影响。单可用区口径下，这类事件会被记为一次区域性的不可用，而不是多台设备的独立事件——看上去只是一次事故，实际影响的是你的全部容量。

这也解释了为什么跨可用区或多活部署是提升实际可用性的主要手段。它需要你在架构层面做投入：把无状态服务分散到多个可用区，用负载均衡做流量调度，把数据层做成跨区的主从或多主复制，并且配置自动故障切换。做完这些，单个可用区的失效才不会演变成整体服务中断。

值得注意的是，很多条款会为跨可用区或多活的部署方式提供更高的可用性等级。这背后的逻辑很直接：服务商敢于承诺更高的百分比，前提是故障域已经被你的架构隔离了。换句话说，更高的可用性等级不是"买"来的，是"部署"出来的——你得先把架构做成那样，才能匹配那一档条款。

反过来，如果你的业务是单点部署在一个实例上，那么无论条款写的是三个九还是四个九，你的实际可用性上限都被这个单点锁死了。这时候去争取更高的百分比，意义不大。

读条款的正确顺序：从定义走到取证，最后才看那个数字

把上面所有内容串起来，得到一个可以直接用在合同评审上的检查顺序。按这个顺序走一遍，一份服务等级条款大概二十分钟就能读出要点。

第一步看定义：什么叫不可用，是完全断连还是包含性能降级，阈值定在哪个数值，用什么指标、在什么位置、以什么频率测量。

第二步看计量粒度与门槛：是连续若干分钟以上才计一次，还是按分钟累计；按月结算还是按年结算；额度能否跨月合并。

第三步看排除项：逐条核对上一节列出的七类，重点看计划内维护的窗口时长与通知提前期是否封顶，上游与攻击流量是否有附加的能力承诺。

第四步看赔偿基数：是按受影响服务的当期费用，还是按整单；服务之间的费用如何切分。

第五步看赔偿上限与形式：比例分档是哪些档位，上限是多少，形式是账单抵扣、服务时长延长还是代金券，能不能折算成现金或顺延到下一期。

第六步看索赔时限与取证依据：提交期限多少天，需要哪些材料，计量以谁的数据为准，对方不提供数据时怎么处理。

第七步才看那个百分比：把它换算成分钟，对照你的业务时间分布评估能不能接受。

走完这七步，你会发现同一份合同里，真正需要谈的往往不是数字，而是第二步、第三步和第六步。

条款能给的是补偿，冗余、故障切换与演练才给可用性

最后回到一个根本判断：服务等级条款是一种事后经济补偿机制，它不改变任何技术事实。签了四个九，设备该坏还是会坏，网络该断还是会断。条款的作用是在事后给你一笔按服务费比例计算的抵扣，仅此而已。

真正决定你的服务能否持续可用的，是四件技术上的事。

消除单点。把架构里的每一层都过一遍，找出任何一个失效就会导致整体不可用的组件——单台服务器、单个交换机、单条上行链路、单个数据库实例、单个负载均衡器。每一个单点都要有对应的冗余方案，或者明确的失效降级路径。

故障切换要自动。有冗余不等于能切换。很多架构里备机存在了很久，但从未验证过切换流程，真出故障时发现切换需要人工执行、需要改配置、需要改解析，耗时几十分钟甚至更久。自动故障切换的核心是健康检查加编排调度，而且健康检查本身的判定逻辑要与业务可用性一致——只检查端口存活是不够的，要检查服务能否正常响应。

数据层的复制与一致性。无状态服务做冗余相对简单，数据层才是难点。跨可用区的主从复制会带来复制延迟，延迟窗口内主库失效意味着可能丢失一部分已提交的数据；多主架构则要解决冲突。这里没有通用最优解，只能在一致性、可用性、延迟之间按业务容忍度做取舍。

演练。没有经过演练的故障切换方案，等于没有方案。定期在业务低峰期做真实的切换演练，验证切换是否生效、耗时多少、数据是否一致、监控是否告警、值班人员是否知道该做什么。演练中暴露的问题，成本远低于真实故障中暴露的问题。

把这四件事做好，你对条款的依赖会显著降低；反过来，如果这四件事没做，再漂亮的百分比也只是纸面数字。

一张可以直接带进合同评审会的条款检查表

下表按前面说的顺序整理，每一行都是评审时应该当场问清楚的问题。表里的"行业常见写法"是条款结构的普遍描述，不代表任何一家服务商的实际条款。

关于服务等级条款，采购与技术最常争论的八个问题

99.9% 和 99.99% 折算下来到底差多少分钟？按年 365 天计算，两者分别对应约 525.6 分钟和约 52.6 分钟，相差约 473 分钟，也就是不到 8 小时。折算到单月，分别是约 43.2 分钟和约 4.32 分钟，相差约 38.9 分钟。这个差距值不值得为它付溢价，取决于你业务的时间价值分布，而不是数字上多了一个九。

赔偿给现金还是给代金券，区别有多大？区别很明显。现金减免直接冲抵当期或下期账单，等于净支出减少；代金券通常附带使用期限和适用范围限制，且只能用于继续消费同一家服务商的服务。如果你的合同即将到期或者正在考虑迁移，代金券的实际价值会大幅缩水。签之前把形式问清楚，并尽量争取现金减免或账单抵扣。

计划内维护到底算不算停机？行业常见写法是不计入不可用，但需要满足"提前通知"这一前提。真正要谈的不是算不算，而是三个参数：单次窗口时长上限、年度窗口总时长上限、通知提前期。这三个参数不封顶，"计划内维护"就会变成一个可以频繁使用的免责通道。

遭受攻击导致的不可用通常赔吗？多数条款把攻击流量导致的中断列入排除项，理由是攻击超出服务商的控制范围。可以争取的不是让它计入赔偿，而是把两个东西单独写进条款：防护能力的配置标准，以及清洗或缓解动作的启动时延承诺。这两项属于能力承诺，可以与可用性百分比分开约定。

服务商自己的监控能不能作为唯一依据？可以用作依据，但不建议接受"唯一"这个限定。服务商监控与其自身网络边界的位置关系，决定了它和客户侧拨测的结果天然会有差异。合理的做法是要求对方在故障后提供原始监测数据与计算过程，并约定数据不一致时的复核机制；更进一步可以约定，对方未在时限内提供数据时，以客户提供的证据为准。

跨可用区部署能不能提高拿到的等级？有可能。不少条款会为跨可用区或多活的部署形态提供更高的可用性等级，因为其故障域已被架构隔离。但要注意前提条件：你必须真的完成了跨区部署和自动故障切换，才适用那一档条款。仅仅采购了多个可用区的资源但没有做流量调度和数据复制，架构上仍然是单点。

索赔时限一般多久，错过了怎么办？条款里通常写"事件发生后的若干天内提交"，具体天数需要看你签署的文本。错过时限的后果是视为放弃，几乎没有补救空间。可行的做法是：把提交时限写进运维值班手册，指定专人负责，并在故障处置的收尾清单里设一个强制检查项，避免所有人都在忙于恢复而忘了申报。

赔偿能不能覆盖业务损失？不能，而且差距通常很大。赔偿的计算基数是"受影响服务的当期费用"，量纲是资源租赁费用的百分比；业务损失的量纲是营收绝对值。两者之间没有任何换算关系。这也是本文最想强调的一点：条款是事后补偿机制，不是风险对冲工具，真正降低中断损失的是冗余、故障切换和演练。

本文关于服务器服务等级条款的判断边界

本文不讨论任何具体厂商的条款数值，也不承诺任何赔付。文中出现的分档比例、窗口时长、通知提前期、索赔时限等描述，全部是对行业常见条款结构的归纳，属于"行业常见写法是……"这一层面的表述，不代表任何一家服务商的实际条款内容。同一家服务商的不同产品线、不同部署形态、不同合同版本之间，条款也可能存在明显差异。

本文给出的换算方法、阅读顺序和检查表是通用的分析工具，适用于任何一份服务等级条款的阅读；但具体能拿到什么承诺、能赔多少、走什么流程，只能以你实际签署的合同文本为准。签署前建议由法务与技术共同参与评审，把定义、计量、排除、基数、上限、取证这六项逐条确认，并要求对方对含糊表述给出书面澄清。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在阅读服务等级相关条款时，建议按"定义—计量—排除—基数—上限—取证"的顺序逐项确认，具体承诺内容以其官方公布与合同约定为准。

本文关于可用性换算与赔偿计算的口径说明

本文所有换算均按年 365 天、月 30 天的口径计算，未考虑闰年及大小月的差异，因此与实际按自然月统计的结果可能存在细微出入。换算公式为：年不可用时长等于 365 乘以 24 乘以 60 分钟再乘以不可用比例，月不可用时长等于 30 乘以 24 乘以 60 分钟再乘以不可用比例。若你的合同采用不同的年度或月度基准，请按合同口径重新计算。

文中"假设演算"部分使用的"100 个单位"是抽象计量单位，仅用于演示计算方法与量纲差异，不构成任何报价、费率或赔付承诺，也不对应任何真实币种与金额。该演算中的分档比例区间来自对行业常见条款结构的归纳，不代表任何具体合同的实际分档。

关于价格：本文不涉及任何具体服务的价格信息。服务器租用与机柜托管的费用主要受 CPU、GPU、内存、存储、带宽、IP 与线路等因素影响，具体报价需实时询价，以官网实时信息或咨询确认为准。文中出现的行业公开资料与市场参考数字，均不构成为任何一方的报价。