当你的团队开始把工作负载分散到多个云厂商时，多云 DevOps 策略就不再是“要不要做”的问题，而是“怎么把碎片化的工作流重新缝合起来”的工程挑战。本文不打算从概念讲起，而是直接进入几个典型场景：你在 AWS 上跑生产、在 Azure 上做灾备、在 GCP 上跑数据分析，同时还要用 GitHub 管理代码。你会发现，工具链的割裂、数据口径的不一致、以及发布流程的混乱，是三个最先浮出水面的痛点。
场景一：多集群部署，监控数据却各说各话
假设你在三个云上各有一套 Kubernetes 集群，每个集群都自带云厂商的监控面板。当线上出现故障时，你不得不来回切换多个控制台，才能拼凑出完整的调用链。更麻烦的是，不同云厂商对“错误率”的定义可能不同，导致跨云对比时数据对不上。
这时，你需要的不是再引入一个“统一监控平台”，而是一个能收集所有云上指标、并统一存储和查询的可观测性后端。Prometheus 就是这样一个开源系统，它最初由 SoundCloud 开发，2016 年加入云原生计算基金会（CNCF），成为继 Kubernetes 之后第二个托管的项目。它的核心是：把指标作为带时间戳的时间序列数据存储，并支持通过标签（label）进行灵活过滤。你可以把每个云上的 Prometheus 实例作为采集器，再通过联邦（federation）或远程存储把数据汇聚到中心。
具体操作时，你需要在每个集群中部署 Prometheus，并配置 scrape 目标（比如 node-exporter、应用自定义指标）。然后，在中心机房或一个独立的云上再部署一个“联邦”Prometheus，通过 scrape_config 中的 honor_labels 和 metrics_path 来抓取各子 Prometheus 的数据。这样，你就能在一个 Grafana 面板上看到所有云上的关键指标。
注意：联邦模式适合指标量不大的场景（比如几百个时间序列）。如果指标量极大，建议改用远程存储方案（如 Thanos、VictoriaMetrics），否则中心 Prometheus 会成为瓶颈。
场景二：跨云发布，CI/CD 流水线需要“多云感知”
你的代码存在 GitHub 仓库，每次 push 都希望自动构建、测试，然后部署到多个云环境。但不同云的认证方式、部署工具各不相同，如果流水线里写死某个云的 CLI，换云时就得重写。
GitHub Actions 允许你在仓库中定义自动化工作流，它天然支持多平台、多环境。你可以为每个云创建独立的 job，利用矩阵策略（matrix）并行部署。关键在于，你需要为每个云配置独立的 secret（如云厂商的 API 密钥），并在 workflow 中通过环境变量引用。这样，流水线代码本身是云无关的，只有密钥不同。
一个常见的误区是：把所有部署逻辑都塞进一个 job 中，用条件判断来区分云。这会导致流水线难以维护，且一旦某个云部署失败，整个 job 都会标记为失败。更好的做法是：为每个云创建独立的 job，并设置 needs 依赖，让它们并行执行。
如果你需要更复杂的部署策略（如灰度发布），可以考虑引入 Argo CD 或 Flux，它们与 GitOps 理念天然契合。但注意，这些工具本身也需要在多云环境中部署，你需要确保它们的 kubeconfig 能同时管理多个集群。此时，你可以参考我们之前的《DevOps 工具链选型：Jenkins、GitLab CI 与 Argo CD 对比》来做出取舍。
场景三：追踪链路，需要统一的遥测数据格式
当请求从一个云上的服务调用另一个云上的服务时，你很难追踪完整链路。不同云厂商的 APM 工具可能使用不同的 trace 格式，导致数据无法关联。这时，你需要一个厂商中立的遥测框架。
OpenTelemetry（OTel）正是为此而生。它是一个开源的可观测性框架，用于生成、收集和导出遥测数据（trace、metrics、logs）。目前已有超过 90 家可观测性厂商支持它，你可以用一套 SDK 在应用中埋点，然后导出到任何后端（如 Jaeger、Zipkin、甚至 Prometheus）。
实际操作中，你需要在每个服务中集成 OpenTelemetry SDK（支持 Java、Go、Python 等主流语言），并配置导出器（exporter）指向你的统一后端。对于跨云调用，你还需要在 HTTP 头中传播 traceparent 头，这样才能把不同云上的 span 串起来。如果你使用的是 Service Mesh（如 Istio），它也能自动注入这些头，但你需要确认版本兼容性。
一个常见的坑是：只集成了 trace，而忽略了 metrics。OpenTelemetry 允许同时导出 metrics，但你需要额外配置指标导出器（如 Prometheus exporter）。否则，你只能看到调用链，却无法看到资源使用率。
策略：统一数据模型，而非统一工具
从上面的场景可以看出，多云 DevOps 的核心策略是：统一数据模型，而不是统一工具。这意味着，你应该优先选择支持标准协议的工具（如 Prometheus 的 metrics 模型、OpenTelemetry 的 trace 模型），而不是每个云厂商的专有方案。这样，你才能避免被某个云厂商锁定，也能在迁移时保留已有的可观测性投资。
同时，你还需要在团队内建立“可观测性文化”，确保所有服务都按照统一的标准暴露指标和追踪信息。否则，即使工具再强大，数据不完整也无法发挥价值。
常见误区与失败条件
- 误区一：认为“多云 = 多一套监控”，于是为每个云部署独立的监控栈，导致数据孤岛。正确做法是建立统一的采集层。
- 误区二：在 CI/CD 中硬编码云厂商的 CLI，导致流水线不可移植。应该使用云无关的抽象层（如 Terraform、Pulumi）或通过 secret 注入。
- 误区三：忽略 OpenTelemetry 的标准化，继续使用不同厂商的 APM agent，导致 trace 无法关联。尽早引入 OTel 是长期投资。
失败条件也很明确：如果你没有足够的指标量级，就贸然引入复杂的远程存储方案，反而会增加运维负担；如果你没有跨云网络的基础设施（如专线或 VPN），即使工具链再完善，延迟和稳定性也会成为瓶颈。
参考资料
延伸阅读