1. 混合云与多云生产环境全景

在进入具体的可靠性治理技术之前，需要先建立一张清晰的“环境地图”：我们管理的到底是什么样的系统，它由哪些部分组成，为什么企业会选择这种形态，以及它给可靠性带来了哪些在单云环境中不存在的难题。本章不讨论某个具体产品的操作，而是为后续 29 章建立统一的术语、架构视角和问题框架。

一、核心定义：混合云与多云不是同义词

混合云（Hybrid Cloud）强调“同构互通”：私有云/自建数据中心与至少一个公有云之间，通过专线、VPN 或云联网打通网络，并具备统一的身份、镜像、编排或数据面，使工作负载可以在两侧迁移或协同。它的关键词是连接与一致性。

多云（Multi-Cloud）强调“多供应商并存”：同时使用两家及以上公有云（如阿里云 + AWS，或 AWS + Azure + 腾讯云），可以是完全独立的孤岛，也可以部分互通。它的关键词是分布与异构。

两者经常叠加出现：一家企业可能既有自建 Kubernetes 集群，又同时使用两家公有云，这就是典型的“混合 + 多云”生产环境。后续章节统一用“混合多云”指代这种复合形态。

二、典型架构：四层视角

理解混合多云，最有效的方式是按“资源—网络—平台—治理”四层来看。下图给出一个典型生产环境的架构关系，注意其中的跨云连接、统一控制面和数据同步路径。

这张图揭示了混合多云治理的核心矛盾：上层越统一，下层异构带来的摩擦就越明显。例如统一的可观测性要求所有集群上报相同格式的指标，但不同云厂商的托管 K8s 在节点标签、网络插件、存储类上各不相同，采集侧必须做适配。

三、业务驱动因素：为什么企业会走到这一步

混合多云很少是“为了技术而技术”，通常由以下四类现实驱动：

• 风险分散与合规：避免单一供应商故障导致业务全停，或满足数据驻留、行业监管要求，必须把部分数据留在自建机房或特定地域。
• 成本与弹性：稳态负载放在自建或包年资源，突发流量用公有云按量实例承接，形成“基线 + 弹性”的成本结构。
• 能力互补：某云的大数据产品更强，另一云的 AI 推理或 CDN 更有优势，业务按能力选型而非绑定一家。
• 组织与并购：不同事业部或收购来的团队已各自上云，短期内无法也不值得强行统一。

这些驱动因素决定了混合多云环境的“形状”是高度定制化的，也决定了可靠性治理不能照搬单云方案。

四、可靠性治理的独特挑战

在单云环境中，可靠性主要围绕可用区、实例、SLB、RDS 高可用等展开。到了混合多云，问题维度显著增加：

其中最容易低估的是跨云链路。一条专线中断，可能同时影响数据同步、服务调用和配置下发，但监控上只表现为“某服务超时”，排查时需要在网络、平台、应用三层之间反复切换。后续章节会专门讨论跨云链路的可观测性与故障演练。

五、课程实战目标

本课程不追求覆盖所有云产品的操作细节，而是围绕一条主线：让混合多云环境中的关键业务达到可定义、可观测、可演练、可恢复的可靠性水平。具体目标包括：

1. 能画出自己环境的四层架构图，并标出所有跨云连接点和单点风险。
2. 能为跨云核心链路定义 SLO，并区分“云厂商责任”与“自身责任”。
3. 能设计一次跨云故障演练，验证切换时间与数据一致性是否达标。
4. 能建立统一的变更管控与配置基线，减少多控制面带来的漂移。