4. 可追溯性（Attributable）

说实话，ALCOA 里面的这个“A”，也就是 Attributable，很多人一开始不重视。但我做了十几年生信，踩过最大的坑，往往不是算法不行，而是找不到“这数据是谁搞出来的”。

可追溯性，说白了就是：每一份数据、每一个操作，都得能追溯到具体的人和设备。你想想看，一个生信分析流水线跑下来，从原始测序文件到最终结果，经过了多少双手、多少个脚本？中间如果有人改了参数、换了参考基因组版本，或者手动修正了一个样本名——没有记录，那结果就是一笔糊涂账。

什么叫“可追溯”？三个要素

我个人习惯把这个概念拆成三句话：

  • 谁 —— 操作人员的唯一标识（用户名、工号、数字签名）
  • 什么 —— 执行的动作（上传、复制、运行、删除、修改参数）
  • 什么时候 —— 精确到秒的时间戳，最好带时区

看起来简单，真落地的时候，到处都是细节。有一次我接手一个项目，隔壁组说“我们所有数据都在网盘里，随便用”。我问：“原始FASTQ是谁下载的？参考基因组的版本号是谁选的？”没人答得上来。后来花了两周重追溯源，才知道同一个样本名被三个人改过命名规则。

实际场景：生信流程中的“谁”

在生物信息学里，可追溯性涉及的不只是“人”，还有工具和环境。比如：

  • 运行 bwa mem 时，用的参数、bwa 的版本号、引用数据库的路径
  • 修改样本元数据时，是谁改了哪个字段？
  • 上传测序数据到共享存储，操作记录是否留了审计日志？

我用一张图来展示核心逻辑：

可追溯性数据流 原始测序数据 FASTQ / BCL 用户：ZhaoLi 2025-03-21 14:30:22 比对工具 bwa v0.7.17 用户：WangWei 2025-03-22 09:12:05 BAM / VCF 分析结果 审计日志 操作ID: act_001 用户: ZhaoLi 动作: 上传FASTQ 时间: 2025-03-21 14:30:22 IP: 10.0.0.15 工具: bwa 0.7.17 参数: -k 32 -r 校验和: sha256:… 每一步都要记录用户、时间、工具版本和参数，并存为不可篡改的审计日志

落地做法：代码里怎么记

我推荐在每个分析步骤的脚本里，主动写一行日志，把关键信息记录下来。下面是一个简单的 bash 包装器：

#!/bin/bash
# 记录当前操作者、时间、命令
LOGDIR="/var/log/bioinfo"
mkdir -p "$LOGDIR"
LOGFILE="${LOGDIR}/analysis_audit_$(date +%Y%m%d).log"
echo "--------------------------------------------------" >> "$LOGFILE"
echo "USER: $(whoami)" >> "$LOGFILE"
echo "TIME: $(date -u '+%Y-%m-%dT%H:%M:%S%z')" >> "$LOGFILE"
echo "HOST: $(hostname)" >> "$LOGFILE"
echo "PID: $$" >> "$LOGFILE"
echo "CMD: $@" >> "$LOGFILE"
# 然后执行实际命令
"$@" 2>&1 | tee -a "$LOGFILE"

这样每次运行 bio_wrapper bwa mem hg38.fa sample_R1.fastq sample_R2.fastq，日志里就会留下完整追索线。

小技巧： 把日志文件放到只写一次的存储上（比如对象存储的 WORM 策略），或者用系统审计框架（auditd）自动捕获所有文件操作。这样就算有人想删日志，也删不干净。

避免手改：时间戳与校验和

有些同事喜欢手动改文件名加日期，比如 sample_20250321_modified.bam。这非常危险。我见过有人把“修改时间”写成未来的日子，结果下游流程直接挂掉。

正确做法是保留文件原来的 mtime、ctime，同时计算 SHA256 校验和。比如：

# 计算文件校验和，记入库
sha256sum raw_data/NA12878_S1_R1_001.fastq.gz >> checksums_20250321.txt
# 用 stat 命令查看真实时间戳
stat raw_data/NA12878_S1_R1_001.fastq.gz
注意： 绝对不要用 touch -t 伪造时间戳用于溯源。审计数据一旦被篡改，就失去了法律效力。在监管严格的环境里（比如临床试验生信），这可能导致数据被判定为无效。

不同记录方式的对比

记录方式优点缺点
手工日志（Excel）零成本，易上手易遗漏、易改、难审计
脚本内置日志自动化，记录完整依赖脚本正确性，日志可能被覆盖
版本控制（Git）全历史可回滚，谁提交了什么不适合大文件，二进制文件 diff 困难
专用审计系统（如 ELK、Splunk）集中管理，不可篡改部署成本高，需要运维支持
区块链式哈希链绝对不可否认技术门槛高，生信领域极少用

我个人的建议是：中小团队用“Git（代码）+ 脚本日志（数据）”，大团队直接上审计日志服务。

我曾经犯的错：共享账号

有一年我们给合作方部署了一套分析平台，为了方便，大家都用同一个 bio-admin 账号跑流程。后来发现某个重要结果异常，查日志只看到“bio-admin”，根本不知道昨晚是谁在跑。那个项目差点因为数据可追溯性不合格被退回。从那以后，我再也不允许任何共享账号操作生信数据。

解决方案很简单：

  • 每个用户分配独立系统账号或 LDAP 账号
  • 流程管理系统（如 CWL、Nextflow、Snakemake）在运行时记录用户 ID
  • Galaxy 或 Seqera Platform 等工具自带用户鉴权和操作历史

实操：用 Python 记录操作溯源

如果你用 Python 写分析脚本，可以用 logging 模块加一层审计：

import logging, getpass, socket, datetime

audit_logger = logging.getLogger('audit')
handler = logging.FileHandler('/var/log/bioinfo/audit.log')
handler.setFormatter(logging.Formatter('%(asctime)s %(message)s'))
audit_logger.addHandler(handler)
audit_logger.setLevel(logging.INFO)

def run_pipeline(input_file, reference):
    user = getpass.getuser()
    host = socket.gethostname()
    ts = datetime.datetime.utcnow().isoformat()
    audit_logger.info(f"USER={user} HOST={host} TS={ts} "
                      f"CMD=run_pipeline INPUT={input_file} REF={reference}")
    # 实际分析代码...
    pass
核心要点： 可追溯性不是“有日志就行”，而是要保证数据来源可查、操作人员可辨、时间顺序不可抵赖。每次写脚本前问自己一句：“三个月后，别人能通过这个记录找到我吗？”

说到底，可追溯性就是给你的数据加上“身份证”和“行车记录仪”。少一步，未来的你可能就要多熬几个通宵去追查。嗯，我宁可多花 5 分钟写日志，也不愿花 5 小时去猜。

← 上一章 📖 返回目录 下一章 →