这些年,大家不是忙着上云,就是忙着追 AI,好像不这样就跟不上时代潮流。 云计算和 AI 确实带来了很多便利,但技术潮流并不意味着所有业务都适合完全依赖云服务。尤其是在业务连续性和基础设施可靠性方面,上云并不等于万无一失。 Neon Cloud Outage Data Center1672×941 465 KB 2026 年 11 月 12 日,微软 Microsoft 365 发生全球性服务故障。此次事件主要影响 Exchange Online,导致部分用户无法正常访问 Outlook 邮箱,邮件投递也出现延迟。同时,一些依赖 Exchange Online 的 Microsoft 365 服务和功能,包括 Teams 日历、Copilot、Microsoft Graph 等,也受到不同程度的影响。 截至 11 月 13 日,微软仍在分阶段恢复受影响的基础设施。虽然服务可用性已经有所改善,但部分用户仍可能遇到间歇性访问问题和邮件延迟。 值得注意的是,微软尚未公布此次事故的最终根本原因,后续仍需等待官方事故报告。 健康检查也可能导致系统过载 在云计算和容器化系统中,健康检查(Health Check)是非常重要的机制。 举个例子,如果你在 AWS 上部署了 Docker 容器,并且更新了应用镜像,在采用滚动更新或蓝绿部署的情况下,通常可以在不中断服务的前提下完成版本升级。 一个典型的部署流程如下: 使用新的镜像创建容器实例。 等待容器启动,并进行健康检查(Health Check)。 健康检查通过后,将新实例加入负载均衡,并逐步切换流量。 确认新版本运行正常,完成流量切换。 将旧实例从负载均衡中移除,等待现有请求处理完成后再销毁。 如果没有负载均衡和多实例部署机制,直接重启单个容器或应用,通常就会造成短暂的服务中断。 对于个人博客和普通网站来说,几秒钟的中断可能问题不大,但对于支付系统、交易系统和企业办公平台来说,这种中断可能造成实际业务损失。 问题往往出现在第二步:健康检查。 如果应用启动时间较长,而健康检查的超时时间、重试次数或启动宽限期设置得不合理,系统就可能过早地将尚未完成启动的实例判定为不可用。 接下来可能出现这样的情况: 新实例因为健康检查失败而无法接收流量。 负载均衡器将流量集中分配给其他正常实例。 剩余实例承受更大的请求压力。 部分实例因资源不足而变得不可用。 更多实例被移出服务集群。 最终,一个局部故障就可能演变成整个系统的连锁故障(Cascading Failure)。 AWS ECS 等平台提供了健康检查宽限期、部署失败检测和自动回滚等机制,但具体行为取决于部署策略和参数配置,并不存在统一的固定故障等待时间。 基础设施冗余度是否足够 从此次 Microsoft 365 故障可以再次看到,云服务的可靠性不仅取决于服务器数量,还取决于整个基础设施的冗余设计和故障隔离能力。 一个真正可靠的云平台,至少需要考虑: 计算资源冗余: 单个服务器或实例出现故障时,其他实例能够接管业务。 网络冗余: 避免单一网络路径或网络设备成为故障点。 跨区域容灾: 单个数据中心或区域出现故障时,其他区域能够提供必要的服务。 容量冗余: 即使部分服务器下线,剩余服务器也有足够的处理能力。 故障隔离: 一个服务出现问题时,不应该无限制地影响其他服务。 如果一个系统在没有足够冗余容量的情况下运行,那么即使只是部分服务器出现故障,也可能导致剩余基础设施承受过高负载,最终形成连锁反应。 当然,不能仅凭这次事故就认定微软的最终问题一定是冗余不足,具体原因仍需要等待官方事故报告。 云服务并不意味着绝对可靠 微软以及其他大型云服务商经常强调自己的高可用性、容灾能力和服务等级协议(SLA)。 但是,SLA 并不等于服务永远不会中断。 对于企业而言,真正需要考虑的是:如果云服务商发生大规模故障,自己的业务是否还有其他运行方式? 例如: 企业内部是否保留必要的数据备份? 是否有独立于云邮箱的紧急通信方式? 关键业务是否存在备用处理流程? 是否能够在云服务恢复之前维持最基本的业务运转? 这些问题比单纯关注云服务商承诺的可用性百分比更加实际。 上云之前,应该考虑什么 云计算有自己的优势,但并不是所有基础设施都应该无条件地迁移到云端。 对于企业来说,合理的架构应该根据业务重要性、成本和可靠性要求进行选择。 有些业务适合完全使用 SaaS 服务,有些业务则需要保留本地基础设施,还有一些关键业务可能需要采用混合云或多区域部署。 真正重要的不是是否使用云,而是当云服务出现问题时,业务是否还有继续运行的能力。 很多基础设施上云,并没有宣传中那么美好。 https://www.isharkfly.com/t/o365/3713