1. 生物计算任务资源治理工程导论

生物计算任务资源治理工程，研究的不是某一个生信软件怎么用，也不是某一台服务器怎么装，而是一个更上位的问题：当测序、组装、比对、变异检测、单细胞分析、结构预测等任务持续进入计算环境时，我们如何让 CPU、内存、存储、GPU、网络、许可证和调度队列这些资源，被稳定、可解释、可复用、可审计地分配给正确的任务。它介于生物信息学、高性能计算运维与平台工程之间，核心目标是把"能跑通"提升为"可治理"。

课程定位：从"跑得动"到"管得住"

很多实验室的第一阶段是"脚本能跑"。一名分析人员写一个 shell 脚本，把 fastq 送进比对工具，再调用变异检测，最后输出 VCF。这个阶段关注的是算法正确性。第二阶段是"多人能跑"，样本量上升、人员增加、集群出现，问题就从算法转向资源：谁占了 64 核、谁把 512 GB 内存节点跑满、临时文件把 /scratch 写爆、GPU 队列排了三天。第三阶段才是"可治理"：资源有配额、任务有优先级、失败可归因、成本可核算、结果可追溯。

本课程面向第三阶段。它不替代生信算法课，也不替代 Linux 基础课，而是补齐"任务—资源—策略—证据"这条链路。学完后，你应当能够为一个真实的生物计算任务定义资源画像，设计队列与配额策略，判断一次失败是算法问题、数据问题还是资源治理问题，并能用日志和指标证明你的判断。

核心问题：四类反复出现的矛盾

资源治理之所以必要，是因为存在四类结构性矛盾。第一，需求异质性：比对任务可能吃满 CPU 但内存平稳，而组装或宏基因组拼接常常是"低 CPU、高内存、长时运行"，GPU 任务则对显存和驱动版本敏感。第二，资源有限性：集群总核数、总内存、存储带宽和许可证数量都是硬约束，不可能无限扩容。第三，公平与效率冲突：严格公平会让大任务频繁被抢占，纯效率优先又会让小任务长期饥饿。第四，可观测性不足：任务失败时，日志往往只写"killed"，不写是被 OOM killer 终止、被调度器抢占，还是超时。

这四类矛盾决定了治理工程的基本动作：把任务分类、把资源量化、把策略显式化、把证据留存下来。缺少任何一环，治理都会退化为"凭经验拍脑袋"。

治理对象：任务、资源、策略、证据

治理对象可以拆成四个层次。最上层是任务，包括任务类型、输入数据规模、预期运行时长、依赖关系与重试语义。第二层是资源，包括计算资源（CPU 核、GPU 卡与显存）、内存、存储（本地 scratch、共享并行文件系统、对象存储）、网络带宽以及软件许可证。第三层是策略，包括队列划分、优先级、配额、抢占规则、超时与重试上限。第四层是证据，包括调度日志、资源使用曲线、退出码、失败原因分类和成本记录。

四层之间是双向的：策略作用于任务与资源，证据反过来修正策略。例如，若发现某类比对任务长期只用到申请核数的 40%，就应下调其默认核数申请，把释放出的资源还给其他队列。这就是治理的闭环。

工程边界：治理不做什么

明确边界同样重要。资源治理工程不负责算法本身的正确性，不负责生物学解释，也不负责重写生信工具。它负责的是：任务提交时的资源声明是否合理、调度策略是否与任务特征匹配、失败是否可归因、成本是否可核算。换句话说，它管的是"任务与资源之间的契约"，而不是"任务内部的科学逻辑"。

边界还体现在粒度上。治理通常以"任务"为最小单位，而不是以"单个函数调用"为单位。一个比对任务申请 32 核、128 GB 内存、运行 6 小时，这是一个可治理的单元；而任务内部某个排序步骤用了多少内存，属于性能调优，不属于治理工程的主战场。把边界划清楚，才能避免治理范围无限膨胀。

一个可操作的起点：任务资源画像卡

治理的第一步不是买机器，而是把任务说清楚。下面给出一张可直接填写的任务资源画像卡示例，字段均来自本节四层对象。示例数值为教学假设，用于说明填写方式，不代表任何真实集群的实测结果。

这张卡的价值在于：它把"我要跑一个比对"变成了可调度、可审计、可复盘的声明。当任务失败时，你可以对照卡片判断是申请不足、策略不当，还是数据异常。例如退出码 137 通常与 SIGKILL 相关，若同时观察到峰值内存逼近 128 GB 上限，就应优先怀疑内存申请偏低，而不是算法出错。

本课程的组织逻辑

后续章节将沿着"任务—资源—策略—证据"这条主线展开：先建立任务分类与资源画像的方法，再进入队列、配额、优先级与抢占策略的设计，然后讨论存储与数据流的治理，最后落到可观测性、失败归因与成本核算。每一章都会尽量给出可填写的表单、可参考的参数和可判断的结果依据，而不是停留在概念层面。

需要强调的是，治理工程没有唯一正确答案。不同机构的数据规模、硬件条件、人员结构和合规要求差异很大，同一套策略在 A 集群有效，在 B 集群可能完全不适用。因此本课程更重视"如何推导出适合自己环境的策略"，而不是提供一套固定模板。判断治理是否成功的标准也很朴素：任务能按时跑完、资源没有被长期浪费、失败能说清原因、成本能算得出来。