1. 容错基础概念：什么是流水线故障、故障类型与核心目标

大家好，我是你们的讲师。今天咱们正式开篇，聊聊流水线故障与容错这件事。说实话，我见过太多团队在流水线出问题时手忙脚乱——半夜三点被报警叫醒，然后一群人盯着红彤彤的构建日志发呆。为什么会这样？说白了，就是没搞懂故障的本质。

这一章，咱们先把地基打牢。你想想看，如果连故障长什么样、分几种类型都说不清楚，那后面的恢复策略、容错设计全是空中楼阁。我个人习惯，每接手一个新系统，第一件事就是给故障分类。这招帮我省了不少事。

1.1 什么是流水线故障

流水线故障，简单说就是CI/CD流程中某个环节偏离了预期行为。它可能发生在代码编译、单元测试、镜像构建、部署发布等任意阶段。我在项目中遇到过最离谱的一次——流水线跑了两个小时，最后失败的原因居然是测试环境的时间戳比生产环境快了8分钟，导致缓存校验一直过不去。

流水线故障有几个典型特征：

• 连锁性：一个环节出问题，下游全堵死
• 隐蔽性：有些故障只在特定条件下触发，平时跑得好好的
• 重复性：同样的故障可能反复出现，尤其是环境差异导致的

1.2 故障的三种类型

根据故障的持续时间与可恢复性，我习惯把它们分成三类。这个分类法不是我发明的，但我在实际排障中反复验证过，确实好用。

故障类型	持续时间	典型表现	恢复方式
瞬态故障	毫秒~秒级	网络抖动、资源竞争、超时重试	自动重试即可恢复
间歇故障	分钟~小时级	内存泄漏初期、磁盘IO波动、偶发死锁	需要定位根因，临时重启可缓解
永久故障	持续存在	磁盘损坏、配置错误、代码逻辑缺陷	必须人工介入修复

瞬态故障

这类故障最让人头疼——因为它「来无影去无踪」。我记得有一次，我们的构建流水线每周三下午都会随机失败一两次，查了三天日志，最后发现是那个时间段有定时任务在跑，把CPU吃满了。重试一次就好了。

处理瞬态故障，我的经验是：先重试，再深究。不要一看到失败就立刻拉人排查，先看看是不是偶发。很多团队在流水线里加了自动重试机制后，故障率直接降了60%以上。

间歇故障

间歇故障比瞬态麻烦一点。它不会每次都出现，但一旦出现，持续时间更长。我曾经遇到过一个Java应用，跑了大概两周后，构建速度越来越慢，最后直接超时。重启节点就好了，但两周后又来一次。后来发现是某个第三方库有内存泄漏。

处理间歇故障，我建议：建立监控基线。把每次构建的耗时、资源消耗、日志模式都记录下来。当某个指标偏离基线超过30%时，自动触发告警。这样你就能在故障完全爆发前抓住它。

永久故障

永久故障是最严重的。它不会自己消失，必须有人去修。比如你改了某个配置文件，结果所有构建都报「找不到依赖」。或者你升级了构建工具版本，结果语法不兼容了。

这类故障的应对策略只有一个：快速定位，快速回滚。我个人的习惯是，每次变更前都打一个快照或标签，一旦发现永久故障，第一时间回滚到上一个稳定版本，然后再慢慢排查原因。

1.3 容错与恢复的核心目标

聊完了故障类型，咱们说说容错到底要干什么。很多人以为容错就是「不出错」，其实不对。容错的真正目标是：出了错，系统还能继续提供服务，或者快速恢复正常。

我把核心目标归纳为三点：

1. 故障隔离：不让一个环节的故障扩散到整个流水线。比如测试阶段挂了，不影响已经构建好的制品。
2. 自动恢复：对于瞬态和部分间歇故障，系统能自动处理，不需要人半夜爬起来。我见过最好的实践是「三步自愈」——重试、切换、降级。
3. 可观测性：当故障发生时，你能在5分钟内知道「哪里出了问题、影响范围多大、根因是什么」。没有可观测性，容错就是盲人摸象。

1.4 本章知识体系

下面这张图，是我梳理的本章核心逻辑。你可以把它当作整个课程的「导航地图」。

这张图把咱们这一章的核心逻辑串起来了。从故障定义出发，到三种故障类型，再到三个核心目标。后面的课程，每一章都会围绕这张图里的某个节点展开。

1.5 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路。