为什么需要重试：计算环境的不确定性

说实话，我在刚搭起第一个 Nextflow 流程的时候，特别担心一件事——跑着跑着突然崩了怎么办。后来我发现，这不是“会不会崩”的问题，而是“跑几次崩一次”的问题。

你想想看，一个标准的多组学分析流程，可能要跑几百个样本。每个样本又要拆成十几个任务。任务多了，遇到环境波动的概率就直线上升。这不是你的代码写得不好，而是生信工作流天生就活在一个不太靠谱的环境里。

完美世界的幻象

我个人习惯把计算环境想象成一个公共厨房。

你早上到的时候，灶台干净、燃气充足、锅碗瓢盆摆放整齐。可到了下午，油渍满地、煤气快没了、锅铲还被隔壁工位的人拿走了。

HPC 集群或者云环境，本质上就是这样。你觉得“明明我昨天跑成功了”，但今天同样的输入、同样的代码，可能就因为 CPU 被别的作业占满了、内存被隔壁抢走了、网络突然抖动了一下……啪，失败了。

这就引出了一个核心问题：失败不一定是你的错。但如果你不做重试，整个流程就卡在那了。

那些让我抓狂的失败原因

我在项目中遇到最多的失败原因，总结下来就三类。我按“遇到的频率”排了个序：

这里我重点展开说说每一类，因为重试策略的配置，其实跟失败类型有很强的关系。

1. 资源不足 —— 最隐蔽的杀手

举个例子。你给一个比对任务申请了 4 核、8G 内存。大部分样本能跑完，但有一个样本特别深，跑到一半内存用满了，被调度器直接 kill 了。

日志里你只能看到一行：

slurmstepd: error: Detected 1 oom-kill event(s)
slurmstepd: error: Step 123456.0 was terminated with signal SIGKILL (signal 9)

我当初第一次看到这个日志，以为是代码出了问题。后来才发现，是内存不够。但问题是，这个样本本身是正常的，只是需要更多资源。如果我简单重试，还是那个内存限制，照样会死。

所以资源不足类的问题，重试时通常要搭配「资源自动扩充」策略。说白了，就是 “这次失败了，下次给你多分点内存再试一次”。

2. 网络超时 —— 最烦人的偶发故障

每次做公共数据下载的时候，我都特别头疼。GEO、SRA、ENA 这些数据库的 API，说断就断，完全没规律。

我记得有一次跑千人规模的 RNA-seq 流程，下载步骤总共要拉 3000 多个 FASTQ 文件。结果跑了一半，一条网络波动，下载任务卡住了 40 秒，然后报了个超时错误：

curl: (28) Connection timed out after 30001 milliseconds

就这一个错误，整个流程停在那。我手动重试了一下，嘿，又好了。

这种问题，说白了就是「临时网络拥堵」或「对方服务器节流」。你做再多的代码优化也没用。唯一有效的办法就是——重试。而且一般重试 1-2 次就能过去。

3. 软件崩溃 —— 分两种，一种能重试，一种不能

软件崩溃比较微妙。我拆成两类：

• 软件本身的内部偶发错误：比如 GATK 在处理某些区域时内存争用导致异常退出，或者 R 包因为 JIT 编译热路径崩溃。这种下次启动大概率就好了，直接重试就行。
• 输入数据或逻辑错误：比如 BAM 文件索引损坏、fastq 文件格式不对、脚本里写了除零操作。这种你重试一万次也没用，必须修输入或修代码。

你在配置重试策略时，最好能把这两种分开。简单粗暴的方法就是：看进程的退出码。

# 常见的退出码约定
# 0    — 成功
# 1-64 — 软件内部错误，但可能可重试
# 64+  — 输入数据错误，不可重试
# 137  — 被 OOM killer 杀掉（资源不足）
# 143  — 被 SIGTERM 终止（常见于超时或调度器回收）

我习惯在 Nextflow 的 process 里加一个判断，如果退出码是 137、143 或者某些偶发错误码，就走重试路径；如果遇到 1 或 2 这类明确不可重试的，直接 fail fast。

为什么环境不确定性是常态？—— 看个实际的调度流程

我画了一张图，帮你理清一个任务从提交到失败再到重试的完整链路。你看看中间有多少个可能出问题的环节。

你看到了吗？从任务提交到执行结束，中间有 4 个环节。每个环节都有可能出问题：调度器队列满了、分配的资源被人抢了、节点上恰好有人跑了个压测程序、软件读取输入的时候硬盘 IO 降级了……

说实话，这还只是单次任务的逻辑。如果是几百个任务同时在跑，失败概率几乎是 100%——你总会遇到至少一两个不顺利的。

实战：资源不足与网络超时的 Nextflow 处理

讲完理论，我给你看看实际代码。在 Nextflow 里处理这两个场景，代码量可以很少，但效果很明显。

针对资源不足：动态扩内存重试

这是我最常用的一段配置。它让 process 在失败时自动增加内存再试：

process bwa_mem {
    errorStrategy { sleep(Math.pow(2, task.attempt) * 100 as long); return task.attempt < 3 ? 'retry' : 'ignore' }
    memory { 8.GB * task.attempt }

    script:
    """
    bwa mem -t ${task.cpus} reference.fa reads.fq > aligned.sam
    """
}

注意看 memory 那块。第一次跑给 8G，如果失败了（大概率是 OOM），第二次就给 16G，第三次给 24G。再不行？我就不管了，让流程继续跑后面的任务。这叫「优雅放弃」。

针对网络超时：加退避和抖动

下载任务我通常这样写：

process download_sra {
    errorStrategy {
        sleep((Math.random() * 10 + 5) * 1000 as long)
        return task.exitStatus in [28, 56, 104] ? 'retry' : 'terminate'
    }
    maxRetries 3

    script:
    """
    fasterq-dump --threads 2 --outdir . ${sample_id}
    """
}

这里我判断了退出码 28（超时）、56（网络不可达）、104（连接被重置）。只要遇到这三种，先随机等 5-15 秒，再重试。最多试 3 次。

写给刚接触生信工作流的你：别慌，重试是常态

说实话，我第一次写 Nextflow 流程的时候，看到日志里出现大段大段的红色错误信息，心跳直接提速。我觉得一定是自己代码写错了。

后来跟一个运维老哥聊了一次，他跟我说了一句让我印象特深的话：

“在分布式系统里，失败不是异常，失败是常态。”

你想想看，每个任务都跑在一个可能随时被抢占、网络可能随时抖动、磁盘可能随时 IL 的节点上。如果你指望一次跑准，那才是小概率事件。正确的做法不是“如何避免失败”，而是“如何优雅地处理失败”。

重试，就是那个最基础、最直观、也最有效的处理手段。你只要记住三个原则：

• 区分失败类型——是临时性的（重试），还是永久性的（报错）？
• 设置合理上限——别无限重试，浪费资源也拖慢流程。
• 配合退避策略——别太快重试，给环境一点“自我修复”的时间。

嗯，这三点贯穿整个课程。等你掌握了 Nextflow 里的重试逻辑，就会发现，很多以前让你抓狂的“流程卡住”问题，都不是问题了。