---
url: /process-workflow/pipeline-mirror.md
description: >-
  把组织里的审批流程和技术里的 CI 流水线并置，会发现它们撞上的反模式惊人地相似——这不是巧合，而是它们本质上是同一种
  workflow。本文是上下篇之上篇，用四个具体例子展开这种"跨域同构"。
---

## 两个工程师的同一天

A 是某互联网公司的流程经理。去年花了半年时间梳理"统一请假审批流程"，目标是把平均审批时长从 6 天压到 2 天以内。上线半年后内部调研结果让人哭笑不得：**平均每次请假要走 4.7 天**才能完成审批链。

她去看后台数据，发现流程在第 3 个节点之后就开始"卡"——不是审批人不在，而是审批人**不知道这单该不该自己批**。审批人开始打电话问隔壁部门的同事"按惯例你们 Q3 这种合同怎么批"，打电话找不到人就拉个会议专门协调。

B 是某团队的 SRE。今年花了两个月把公司的发布流程改造成 Jenkinsfile 流水线。两个月后他们统计：**每次发布平均要花 2.5 小时**才能走完流水线——其中 1.5 小时是在等"上游镜像构建失败"的错误信息传到 stage 5。

他去看 pipeline 日志，发现 stage 1 拉镜像失败之后，stage 2/3/4 还在傻跑，等跑到 stage 5 才报错。流水线跑得越长，等待时间越多。

两个人在不同领域做优化，最后**列出的"问题清单"惊人地相似**。

* 审批流程要靠打电话、开会、发邮件才能走通。
* 发布流水线要跑到最后一步才发现第一步出错。
* 流程图里塞了不该有的业务数据。
* Jenkinsfile 里塞了不该有的业务规则。

这不是巧合。A 和 B 碰到的是同一个老问题的不同侧面。

***

## 第一个坑：业务规则出现在不该出现的地方

### 流程侧的糟心例

某公司的合同审批节点，审批人要在系统里手动判断"**这单合同是否超过部门 Q3 预算**"。

审批人该做的决定是"批 / 不批"。但系统逼他做了第二个决定——"算不算超预算"。

审批人不是财务，业务判断跑到了不该出现的地方。结果是：

* **审批速度变慢**——审批人要查预算、翻历史数据。
* **判断标准不一致**——每个审批人口径不同，有的宽松有的严格。
* **出了错没人负责**——超预算的合同签了，所有审批人都会说"我以为财务算过"。

### 流水线侧的糟心例

同一个团队改造的发布流水线，Jenkinsfile 的 deploy stage 里塞了一段判断"**这次部署是否冲突下个季度的产品发布窗口**"。

pipeline 该做的是"构建产物 + 推到目标环境"。但它偷偷干了"判断发布时机"这种业务规则。

结果是：

* pipeline 越长、业务人员越看不懂。
* 出了错不知道是构建的错还是业务的错。
* 业务规则改一次，pipeline 要跟着改一次。

### 共同的发现

两边都在"该做决定的人/系统"身上塞了"不该做的决定"。

**审批节点该做的是"按业务规则执行"，不是"自己造业务规则"。**

**pipeline 该做的是"按规矩跑构建"，不是"自己定规矩"。**

判断归决策层，执行归执行层。审批节点是执行层，pipeline 是执行层，它们都不该做判断。

***

## 第二个坑：错误被拖到最后才暴露

### 流程侧的糟心例

某 OA 系统的报销流程有 8 个节点。员工小王填了第 2 步"项目编号"——**手抖填错**。

流程继续往下走，到第 8 步才被退回，理由是"项目编号无效"。此时小王已经等了 5 天，前面 6 个审批人也都白签了。

错得越晚发现，整个流程浪费得越厉害。小王后来学乖了，每次报销前先打电话问财务"项目编号怎么填"，又给财务增加了工作量。

### 流水线侧的糟心例

同一个团队的 Jenkinsfile 有 5 个 stage：lint → test → build → package → deploy。某次发布因为**第一个 stage 用的基础镜像 tag 被误删**，结果跑到 stage 5 才报错"找不到镜像"——前面 4 个 stage 全跑了 30 分钟才白费。

错在源头，但等到终点才发现。

### 共同的发现

两边都在"错误该早点暴露的地方"让错误拖延了。

**流程的"快速失败"靠前置校验**——第 2 步就该校验"项目编号是否合法"，不该等到第 8 步。

**pipeline 的"快速失败"靠 stage 1 就做基础检查**——基础镜像、依赖、配置，每个都在进入下一个 stage 前校验完毕。

让错误在该浮出来的地方就浮出来，不要让流程和 pipeline 越长越能藏错。

***

## 第三个坑：决定的事和被决定的事搅在一起

### 流程侧的糟心例

某公司的请假流程，审批节点要求填"**请假者上月绩效分**"。

审批人看到绩效分后，决策被绩效影响了——绩效低的员工请假就被卡得更严。

但绩效分跟"该不该批假"是两件事。**做决定的事**（审批）和**被决定的事**（绩效数据）搅在了一起。

结果是：

* 审批节点失焦——审批人不知道该看"事实"还是"绩效"。
* 决策被业务数据污染——同一个请假理由，绩效 A 可能批、绩效 C 可能不批。
* 流程图变成数据搬运图——节点越多、搬的数据越多、流程图越长。

### 流水线侧的糟心例

同一个团队的 Jenkinsfile，build stage 要写"**这次是否新功能、是否涉及支付链路**"。

但这些跟"构建"没关系——它们是部署决策的依据，不该出现在构建配置里。pipeline YAML 越长，业务参数越塞越多，最后维护 pipeline 的人成了"业务翻译官"。

### 共同的发现

两边都在"做决定的位置"塞了"被决定的东西"。

**做决定该看的是规则，不是数据。pipeline YAML 该承载的是执行编排，不是业务参数。**

做决定的事（流程图 / pipeline YAML）和被决定的事（业务数据 / 业务参数）必须分离。前者是控制面，后者是数据面。

***

## 第四个坑：流程反向吞噬工作（最关键的一个）

前三个坑都能在"代码层面"修补——改一个字段、改一段配置、加一个 stage 校验。但第四个坑必须靠**组织能力**修。

### 反面：流程要靠"流程外"的手段补缺

差流程的典型状态——**流程要走通，得靠流程以外的东西补**：

* 要打电话问"这步到底该谁批"。
* 要拉会议协调"下一步谁接"。
* 要发邮件确认"前置条件齐不齐"。
* 要翻一份冗长操作手册查"流程图之外的细节"。

工作者花在"应对流程"上的时间，比做工作本身还多。流程不是工具，反而成了另一种工作。

某 IT 公司的内部调研显示：员工平均每周花 6.4 小时在"应对流程"上——开会协调、写邮件确认、打电话问下一步。流程不仅没省事，反而成了最大的时间黑洞。

### 正面：流程主动引导工作

好流程是什么样的状态——**工作者不需要了解流程本身**：

* 系统提示"现在该做什么、约束是什么、下一步交给谁"。
* 所有节点都在系统里走完，**完全不需要打电话、开会、发邮件、查说明书**。
* 工作者的注意力只在"工作"上，不在"流程"上。

这是流程的"隐形"——**最好的流程是工作者感受不到它的存在**。

某 SaaS 公司的 oncall 流程改造：oncall 收到告警后，系统直接告诉他"这是第几类问题、按 runbook 走哪个 play、要不要叫人"。oncall 平均处理时间从 22 分钟降到 6 分钟——不是因为他变厉害了，而是因为流程不再让他"应对流程"。

### 关键能力：职责划分

要让流程变成"引导者"而不是"负担"，核心能力是**职责划分**：

* **流程设计者**要先回答"这个工作由谁负责、边界是什么、上下游如何交接"，把工作范畴划分清楚。
* 对每个划分出来的职责，要么自己设计具体执行步骤，要么**把"怎么做"交给该职责的负责人**，让他们做可执行管理设计。

这是一种**职责逆转**：不是"先有流程让工作去适应"，而是"先有职责划分让流程去承载"。

工作完全线上化流程化，是这种职责划分能力的直接体现——好的流程设计本身就是一个能力的体现。流程设计者划分工作范畴，对每个职责做具体设计，或者交给每个职责负责可执行管理设计。

### 为什么这一坑最深

前三个坑（业务规则越界、错误延迟、控制/数据混淆）都可以靠"代码层面的纪律"修——多一次校验、多一层抽象、多一份规范。

唯独这一坑必须靠**组织能力**——没有"会做职责划分的人"，再多的工具都没用。

这也呼应了开头讲的"数智化 ≠ 上工具"——好流程的本质不是流程图，是划分工作范畴的能力。

***

## 收尾：四个坑是一个老问题的四种投影

这四个坑看似独立，其实是同一个老问题的四种投影：

* 第一个坑：把判断放错了地方。
* 第二个坑：让错误延迟暴露。
* 第三个坑：把数据塞进了控制。
* 第四个坑：让流程反向变成工作的负担。

它们都指向同一件事——**workflow 这个东西，本来该让事情更省力，但很多人把它做成了反过来的样子**。

不论是组织里的审批流程，还是技术里的 CI/CD 流水线，**坑长得几乎一模一样**，因为它们本质上是同一种东西——都是"把工作串起来"的载体。

下篇要谈的不是"再加几条原则"，而是"在数智化的成熟态，这种载体该怎么重新被组织起来"。我们会把流水线拆成三层，看清每层该管什么、不该管什么；再给一张判断表，让不同阶段的团队知道"自己该做到什么程度"。

***

## 参考

* [流程驱动工作：从纸质审批到智能门闩](./workflow-design-philosophy.md) —— 上篇四个坑里"流程侧的糟心例"的源头
* [基础篇总结：从手动部署到声明式流水线](../sre/devops/foundation/foundation-summary.md) —— 上篇四个坑里"流水线侧的糟心例"的源头
* [流程即镜像：数智化语境下流水线该怎么设计（下）](./pipeline-design.md) —— 本文下篇