先问个问题:你们公司上一次网络中断,损失了多少钱?
我问过几个做 IT 的朋友,回答基本一致——说不清。能说清的是断了多久、影响了哪些系统、谁在群里骂了几句,但换算成钱,没人算过。
这大概是网络这件事上最普遍的一个盲区:大家都知道断网不好,但没人知道它到底值多少钱。 而只要这个数字算不出来,"要不要投入做冗余"这个问题在预算会议上就永远排在最后。
Cockroach Labs 和 Wakefield Research 做过一份叫《The State of Resilience 2025》的调查,访了北美、欧洲和亚太三地一千名 VP 级以上的云架构师和技术高管。它试图回答的就是这个问题。
先看频率:一年 86 次,每次 196 分钟
这份调查里我觉得最值得琢磨的,其实不是钱,是两个频率数字。
受访企业平均每年经历 86 次中断,平均每次持续 196 分钟。
86 次听起来还好,一年也就是每四天多一次。但乘一下:86 × 196 分钟 ≈ 16856 分钟,折合 281 小时,差不多 11.7 天。
也就是说,一家企业平均每年有将近十二天,某个系统处在不可用状态。
调查里还有个更直观的说法:69% 的公司至少每周都会遇到中断或服务干扰,14% 是每天都遇到。
每天。
这跟大部分人的直觉不太一样。我们印象里的"网络故障"是那种上新闻的大事故——某某云挂了、某某平台崩了。但实际上,绝大多数中断是小规模、短时间、局部的,它们不上新闻,也很少被记录,只是在某个工作日的下午让几十个人干等了二十分钟。积少成多,就是一年十一二天。
再看钱
调查里所有受访企业——100%——都在过去十二个月经历过因中断导致的收入损失。
具体金额上:
- 84% 的企业,单次中断损失至少 1 万美元
- 三分之一的企业,单次损失在 10 万到 100 万美元之间,甚至更高
- 规模大的企业(员工 1000 人以上、年经常性收入 5 亿美元以上)更惨,平均每次中断损失约 49.5 万美元,其中 8% 单次超过 100 万美元
把频率和金额放在一起,数量级就出来了:如果一家企业一年 86 次中断、每次哪怕只损失一万美元,一年也是 86 万美元。
这个乘法我做的时候有点犹豫——它假设每次中断的损失都一样,现实里当然不是,大部分小中断可能只损失几百块,而个别大事故一次就吃掉大头。所以这个数字应该当成量级参考,不是精确账单。但即便打个大折扣,它依然远超大多数公司在网络冗余上的年度投入。
更有意思的是另外两个数字
数据到这儿其实还只是"吓人"。真正值得想的是下面这组:
- 95% 的高管说,他们知道自己组织存在运营层面的薄弱环节
- 但 48%,也就是接近一半,承认公司的应对做得不够
- 只有 20% 认为自己的组织已经完全具备预防和应对中断的能力
看明白了吗?问题不在于不知道,而在于知道了也没动。
这才是这份调查里最真实的部分。它说明网络韧性这件事的障碍不是认知,是别的东西。
为什么明知道,还是不做
我的理解是,这里面有个结构性的不对称。
中断的成本是隐形的、事后的、分散的。 它不会开一张发票给你。它散落在:客服多接的那些电话、销售没跟上的那几个单、员工干等的那些工时、客户心里悄悄减掉的那点信任。这些成本真实存在,但没有哪个科目会把它们汇总成一个数字放到你面前。
而冗余的投入是显性的、事前的、集中的。 它就是一笔明确的钱、一份合同、一个要签字的采购单。
于是在预算会议上,一边是"一个具体的、马上要花的数字",另一边是"一种模糊的、可能不会发生的风险"。结果几乎是注定的。
那份调查里还提到几个更直白的阻力:根深蒂固的变革阻力、内部优先级不一致、系统老旧、预算僵局。翻译一下就是——不是没人想做,是这事推不动。
顺带说一句,这份调查是 Cockroach Labs 做的,而他们卖的正是"高可用的分布式数据库"。所以数字往严重了说是有动机的,读的时候该打个折。但即使打折,那些结构性的结论——中断很频繁、成本被低估、知道了也不动——和我实际接触到的情况是对得上的。
那怎么把这笔账算出来
如果你想推动这件事,第一步不是去找方案,是先把损失算成一个数。哪怕是个粗糙的数,也比"说不清"强得多。
一个能用的简化算法:
先算每小时的业务价值。 拿相关业务线的年营收除以年工作小时数,得到一个基准。比如一条年营收 3000 万的业务线,按每年 2000 工作小时算,大约是每小时 1.5 万。
再算受影响的比例。 中断未必让业务全停,可能只是效率下降。估一个折扣,比如 50%。
加上人力空转的成本。 多少人被卡住、卡了多久、他们的时薪大概多少。这部分容易被忽略,但在人多的公司里数字不小。
最后加上那些不好量化的。 客户流失、订单延误、口碑损伤、赶工补救——这部分给不出精确值,但至少要在报告里留一行,提醒决策者它存在。
四项加起来,你会得到一个虽然粗糙但可讨论的数字。它的价值不在于精确,而在于它把一个模糊的风险,变成了一个能和采购金额放在同一张表上比较的东西。
这一步做完,后面的对话性质就变了:不再是"要不要花这笔钱",而是"花这笔钱能挡住多少损失"。
跨境场景要额外算一笔
如果你的业务涉及跨境,上面这些还得往上加。
链路更长,可控性更低。 国内的网络出问题,你能找到人、能催、能预估恢复时间;跨境链路出问题,中间经过多少运营商、绕了什么路,你基本看不见。
时差让影响窗口更长。 你的白天可能是目标市场的深夜——问题在你们下班后发生,等有人发现时已经过了好几个小时。反过来,你们的深夜正是海外用户最活跃的时候,而那时候公司里可能一个人都没有。
恢复不由你决定。 国际链路的故障,修复节奏往往取决于运营商甚至更上游,你能做的只有等。在这种情况下,冗余就不是锦上添花,而是唯一的自救手段——因为你没法让它快点好,只能让业务不依赖它。
写这篇的起因,是最近又碰到几次同样的对话:客户说"我们其实一直想做备份链路,但一直没排上优先级"。
我完全理解。在没出事的时候,冗余看起来就是一笔多花的钱——你付了钱,但什么都没发生,那种"白花了"的感觉很难对抗。
但换个角度:什么都没发生,恰恰就是它在起作用。这跟买保险是一个道理,只不过网络这件事更隐蔽——保险你至少每年都会收到账单提醒你它的存在,而一条从没被启用过的备用链路,静悄悄地什么都不说。
所以我的建议还是那句朴素的:先算账。 算完之后,这件事该不该做、该做到什么程度,答案通常会自己浮出来。有些公司算完发现确实不值得,那也是个好结论——至少是想清楚之后的决定,而不是一直拖着。
如果你正在算这笔账,或者算完之后想看看跨境这段怎么做冗余,可以找我们聊聊。