线上服务一挂，事故群、值班表、升级流程立刻启动。可同一家公司里，主干代码无法编译、必跑测试瘫痪、GitHub Actions 或 Jenkins 队列卡死、QA 环境宕机，常见处理仍是：提个工单，等平台团队有空再看。
这很反常。
前者直接挡住用户，后者则挡住新版本、缺陷修复和安全补丁。影响出现得晚一些，不等于损失更小。开发流水线一旦成为所有变更的必经之路，它就已经是一套内部生产系统。
真正等同于停产的，是共享交付路径被堵死
这套系统的边界比 CI/CD 更宽。
从需求进入开发，到代码编译、自动测试、制品生成、环境验证，再到变更部署，任何不可绕过的阻塞环节，都属于交付产线的一部分。
但并非每个工具报错都该拉响事故警报。关键要看四件事：影响范围、是否有替代路径、阻塞时间，以及当前是否存在紧急发布需求。
| 故障场景 | 是否应按交付事故处理 | 判断依据 |
|---|---|---|
| 某位开发者的分支因代码错误无法编译 | 通常不需要 | 局部问题，有明确修改人，不影响他人交付 |
| 单个非强制测试不稳定，但可安全绕过 | 先按缺陷治理 | 流水线降级，尚未完全阻断发布 |
| 主干代码因共享构建服务故障无法编译 | 应升级 | 多个团队同时受阻，个人无法自行恢复 |
| 必跑测试套件因测试基础设施失效而无法运行 | 应升级 | 无法完成发布所需的质量验证 |
| CI/CD 平台中断，制品无法生成或部署 | 应升级 | 版本和紧急修复都无法送达 |
| 唯一 QA 环境宕机，且没有替代环境 | 视发布依赖升级 | 测试人员停工，发布审批链被卡住 |
这里必须区分“代码没写对”和“生产工具坏了”。
测试因为新提交引入缺陷而失败，责任通常在代码变更。测试因为共享数据库、执行器、凭证系统或测试环境故障而集体失败，责任则落在流水线基础设施。两者界面相似，管理动作完全不同。
受影响的也不只是开发者。
测试人员无法验证版本，业务方拿不到承诺中的迭代，客户等待的缺陷修复继续延期。若关键共享路径彻底中断，组织损失的就不只是若干工程师工时，而是一段时间内的整体交付能力。
内部停线总被降级成“工具问题”
客户侧服务通常有事故等级、响应流程、状态同步和 SLA。内部流水线故障却经常被塞进普通工单系统，和申请一个账号、调整一项权限排在一起。
原因并不神秘。
客户服务宕机，投诉和收入压力会立刻出现。内部产线停摆，损失散落在开发、测试、产品和客户支持之间。每个人都耽误一点，却很难在财务报表里形成一笔醒目的数字。
结果是激励错位：业务不断要求缩短交付周期，维护流水线的人却拿不到稳定预算；研发负责人追版本进度，构建集群、测试环境和部署平台仍被视为后台成本。
口头上重视交付，预算上却只购买功能，不购买交付能力。
制造业早就理解“停线”的含义。丰田生产方式中的安灯机制，允许现场在发现问题时暂停产线，目的不是制造紧张，而是避免故障继续向下游扩散。
软件研发和实体制造并不完全一样。开发者可以切换任务，部分团队也能临时手工部署。但只要编译、测试或发布平台已经成为共享瓶颈，停线逻辑依然成立：上游继续堆积工作，不能让下游凭空恢复产能。
“工欲善其事，必先利其器。”放到今天，所谓“器”早已不是一台电脑，而是整条从提交代码到部署上线的系统。
要建立事故机制，也要防止过度响应
把流水线当生产系统，不代表每次构建失败都要半夜叫醒整支团队。机械照搬客户侧的 7×24 小时值班，只会制造新的形式主义。
更合理的分级，应由业务后果决定：
- 多个团队是否同时无法交付；
- 是否存在安全修复、线上故障修复等紧急发布；
- 能否切换备用环境或采用经过验证的手工路径；
- 故障是否持续扩大，或导致待发布变更不断堆积。
响应时限不必全行业统一。面向高频发布业务的流水线，和每月发布一次的内部系统，维护投入不会相同。企业要承认这笔账存在，再按自身发布节奏定等级，而不是假装内部停线没有成本。
工程负责人最该做的，是把责任和判断标准写清楚：
| 管理动作 | 解决的问题 |
|---|---|
| 为构建、测试、制品和部署平台指定明确负责人 | 避免故障发生后四处找人 |
| 定义“局部失败、能力降级、交付阻断”三级边界 | 防止小题大做，也防止严重故障被压成工单 |
| 建立事故频道、状态同步和恢复记录 | 让开发、测试和业务知道何时恢复、是否可绕行 |
| 记录排队时间、基础设施失败率和恢复时间 | 把“大家感觉很慢”变成可排优先级的问题 |
| 为关键环节准备替代路径 | 降低单个平台或单一 QA 环境失效的冲击 |
| 对重复故障做复盘并安排维护预算 | 防止团队长期靠重试和人工救火维持交付 |
研发效能团队也需要调整角色。只提供工具目录和使用文档还不够。共享流水线有了明确依赖者，就要像服务团队一样管理容量、变更风险和故障恢复。
DORA 常用部署频率、变更前置时间、变更失败率和恢复时间观察软件交付能力；SRE 则用服务等级目标和错误预算约束可靠性投入。企业不必照抄这些框架，但可以借它们回答一个现实问题：流水线坏到什么程度，必须暂停其他工作优先修复？
如果你负责内部基础设施排期，下一次遇到 CI/CD 中断，不要只问“修这个要几个人”。还要问：有多少团队被阻塞，哪些版本无法发布，客户问题是否因此延迟解决，以及有没有安全的替代路径。
产能损失也不必伪装成精确财务模型。用“受阻人数 × 持续时间”，再加上发布延期和客户修复延迟，已经足以比较它与其他需求的优先级。
真正需要观察的变量很具体：企业是否给流水线设负责人，是否允许阻断性交付故障升级，是否记录恢复时间，是否愿意为冗余环境和长期维护付钱。
这些动作都没有，所谓“研发效能”多半还停留在仪表盘上。