把发布流水线当产品来维护：一次 DevOps 值班后的三个改动

# 把发布流水线当产品来维护：一次 DevOps 值班后的三个改动

 

前阵子值班时，我碰到一个很典型的问题：应用本身没挂，CPU、内存、Pod 副本数都正常，但版本就是发不出去。最后排查下来，不是 Kubernetes 有问题，也不是镜像仓库抽风，而是流水线里几个“平时看不见、出事就卡死”的细节叠在了一起。

 

很多团队聊 DevOps，容易把重点放在“工具链够不够新”，比如是不是用了 GitOps、是不是上了 Argo CD、日志是不是进了 Loki。工具当然重要，但一线稳定性往往不是由新名词决定的，而是由那些很朴素的工程动作决定：超时怎么设、失败后谁来兜底、发布过程有没有可观察性、脚本是不是足够幂等。

 

那次值班之后，我对发布流水线做了三个小改动，收益都挺直接。

 

## 1. 给每个阶段补上明确超时，而不是无限等

 

以前我们的构建脚本里有不少“等它自己结束”的逻辑。看起来简单，实际上很危险：一旦外部依赖卡住，任务不会失败，只会一直挂着，占着 Runner，顺便把后面的发布全部堵住。

 

后来我把关键步骤都包了一层 `timeout`，并区分“可重试失败”和“直接终止失败”。

 

```bash

#!/usr/bin/env bash

set -euo pipefail

 

log() { printf '[%s] %s\n' "$(date '+%F %T')" "$*"; }

 

log "build image"

timeout 20m docker build -t registry.example.com/app:${GIT_COMMIT} .

 

log "push image"

timeout 10m docker push registry.example.com/app:${GIT_COMMIT}

 

log "deploy"

timeout 15m kubectl rollout status deploy/app -n prod

```

 

这个改动看起来很小，但效果很明显：以前一条异常流水线可能卡一个多小时，现在通常二十分钟内就能确定失败。失败不可怕，最怕的是“既没成功，也没失败”。

 

## 2. 把幂等性放到脚本第一优先级

 

很多发布脚本第一次执行能过，第二次重跑就翻车。原因通常是脚本默认环境一定是“干净”的，比如默认 ConfigMap 不存在、默认 Helm release 一定没装过、默认数据库迁移一定只跑一次。

 

我后来统一要求：运维脚本必须支持重复执行，至少不能因为重复运行把环境搞坏。比如 Helm 升级统一改成下面这种写法：

 

```bash

helm upgrade --install app ./chart \

  -n prod \

  --create-namespace \

  --set image.tag=${GIT_COMMIT} \

  --wait --timeout 10m

```

 

数据库迁移也不再靠人工记忆，而是把版本记录放进迁移表里。这样流水线重试时，应用部署和数据库变更都能沿着同一套状态机往前走，而不是“上一次跑到哪儿了只能靠猜”。

 

幂等性还有一个附带价值：你会更敢于让系统自动恢复。脚本一旦不怕重试，很多原来必须人工点击的步骤，就可以放心交给 Job 或调度器处理。

 

## 3. 给发布过程补一条“对人友好”的观察链路

 

我越来越觉得，流水线日志不是写给机器看的，是写给凌晨两点被告警叫醒的人看的。那次故障中，CI 页面虽然有日志，但关键信息全埋在一堆输出里：哪个镜像 tag 被部署、当前集群上下文是什么、失败发生在构建、推送还是 rollout，根本不直观。

 

后来我做了两个约束：

 

1. 每个关键步骤开始前必须打印阶段名。

2. 每次发布结束后必须输出结构化结果。

 

例如：

 

```json

{

  "service": "app",

  "env": "prod",

  "image": "registry.example.com/app:9f3c2d1",

  "status": "rollout_failed",

  "duration_sec": 426

}

```

 

有了这层结构化输出之后，后面无论是接飞书通知、发 Slack、还是做失败统计，都容易很多。更重要的是，排障时不用再从五百行日志里捞针。

 

## 一个容易被忽略的判断标准

 

我现在看一条发布流水线，最关心的不是“它快不快”，而是“它在失败时是不是足够诚实”。好的流水线在失败时会立刻停、明确报、方便重试；差的流水线则喜欢给你一种“好像快好了”的幻觉。

 

DevOps 做久了会发现，稳定性并不神秘。很多时候，系统不是败给了高并发，而是败给了一个没有超时的命令、一段不能重入的脚本、或者一份没人看得懂的日志。

 

工具可以持续升级，但工程习惯更值得反复打磨。如果要我给团队一个很具体的建议，那就是：把发布流水线当成产品来维护，而不是当成“能跑就别动”的后台脚本。真正决定交付质量的，往往就是这些不起眼的小地方。