云服务的「不可抗力」条款,早就把最致命的那种宕机排除在外
最可能让你的业务在多个区域同时断线的,不是硬件故障,而是蓄意的敌对行动。这恰恰是云服务商合同、SLA和你的业务中断险各自设计用来拒赔的场景。这个缺口没有定价,没有投保,却实实在在压在你的资产负债表上。
打开你云服务商的主协议,找到「不可抗力」条款。AWS的用户协议明确将「非其合理控制范围内的事件」排除在其责任之外,并列举了战争与恐怖主义。就这一句话,悄悄决定了当一切同时崩溃时谁来买单,而答案不是服务商。最可能在同一小时内打垮多个区域的,是蓄意的敌对行动,而这恰恰是合同明文排除的那一类。去读一读你自己的条款,这种写法几乎是行业惯例。于是,相关性最高、破坏力最强的那种故障,恰恰是服务商已经明确表示不会兜底的那种。
SLA(服务级别协议)填不上这个缺口,它自己的数字就说明了这一点。AWS计算服务的SLA规定,月度可用率跌破99.99%时赔付10%服务额度,跌破99%时赔付25%,只有跌破95%才赔付100%,而且每一档都是该项服务账单的额度返还,不是弥补业务损失的现金。算笔账:如果你的月度云支出是五位数(以美元计),一次灾难性的多日宕机能拿到的赔付上限,也只是一笔五位数的额度,还只能花在那个刚刚让你掉链子的服务商身上。SLA从来都不是业务连续性保障,它是一张服务质量的折扣券,把它当成财务兜底,是第一个定价错误。
剩下能指望的就是保险,而这里的缺口只会更大。业务中断险和网络安全险普遍将战争与敌对行动列为标准除外条款,一旦损失金额巨大,保险公司往往会援引这类条款。2017年那场重创一家跨国制药企业、造成数十亿美元级损失的NotPetya恶意软件事件,后来成为标志性案例:保险公司以「敌对与战争行为」除外条款拒赔,官司打了好几年。此后保险市场的应对方式是收紧而非放松,伦敦劳合社(Lloyd's)甚至要求独立网络保险单必须明确排除「国家支持的攻击」。也就是说,董事会默认能兜底相关性故障的三道防线,服务商合同、SLA和保险单,恰恰都设计成在敌对行动引发宕机时全身而退。以上说的是行业普遍惯例,不是对你具体条款的裁定,你应该去读自己的条款。但如果相关性最高的宕机恰好就是不投保的宕机,风险并不会因此消失,它只是悄悄转移到了你自己头上。
未投保的多区域宕机,实际代价是多少?
假设一家年营收8000万美元的企业,这意味着一个正常交易日大约对应21.9万美元的营收。假设一次相关性事件让其主要服务商的多个区域瘫痪三天,而且如上文所述,SLA和中断险都以「除外事项」为由拒赔。直接营收风险大约是66万美元,这还没算上违约金、商誉损失,以及那些在你「离线」期间悄悄改用竞争对手服务的客户。这些数字只是示例,请代入你自己的数据,但结构是成立的:损失没有上限,而且全部压在你自己的资产负债表上,因为你以为能兜底的那些机制,全都在这一刻选择了置身事外。
你花钱买的冗余架构,为什么挡不住这种风险?
因为冗余架构是为「意外」定价的,而蓄意打击不是意外。多区域架构建立在一个假设之上:故障是相互独立的。两个区域在同一时间窗口内同时出问题的概率,大致等于两个小概率相乘,结果是一个小得多的数字,所以把负载分散开,整体宕机的概率就会低到可以忽略不计。面对硬件故障、断电、配置失误和极端天气,这套算法是成立的。但对手只需一步就能打破它:因为攻击者读到的是和你同一张架构图,他会同时选中你的两个区域,在同一小时内下手。一旦故障是被「选中」而不是「抽中」的,独立性假设就不成立了,冗余带来的那点概率安慰也随之消失。客户用来设计容灾方案的信息,基本上就是攻击者用来击破它的信息,而服务商按照设计公开了大致的架构形态,本意正是让你据此做容灾规划。
为什么云集中风险现在是业务连续性问题?
两个变化把这件事从「尾部风险」推进了规划范围。第一,云服务的版图变小了:Synergy Research Group的公开数据显示,三大云服务商合计占全球云基础设施收入的约三分之二,也就是说,大多数企业的云资源如今都集中在少数几家服务商的版图之内,这正是一次单点的敌对行动能演变成跨租户相关性事件的原因。第二,政治叙事变了:美国现政府将其「AI行动计划」定位为维持美国技术主导地位的战略,这让任何反对该政府的一方,都可能把商业数据中心重新归类为战略目标。你不需要一次具名的事件才能为这个风险定价,集中度和被针对的逻辑本身就足够了。真实事件只是让它变得具体:此前就有过声称(应以对交战一方宣传的怀疑态度看待)商业数据基础设施被列为打击目标的说法,比如伊朗伊斯兰革命卫队曾宣称袭击了亚马逊位于巴林的数据中心,这是冲突一方单方面的表态,没有得到证实回应。即便未经证实,它也说明,已经有人把商业数据中心当作合法的军事目标看待。建筑物本身没有变,它的围栏、合同和保险条款也没有变,变的只是打击清单。
能不能为无法投保的宕机提前做计划?
在单一云服务商的版图内,你买不走这份风险,关键部分也保不了险,所以应对手段只能落在运营层面。别再问「我的服务商够不够可靠」,这个答案取决于别人家的安保和别人家的意图,你控制不了。要问的是你自己能回答的问题:业务在90%、50%、10%的运力下,分别还能交付什么,能撑多久,对客户和声誉的代价是多少?大多数连续性预案是二元的,要么在线,要么离线,「切换到另一个区域」是一句写在计划书里的假设,不是真正的计划。分级降级方案成本低、可测试,而且能在一次没有任何理赔支票能阻止的相关性故障中真正撑住。
提前决定先放弃哪些服务,不惜代价保住哪些服务,以及「运力降到10%」对订单处理或安全底线具体意味着什么,这和设计在压力下仍可控的系统是同一种纪律,应该被写进你的技术战略正文,而不是压在一份没人演练过的附录里。多云架构对少数「必须存活」的关键业务是值得的投入,因为它消除了攻击者可以利用的单一版图相关性,但它也会带来真实的复杂度。把它当成为「必须存活」的部分买的定向保险,而不是一次全盘重建。
云本身不是问题,各家服务商为它们被要求解决的那类故障,确实造出了足够好的机器。缺口在你自己的预案里:那份你没读到最后一条的条款,那张你误当成保障的SLA,以及你从未定价过的风险敞口。去搞清楚你的不可抗力条款和中断险到底排除了什么,再决定当那件被排除的事情真的发生时,你还能运行什么。这是下一次架构搭建之前要做的功课,不是下一条头条新闻之后才补的作业。
常见问题
一旦发生针对数据中心的蓄意攻击,我的SLA或业务中断险会赔付吗?
多半不会。云服务的不可抗力条款通常把战争和恐怖主义列为服务商责任范围之外的事件,网络保险和业务中断险也普遍设有敌对行动除外条款,一旦损失巨大,保险公司会援引这类条款,NotPetya的诉讼就是先例。SLA服务额度只按比例返还受影响服务的账单,从不覆盖业务损失。请去读你具体的服务商协议和保单条款,不要假设最伤人的那个场景一定有保障。
我该怎么估算自己在云集中风险上未投保的敞口?
先算出依赖相关系统的日营收,乘以一次相关性事件的合理持续天数,再加上违约金,以及对客户流失和声誉损失的合理估计。然后减去在「除外事项」成立的情况下,保单和SLA实际会赔付的部分,而这部分往往接近于零。剩下的数字,就是压在你资产负债表上、从未被定价过的风险敞口。
如何为云宕机制定分级降级预案?
先定义业务在90%、50%和10%运力下分别能交付什么,决定先放弃哪些服务、不惜代价保住哪些服务,并测算每一档对客户和声誉的代价,然后拿去演练。目的是把「要么在线要么离线」的二元假设,变成你在压力下真正能执行的经过测试的决策,因为当保险和SLA都选择置身事外时,这正是你唯一能掌控的应对手段。
相关阅读
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。