多云的优势：韧性、议价能力与灵活性

多云优势

发布于 2026 年 1 月 30 日，星期五

2025 年 10 月的 AWS 故障持续了 15 个小时。对于完全运行在 AWS 上的公司来说，这 15 个小时意味着服务全面中断、收入损失，以及一通通焦急的电话。对于采用多云架构的组织来说，这意味着在主供应商恢复期间，只需花几个小时重定向流量。

这并非假设。重大云故障确实会发生，而且你不能指望它们只是偶尔出现。将有韧性的组织与脆弱的组织区分开来的，不是运气，而是架构选择。

多云基础设施已经从防止供应商锁定的防御姿态，演变为一种能够释放灵活性、韧性和竞争优势的战略能力。然而，许多技术领导者仍然犹豫不决，被感知中的运营复杂性所震慑。这种复杂性确实存在，但可以管理；而持续被单一供应商锁定的成本，会随着时间推移不断累积，直到演变为灾难时才会显现。

为什么单云的舒适感正变得不可持续

云服务提供商已经从根本上改变了权力格局。最初围绕企业客户的激烈竞争，已经演变成这样一种局面：在规模化之后，组织会发现自己受制于供应商的单方面决策。

服务弃用可能只会提前有限时间通知，而且窗口期因产品和供应商而异；当你高度依赖单一供应商时，这会增加规划风险。定价结构会随着季度业务回顾而变化。区域容量限制会约束增长。合规要求迫使企业进行地理分布，而单一供应商无法满足。你需要的 AI/ML 能力存在于一个平台上，而你的核心基础设施却运行在另一个平台上。

考虑一下供应商依赖的数学关系。一家中型 SaaS 公司完全运行在 GCP 上，却发现其主要数据库服务即将停止支持。迁移工程成本高达数百万美元，时间影响至少是一个季度的功能开发延迟。与此同时，他们的竞争对手正在运行多云架构，并在一个周末内切换工作负载。

在实践中，大多数企业其实已经在运营多云环境。只是这种多云是意外形成的，而不是有意设计的。Shadow IT 造成凭据蔓延。并购带来不同的云足迹。各个团队在没有协调的情况下选择各自最优的工具。结果是多云混乱，而不是多云战略。

战略问题已经改变。它不再是“我们应该转向多云吗？”大多数组织其实已经在这样做了。问题是：“我们会有意地管理它，还是继续被动地回应供应商决策？”

多云的真实数学关系

多云架构引入了真实存在的复杂性。假装不是如此，是对评估这条路径的技术领导者的不尊重。诚实的判断很重要：是的，运营开销会增加，但这种复杂性的性质，与供应商锁定的风险特征有着根本不同。

管理复杂性会在多个维度上累积

每个云提供商都有不同的 API、控制台界面和运营范式。将同一个应用部署到 AWS 和 GCP，需要学习两种 infrastructure-as-code 方法、两套监控系统和两种 IAM 模型。团队需要在不同平台之间切换上下文，并在多个供应商生态系统中维持专业能力。

每增加一个供应商，安全挑战都会成倍增加

凭据会激增：API keys、service accounts、access tokens、证书。每个云都实现了不同的安全模型、审计日志格式和合规框架。

根据 Verizon 2025 年的 Data Breach Investigations Report，88% 的 Web 应用泄露涉及凭据泄露。若以传统方式管理，多云环境会指数级扩大攻击面。

这正是 secrets management 成为关键赋能因素，而不仅仅是另一个工具的地方。如果没有跨云的统一凭据管理，安全团队将面对一项几乎不可能完成的任务：在不同系统之间维持一致的策略、轮换计划和审计轨迹。像 Infisical 这样的 secrets management 平台，通过为所有云环境中的凭据提供单一控制平面，将这一挑战从不可逾越变成可处理。

集成和数据移动会产生隐性成本

云之间的网络延迟会影响应用性能。数据 egress charges 往往埋在定价细节中，当你在不同供应商之间移动大量数据时，这些费用会不断累积。

应用必须处理地理分布系统之间的最终一致性。

这里的区别在于：有些复杂性是前置的（例如标准化工具和抽象层），但多云也会带来持续的运营负担，这需要明确的责任归属和预算。

你只需构建一次抽象层，它随后就能服务于所有应用。供应商锁定会带来持续的业务风险，而且这种风险会不断叠加。依赖的每一年都会使迁移更加昂贵，每采用一个新服务都会增加切换成本。

真正重要的数学关系：

• 多云设置成本：前置、可预测、会随着时间摊销
• 供应商锁定成本：不可预测、可能是灾难性的，并且会随着时间增加
• 可选性的价值：会随着基础设施规模扩大而复利增长

云传输定价会随着时间变化，并可能重塑你的架构经济性。例如，AWS 在 2021 年降低了 internet egress pricing，随后又在 2024 年为切换供应商的客户取消了某些 transfer fees。多云准备并不能保证更低成本，但当定价变化时，它可以减少锁定并改善你的谈判地位。

让这一切运作起来的抽象层

那些在多云上取得成功的组织，并不会把每个供应商当作需要独立管理的孤立系统。他们会构建统一的抽象层，在所有云上提供一致的接口，将复杂性从乘法效应转变为加法效应。

Infrastructure as Code 提供了基础。 Terraform 和 Pulumi 支持云无关的基础设施定义。IaC 减少了重复，并支持一致的工作流，但真正的可移植性仍然需要 provider-specific resources、guardrails 和测试。这不是理论上的事情。团队可以用单一代码仓库管理跨多个云的数百个生产服务。

容器编排消除了应用层锁定。 Kubernetes 已成为多云运行时的事实标准。被打包为容器的应用可以在任何 Kubernetes 集群上以相同方式运行，不受底层云提供商影响。应用逻辑中没有硬编码的 AWS SDK 依赖，也没有 GCP-specific 的服务集成在制造迁移障碍。可移植性是真实且即时的。

可观测性平台聚合监控。 不必分别在 CloudWatch、Azure Monitor 和 GCP Operations 之间来回切换，Datadog 或 Grafana 等平台提供单一视图的可见性。定义一次告警，并将其一致地应用于所有基础设施。排查故障时，无需在各个供应商控制台之间切换上下文。

secrets management 是关键的连接纽带。 每个应用都需要数据库密码、API keys、加密证书和 service account tokens 等凭据。传统方法会让这种复杂性成倍增加：分别管理 AWS Secrets Manager、GCP Secret Manager 和 Azure Key Vault，而它们各自都有不同的 API、轮换机制和审计格式。

统一的 secrets management 平台解决了最棘手的多云挑战。借助 Infisical，安全团队可以在所有云之间执行一致的策略。开发者无论部署目标是什么，都使用同一种工作流。凭据会在统一计划下自动轮换。审计日志会聚合到一个位置。凭据蔓延问题——多云安全风险中最主要的问题之一——从根源上得到解决。

这比基础设施可移植性更重要。应用理论上只要容器化就可以在任何地方运行，但如果其凭据散落在各个供应商特定的 secret stores 中，那么这种可移植性就只是理论上的。统一的 secrets management 让多云从一种愿景变为现实。

把多云从负担转变为能力的关键洞见在于：抽象层并不会随着云的数量成倍增加运营开销。它们增加的是可控的一次性复杂性，而这种复杂性会在灵活性上带来复利回报。构建正确的基础设施：统一 secrets management、infrastructure as code、可观测性、CI/CD——多云的运营反而会比在单云部署中管理供应商特定工具更简单。

实用行动手册

战略性地采用多云遵循成熟模式。成功的组织不会陷入非此即彼的迁移陷阱，而是会在维持运营稳定的同时逐步构建能力。

从多云能立即带来价值的工作负载开始。灾难恢复是风险最低的切入点。将关键系统复制到第二个云提供商，而不改变主要运营。当你的主供应商出现区域性故障时，故障切换机制会自动激活。Warm standby 可能成本不低，但它是可预测的。故障影响会因商业模式而异，但对于收入关键系统，停机很快就会变得极其昂贵。

地理优化可带来切实的性能提升。你可以将服务部署到离用户更近的地方。北美流量使用 AWS，欧洲客户使用 GCP，亚太地区使用区域性提供商。延迟改善会直接转化为转化率和用户满意度指标的提升。

最佳工具组合选择可以解锁单一供应商无法提供的能力。使用 BigQuery 做数据分析，AWS 做通用计算工作负载，Azure 做企业集成。每个云在特定领域都有优势，而多云架构让你能够利用这些优势，而不是接受妥协。

在迁移现有系统之前，先构建支撑性基础设施。 顺序很重要。在没有基础工具的情况下尝试多云迁移，会制造出让多云声名狼藉的运营噩梦。先建立这些能力：

统一 secrets management。 在将应用分布到多个云之前，先解决凭据管理。Infisical 为 AWS、GCP、Azure 和本地基础设施中的 secrets 提供控制平面。应用只需一次认证，即可通过程序化方式获取凭据，并且永远不会在代码或配置文件中暴露静态 key。这一项投入就能消除最常见的多云安全失败模式。

Infrastructure as Code 工具。 在扩大云足迹之前，先标准化 Terraform 或 Pulumi。定义可部署到任何 provider 的基础设施规范。将基础设施与应用代码一起进行版本控制。通过自动化流水线和适当的审查流程进行变更部署。

可观测性和监控。 在运营负载增加之前，先实施统一监控。将所有环境中的日志、指标和 traces 聚合到单一平台。配置无论应用运行在哪都能一致工作的告警规则。

具备多云部署能力的 CI/CD 流水线。 GitHub Actions、GitLab CI 以及类似平台都支持通过单一流水线向多个云部署。尽早建立这项能力；对现有部署流程进行改造，比从一开始就构建多云支持更具破坏性。

经验证的迁移模式

• 第一阶段：新工作负载从第一天起就以多云原生方式部署。将可移植性作为一等要求来设计。这能在不危及现有生产系统的情况下建立组织能力。
• 第二阶段：迁移非关键的现有工作负载以积累经验。选择具有明确回滚路径的服务。记录不同 provider 之间的运营差异。构建可跨云工作的 runbooks。
• 第三阶段：在成熟的运营实践下迁移关键系统。到这时，团队已经具备管理多云部署的经验，监控工具已经得到验证，incident response 程序也已考虑了多云复杂性。

常见陷阱

• 分布式单体陷阱：在多个 provider 上复制单云架构，却不为可移植性重新设计。这会造成最糟糕的结果：复杂性倍增，却没有灵活性的收益。
• 被无数工具拖垮：为每个云环境采用不同工具。标准化可在任何地方工作的抽象层。三个统一平台是可管理的；十二个供应商特定工具则不行。
• Shadow IT 卷土重来：在多云环境中，治理比以往更重要，而不是更不重要。团队不应在没有协调的情况下独立采用云服务。中心化 secrets management 和 infrastructure as code 可以强制保持必要的一致性。
• 成本盲区：从第一天起实施全面的 tagging 策略。持续监控数据 egress cost，尤其是跨云流量。云提供商会把这些费用埋在定价细节中，但当你在平台之间移动数据时，它们会迅速累积。

那些在多云上胜出的组织并没有做什么神奇的事。他们投资了使多云可管理的基础设施，尤其是统一的 secrets management，然后系统性地建立专业能力。技术挑战是真实存在的，但已经有了解法。战略优势会随着时间复利增长。

作为竞争优势的自由

多云架构并不是因为时髦才将基础设施分布到多个供应商上。它关乎功能与自由，关乎拥有在每个时刻为每个工作负载做出最优选择的能力，而不受供应商依赖施加的人为约束。

具体的业务优势

谈判筹码会改变供应商关系。当云提供商知道你可以迁移工作负载时，定价讨论会发生巨大变化。拥有可信多云能力的组织能够获得更好的合同条款、更灵活的承诺以及优先支持。单云客户只能接受季度业务回顾中带来的任何定价变化。

当你可以在不进行整体迁移的情况下采用新能力时，创新速度会加快。当云提供商发布突破性的 AI/ML 服务时，多云组织可以立即开始使用，例如在一个平台上运行 AI 工作负载，同时核心基础设施仍保留在其他地方。单云组织只能等待其供应商开发出等效能力，或者面临大规模迁移项目。

韧性不再只是基础设施 uptime，而是业务连续性。但云提供商的服务弃用、定价变化和战略转向并不会消失——它们是长期存在的。多云架构为那些与你业务要求相冲突的供应商战略决策提供了保险。

成本优化从理论变为实践。真实的价格比较、谈判中的真正筹码、能够根据实际使用经济性而不是沉没成本来调整工作负载。“我们应该评估其他供应商”和“我们正在积极部署到 GCP”之间的差别，就是姿态与筹码之间的差别。

监管合规变得可实现，而不是停留在愿景中。数据主权要求迫使进行地理分布。GDPR 规定、金融服务监管，以及带有特定云要求的政府合同。多云架构可以处理这些要求，而不会迫使企业做出限制业务的妥协。

人才优势会在竞争激烈的招聘市场中显现。开发者希望使用一流工具，而不是被供应商锁定的技术栈。能够提供跨云平台经验、接触多样化技术，以及摆脱僵化供应商生态系统自由的组织，会吸引更强的技术人才。

战略重构

将多云视为运营负担的公司会因复杂性而挣扎，因为他们解决的是错误的问题。他们试图维护彼此独立的云环境，而不是构建统一的抽象层。

将多云视为战略能力的公司会投资于支撑性基础设施，包括统一 secrets management、infrastructure as code、可观测性平台和 CI/CD 自动化。随着基础设施规模扩大，他们会获得复利回报。

技术领导者面临的问题，不是你是否最终需要多云灵活性。市场动态、供应商行为和技术要求，使这对规模化运营的组织来说不可避免。问题在于，你会主动构建这种能力（在你有时间把它做对的时候），还是被动地在某个供应商决策迫使你行动时再去做。

那些在 2023 年建立了多云能力的组织，在 2024 年定价讨论中争取到了更好的条款。那些在 2024 年建立了多云能力的组织，在 2025 年的区域故障期间维持了运营。模式是一致的：对灵活性的主动投资，会在最关键的时候带来筹码。

摆脱供应商锁定的最佳时机，是在你被锁定之前。第二好的时机就是现在。从基础开始。跨你的基础设施实施统一 secrets management。采用 infrastructure as code 实践。将应用容器化以获得可移植性。在维持运营稳定的同时，逐步构建这些能力。

多云的技术挑战是已解决的问题。战略优势会随着时间复利增长。唯一的问题是，你会有意选择构建这种能力，还是继续在供应商决策的摆布下运营。

多云，而无需支付运营税

当多云以明确意图实施时，它可以成为真正的优势。这意味着独立的故障域、可移植的部署模式，以及对持续开销的清晰理解。

它的收益是在价格、可用性或组织需求变化时具备韧性和灵活性。它的代价是复杂性，而这种复杂性只有在你主动为此设计并进行测试时才值得付出，尤其是对于有状态系统、身份和 incident response。

如果你想获得这些好处，而不在各个 provider 之间搭建脆弱的 glue，那么就先标准化基础。先从那些以后最难拆解的部分开始，比如 secrets、machine identities 和策略 enforcement。

Infisical 是一种可帮助团队的方案，它为在不同环境中管理 secrets 和 machine identities 提供了一致方式，并带有策略控制、可审计性以及可跨云工作的工作流。

无论你采用 Infisical 还是其他方案，目标都相同：降低切换成本，让你的 security 和 ops 基础原语保持一致，并使多云成为一种有意为之的能力，而不是偶然形成的蔓延。

Mathew Pregasen

Infisical 技术写作者

• 原文链接： infisical.com/blog/multi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～