多云与混合云工程：成本、身份与统一编排

动机要能支撑"复杂度成本"：
  合规与数据主权：数据必须留在某地域/某云（政治与行业要求）
  供应商风险：避免被单一厂商锁定，保留议价与迁移选项
  最优能力：不同云在某领域更强（如某云对象存储/某云 GPU）
  容灾：跨云双活，应对"整朵云不可用"的极端故障

复杂度：两套账号/网络/身份/成本模型，运维面翻倍
技能：团队要同时会两朵云，招聘与培训成本高
排障：跨云问题定位难，指标和日志要对齐才可比
成本失控：账单分散、对不上、没人看得全

# 一个 repo 管理多云：按 cloud 分目录
provider "aws" { region = "ap-southeast-1" }
provider "gcp" { project = "shop-prod" }
# 目录划分
# modules/aws/vpc/        modules/gcp/vpc/
# environments/prod/aws/  environments/prod/gcp/

# 分 state 隔离，避免跨云资源互相踩
terraform init -backend-config=envs/prod/aws/backend.hcl
terraform plan -out=plan.tfplan   # 只操作当前云
# 每次变更限定在一个云内，跨云编排放 CI 里串

# Crossplane 用 K8s CRD 声明云资源，统一在集群内编排
apiVersion: aws.upbound.io/v1beta1
kind: RDSInstance
metadata: { name: shop-db }
spec:
  forProvider:
    engine: postgres
    region: ap-southeast-1
    instanceClass: db.t3.medium
  providerConfigRef: { name: aws-provider }

优势：应用团队只写声明，云差异由平台 provider 屏蔽；
  配合 GitOps，多云资源统一走"PR → 审批 → 同步"流程

抽象要"薄"：屏蔽差异，但不隐藏计费/配额/网络这些要命的差异
先建共享模块（网络/安全组/命名规范），再建服务级模块
不要为"移植性"过度抽象：抽象层本身也是维护成本

身份源：企业 IdP（Okta/Azure AD/自建 Keycloak）作为唯一可信源
  员工入职/离职只改一处；各云通过 SAML/OIDC/SCIM 联邦，自动同步与吊销

原则：用"角色"而非"人"做权限
  同一个业务角色（如 app-prod-deployer）映射到各云的等价权限
  禁止各云分别建账号、手工发钥匙

# 各云都优先临时凭证，禁用长期密钥
aws sts get-session-token --duration-seconds 900
gcloud auth login --brief   # 短时令牌
# CI 里用 OIDC 联邦：工作负载身份直接从 IdP 换云凭证，无静态 secret

定期审计：跨云权限清单季度复盘，清理僵尸角色与 unused 权限

各云账单导出到统一成本仓（如 BigQuery/S3 + 成本管理平台）：
  统一标签（service/team/env）是关键，没标签的成本 = 没主
每日聚合 → 团队/服务粒度报表 → 预算与超支告警

可见性：谁用了什么花了多少，仪表盘人人可看
归属：成本打回团队预算（Chargeback/Showback）
优化：空闲资源下线、按需实例、Reserved/Commit 用对场景
节奏：月度成本评审会，讨论增长点与回收项

跨云流量费：云间数据迁移/复制流量很贵，架构要"数据就近"
重复计费：同一服务在两个云各跑一套，容量利用率双低
方案：明确"每朵云跑什么"，避免同 workload 双跑冗余

互通方案：
  专线/云互联（AWS Direct Connect + GCP Interconnect 等）
  云间 VPN（低成本但延迟/带宽受限）
  公网 + 严格加密（低敏感场景）
设计：中心 hub 账号集中管理跨云网络，避免点对点乱接

数据引力：计算要向数据靠拢，跨云搬数据又贵又慢
架构原则：服务与其数据在同一云内，跨云只传"聚合结果/变更日志"
  例如：某云存用户库，另一云只放只读副本或数据湖分析

跨云双写数据库 = 分布式一致性难题，别轻易做
务实方案：数据主副本在一个云，另一云做异步副本/容灾，
  业务层容忍最终一致；需要强一致就接受单云部署

双活前提：应用无状态 + 数据可复制 + 流量可全局调度
  全局负载均衡（如 DNS 流量策略）按区域/故障切换
  状态外置到可复制存储，会话/缓存要能跨云重建
只有真正把"单点数据"消除了，双活才是双活，否则只是"多活了个壳"

至少做到"备份跨云"：对象存储/数据库备份复制到另一云
RPO/RTO 分级：核心数据 15 分钟 RPO 的用持续复制，次要数据日备即可
定期演练恢复：光备份不演练 = 没有容灾

每半年一次"主云失联"演练：
  切流量到备云 → 验证核心路径 → 回切
演练要真实阻断流量（模拟机房失联），别用"看看配置"替代

两朵云各出一套监控 = 排障时两边对不上
方案：统一采集层（OpenTelemetry）→ 统一存储（Prometheus/云上托管 + 集中日志）
字段规范化：service/team/env/cloud 作为统一标签，跨云查询

一次请求跨云经过多个服务 → 必须统一 trace 才能定位慢在哪
OpenTelemetry 采集，trace 带 cloud 标签，统一 trace 后端

两朵云告警进同一 Alertmanager/值班系统，SLO 与事件流程不分云
告警归一到统一事件平台，避免"AWS 一套人、GCP 一套人"割裂

平台团队统一管理多云底座（网络/身份/成本/可观测）
业务团队不感知"哪朵云"，只消费平台能力（黄金路径）
设"多云架构师"角色：负责抽象层与差异决策

变更流程统一：无论哪朵云，变更都走同一审批/灰度/回滚
供应商接触：采购/合同/支持 SLA 由平台团队统一管理

策略即代码：成本限额、区域限制、加密要求用策略引擎统一执行
  例如：禁止开未审批区域、对象存储强制加密、超预算自动告警
审计合规：跨云权限与资源配置定期审计，留痕可回溯

某金融集团（概念案例）：合规要求数据留在两朵云的不同地域
  采用：统一 Terraform 仓库 + Crossplane 声明 + 企业 IdP 联邦 + 统一成本仓
  网络：中心 hub 专线互联；数据：主库在 A 云，B 云只读副本做容灾与报表
  结果：跨云资源从"手工对不齐"变成 PR 审批即同步；成本报表团队级可见；
      双活演练 4 小时完成切换，核心服务 RPO 15 分钟

□ 用决策矩阵确认"真需要多云"，别为备份上多云
□ Terraform 分云分 state，一次变更只动一个云
□ Crossplane/GitOps 统一多云资源编排
□ 身份用企业 IdP 联邦，各云角色映射 + 临时凭证
□ 统一标签 + 账单聚合，成本打回团队，月度评审
□ 跨云网络走中心 hub，服务与数据就近
□ 双活只做无状态 + 可复制数据；至少备份跨云
□ 统一可观测性（OTel 标签 + 统一 trace + 统一告警）
□ 平台团队统一治理，策略即代码，定期演练与审计