SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

基础设施即代码和 GitOps:一个把机器写成文件,一个让文件自动驾驶机器

两个概念都围绕“用代码管基础设施”,团队容易把它们当一个东西的不同叫法。基础设施即代码解决的是“资源怎么用声明式语言描述”;GitOps 解决的是“谁来触发变更、以什么为准、怎么自动校验”。写了 Terraform 不代表跑了 GitOps,后者要的是 Git 作为单一事实源加上自动同步。

寓言

两只手都能写菜单,但厨房里只有一个主厨

老字号酒楼的后厨管理经历了两个阶段。第一阶段是把老师傅脑子里的菜谱全部写成标准操作卡:每道菜的配料克数、火候时间、装盘方式全部落在纸上。新厨师拿到操作卡就能复现出品,不再依赖师傅口传。这就是把无形的经验变成了有形的文件。

第二阶段的问题来了:操作卡散落在厨师各自兜里。有人改了点盐量没通知别人,有人拿到的是旧版卡,有人做了改良但其他岗位不知道。同一道糖醋鱼,三个灶台三种口味。操作卡是写出来了,但版本是乱的。

管事的总厨做了一件事:他把所有操作卡存进一个公用的铁皮柜,柜子只有一把钥匙。任何人想改菜谱,必须经过他——交出旧卡、说明原因、拿到新卡。铁皮柜里的卡就是唯一可信版本,厨房按柜子里的卡做菜,每天开工前核对一遍。

又过了半年,总厨发现光是中央柜还不够。有人照着新卡做完菜,但实际出品的火候和卡上不完全一样——厨房执行的是什么,跟柜子里写的是什么,中间差着一道检查。他加了一个步骤:每天中午抽查两道菜,拿成品对比操作卡,发现偏差立刻追溯是卡有误还是人没照做。

这个铁皮柜加上每日核对的组合,就是后厨经历了“写成文件”之后才踩到的第二个坑。光有操作卡是基础设施即代码——把配置变成可读可复现的文件。铁皮柜加上单一钥匙、版本控制和自动核对,才是 GitOps——用一个中央仓库作为唯一事实来源,持续校验实际状态是否偏离。

酒楼的厨具采购后来也走了同样的路。以前采购清单记在采购员的本子上,改成共享文档之后确实清晰了。但直到他们把共享文档设置成“只有厨房主管可以修改、采购员只能读取和下单”,并且每天自动对账一次,采购偏差率才真正归零。

后厨总结会上,总厨在黑板上画了一条线:左边写着“写成文件就能传递”,右边写着“把文件锁进唯一仓库并且每天校验”。他说两个阶段各自值一笔钱,但只有第二个阶段值大钱。

基础设施即代码

用声明式或脚本语言描述和管理计算、网络、存储等基础设施资源,替代手工操作。

GitOps

以 Git 仓库作为基础设施和应用配置的唯一事实来源,通过自动化工具持续同步声明状态与实际运行状态。

故事对应

  • 把菜谱写成标准操作卡:IaC,把基础设施配置变成可读可复现的代码文件
  • 铁皮柜作为唯一可信版本:GitOps 的核心——Git 仓库作为单一事实来源
  • 每日抽查对比成品和操作卡:GitOps 的持续校验机制,自动发现配置漂移
  • 采购清单从共享文档到只读+自动对账:IaC 加上 GitOps 才堵住了执行层面的偏差

落到 Soloharness 项目里

写了 Terraform 或 Pulumi 只是完成了 IaC 这一步。部署 Agent 基础设施时再加一层:所有配置变更必须通过 Git PR 合并,合并后由自动化流水线同步并校验实际状态。Git 是唯一入口,任何手动修改都应触发告警。只有 IaC 没有 GitOps,等于文件写好了但没人保证线上跑的就是文件里写的。