生信工作流审计概述：GxP背景、审计目标、审计范围

大家好，我是老李。做了七八年生信工作流的开发和运维，近三年才开始真正碰审计这一块。说实话，以前觉得审计就是查文档、填表格，跟技术无关。直到有一次客户的 QA 团队在验证环节卡了我两周——因为我的 FastQC 参数没在 SOP 里写明。从那以后，我意识到：不懂 GxP 的生信工程师，迟早要撞墙。

这一章我们聊聊审计的起点。说白了，就是搞清三件事：为什么要审？审什么？审多深？

1.1 GxP背景：为什么生信工作流需要规管

GxP 里的「G」是 Good（良好），「x」是 Practice 的领域缩写，比如：

• GMP – 药品生产质量管理规范
• GLP – 药物非临床研究质量管理规范
• GCP – 药物临床试验质量管理规范

我早期的项目大多在科研环境，跑个 RNA-seq 只要本地文件不丢就行。但进了制药公司就不一样了——每一步操作都可能被监管机构翻出来查。我记得有一次做肿瘤 panel 的验证，因为对齐脚本里的 seed 参数没固定，被审计员指出「结果不可重复」。嗯，那一版数据直接作废了。

你可能会问：我的生信流程又不是生产药片，为什么要管那么严？其实说白了，监管看的是「过程」而不是「产品」。不管你是跑比对还是做变异注释，只要结果最终支撑药物审批或临床决策，你的流程就必须经得起稽查。

1.2 审计目标：我们到底要证明什么

我个人习惯把审计目标拆成三个层次：

1. 数据完整性 – 原始数据没丢没改，中间文件不被篡改。
2. 流程可重现 – 给一个新人、一台新机器，按文档能复现一模一样的分析结果。
3. 异常可追查 – 哪个 job 失败了？谁改了参数？什么时间点？日志里必须能定位。

我曾在项目里遇到过这样一个情况：一个全外显子分析用 Nextflow 跑了三个月，突然有一天结果偏了。查来查去，发现是一个 node 上的 BWA 版本被系统管理员更新了，但我们的 container 没锁版本……当时我就想，如果审计机制早把容器哈希登记下来，这个问题一分钟就能定位。

1.3 审计范围：审到什么粒度才算够

这是最容易吵架的地方。开发团队说「我用的是社区公认的 bowtie2，不用审了吧」，但审计员可能会问：你用的 bowtie2 是哪个 commit？编译参数是什么？——你看，分歧就在于粒度。

我一般建议按「三域模型」划分审计范围：

• 数据域：FASTQ/BAM/VCF 等文件的存储、流转、归档。审计点包括文件校验和、存储路径规则、备份策略。
• 计算域：软件环境、容器镜像、参数文件、CPU/GPU 资源。审计点包括镜像 digest、参数 JSON 快照、作业调度日志。
• 管理域：SOP、变更记录、用户权限、电子签名。审计点包括 SOP 版本号、变更审批单、系统访问日志。

实际操作中，大多数制药公司会要求至少覆盖数据域和计算域，管理域视公司成熟度而定。我见过一种极端的案例：某 CRO 的审计范围甚至连工作流输入参数都要比对源代码里的 default 值，连一个逗号都不能差。

1.4 审计核心原则（一张图理清）

下面这张 SVG 图帮你把本章的核心逻辑串起来。你看完应该能直接画给团队看。

你看，GxP 背景提供「为什么审」的驱动力，审计目标定义「审成什么样」，审计范围划定「审多宽」，而审计原则（如记录完整、变更可追踪）是贯穿始终的底线。这四个支柱缺一不可。

1.5 本章要点再拎一下

• GxP 不是可选，是强制 – 只要你的生信流程用于药品研发或临床试验，就必须对齐。
• 审计目标三层次 – 完整性、可重现、可追查。缺一层都不算合规。
• 审计范围三域 – 数据域 + 计算域 + 管理域。建议从数据域起步，逐步补齐。
• 工具辅助 – 用容器哈希、参数快照、执行日志来加固审计证据链。

find . -type f \( -name "*.config" -o -name "*.cwl" -o -name "*.json" \) | xargs wc -l