部署运维总清单：上线检查与服务接管

高谷深陵大约 16 分钟约 4654 字

发布检查与长期接管记录实际制品、配置和数据状态，按发布阶段检查，再交给持续运行流程。高清原图

应用上线需要同时满足几类条件：运行环境能够承载程序，入口能够正确路由，数据依赖已经准备，发布过程可控，故障能够被发现和处理。检查时应围绕一个具体服务、一次具体变更记录结果，避免把不同环境、不同版本的输出混在一起。

每个检查项使用“符合预期、异常、未检查、不适用”四种状态，并附结果位置。访问受限时写明缺少的权限；不适用时说明原因，例如该服务没有消息消费功能。只有文件名、截图标题或一个勾选框，无法说明实际检查了什么。

建立服务与发布记录

六个阶段怎样连接

部署运维可以按以下顺序学习与准备。首次部署就要安排最基本的日志、备份和回退，后续阶段再系统完善：

阶段	要解决的问题	主要阅读入口
Linux 与服务器基础	进程在哪里运行，身份与权限怎样设置，主机怎样维护	Linux、服务器初始化、SSH、网络与端口
应用部署与访问入口	怎样构建、启动应用并通过域名访问	构建与制品、Spring Boot、Docker、Nginx、域名与 DNS、证书
数据与中间件运维	数据保存在哪里，如何授权、升级与恢复	MySQL、Redis、消息队列、对象存储、注册与配置
自动化构建与发布	怎样追溯、保存和逐步发布制品	制品仓库、镜像仓库、发布脚本、流水线、灰度发布
容器编排	多实例怎样调度、发现、挂载和更新	Kubernetes、Helm
持续运行与故障处理	如何发现异常、安排容量、恢复业务	日志、监控告警、调用链、巡检、备份恢复、应急

服务采用 systemd、Compose 或 Kubernetes 中的一种，就按实际平台准备命令；没有 Kubernetes 的服务无需为填表额外部署集群。静态前端、WAR 容器和受限网络可分别补充前端部署、Tomcat和离线部署。

服务信息与本次变更分开记录

服务信息相对稳定，包括负责人、业务入口、部署位置、运行身份、数据依赖、告警与恢复入口。发布记录描述一次变化，包括源代码提交、实际制品、配置版本、迁移脚本和部署批次。两份记录通过服务名和环境关联。

服务记录
  ├─ 服务 / 环境 / 负责人 / 值班与升级联系人
  ├─ 入口 / 主机或集群 / namespace / 工作负载
  ├─ 运行账号 / 凭据保管位置 / 网络访问范围
  ├─ 数据库 / 缓存 / 消息 / 对象 / 外部依赖
  └─ 日志查询 / 告警 / 备份与恢复 / 应急预案

发布记录
  ├─ 变更目的 / 提交 / 构建任务 / 测试结果
  ├─ 制品地址与 SHA-256 或镜像 digest / 目标架构
  ├─ 配置版本 / schema 迁移 / 功能开关
  ├─ 发布批次 / 继续条件 / 停止条件 / 回退方案
  └─ 实际部署结果 / 业务验证 / 观察与交接

记录凭据保管位置和获取身份，不粘贴密码、令牌或私钥。代码提交只能标识源码，运行实例还受构建依赖、制品、配置和数据状态影响。可变 tag 会被重新指向，镜像 digest 更适合作为精确发布输入；本机 image ID 与仓库 manifest digest 用途不同，记录时不要混写。

检查结果怎样便于复查

一条完整结果可以写成“预发订单服务，配置版本 cfg-7，目标镜像 digest 已核对，三个实例中两个已更新，第三个因拉取失败未更新；暂停扩大批次”。这比“镜像已检查”更有操作价值。

检查结果应包含目标、观察值、预期值、时间和执行人。原始输出放在受限记录中，摘要只保留必要信息。大型配置展开、docker inspect 全量输出和环境变量列表可能含秘密，不应自动上传到公开流水线日志。

发布前确认环境与变更条件

主机、身份和容量

检查项	要确认的结果	异常时的处理
主机或集群身份	环境、实例、namespace 与发布单一致	停止执行，重新核对目标；不要凭终端标题判断
运行账号	具备必要读写权限，无多余管理权限	按目录与对象修正授权，不用递归放开全部权限
时间、DNS、网络	时间同步，实际目标可解析，必要依赖可达	先确定解析、路由或访问规则是哪层失败
磁盘与 inode	包、镜像、日志、临时文件和恢复材料有空间	估算增长与部署峰值，处理明确的容量问题
运行资源	内存、CPU、文件句柄及连接池有余量	检查同机进程与依赖容量，避免只提高应用限额
日志和告警	新实例可查询，业务探测与接收人可用	修复观察路径，未完成前不进入无人值守发布

Linux 主机上，发布人员可以先执行以下只读命令。读取内核、服务或日志信息可能需要受控提权，不要因此直接切换到长期 root 会话：

id
hostname
uname -m
df -hT
df -i
free -h
systemctl --failed --no-pager

检查输出必须结合实际部署目录和限制解释。主机剩余内存较多，容器仍可能达到自己的内存上限；根分区有空间，挂载到数据目录的另一块盘仍可能已满。读取失败记为未检查，列出后续负责人。

制品、配置与数据变更

构建和测试在受控构建环境完成，再发布同一份制品。不要在生产节点临时重新解析依赖、跳过测试再生成一个同名包。运行时版本、CPU 架构和启动参数应与已测试组合一致，制品校验要对照可信发布记录。

Compose 项目可先做不打印展开内容的配置检查：

# 在本次发布目录执行；显式指定项目、配置和变量文件。
docker compose -p orders-test --env-file ./release.env \
  -f ./compose.yaml config -q

orders-test 是示例项目名，应替换为已核对的目标。退出码 0 表示 Compose 模型校验成功，仍需检查挂载、权限、镜像存在性和应用实际配置。完整展开内容可以在受限环境审阅，别直接输出包含密码的配置到共享日志。选项见 Compose config。

数据变更单独检查新旧程序兼容性。先新增可兼容结构、部署能同时处理过渡状态的程序、完成数据迁移，最后再删除旧结构，通常比同时替换所有东西更容易控制。每个阶段都要定义可回退范围。备份完成后还需确认恢复位置和实际恢复方法；一个备份文件无法替代迁移逆向处理方案。

注册中心、配置中心、规则存储等组件也可能改变应用行为。发布包不变而配置或流控规则变化时，仍应记录变更及回退方式。相关维护见 ZooKeeper、Nacos、Seata和 Sentinel。

入口、依赖与回退材料

对象	发布前确认
DNS / TLS / Nginx	目标地址、证书名称与信任链、配置语法、upstream 与旧配置副本
数据库	连接权限、迁移兼容性、锁与连接余量、复制进度、可恢复位置
Redis / MQ	内存、持久化、消费者与队列年龄；本次变化是否影响数据格式或消息契约
文件与对象存储	桶/目录权限、上传下载、文件引用、保留及恢复方式
外部接口	超时、重试、幂等约定、凭据、配额及模拟验证方式
回退材料	旧制品、配置、命令、数据处理方案、执行身份和验证方法

阈值要结合业务与历史基线。例如“队列长度大于零就禁止发布”会误伤持续消费系统；应看消息年龄、趋势和当前延迟目标。备份、复制或容量保护已经明显减弱时，应先处理风险，再决定是否继续非必要变更。

受限网络要从目标环境确认拉取身份、内部源与离线包可用，不能只看构建机缓存。证书续期依赖外部服务时，还要检查验证路径和失败通知。回滚镜像需要保留对应平台和仓库权限，不能等故障发生后再查保留策略。

按批部署并验证业务结果

先控制变更范围

发布前写清第一批实例或流量、观察指标和停止条件。指标可以包含错误率、延迟、关键业务结果、资源压力和异步处理进度；阈值与观察窗口应根据服务特点设置。小范围发布便于比较新旧版本，但仍需足够的有效请求样本。Google SRE 灰度发布解释了这种分组评估方式。

发布中保持制品与配置输入稳定。临时修改会产生另一种组合，需要重新核对影响、测试结果和回退条件。每批结束后记录实际运行状态，不因为启动命令返回 0 就自动扩大范围。

按运行平台选择核验命令

下面是只读核验入口，不包含向生产写入的新发布命令。变量由实际服务记录填写，身份应具有读取对应目标的权限。

systemd 服务核对进程和退出状态：

UNIT=orders.service
systemctl show "$UNIT" \
  -p ActiveState -p SubState -p MainPID -p ExecMainStatus
journalctl -u "$UNIT" --since '-5 min' --no-pager -n 100

状态为运行中后，还要确认该进程加载的制品和配置，再做请求验证。服务启动失败时，按退出码和日志定位，不连续重启掩盖第一次错误。发布目录和 systemd 运行配置见 Spring Boot 部署。

Compose 项目核对指定服务的容器与实际镜像 ID：

docker compose -p orders-test --env-file ./release.env \
  -f ./compose.yaml ps app
docker compose -p orders-test --env-file ./release.env \
  -f ./compose.yaml images app

compose up 会在检测到服务配置或镜像变化时重建容器，并保留已挂载的卷；修改文件后是否重建、是否拉取新镜像，要结合命令选项判断。单纯 restart 不会重新应用所有 Compose 配置。运行行为见 Compose up。

Kubernetes 同时限定 context、namespace 与工作负载：

CTX=staging-cluster
NS=orders
DEPLOY=orders
kubectl --context "$CTX" -n "$NS" get deployment "$DEPLOY"
kubectl --context "$CTX" -n "$NS" rollout status \
  deployment/"$DEPLOY" --timeout=120s
kubectl --context "$CTX" -n "$NS" get pods -l app=orders -o wide

超时或 Pod 未就绪时停止扩大批次，检查事件、容器退出、探针和镜像拉取。Deployment 的回退只覆盖相应 Pod 模板历史，不能自动撤销外部配置、数据库迁移或持久卷内容。历史保留与滚动更新语义见 Kubernetes Deployment。

从入口验证到业务完成

业务验证至少选择一条重要读取与一条受控写入，并根据服务特点覆盖鉴权、文件、消息或外部依赖。生产写入测试应有专用账号、可识别数据、幂等标识和清理安排；没有安全测试渠道时不要临时调用真实付款、短信或删除接口。

可以先用应急实验中的固定订单接口练习响应检查。按应急预案实验启动网关后，在同一宿主的 Bash 中执行：

LAB_URL=http://127.0.0.1:18680/orders/1001
curl -q --noproxy '*' --fail-with-body \
  --connect-timeout 2 --max-time 5 -sS "$LAB_URL"

正常时返回订单 1001、状态 CREATED 和版本 lab-1；错误上游返回 502，维护分支返回 503，两者都让命令非零退出。更换为真实接口时，还需按业务约定校验 JSON 字段、数据落库和异步终态，不能只匹配一个状态码。

回环实验显式禁用代理与 curl 配置文件。外部网络若必须经过代理，则按已批准路径配置代理，不能照搬 --noproxy '*' 来证明生产入口可达。curl 的响应码、配置文件和代理选项见官方手册。

异常时怎样停止或回退

达到预定停止条件后，先暂停后续批次，确认已更新实例与流量范围，再执行适用的回退或止损。旧程序兼容当前数据时可以回退程序；持续错误写入要先限制写入，再处理数据；回退材料不可用时应升级处置，避免临时拼装未知版本。

恢复旧版本后重新检查业务，而不只检查版本号。观察旧实例是否仍然负载过高、数据库是否留有锁或长事务、消息是否存在重复处理。数据库恢复到过去会排除之后的正常写入，具体选择与对账见备份与恢复。

发布后观察与长期接管

发布结果记录

阶段	记录内容	继续或结束条件
首批部署	实例、实际制品、配置与部署结果	目标组合运行，异常已查明或已回退
业务验证	入口、鉴权、必要读写、异步与外部结果	与约定业务结果一致，测试数据可识别
扩大范围	每批实例或流量、版本分组指标	误差与趋势在约定范围内，有足够样本
稳定观察	相关周期内的资源、依赖、业务指标	无持续恶化，临时措施已有处理安排
交接	当前版本、遗留问题、负责人和下次检查	接收人确认，并能找到运行与恢复材料

观察期由故障出现的时间特征决定。缓存过期、连接更新、定时任务和业务高峰不在同一个周期内；低流量服务也可能长时间没有有效样本。记录已经观察到的范围，对尚未覆盖的高峰或任务设置后续检查，别用统一等待时长替代判断。

接管一个服务要拿到哪些材料

接管人员至少应能完成三件事：找到正在运行的服务，判断它是否完成业务，在故障时取得必要权限和恢复材料。可按下面的表逐项核对：

类别	应能找到或执行的内容
运行位置	主机、集群、namespace、工作负载、入口与网络关系
部署方式	制品仓库、构建任务、配置位置、迁移与回退步骤
身份与权限	运行账号、操作账号、凭据保管与紧急访问流程
日志与监控	按服务和时间检索日志，查询关键指标，确认告警接收人
数据恢复	备份位置、解密能力、可恢复区间、隔离恢复记录与耗时
日常维护	容量增长、保留策略、证书续期、升级节奏与兼容要求
故障响应	预案、当前值班、升级联系人、依赖服务负责人

证书、镜像仓库、备份库和告警通道都可能依赖不同账号。服务账号可运行并不意味着接管人员已具备恢复权限，应通过受控读取或测试环境操作核对。

发布期间临时关闭的功能、消费者、告警或调度器，需要逐项恢复或继续跟踪。临时权限及时撤销，临时配置同步回正式配置来源，否则下一轮自动部署可能重新引入故障。

持续运行中的检查频率

业务告警持续监测突发故障；周期巡检寻找缓慢恶化的趋势；恢复演练检查备份、身份和步骤是否仍然可用。频率应根据数据变化、容量增长、服务重要性及恢复目标确定。

备份检查关注最近可恢复位置与演练结果，容量检查关注剩余处理时间，证书检查关注实际入口证书与续期链路。主机资源、日志文件、集中存储和数据库各有自己的保留与增长规律，不应使用同一条清理命令。

每次事故或接管发现的漏项，都应回到对应位置修正：运行配置错误进入配置仓库，缺失探测进入监控，恢复失败进入恢复脚本与演练，联系人失效进入值班安排。清单保持精简，保留那些确实影响上线决策或长期运行的检查。

curl 命令手册