多云架构的提案听起来总是很完美：避免供应商锁定，根据任务需求选择成本最低的提供商来运行工作负载以优化成本，并通过在独立的故障域之间分布来提升韧性。从纸面上看，这是一个极具说服力的案例。然而在实践中，那些实际运营多云部署的团队往往描述的是截然相反的情况：运维复杂度翻倍，可观测性减半，以及一类仅因存在两朵云而非一朵云而特有的可靠性问题。我曾密切合作的一个团队，因当时 GPU 可用性和定价更优，将工作负载迁移至 AWS，同时将机器学习推理流水线部署在 GCP，随后花了接下来的八个月时间处理一类他们未曾预料到的故障：这些故障既非应用程序所致，也非任一云服务商的责任，而是存在于两者之间的边界地带。仅在负载下才会显现的数据传输延迟尖峰；仅在跨云调用时才会触发的认证令牌过期边缘情况；以及那些在预生产环境中通过所有测试，却在凌晨三点的生产环境中失败的网络安全策略交互。这些问题单独来看并不棘手，之所以棘手，是因为每朵云的诊断工具都指向内部，而故障恰恰存在于这两类工具均未覆盖的空间之中。