← 返回概念解读

Concept Fable精修版

GitOps

GitOps · DevOps / operations

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

城墙以图纸为准

石南城的城墙每天都有人修。东门缺砖,守卫临时补;西门要加灯,工匠直接装;夜里有人改排水沟,第二天没人知道原因。

城墙看似一直有人维护,却没人说得清现在到底该是什么样。不同工匠按自己的习惯修,同一座城墙渐渐变成好几套做法。

城主先要求每天汇报改动。可汇报有漏,口径也乱。出了问题,只能到现场一块砖一块砖查,谁改的、为什么改,很快说不清。

新总工宣布:城墙不再以现场口头命令为准,而以总图纸库为准。任何人想改城墙,先改图纸,图纸审核盖章后入库。

巡墙员每天拿现场和图纸比对。发现不一致,就把现场修回图纸样子,或报告图纸确实需要更新。这个办法一开始显得绕。

直到一次错误改动拆了西门灯。总工翻回上一版图纸,巡墙员立刻知道该恢复哪些灯。石南城终于承认,稳定来自所有人承认同一个期望状态,并让现场不断向它靠拢。

工匠慢慢发现,先改图纸不是多一道麻烦,而是多一道共同记忆。每次变更都有理由、审阅和版本,后来的人能知道城墙为什么长成这样。

现场仍会被风雨损坏,也可能有人临时误改。但只要图纸库是共同承认的目标,巡墙员就能把偏差拉回来。石南城把混乱现场和期望状态分开后,维护才真正可控。 后来新手入门时,老师傅不再先讲抽象名目,而是让他们复盘那次失误:原先哪里靠直觉,第一次修补为什么不够,新的安排怎样把风险留在能检查的位置。等他们能说清这些细节,还能指出什么时候该沿用、什么时候该升级,才算真正懂了这套办法。 后来他们还把这套办法交给新人演练:先让新人按旧办法做一遍,看错误怎样出现;再按新规矩重做,看哪一步被提前拦住,哪一步留下了证据。新人若只会背名字,仍会在相似场景里乱用;只有能说出适用边界、代价和失败后的补救,才被允许独立接活。

揭示

这个故事讲的是:GitOps

它把 Git 仓库作为系统期望状态的唯一可信来源,基础设施和应用配置用声明式文件描述,自动化控制器持续把实际环境同步到 Git 中描述的状态。

GitOps 的关键机制包括声明式配置、Pull Request 审核、自动同步、漂移检测、审计历史和快速回滚。运维动作不靠人在服务器上临时敲命令,而是通过修改可追踪的 Git 状态来驱动系统变化。

隐喻映射

  • 总图纸库:Git 仓库,保存期望状态
  • 图纸经过审核:Pull Request 和代码审查
  • 巡墙员比对现场:GitOps 控制器检测实际状态
  • 自动修回图纸样子:自动同步和漂移修正
  • 翻回上一版图纸:基于 Git 历史回滚

Soloharness 判断

GitOps 的商业价值是降低交付环境的不确定性。对于 Agent 平台,配置、权限、工作流和部署状态都应该可审计、可回滚、可复制。

IaCKubernetesArgo CDFluxdeclarative deploymentdrift detection

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。