2. 计算生物分析环境的需求工程
在计算生物分析中，环境管理失败往往不是技术问题，而是需求问题。一个典型的翻车场景是：研究者拿到一批 30 例人类全基因组测序数据，直接在一台 32 核、128 GB 内存的服务器上启动 GATK 联合变异检测，运行到第 6 小时被 OOM Killer 杀掉，重跑三次仍未定位原因。真正的问题不在 GATK，而在于没有人把“30 例 WGS 联合分析”翻译成“峰值内存约 200–400 GB、需要按区间并行、需要参考基因组与已知位点资源版本锁定”这样的计算需求。需求工程就是把生物学问题逐层拆解为可验证的计算与环境约束的过程。
一、从生物学问题到干实验目标
生物学问题通常以自然语言提出，例如“这批肿瘤样本中是否存在可靶向的驱动突变”。它本身无法直接驱动环境配置，必须先转译为干实验目标。转译的关键是明确三件事：分析对象（样本类型、物种、测序策略）、分析类型（变异检测、表达定量、宏基因组分类、系统发育等）、结果判据（灵敏度、特异性、分辨率、可重复性要求）。
以“肿瘤驱动突变识别”为例，可拆解为：全外显子或 panel 测序数据 → 体细胞变异检测（肿瘤-正常配对）→ 变异过滤与注释 → 驱动基因优先级排序。每一步都对应不同的工具链与环境依赖，例如体细胞变异检测需要 Mutect2 或 Strelka2，注释需要 VEP 或 ANNOVAR，而 ANNOVAR 依赖的数据库版本会直接影响结果，必须写入需求。
二、数据规模与算力评估
算力评估不是拍脑袋，而是基于数据规模的经验估算。常用估算维度包括：原始数据量（GB）、有效深度（×）、样本数、参考基因组大小、是否联合分析。下表给出常见分析类型的量级参考（示例值，用于教学估算，实际以工具文档和实测为准）。
| 分析类型 | 单样本数据量 | 典型峰值内存 | 典型 CPU 时间 | 并行策略 |
|---|---|---|---|---|
| WGS 单样本比对 | 80–120 GB | 16–32 GB | 8–20 核时 | 按 read group 并行 |
| WGS 联合变异检测 | 30 样本约 3 TB | 200–400 GB | 数百核时 | 按基因组区间 scatter-gather |
| RNA-seq 定量 | 5–15 GB | 8–16 GB | 2–6 核时 | 按样本并行 |
| 宏基因组组装 | 20–50 GB | 64–256 GB | 数十核时 | 按样本或分箱并行 |
估算时还要考虑 I/O 瓶颈。变异检测的中间文件（如 BAM、gVCF）往往达到原始数据的数倍，若存储为网络文件系统且带宽不足，CPU 利用率会长期低于 30%。因此算力评估必须同时给出CPU 核数、内存上限、临时存储空间、I/O 带宽四项指标，而不是只写“需要高性能服务器”。
三、环境约束与合规要求
环境约束分为技术约束与合规约束。技术约束包括操作系统版本、glibc 版本、CUDA 驱动、容器运行时、调度器类型（Slurm/PBS/K8s）、模块系统（Lmod/Conda）。合规约束则来自数据本身：人类基因组数据属于敏感个人信息，涉及《个人信息保护法》《人类遗传资源管理条例》以及机构伦理审查要求，通常要求数据不出境、访问可审计、存储加密、传输加密。
这些约束会直接改变环境设计。例如，若数据不得出境，则不能使用境外云厂商的托管分析服务；若要求访问可审计，则需在调度层记录每个任务的用户、时间、输入输出路径；若要求可重复，则必须锁定参考基因组版本（如 GRCh38 no-alt analysis set）、已知位点文件（dbSNP、1000G 资源）和工具版本。任何一项未锁定，都会导致结果不可复现。
四、需求规格说明书撰写
需求规格说明书（SRS）是需求工程的交付物，也是环境验收的依据。它不需要冗长，但必须可验证。建议包含以下字段：需求编号、来源生物学问题、干实验目标、输入数据规格、工具与版本、计算资源下限、存储与 I/O 要求、合规约束、验收判据、负责人。下面给出一个可填写的示例片段。
需求编号：REQ-002
来源问题：30 例肿瘤 WGS 中识别可靶向驱动突变
干实验目标：体细胞变异检测 + 功能注释 + 驱动基因排序
输入数据：30 对肿瘤-正常 WGS，PE150，平均深度 60×，BAM 已比对至 GRCh38
工具与版本：GATK 4.4.0.0、VEP 110、GRCh38 no-alt analysis set
计算资源下限：单区间任务 16 核 / 64 GB 内存；联合分析峰值内存 ≥ 256 GB
存储与 I/O：临时空间 ≥ 8 TB，顺序读带宽 ≥ 500 MB/s
合规约束：数据不出境；访问日志保留 180 天；存储加密
验收判据：所有区间任务成功；VEP 注释率 ≥ 95%；结果可由第二人按同版本复现
负责人：分析平台组
撰写时最常见的错误是把“工具名称”当成需求。例如只写“使用 GATK”，却没有写版本、参考基因组和资源包版本，导致半年后无法复现。另一个错误是验收判据写成“结果正确”，这不可验证。应改为可观测指标，如注释率、覆盖度、重复率、任务成功率等。
需求工程的价值在于把“跑不动、跑不对、跑完不可复现”这三类问题提前暴露在设计阶段。当生物学问题被拆成可验证的干实验目标，当数据规模被换算成 CPU、内存、存储和 I/O 下限，当合规约束被写成可审计的条款，环境管理才真正有了依据。SRS 不是一次性文档，而是随分析推进不断修正的活文档；每一次验收不通过，都应回退到需求层重新评估，而不是在环境层反复试错。