这些年，大家不是忙着上云，就是忙着追 AI，好像不这样就跟不上时代潮流。
云计算和 AI 确实带来了很多便利，但技术潮流并不意味着所有业务都适合完全依赖云服务。尤其是在业务连续性和基础设施可靠性方面，上云并不等于万无一失。
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 服务，有些业务则需要保留本地基础设施，还有一些关键业务可能需要采用混合云或多区域部署。
真正重要的不是是否使用云，而是当云服务出现问题时，业务是否还有继续运行的能力。
很多基础设施上云，并没有宣传中那么美好。
Comments