鲁南快报美东时间11月12日，微软旗下Microsoft 365、Outlook等多项服务持续中断数小时，影响范围还溢出到了OpenAI等依赖其基础设施的下游服务。对很多公司来说，那半天的工作是这样度过的：邮件发不出、日历打不开、单点登录进不去、会议链接点开是错误页。
这类事故的破坏力，不在于某一个应用挂了，而在于它同时挂在了几个关键节点上。邮件是外部沟通的入口，日历是协作的骨架，身份认证是几乎所有内部系统的大门。三者同时不可用，企业不是“少了一个工具”，而是“整条流程停摆”。
更值得注意的是依赖的集中度。过去十年，企业IT从自建机房迁到少数几家公有云，成本降了、弹性有了，但也把风险集中了。当一家云厂商的区域性故障能同时影响办公套件、协作工具和AI服务，所谓“多云”在很多企业里其实只是“多买了几家的SaaS”，底层算力和身份体系仍然是单点。
SLA能赔多少？通常很有限。多数云服务的可用性承诺按月计算，几个小时的故障往往落在补偿门槛之下，赔的也多是服务抵扣额度，不是业务损失。指望合同兜住停摆，本身就不现实。
真正有用的是设计层面的冗余。身份认证准备一套本地或第二供应商的备用登录路径，关键系统保留降级方案（比如邮件不可用时切换到备用沟通渠道），对外发布页与内部状态页解耦，定期做一次“假设主供应商全挂”的桌面演练。这些动作不酷，但它们在故障发生的那两个小时里决定一切。
对普通用户，也有一条经验：重要的截止时间不要压在单一工具上，能本地保存的先保存，能提前发的别卡点发。系统可用性是概率问题，个人能做的只是不把自己放在最坏的那个分支上。
云把计算变成了水电，但水电也会停。可用性不是买来的承诺，是设计出来的冗余。