离线交付实战：隔离机房环境下的依赖打包与部署设计

干交付这行的，最怕听到的一句话不是"客户又要改需求"，而是"机房是隔离网，上不了外网"。那意味着你平时熟练的那套操作全部失效：yum源连不上、pip装不了包、Docker Hub拉不了镜像、出问题连百度都搜不了。更难受的是，你辛辛苦苦搭好的一套部署方案，可能因为交付项目延期、客户机房变更、预算砍半等各种原因，一直没机会真正到现场跑一遍。这套建好了却还没上过战场的离线交付工程，就是我最近半年的状态：方案文档写得厚厚一沓，部署脚本来回测了十几遍，可真要拉到生产环境里硬碰硬，一次都还没有过。

这个场景我相信很多做政企项目、工业信息化、医疗系统集成的同行都懂。隔离机房、内网环境、等保要求，是绕不开的交付形态。这篇文章就聊聊我是怎么面对"不能上网"这件事做整套交付准备的，包括离线安装包怎么攒、部署脚本怎么设计才不至于在现场翻车、以及一套"没上过战场"的方案到底有哪些隐患。

1. 不能上网的机房：交付工程师的另一个位面

1.1 先搞明白机房为什么"不能上网"

很多没做过政企项目的人会疑惑：都2025年了，机房怎么会不能上网？实际上"不能上网"分好几种情况，每一种对交付的影响程度完全不同。

一种是物理隔离，机房跟外网之间压根没有物理链路，你要么背着硬盘进去，要么走审批流程通过专用的摆渡设备把数据传进去。这种环境最严格，常见于涉密系统、军工科研、部分金融核心节点。

还有一种是逻辑隔离，机房有网络出口，但是有严格的访问控制策略，只有特定IP、特定端口能通，或者需要通过代理才能访问外网。这种情况下，开发机在办公室能做的所有事，在现场都要提前想好替代方案。

第三种是最常见也最坑的：平时能上网，但交付那几天因为护网行动、重保期间、领导视察等特殊原因，临时切断了外网访问。我认识的一个兄弟就遇到过，周五进场部署，周六国家护网演习封网，活儿干了一半，剩下的全靠U盘和人脑硬扛。

不管哪种情况，结论都一样：不要把"能上网"当作交付方案的前置条件。提前做好完全离线可用的准备，是对自己负责。

1.2 离线交付的真正难点不是"不能联网"

刚接手这类项目时，我以为离线交付就是"把安装包拷贝过去，然后正常装"。实际做起来才发现，真正折磨人的是后面这几件事。

第一，你不知道目标机器的系统到底长什么样。同样是CentOS 7，内核版本、glibc版本、自带OpenSSL版本可能差很多；有的机器甚至是多年没打过补丁的老系统，连基础依赖都不全。你在开发机上装得好好的，到现场各种"缺lib""找不到so文件"。

第二，你没法用远程手段兜底。在线部署时出了问题，我可以开SSH上去慢慢查，或者发个包让现场同事执行一下。离线环境里，所有的排查都必须靠提前准备好的诊断脚本、日志采集工具、随身携带的备用软件包。

第三，历史包袱重。很多客户机房的机器不是新装的，上面可能已经跑着旧版本的服务、占用了端口、设置了奇怪的环境变量。你的部署方案不能裸奔，必须具备"在已有复杂环境里全身而退"的能力。

这些挑战叠加在一起，决定了离线交付的本质：你交付的不是一个软件，而是一整套自包含的、经过演练的、能在信息不全的情况下排障的自助服务体系。

1.3 一个典型的离线交付场景长什么样

拿我手上这套系统举例，业务架构不复杂：前端Nginx，后端一个Java服务，依赖一个PostgreSQL数据库，另外还有几个Python写的辅助脚本做数据处理。但因为是部署在电力行业的监控机房里，所有节点全部物理隔离，且操作系统是定制的、裁剪过的Linux发行版。

在这个场景下，我需要准备的交付物包括：

• 应用本身的安装介质（编译好的二进制包、JAR包、前端静态资源包）
• 运行环境底座（JDK、Nginx、PostgreSQL、Python运行时、必要的系统库）
• 依赖组件的离线包（包括数据库驱动、Python依赖库、前端构建产物）
• 部署编排脚本（自动检测环境、初始化配置、拉起服务、健康检查）
• 运维辅助工具（日志采集、指标监控、问题诊断脚本）
• 详细的部署文档和FAQ手册

这套东西在开发环境验证过无数遍，但真正拉去现场之前，还有一个关键的卡点：我无法完整模拟客户现场的那种"纯净+奇怪"并存的环境。这个问题我放到后面细说。

2. 离线部署的三座大山：依赖、镜像、环境差异

2.1 第一座山：依赖收集是个无底洞

每个软件都有依赖，依赖还有依赖。在线装的时候包管理器帮你自动处理，离线装的时候全都得自己背过去。这里最深的坑是"一级依赖好找，二级依赖致命"。

举个例子，一个Python脚本用到了requests库，你从PyPI上下载了requests的离线包。但没意识到它还依赖urllib3、certifi、charset-normalizer、idna四个库，而且每个库又有自己的版本要求。如果直接安装，你会发现缺一个装一个，装了又缺下一个，循环往复，心态爆炸。

我踩过一次很疼的坑：一个用Java 8写的服务，依赖了一个内部封装的加密组件，这个组件又依赖了bcprov-jdk15on。我在开发环境构建时没注意版本冲突，结果到现场安装时发现加密组件需要的是bcprov-jdk15on:1.68，而其他模块强依赖了bcprov-jdk15on:1.60，两个jar包同时存在，类加载直接乱套，服务启动报各种类找不到。

解决依赖问题的核心思路是：在联网机器上，用锁文件把整个依赖树固定下来，然后一次性拉取全部依赖产物。具体来说：

• Python项目，用pip freeze > requirements.txt锁定版本，再用pip download -r requirements.txt -d ./offline_packages一次性拉下所有依赖包。
• Node.js项目，用npm ci配合package-lock.json，再用npm pack或者npm cache的方式离线化。
• Java项目，用Maven构建后，执行mvn dependency:copy-dependencies把所有依赖jar包导出到指定目录。
• 操作系统层面，在联网机器上配置好yum源或者apt源之后，用yum install --downloadonly --downloaddir=/tmp/rpms把需要的rpm包全部拉下来。

最关键的一点是：拉依赖的机器和目标机器保持同一主版本的操作系统。你在Ubuntu上拉的deb包，不可能装到CentOS上；就算都是CentOS 7，yum源的版本和库的编译参数也可能造成兼容问题。最好准备一台和现场环境一致的"黄金镜像机"，作为唯一的依赖拉取来源。

2.2 第二座山：镜像传输比想象中麻烦

如果你的应用是容器化部署的，Docker镜像是另一座大山。开发环境的镜像仓库是联网的，到了现场却一片空白。

最常用的办法确实是docker save和docker load，但这里有几个细节很多人第一次做会踩：

• docker save是导出整个镜像层，包含所有历史记录，所以文件特别大。如果你的镜像构建时写了多行RUN，每一层都会被保存。建议先docker history看一下镜像层数，考虑是否用squash压缩层级。
• 镜像导入后docker images显示的仓库名和标签可能变掉。save的时候要用完整的-t参数维护好tag，load之后用docker tag重命名，否则Kubernetes或编排脚本引用的镜像名对不上。
• 如果现场机器是多架构的（比如有arm64的盒子，也有x86的服务器），你save的x86镜像在arm上根本load不进去。要么提前build多架构镜像，要么准备好两套介质。

另外一个容易忽略的是容器镜像仓库本身。如果现场机器数量多，或者有容灾需求，单靠Docker daemon本地存储肯定不够，还要在隔离环境里部署一套私有的镜像仓库（Harbor或者轻量的Registry）。这又引入了一个鸡生蛋的问题：私有仓库本身也要用镜像跑，它的镜像也要靠带进去。我的做法是把registry:2镜像也打包到介质盘里，现场临时起一个。

2.3 第三座山：环境差异比你想象的更隐蔽

操作系统层面最让人头疼的差异就是glibc版本。这个看似基础的问题，能毁掉一整个项目的现场部署。我用一个表格说明常见的兼容性问题：

glibc这个问题基本无解，因为它几乎跟系统绑死，如果程序在联网开发机上动态编译，到老系统上极大概率会挂。唯一的解法是：在目标环境的同版本系统上编译，或者采用静态编译。Go语言在这方面天然占便宜，build的时候加上CGO_ENABLED=0就是纯静态编译，拷过去就能跑。Java本身是字节码，JVM用自己的运行时，反而绕开了glibc的问题，前提是JDK版本必须对得上。

CPU指令集差异也很坑。开发机是新的至强处理器，目标机器可能是十年前的酷睿处理器，编译程序时用了新CPU才支持的指令集（比如AVX2），现场直接报"Illegal instruction (core dumped)"。这点在做Python和C++项目时尤其要注意，最好在编译参数里加-march=x86-64这类兜底选项。

还有一类不被注意的差异是字符集。现场机器可能没装中文字体、LANG环境变量奇怪，导致日志中文全是乱码。这不影响功能但影响排查体验，所以离线包里要带一份fontconfig和无衬线字体，部署脚本里显式设好LANG=en_US.UTF-8。

3. 我的离线交付包长什么样：一场预谋已久的"弹药组装"

3.1 从结果倒推：现场拿到U盘后第一件事是什么

我在设计交付包的时候，一直强迫自己想一个问题：如果我是现场那个已经被客户电话催了三遍的工程师，拿到这个U盘后，最希望看到什么？

答案是：别让我看README就开始猜，给我一个脚本，一个命令跑完。

哪怕这个命令背后实现得很笨，也比让现场同事在命令行里手动执行十步强。基于这个原则，我把整套离线交付包组织成下面这样的结构：

offline-delivery/ ├── 00_README_FIRST.txt ├── 01_checklist.html ├── 02_install.sh ├── 03_verify.sh ├── 04_rollback.sh ├── conf/ │ ├── app.conf │ ├── nginx.conf │ └── postgresql.conf ├── packages/ │ ├── jdk-8u411-linux-x64.tar.gz │ ├── nginx-1.24.0.tar.gz │ ├── postgresql-14.11.tar.gz │ ├── python-3.10.12.tar.gz │ └── rpms/ ├── apps/ │ ├── backend.jar │ ├── frontend-dist.zip │ └── scripts/ ├── images/ │ └── app-docker-images.tar ├── backups/ │ └── 说明.txt └── docs/ ├── 部署手册.pdf ├── 常见问题FAQ.md └── 网络架构说明.jpg

这个结构看似简单，但每一个目录都有讲究。packages目录放所有运行环境底座，apps目录放业务应用本身，conf目录集中放配置模板，backups目录用来承载现场的原数据备份（安装过程中会先把旧配置备份到这里），docs目录放各种文档。这么划分的目的是让现场人员能快速判断"现在缺什么东西""某个东西是干嘛的"。

02_install.sh是入口，它会把其他脚本按顺序组织起来执行。03_verify.sh做部署后的健康检查，04_rollback.sh做回滚。这三个脚本加上一个更新版本的05_upgrade.sh，构成了整套运维闭环。

3.2 安装脚本的幂等设计：能跑两遍不留副作用

离线部署的脚本，我给自己定了一个死规矩：必须幂等。什么叫幂等？通俗讲，同一套脚本在同一个环境上跑一次能成功，跑两次、三次，结果应该也一样干净，不会因为重复执行而出现脏数据、重复配置、端口占用。

要做到这一点，脚本里必须有清晰的"状态判断"逻辑。举个例子，PostgreSQL的初始化任务：

if [ -d "${PG_DATA_DIR}" ] && [ "$(ls -A ${PG_DATA_DIR})" ]; then echo "[INFO] PostgreSQL data directory already initialized, skipping..." else echo "[INFO] Initializing PostgreSQL data directory..." sudo -u postgres ${PG_HOME}/bin/initdb -D ${PG_DATA_DIR} \ --locale=en_US.UTF-8 -E UTF-8 fi

这段代码的含义很直白：数据目录非空就跳过初始化。数据库最怕的就是重复初始化把已有数据清了，这种判断是底线要求。

Nginx配置也一样，如果配置文件已经存在且内容非空，就只备份不覆盖、或者跳过配置步骤。但对于应用二进制，我的策略是必须覆盖，因为新版本就是修正旧版本问题的。

幂等设计还有一个隐藏好处：现场操作人员如果出现手滑、操作到一半断电等意外，恢复之后重新跑一遍脚本就行，不用心智负担地"我要从哪里重新开始"。

3.3 健康检查脚本：比安装脚本更重要

很多人煞费苦心写安装脚本，却忽略了部署完成之后的验证环节。我觉得这套离线工程里，verify.sh的价值甚至超过install.sh，因为现场最担心的不是安装失败，而是"装完了但服务不正常，还不知道哪里不正常"。

我的verify.sh会按顺序检查这些内容：

1. 端口连通性：检查Nginx的80/443、PostgreSQL的5432、后端服务的8080是否LISTEN。
2. 进程存活状态：检查java、nginx、postgres等相关进程是否存在。
3. 接口可用性：用curl请求后端的健康检查接口（比如/actuator/health），判断服务是否返回200。
4. 数据库连通性：用pg_isready命令检查数据库是否接受连接，并尝试用一个临时表做读改写验证。
5. 磁盘空间：检查数据目录所在分区的剩余空间。
6. 日志错误扫描：在应用日志和系统日志里搜索ERROR、Exception等关键词。

#!/bin/bash # 健康检查脚本关键片段：服务状态检测 SERVICES=("nginx" "postgresql" "backend") for svc in "${SERVICES[@]}"; do if systemctl is-active --quiet "$svc" 2>/dev/null; then echo "[OK] $svc is running" else echo "[FAIL] $svc is not running" fi done

这还不够。更贴近现场需求的做法是把检查结果输出成一份带时间戳的报告，当场就能给客户看："您好，我们的部署已经全部完成，各项检查项均通过，这是报告。" 省得客户问你一句你答一句，两个人都费劲。

3.4 回滚方案的三种形态

交付不是一锤子买卖，万一升级后出了问题，必须能退回去。我的回滚方案分了三个层次：

• 应用文件级回滚：每次部署前，脚本自动把当前版本的应用包复制到backups目录，比如backend.jar.20250601。回滚时只用停服务、替换文件、重启。
• 数据库逻辑级回滚：提前在数据库脚本里带上DDL和DML的逆操作，在升级脚本里记录升级前的数据库版本号。出问题后执行逆SQL降级，但前提是业务数据兼容新旧两个版本。
• 全量系统快照：针对整个部署目录做一个压缩备份，极端情况下解压覆盖。

三层回滚各有利弊，我通常建议现场同事优先采用第一层（应用文件回滚），因为最快；第二层要谨慎，涉及数据操作；第三层是最后的堡垒，耗时最长但最彻底。

4. 还没上过战场：这套方案到底藏着哪些隐患

4.1 纸上谈兵的局限：测试环境的"假隔离"

最残酷的事实是：我的开发测试环境虽然也是内网，但它是"自己人搭的内网"，和客户现场那种"物理隔离+定制的系统"完全是两码事。很多我引以为自豪的验证，放到现场可能一击即碎。

我自己梳理了一下，至少有这几个盲区。

第一个盲区是系统的差异性。我在测试环境用的是标准的CentOS 7.9，现场那台是客户IT部门基于CentOS 7.4二次裁剪的系统，删掉了很多他们认为没用的包。我脚本里依赖的tar、unzip、vim可能现场根本没有。有些人会说"那就用tar.gz包里面带stress-ng等静态编译工具替代系统工具"，但更稳妥的做法是：进场之前先要一份现场的基线信息（操作系统版本、内核、glibc、基础软件列表），提前做差异对比。

第二个盲区是资源限制。我在测试机上模拟不出来客户现场的硬件环境，比如磁盘阵列卡不支持乱序IO、内存只有4G、文件系统是XFS且inode数量非常有限。这些资源限制往往在线上环境压测时才浮出水面。

第三个盲区是网络拓扑。离线环境下虽然"不能上网"，但内部的网络访问关系依然复杂，有多张网卡、多个VLAN、防火墙策略、堡垒机代理。我的脚本默认的是"本地单机部署"，但现场可能是两台机器组集群，或者数据库在一个网段，应用在另一个网段，中间要过防火墙。如果脚本里写死了localhost，到了现场就会因为连接被拒而抓瞎。

这个阶段，我能做的只有"换位思考"：把自己想象成第一次拿到这套包的人，尝试各种非常规操作去破坏它。这个过程我没有省，也就是所谓的"验尸"。

4.2 介质本身的可靠性：U盘坏了怎么办

一个很容易被忽略但实际很致命的问题：交付介质的可靠性。我见过不止一次，U盘到现场了，插上电脑认不出来或者拷文件拷到一半报错，整套部署卡在最基础的文件拷贝上。

针对这个隐患，我的交付包会做三重保障：

• 交付前对U盘做全盘校验，并写入校验信息。具体做法是把整个交付包目录生成一个SHA256SUMS文件，用sha256sum -c验证完整性。
• 拷贝时采用rsync -av的方式，断点续传加上校验，不直接用cp。
• 保留一份加密打包的副本在共享网盘或者本地NAS上，万一口令介质损坏，可以从其他路径临时拉取。

具体校验文件的生成很简单：

cd offline-delivery/ find . -type f -exec sha256sum {} \; > SHA256SUMS # 现场校验： sha256sum -c SHA256SUMS

这个动作看起来笨，但关键时刻能救命，尤其面对的是客户那种"不给第二次进场机会"的重保环境。

4.3 "没打过仗"的心理建设：预案的价值大于操作本身

这套工程建好了、没上过战场，最让我夜里睡不着的不是技术方案本身，而是"我没有现场排查的经验积累"。在线部署时出了问题，我可以在开发机上一行行Debug，甚至远程连上去看日志。但离线现场，客户盯着你，日志看不了，网也通不了，很多问题只能靠经验和预案去猜。

为了缓解这种不确定性，我一共准备了四十八个场景的应急预案。这些预案不是凭空写的，而是源自团队其他成员在过往项目里留下的"战报"。

举几个典型的：

• 现场机器时间不对，导致SSL证书验证失败，应用和数据库连接报错。预案是在部署脚本里强制用date校验当前时间，并要求现场人员确认，或者把应用层的超时时间放宽。
• 客户机器的磁盘格式是LVM，扩容麻烦，数据目录空间不够。预案是检测磁盘使用率，低于20%才允许部署，否则自动中止并提示。
• 系统防火墙策略阻止端口访问。预案是检测firewalld或iptables的规则，发现端口冲突或未放行时给明确的提示而不是黑屏报错。

这些预案的价值不在于每条都能用上，而在于给了现场人员"按下按钮前有心理锚点"的底气。那种感觉就像第一次上台演讲，虽然不知道台下会问什么问题，但如果把"不知道的问题记在小卡片上"都背了一遍，话筒递过来的那一刻就不会冷场。

4.4 交付窗口前的技术验证：一台"脏"的虚拟机很重要

既然还没上过真战场，我就在后方尽可能模拟一个"脏战场"。很多人做测试的时候习惯用一个全新的干净虚拟机，但我特意造了一台"环境被搞乱过的机器"：系统是老版本的CentOS，几个人装过各种东西，环境变量混乱，端口被乱七八糟的服务占着，甚至防火墙策略是不通的所有端口。

把交付包拿到这台机器上，强制自己走一遍标准部署流程。这个过程很有价值，因为所有"干净环境测不出来"的问题都会浮出水面。

• JDK版本冲突：机器上预装了一个不同版本的JDK，环境变量指向它，脚本里没注意用了裸的java命令调错版本。
• 端口占用：Nginx想监听80端口，机器上有个旧的Tomcat占着，脚本报了端口冲突，但没有给自动化处理方案。
• /etc/hosts里面记录了残留的旧域名映射，导致应用内部通信跑到错误地址上。

这些都是平时开发环境永远不会碰到的问题。但真实客户机上一定存在。在"脏环境"里把脚本打磨到能自适应处理，或者至少快速定位问题并给出指引，是我上战场前能做的最大程度准备。

5. 进场前一周的装备清单与研究目录

5.1 操作系统的"体检报告"：进场之前搞定基线信息

为了避免到了现场才发现系统裁剪严重，我在交付方案里新增了一个硬性要求：客户进场前，必须先提供一份"目标主机信息采集表"。这个表格由我在离线包里附带一个采集脚本，客户IT可以在现场直接执行，把输出发回给我预判风险。

采集脚本里包含这么几项：

echo "===== 系统版本 =====" cat /etc/os-release uname -m uname -r echo "===== 基础工具 =====" for tool in tar unzip gzip wget curl zlib pcre openssl; do printf "%s: " "$tool" command -v "$tool" || echo "MISSING" done echo "===== 内存和磁盘 =====" free -h df -h echo "===== glibc 版本 =====" ldd --version | head -1 echo "===== 已存在端口 =====" ss -tlnp 2>/dev/null || netstat -tlnp echo "===== 防火墙状态 =====" systemctl is-active firewalld 2>/dev/null || echo "firewalld inactive" systemctl is-active iptables 2>/dev/null || echo "iptables inactive"

这个表格的作用是砍掉一批明显不兼容的问题。比如客户说他们用的是CentOS 8，结果采集回来看是RedHat 8.5，命令差异和源差异都要提前适应，不会在进场当天才开始跟客户商量"能不能换系统"。

另外，如果已经知道客户现场有堡垒机、跳板机，我会额外确认一下他们允许的访问方式（SSH密钥还是密码）、分配的用户权限（root还是普通用户+sudo），这些都直接影响脚本的落地方案。很多部署脚本卡壳就是因为自以为用root跑的，现场给了个普通用户。

5.2 离线软件包与外部工具的"军火库"

除了业务本身的依赖，我还会准备一些"通用军火"，这些工具不一定每次都用得上，但没带就可能现场解决不了问题。

• tcpdump和netcat的离线rpm包：排查网络连通性；
• strace的离线包：程序启动失败时跟踪系统调用，定位是缺库还是权限问题；
• lsof的离线包：查看谁占用了端口和文件；
• rsync的离线包：大文件传输和断点续传；
• vim和tree的离线包：现场编辑配置和查看目录结构；
• python3的离线tar.gz：很多诊断脚本依赖Python环境；
• file命令的离线包：确认上传的二进制文件确实是目标架构；
• dmidecode、smartctl等硬件信息采集工具：判断硬件健康状态。

这些工具的离线包可以在联网机器上通过yum或apt直接拉取。不要小看这些"基础能力"，在现场那是保命用的。

我把这些工具也纳入到交付包的一个独立目录tools/里，并在README_FIRST.txt中标注"这些不是本系统组件，是排障辅助工具，不占业务空间，体积也很小，千万不要误删"。

5.3 文档不嫌少：FAQ手册的积累办法

给客户的交付文档，很多工程师是最后一天才开始写的。我的经验是：从写第一行脚本那天开始，就把"如果这里有坑，谁最可能在这里踩坑"记录下来。

我会在每一个容易出问题的环节旁边写注释和提示，脚本注释不全用"-- 这里是配置参数"，而是写成"注意：如果目标机是CentOS 8，此路径变为...；如果现场没有systemctl，请使用service命令"。

这些备注汇总成FAQ，是离线交付包最有价值的副产品。FAQ的目录结构通常是：

• 硬件兼容类
• 操作系统差异类
• 依赖错误类
• 配置参数类
• 网络策略类
• 数据库问题类
• 应用启动失败类
• 客户常见问题应对类

我见过太多交付团队，一线工程师做完了项目，经验烂在个人手里——他走了，团队就失忆了。离线交付包里的FAQ，算是把这批经验从个人记忆里挖出来存档的一种手段。

6. 这一套方案接下来还会怎么打磨

6.1 从"能不能装"到"装得好不好"：加入自动化压测

现在这套交付包只能满足"把服务拉起来、接口通、数据写进去"这种基本目标，但离"装得好不好、扛不扛得住"还有距离。如果后续接入真实环境，我计划在离线包里附带一个轻量压测工具（比如基于wrk或者自定义脚本），部署完之后做一个短时压测：模拟10个并发请求，持续五分钟，记录响应时间和错误率。输出成一份简单的测试报告，作为交付验收的附件之一。

压测的价值不只是给客户看"性能达标"，更重要的是在部署完成后早期发现问题。很多故障其实在刚上线时就有潜伏症状，比如GC频繁、连接池耗尽、慢SQL，只是没有流量时看不出来。压测等于把"第一次上线前的体检"提前做掉。

6.2 增加"无人值守"能力：自动应答文件和远程协作预案

有些隔离机房的现场甚至不允许太多工程师同时进入，或者当天大家都被别的项目占着，无法到场。为了让这套方案能用更少的人力完成交付，我计划在下一个迭代里把部署脚本改成支持"自动应答文件"模式。

也就是说，现场人员只需要编辑一个deploy.conf，填好IP、路径、端口，然后执行./install.sh --config deploy.conf，整个部署过程不再需要人工交互，全程输出日志。

同时，我也在摸索通过JDBC、HTTP这些通道递出诊断信息的方案。虽然网络不通外网，但内网内部如果有Web服务和管理终端，可以把日志和监控页面上传到内网的一个共享Web目录，让不在现场的人也能通过浏览器查看，减少亲自到场的频率。

6.3 版本演进的节奏：小版本勤发，大版本稳发

对于这套离线交付工程本身，我也开始实行版本管理。install.sh每次改动，都会同步更新版本号和改动日志。小改动直接进入交付包，大改动（比如更改部署拓扑、增加组件）必须走一遍完整的测试流程才能发版。

目前工程是V1.2版本。距离V2.0还有几项关键工作：支持数据库主从、支持应用多实例集群、支持灰度发布。这些功能在联网环境很成熟，但在离线环境要想做好，需要更多的设计和测试。

6.4 跨过"没上过战场"的心态关卡

最后说说心态。项目标题写"还没上过战场"不是矫情，是因为我很清楚，开发环境和真实交付现场之间的鸿沟，不是光靠想象能弥合的。自定义脚本、自动化检查、应急预案这些东西，说到底都是在给自己的不确定性打个折扣。

但我有一个信念：技术方案的成熟度不由"上过战场的次数"决定，而由"对待不确定性的态度"决定。你在干净环境里跑通一百遍纯属自嗨；你在"脏环境"里模拟过几十种失败，却比什么实战经验都更能提前揭出问题。

如果这套东西最终拉去现场出现意外，我可以接受——因为"意外"本身就是这类交付绕不开的一部分。我真正不接受的是：明知有那么多离线环境的坑，却不上心去填，把"建好了一套方案"当成"能交付一套方案"。

做好手上能做的，剩下的交给时间。

我个人在把这份交付包反复打磨的过程里，最大的体会就是：离线交付是一场"把所有可能的失败都提前想一遍"的智力游戏。每多想到一种现场可能出现的状况，每多写进一行容错逻辑，真正上战场时的心态就会稳一分。送给每一个正在跟隔离机房的复杂性较劲的同行。