"这次生产库的删除是谁批的？"——审计或事故复盘现场，问题往往只有一个，但不一定有人答得出。往回翻三个月：操作确实发生过，执行痕迹也在，可"谁"是共用账号，"什么时候"是容器里的 UTC 时间，"依据"是私聊里的一句"你处理下"。三样缺两样，等于没有证据。
核心命题只有一句：证据链是事前设计出来的，事后补出来的只能叫说明。事后补的材料有两个绕不开的缺陷——它由当事人生成，无法独立复核；它的时间点不再是动作发生的那一刻。
判断一份材料够不够格当证据，先过三道门槛：在动作发生时生成（不是事后整理）、独立于当事人（由系统而非人手写）、第三方能读懂（不需要你的口头解释）。第三条最常被忽略。
1. 四要素，以及某一项缺失后你还剩什么
| 要素 | 载体 | 缺失时能证明什么 | 事后能否补齐 |
|---|---|---|---|
| 谁（主体） | 网关、堡垒机、账号到人的映射 | 只能证明"发生过" | 不能，共享账号不可逆 |
| 做了什么（动作、目标、参数） | 操作日志、数据库审计、变更流水 | 只能证明"有人动过" | 部分可补（行为可重放时） |
| 什么时候（带时区的可信时间） | 主机时钟 + 统一时区 | 无法与其他系统的记录对齐 | 部分可补，取决于当时的时钟质量 |
| 依据是什么（授权引用） | 变更单、审批实例 ID、工单号 | 能证明有人做了，不能证明有人批了 | 不能，事后补的记录无证明力 |
最常见的不是四缺三，而是三缺一：动作、时间、主体都在，唯独没有授权引用。技术上这份日志很完整，但它只能回答"是谁按的"，回答不了"凭什么按的"。审计追问的恰恰是后一句。
2. 操作日志不是证据，三类记录要缝在一起
| 记录类别 | 回答什么 | 典型来源 | 关联键 | 典型失效 |
|---|---|---|---|---|
| 操作记录 | 谁在何时对什么执行了什么 | 应用审计、数据库审计、命令审计 | 请求/链路 ID | 只记了 URL，没记参数与前后值 |
| 审批记录 | 谁批准了这次动作 | 审批系统、变更单 | 变更单 ID | 审批发生在私聊或口头 |
| 发布记录 | 当时跑的是哪个版本 | 流水线、制品库 | 制品摘要 | 摘要未入库，回溯不到构建源 |
三类记录各自的证明力都不足，价值产生在关联键上。把它们缝在一个结构里，取证时才不必做三次人工拼接：
// 一条可用作证据的事件：四个要素落在同一个结构里
// 注释行示意字段语义，实际存储按目标系统的 schema 定
{"event_id":"uuid",
"ts":"2026-01-02T03:04:05+08:00", // 带偏移的 RFC3339，不用裸本地时间
"actor":"user:zhang.san", // 禁共享账号；服务账号要能回溯到触发人
"action":"config.update",
"target":"service=order,env=prod,key=timeout_ms",
"before":"3000","after":"5000", // 变化前后值，缺了只能证明"改过"
"decision_ref":"CR-2026-0102-07", // 与审批记录缝合的键
"approval":"approver:li.si",
"artifact_digest":"sha256:……", // 与发布记录缝合的键
"source":"pipeline|bastion|console"}
decision_ref 是这份结构里最不能省的一个字段。它是把"动作"与"授权"缝在一起的唯一针脚；缺了它，日志再全也只能落到"有人做了"这一档。
自动化操作尤其要补人可读的那一层：流水线触发的变更，主体是服务账号，但审批来自人。两者要么在同一个事件里都出现，要么通过变更单 ID 一跳可达——机器主体的日志如果没有落回具体的人，等于把主体要素判了缓刑。
3. "日志里有"不等于"能查出来"
可用性由检索成本决定。同一条记录，放在索引里是秒级，落在压缩归档里是小时级，落在已轮转的日志里是不存在。
| 检索方式 | 前提 | 典型量级 | 可用性 |
|---|---|---|---|
| 结构化入库 + 索引 | 采集管道可靠、字段已切分 | 秒级到分钟级 | 可日常使用 |
| 原始文件全量扫描 | 文件仍在磁盘、格式可解析 | 随数据量线性增长 | 事故当天勉强可用 |
| 冷归档层 | 先取回/解冻 | 数十分钟级 | 应急可用，复盘可用 |
| 日志已被轮转删除 | 无 | — | 不可用 |
字段化程度直接决定检索路径。常见的"记了但查不出"是把整条消息塞进一个 message 字段：SQL 记的是模板不带参数、请求只记 URL 不记 body。这类日志的取证只能退化成全文匹配，命中率和耗时都不可控。
// 取证查询：先固定时间窗与主体，再按目标收窄
$ jq -r 'select(.actor=="user:zhang.san")
| select(.ts >= "2026-01-02T00:00:00+08:00")
| select(.target|test("env=prod"))
| [.ts,.action,.target,.decision_ref] | @tsv' evidence/*.json
// 前提是字段已结构化；只有 message 一整行的日志，这里只能换成全文匹配
保存期限是同一笔账的另一半。它应当由最长追溯窗口倒推（对外承诺、合同约定、行业惯例、事故诉讼期），而不是由磁盘余量倒推——按容量定的保留期，恰好在需要它的年份之前把数据删干净。
| 层 | 保留期 | 介质 | 检索延迟 | 单位成本 |
|---|---|---|---|---|
| 热 | 天级到周级 | 本地盘 / 索引集群 | 秒级 | 最高 |
| 温 | 月级 | 对象存储标准层 | 分钟级 | 中 |
| 冷 | 年级 | 归档层 / 离线介质 | 小时级 | 最低 |
不可篡改性是一个分级采购的问题，不是有或无：
| 等级 | 抵抗对象 | 实现成本 | 适用 |
|---|---|---|---|
| 普通日志文件 | 无 | 最低 | 内部排错 |
| 追加写 + 独立只读账号 / 对象锁 | 误删、顺手改 | 低 | 多数团队 |
| 哈希链（每条含前一条摘要） | 局部篡改与删除 | 中 | 需要证明"未被改动" |
| 外部存证 / 第三方时间戳 | 内部整体否认 | 高 | 对外承诺、受监管场景 |
// 哈希链：每条记录含前一条摘要，断链即篡改
$ prev=$(cat chain.head)
$ for f in evidence/*.json; do
digest=$(sha256sum "$f" | cut -d' ' -f1)
echo "$prev $digest" | sha256sum >> chain.log
prev=$digest
done
// 取回时按同序重算并逐条比对；chain.head 单独保存，否则整链可被整体重算
4. 时间对齐、演练与度量
跨系统的证据靠时间缝合，时钟漂移会直接让缝合失效。未同步的主机之间偏移可达秒级到分钟级，足以让"先授权后操作"与"先操作后授权"两种顺序无法区分——而这个顺序正是审计要判定的事情。
// 取证时的固定动作：把时间源状态与数据一起归档
$ timedatectl status // 时区与 NTP 同步状态
$ chronyc tracking | tee clock-state.txt // 偏移量、同步源、最近一次同步
// 归档要求：数据 + 时间源状态 + 采集时刻，三者缺一，时间这一要素就无法主张可信
验证证据链的唯一可靠方式是出题演练：提一个具体问题，限时把四要素材料拿齐。演练的价值不在"我们查到了"，而在暴露缺口——哪一要素缺字段、哪一步只能靠人肉拼。
// 演练题库：每题都必须能用一个具体事实回答，答不出即记为缺口
// ─── 上周某日 14:00 后，生产环境 timeout_ms 是谁改的，依据哪张变更单？
// ─── 某条 DELETE 是哪个进程发起的，对应当时发布的哪个制品版本？
// ─── 那次误操作前 30 分钟内，谁提升过数据库账号的权限？
// 计时点从"提出问题"开始，到"四要素材料齐备"结束，中间的人工协助要单列
| 指标 | 定义 | 反向信号 |
|---|---|---|
| 四要素齐备率 | 抽查事件中四要素齐全的比例 | 缺的永远是同一要素，说明采集点缺字段 |
| 平均取证时长 | 从提问到材料齐备的时间 | 只有当事人协助时才达标 |
| 证据缺口数 | 演练中无法回答的问题数 | 只有上级关注时才做演练 |
| 过期证据占比 | 相关记录已过保留期的比例 | 保留期由容量而非追溯窗口决定 |
5. 排错：取证现场的五种卡点
| 现象 | 根因 | 处理 |
|---|---|---|
| 记录在，但查不出来 | 字段未结构化，或日志已轮转 | 先补采集字段，再重定保留期 |
| 两个系统的时间对不上 | 时钟未同步，或时区混用 | 统一带偏移格式，归档时间源状态 |
| 主体是共享账号 | 无法归因到人 | 一人一号；服务账号必须绑定触发人 |
| 有动作无授权 | 审批在私聊或口头 | 授权必须落到可引用的实例 ID |
| 材料外人读不懂 | 内部代号与术语 | 附解释层：字段含义、代号映射表 |
6. 边界：这些情况下证据链可以更薄
| 场景 | 做法 | 理由 |
|---|---|---|
| 内部小系统、无对外承诺、无监管要求 | 压到"变更单 + 操作日志"两件 | 授权由变更单承载，动作由日志承载 |
| 性能敏感的高频读路径 | 只记变更类事件，不记读操作 | 记录成本会变成业务成本 |
| 依赖第三方 SaaS | 至少按期导出到自有存储 | 保留期与导出能力受对方约束 |
| 一次性脚本、临时环境 | 不建独立证据，由变更单覆盖 | 生命周期短于追溯窗口 |
| 已有外部合规采集体系 | 复用其采集点，自建只做检索优化 | 重复采集换不来额外证明力 |
补记一点常被问到的：证据材料的可读性是一项独立预算。字段名、代号、环境别名对外人而言都是黑话，取证现场第一小时经常花在解释表结构上。一次性的代价做法是在归档目录里放一份字段字典与代号映射，随证据一起冻结；省掉它，等于每次取证都重新付一遍这笔解释成本。
一句话收束：证据链的验收标准不是"我们记了很多日志"，而是"任意一个具体问题，能否在不求助当事的人前提下、在可接受时间内、拿齐四个要素"。
自测
- 什么样的材料才算证据，三道门槛分别挡掉了哪类"事后整理"的材料？
- 四要素里最常缺失的是哪一个，缺了它之后材料只能降级到什么结论？
decision_ref这类关联键解决的到底是什么问题？- 为什么保留期应当从追溯窗口倒推，而不是从磁盘容量倒推？
- 时钟漂移为什么会让"先授权还是后授权"无法判定？
- 内部小系统把证据链压到两件记录，依据是什么？