核心思想
把系统的期望状态用声明式文件描述，存放在 Git 中，然后用自动化工具确保实际状态与 Git 中的声明一致。
与传统方式的区别
传统（命令式）：
- 运维人员执行一系列命令：部署这个版本、改那个配置、扩容到 5 个实例；
- 系统的实际状态散落在多处（有人记得、有人不记得）；
- 出问题时，难以回答"系统现在应该是什么样的？"
GitOps（声明式）：
- 所有期望状态写在 Git 仓库的配置文件中；
- 要改变系统，就修改配置文件并提交 PR；
- 自动化工具（如 ArgoCD、Flux）持续监控 Git 仓库，把实际应用状态拉向声明的状态。
优势
一、可追溯。
所有变更都有 Git 历史：谁改的、什么时候、为什么（通过提交信息）。
出问题时，git log 和 git revert 就能定位并回滚。
二、可审查。
变更通过 Pull Request 进行，可以评审、讨论、自动化检查。这把基础设施变更纳入了与代码相同的质量流程。
三、一致性。
实际状态如果被人手动改动（"直接去机器上改了点东西"），GitOps 工具会检测到漂移并自动纠正（或至少告警）。
这保证了环境的可重现性。
四、灾难恢复。
因为所有配置都在 Git 里，重建整个系统相当于"让新集群指向同一个 Git 仓库"——工具会自动把一切恢复。
关键实践
一、声明式而非命令式。
配置文件描述"要什么"，而非"怎么做"。
二、Git 是唯一事实来源（Single Source of Truth）。
所有变更都要经过 Git。禁止手动修改生产环境。
三、自动化同步。
工具持续拉取 Git 仓库，检测差异并自动应用（或在某些配置下需要手动批准）。
四、密钥管理。
不要把明文密钥放在 Git 里！
解决方案：
- 使用加密方案（如 Sealed Secrets、SOPS）——加密后的密文可以安全地存 Git，只有集群能解密；
- 或从外部密钥管理服务（如 Vault、云厂商的密钥服务）动态注入。
挑战
一、文化转变。
团队要接受"不再 SSH 到服务器上改配置"。对习惯了直接操作的人来说，这是流程上的约束。
二、紧急情况的矛盾。
线上出故障时，"改配置 → 提交 → 等同步"可能比"直接改"慢。
实践做法：保留紧急通道，但要求事后补回 Git（否则就会产生漂移）。
三、状态与配置分离。
无状态服务容易 GitOps 化；有状态服务（数据库）的数据不在 Git 里，需要额外的备份策略。
一个延伸
GitOps 是基础设施即代码（IaC）理念的一种实现方式。
相关的工具生态还包括：
- Terraform：声明式地管理云资源（虚拟机、网络、存储）；
- Ansible/Puppet/Chef：配置管理（更偏命令式/混合）；
- Helm/Kustomize：Kubernetes 应用的模板化和配置管理。
它们共同的目标是一致的：让基础设施可版本化、可审查、可重现。
说明：本文为运维实践的知识整理。