“谁在什么时候改了什么？”——用 CI/CD 把变更记录干到“法律级别”

“谁在什么时候改了什么？”——用 CI/CD 把变更记录干到“法律级别”

先跟你说句掏心窝子的实话。

绝大多数团队的“变更记录”，在法律面前几乎等于没有。

不是我危言耸听，而是我见得太多了。

• 出事故了，问：谁改的？

  • 回答：Git 上好像是小王

• 再问：谁审批的？

  • 回答：群里点过 👍 吧

• 再问：什么时候上线的？

  • 回答：大概是上周？

如果这是一次普通线上故障，也就算了；
但如果是金融、数据合规、生产安全、隐私泄露、合同纠纷——
对不起，这套说辞在法律层面站不住一分钟。

今天我就想聊一件事：

怎么通过 CI/CD，把“运维变更”这件事，从“口头记忆”，升级成真正可追溯、可审计、可举证的“变更链”？

一、先搞清楚：什么叫“法律级别的变更链”？

别一上来就被“法律级别”吓住，我给你翻译成大白话。

一个法律级别可用的变更记录，至少要回答清楚这 6 个问题：

1. 谁发起的变更？
2. 改了什么？
3. 为什么要改？
4. 谁批准的？
5. 什么时候生效？
6. 是否可以被篡改？

注意重点在最后一句：

事后，任何人都不能“偷偷改历史”。

这才是法律关心的点。

二、为什么“人工记录 + 群聊”一定不行？

很多团队一开始都会说：

“我们有变更单啊”
“我们有群记录啊”
“Git 不是都有提交记录吗？”

我逐条给你拆。

1️⃣ 变更单：可以补写，就不可信

如果变更单是事后补的，那在法律上基本没什么效力。

法律不怕你犯错
法律怕的是你事后编故事

2️⃣ 群聊记录：不完整、不严肃

• 群可以解散
• 消息可以撤回
• 表情 👍 不等于授权

说句不好听的：

群聊在法律眼里，更像“闲聊证据”

3️⃣ Git 提交记录：不等于上线记录

Git 只能证明：

“代码被提交过”

但它证明不了：

• 是否真的部署
• 谁触发的部署
• 部署前有没有审批

三、CI/CD 才是“变更链”的天然载体

我一直有个观点：

CI/CD 不是为了快，而是为了“留下痕迹”。

因为 CI/CD 天生具备四个特性：

1. 强制流程（你绕不过去）
2. 自动记录（没人能偷懒）
3. 集中存证（日志完整）
4. 可审计（机器比人诚实）

只要你设计得当，
CI/CD 就是一条自动生成、不可抵赖的变更链。

四、一条“合格的变更链”，在 CI/CD 里长什么样？

我给你画一条现实中的路径（不画图，用人话）。

人 → 提交代码 → 触发流水线 → 审批 → 构建 → 部署 → 生效

关键不是步骤多，而是每一步都要“留证据”。

五、实战一：把“人”钉死在第一步

原则一句话：

任何变更，必须能追溯到“自然人”。

示例（Git Commit 规范）

git commit -m "feat(payment): adjust timeout [Change-ID: CHG-20240123-001]"

配合 Git 平台强制策略：

• 禁止匿名提交
• 禁止 force push
• 提交人必须和工号系统绑定

这一步的目的不是形式主义，而是：

把“责任主体”固化下来

六、实战二：审批不是“点个赞”，而是流水线关卡

这是很多团队最容易偷懒的地方。

❌ 伪审批

• 群里说一句：可以上
• 会议上口头同意

✅ 真审批（CI/CD Gate）

stages:
  - approve
  - deploy

approve:
  stage: approve
  when: manual
  only:
    - main

重点不在语法，在于：

• 谁点的“Approve”
• 什么时候点的
• 点之前流水线状态是什么

这些，平台都会自动记下来。

七、实战三：构建物必须“可指纹识别”

如果你连“上线的到底是哪一份东西”都说不清，
那前面的追溯全是白搭。

示例：构建产物带哈希

IMAGE_TAG=${CI_COMMIT_SHA}
docker build -t app:${IMAGE_TAG} .

上线记录里至少要能反查：

• Commit SHA
• 构建时间
• 构建环境
• 使用的依赖版本

一句话总结：

上线的不是“代码”，是“可校验的构建物”。

八、实战四：部署日志，本身就是证据链的一环

很多人只关心部署成不成功，
但在“法律级别”里，更重要的是：

部署过程是否可复盘

你至少要记录：

- 触发人
- 目标环境
- 部署命令
- 执行结果
- 回滚记录（如果有）

而且这些日志：

• 集中存储
• 只读权限
• 长期保留

九、再往前一步：防篡改，才叫“法律级别”

我说句大实话：

能被管理员随手删掉的日志，法律上基本等于不存在。

进阶方案包括但不限于：

• 日志写入 WORM 存储
• 日志签名 / 哈希链
• 日志同步到第三方审计系统

甚至有团队直接：

CI/CD 变更摘要上链（不存数据，只存指纹）

你可以不一步到位，
但你心里得知道：

“可追溯”和“不可篡改”是两个层级

十、我自己的一个真实感受

我这些年做运维，最大的变化不是技术栈，
而是认知。

以前觉得：

“系统跑得稳就行”

后来越来越清楚：

系统稳不稳，是技术问题；
出事你能不能说清楚，是生存问题。

CI/CD 的终极价值，不只是自动化，
而是：

在关键时刻，它能替你“说话”。

它能告诉别人：

• 我不是拍脑袋
• 我有流程
• 我有记录
• 我有证据

十一、最后一句话送你

如果你所在的团队：

• 涉及核心业务
• 涉及用户数据
• 涉及监管行业

那我真心建议你认真想一件事：

“如果今天上了法庭，我们的变更记录，敢不敢拿出来？”

=