1. 计算生物学平台运维工程导论

计算生物学平台运维工程，是一门把“生物信息学分析能力”与“IT 基础设施运维能力”缝合在一起的交叉工程学科。它要回答的核心问题不是“某个基因序列比对算法怎么写”，而是“当几十个课题组、上百名分析人员同时提交测序数据分析任务时，这套平台如何稳定、可复现、可追溯、可扩展地跑完，并在出问题时能被快速定位和恢复”。

理解这门课，先要理解它的定位。传统生物信息学课程关注算法、数据库与统计模型；传统运维课程关注服务器、网络、存储与容器。计算生物学平台运维工程处在两者之间：它把生信工具链当作被运维的“业务系统”，把集群、调度器、存储、容器、工作流引擎当作承载这些业务的“基础设施”。因此，本课程的学习者需要同时具备两类视角——既看得懂 FASTQ、BAM、VCF、参考基因组索引这些生物数据对象，也看得懂节点、队列、挂载点、镜像、作业状态这些系统对象。

运维对象：从数据到作业的完整链条

计算生物学平台的运维对象可以按“数据—工具—作业—资源—服务”五层来梳理。数据层包括原始测序数据（FASTQ）、比对结果（BAM/CRAM）、变异结果（VCF）、参考基因组及其索引（如 BWA 的 .bwt/.pac/.ann/.amb 文件、GATK 的 .dict/.fai 文件）；工具层包括 BWA、STAR、GATK、Samtools、BCFtools、Picard 等；作业层包括单个分析任务及其依赖关系；资源层包括 CPU、内存、GPU、本地盘、并行文件系统与对象存储；服务层包括作业调度、工作流引擎、Web 门户、数据库与监控告警。

这些对象之间存在明确的依赖关系：一个 GATK HaplotypeCaller 作业需要参考基因组 .fai 与 .dict 索引、输入 BAM 及其 .bai 索引、足够的堆内存，并在调度器分配的节点上运行。任何一环缺失或版本不匹配，作业都会失败。运维的核心工作，就是保证这条链条上的每个对象都处于“可用、可查、可复现”的状态。

核心职责：稳定、可复现、可追溯、可扩展

平台运维工程师的职责可以概括为四个关键词。第一是稳定：保证调度器、共享存储、登录节点、网络等关键组件持续可用，作业不会因为磁盘写满、inode 耗尽、内存溢出而被批量杀死。第二是可复现：同一个分析流程，在不同时间、不同节点上运行应得到一致结果，这要求工具版本、参考基因组版本、容器镜像、参数都被明确记录。第三是可追溯：每个结果文件都能回溯到它的输入、所用命令、运行时间和执行节点。第四是可扩展：当数据量从 TB 级增长到 PB 级、用户从几人增长到几百人时，平台能通过增加节点、调整队列策略、优化存储分层来平滑扩容。

在实际工作中，这四项职责会落到非常具体的操作上。例如，当用户报告“GATK 作业总是跑到一半被 killed”，运维人员需要依次检查：作业请求的内存是否小于实际峰值（可用 /usr/bin/time -v 或 Slurm 的 sacct -j <jobid> --format=MaxRSS 查看）；节点是否发生 OOM；共享存储是否出现 I/O 等待；容器内工具版本是否与流程声明一致。这类排查不是靠猜，而是靠对五层对象的系统性检查。

典型平台架构与学习路径

一个典型的计算生物学平台通常由登录节点、计算节点、管理节点、共享存储和高速网络组成。用户通过 SSH 或 Web 门户登录，提交作业到 Slurm 队列；调度器根据队列策略和资源请求把作业分配到计算节点；计算节点通过 NFS 或 Lustre 挂载共享存储，读取参考基因组和输入数据，写回结果；管理节点运行监控、数据库和许可证服务。对于容器化平台，还会在计算节点上部署 Singularity/Apptainer 或 Docker，用镜像封装工具及其依赖。

学习路径建议按“先会用、再会管、后会优”推进。第一阶段掌握 Linux 基础、Slurm 常用命令（sbatch、squeue、scancel、sacct）和生信文件格式；第二阶段学习共享存储管理、容器封装、工作流引擎和监控告警；第三阶段进入性能调优、成本控制、多租户隔离和自动化运维。每一阶段都应以“能独立处理一个真实故障或完成一次真实部署”为验收标准，而不是以看完多少课时为准。