别再手点云控制台了：用 GitOps 管多云，我踩过的坑都在这了

大家好，我是 Echo_Wish。

说个很真实的场景：
很多团队一边喊“多云战略”，一边每天在 AWS、阿里云、GCP 控制台之间来回点鼠标。

结果是什么？

资源越来越多，人越来越累，问题越来越难复现。

你以为你在“管理多云”，其实你在“手工运维分布式系统”。

今天我们聊点实战的：
怎么用 GitOps 把多云资源管起来，以及那些你迟早会遇到的冲突和回滚问题。

一、GitOps 的本质：不是工具，是“控制权回归”

很多人理解 GitOps 还停留在：

• 用 Git 管 YAML
• 用 CI/CD 自动部署

但我更喜欢一句话总结：

GitOps = 用 Git 作为“唯一真实源”（Single Source of Truth）

什么意思？

• 线上是什么状态，不看云控制台
• 只看 Git 仓库

👉 控制台是“结果”，Git 才是“原因”

二、多云为什么更需要 GitOps？

单云你还能“忍”，多云基本必崩：

1. 配置不一致（最常见）

比如：

• AWS 上是 3 节点
• 阿里云是 2 节点
• GCP 忘了改

👉 最后谁也说不清“标准配置是什么”。

2. 权限体系混乱

每个云：

• IAM 不一样
• API 不一样
• 审计方式不一样

👉 最终演变成：
“谁改的？不知道”

3. 故障不可复现（最致命）

线上挂了，你想复盘：

• 配置改过几次？
• 谁改的？
• 为什么改？

👉 全靠猜。

三、落地方案：一套能跑的 GitOps 多云架构

我给你一个简单但靠谱的结构：

Git Repo
 ├── environments/
 │   ├── prod/
 │   ├── staging/
 │   └── dev/
 ├── cloud/
 │   ├── aws/
 │   ├── aliyun/
 │   └── gcp/
 └── apps/

核心思想：

环境 + 云厂商 + 应用 三维拆分

1. 用 Terraform 做资源统一抽象

# aws 示例
provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "app" {
  ami           = "ami-123456"
  instance_type = "t3.micro"
}

# 阿里云示例
provider "alicloud" {
  region = "cn-hangzhou"
}

resource "alicloud_instance" "app" {
  instance_type = "ecs.t5-lc2m1.nano"
}

👉 关键点不是写代码，而是：

所有资源必须进 Git，禁止手改

2. 用 ArgoCD / Flux 做持续同步

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: multi-cloud-app
spec:
  source:
    repoURL: https://github.com/org/repo
    path: environments/prod
  destination:
    server: https://kubernetes.default.svc

👉 本质：

让系统自动“追 Git”，而不是人去点部署

四、冲突问题：GitOps 最大的现实考验

说句大实话：

GitOps 最大的问题不是部署，而是“冲突”。

场景一：人手改 vs Git 自动同步

比如你：

• 临时在控制台改了实例规格（救火）
• Git 里还是旧配置

结果：

👉 GitOps 系统下一次同步，又给你改回去了。

解决思路：禁止“野操作”

# 强制只读权限
deny_console_changes = true

或者：

👉 至少要有“漂移检测”：

terraform plan

场景二：多云配置分叉

比如：

• AWS 支持某特性
• 阿里云不支持

你写一套配置，直接炸。

解决思路：抽象 + 分层

variable "cloud_provider" {}

resource "aws_instance" "app" {
  count = var.cloud_provider == "aws" ? 1 : 0
}

👉 核心理念：

统一接口，不强行统一实现

五、回滚策略：GitOps 的“后悔药”

很多人觉得：

GitOps 有版本控制，不怕回滚

但现实是：

👉 你只回了代码，不一定回了状态

1. 最基础：Git 回滚

git revert HEAD
git push

👉 系统自动同步回旧版本

2. Terraform 状态回滚（重点）

terraform state list
terraform apply -refresh-only

👉 防止“状态漂移”

3. 灰度回滚（推荐）

replicas: 10
strategy:
  rollingUpdate:
    maxUnavailable: 2

👉 本质：

回滚也要像发布一样，分批进行

4. 多云回滚的关键原则

永远不要同时回滚所有云

为什么？

• 你至少要保留一个“正常环境”
• 否则就是全线崩溃

六、我踩过的一个坑（真实经历）

有一次我们做多云迁移：

• Git 配置没问题
• CI/CD 正常
• ArgoCD 也同步了

结果线上直接炸。

原因很简单：

某个云厂商 API 延迟，导致状态不一致

👉 最后结论：

Git 正确 ≠ 云状态正确

所以后来我们加了一层：

def verify_resource():
    # 检查真实资源状态
    return check_cloud_api()

if not verify_resource():
    rollback()

七、我对 GitOps 的一个真实看法

很多人把 GitOps当成“银弹”，但我更愿意这么说：

GitOps 解决的是“可控性”，不是“复杂性”

多云本身就是复杂的：

• 网络复杂
• 权限复杂
• 资源复杂

GitOps 只是帮你：

👉 把混乱变成“有记录的混乱”

八、最后一句话

如果你现在还在手动点控制台，我建议你尽快做一件事：

哪怕不做 GitOps，也先把所有变更写进 Git。

因为未来某一天你一定会问自己：

“这个资源当初是谁建的？”

那一刻，你就会明白 GitOps 的价值。