Azure Pipelines是否支持数天乃至数周的长时间运行作业？

关于“Azure Pipelines并非为长时间运行作业设计”的说法 #

微软官方文档虽未明确禁止长时间运行作业，但从产品核心定位来看，Azure Pipelines的设计初衷是支持CI/CD流水线场景（如代码编译、自动化测试、应用部署等，这类任务通常在数小时内完成），而非长期运行的后台批处理或持续计算任务。这种定位导致其在心跳机制、资源管理等方面的默认配置，更适配短周期任务，而非数天甚至一周的长作业。

微软对作业时长的官方承诺 #

• 微软托管代理：有明确的时长限制（最长24小时），超出后会被强制终止，这一点在官方文档中有明确说明。
• 自托管代理：官方文档未设定硬性的作业时长上限，当作业超时设置为0时，理论上允许无限运行，但微软并未对超长时间运行的作业提供SLA级别的支持承诺。

作业失联但进程仍运行的常见原因 #

出现“我们失去了与代理的联系”报错但进程仍在运行，大多和代理与Azure Pipelines服务的心跳机制相关：

• 代理需要定期向服务发送心跳包，若网络波动、代理机器资源耗尽（内存/CPU不足）、系统将代理进程休眠或暂停，都会导致服务判定代理失联。
• 即使作业进程本身还在运行，代理服务的异常会让Azure Pipelines服务无法获取作业状态，从而标记作业失败。

排查与优化建议 #

• 检查代理机器的系统日志，确认是否存在内存不足、OOM killer终止进程、系统休眠等情况。
• 查看Azure Pipelines代理的本地日志（默认位于代理安装目录的_logs文件夹），定位心跳失败的具体原因。
• 考虑将超长时间作业拆分为多个阶段，通过外部存储（如对象存储、数据库）保存中间状态，利用Pipeline的阶段依赖逐步执行，降低单作业持续运行的风险。

内容的提问来源于stack exchange，提问作者Jura Gorohovsky