接到DataAI Portal在信创环境离线部署这个任务时我的第一反应不是兴奋而是心里发虚。信创环境意味着飞腾ARM64的CPU、银河麒麟V10的操作系统离线部署意味着整个机房没有任何外网通道所有安装包、依赖、补丁都得提前准备好——这两件事叠在一起就不是“装个软件”那么简单了。整个过程从方案设计、介质准备、环境初始化、安装执行到功能与稳定性测试前前后后花了三周时间中间踩了不少坑。这篇文章就把我这次完整的离线部署测试过程记录下来包括环境概貌、依赖准备的方法、安装执行的细节、测试方案的设计思路以及那些在文档里根本找不到的坑。无论你是要部署DataAI Portal还是要做其他业务系统在信创平台的离线交付这套思路都可以直接复用。1. 接手任务时先想清楚的三件事1.1 信创环境到底特殊在哪先说硬件。我们这次拿到的机器是飞腾FT-2000/64处理器ARM64架构aarch64128GB内存系统盘是2块480GB SSD做RAID1数据盘是6块4TB SATA盘。操作系统是银河麒麟V10国防版内核版本4.19。这里有个关键点同样是“Linux”ARM64和x86_64是两套完全不同的生态。很多软件在x86上装得好好的换到飞腾上要么没有对应包要么有包但内部带了x86的原生动态库.so跑起来就报“cannot execute binary file”。后面我会专门讲这个坑。可以说信创环境部署的第一课就是忘记你在x86服务器上的所有经验惯性每一个组件都要重新确认架构兼容性。另外银河麒麟V10虽然是国产操作系统但它本质上还是基于Linux内核的所以基础操作逻辑和CentOS/RHEL非常接近。这意味着我们之前积累的systemd、yum/rpm、shell脚本等技能完全能用只是需要额外注意ARM64的软件来源和版本匹配。1.2 DataAI Portal的组件依赖画像DataAI Portal是我们团队负责的一站式数据智能平台门户端包含数据源管理、数据开发、AI模型管理和可视化报表几大模块。它的技术栈不算冷门前端是Vue打包后的静态资源由Nginx托管后端是Spring Boot微服务跑在JDK 8上数据层用了MySQL信创环境一般要换成达梦或人大金仓 Redis缓存消息这块走RabbitMQ文件存储用MinIO。听起来都是常规组件但在离线ARM64环境下每一个组件都可能成为拦路虎。我拿到手的第一件事就是把DataAI Portal的部署文档翻了一遍列了一个完整的组件依赖清单。这一步不能省因为你后面准备离线介质时所有依据都来自这张清单。列清单时至少要包含组件名称、版本号、架构要求、依赖的其他包、用途、部署方式rpm/二进制/源码编译/容器镜像。1.3 离线环境带来的三个连锁难题在线部署时遇到问题yum install、pip install、docker pull都很方便离线环境则是另一套游戏规则。我归纳了三个核心难点依赖闭包问题每个软件都有依赖依赖还有传递依赖。离线环境下没有镜像源可用所有依赖必须提前算出一个完整“闭包”少一个都装不成。架构差异问题所有包必须是aarch64版本不能直接从x86的机器上拷贝。验证成本问题一旦现场装不上没法上网查方案、没法临时下载补丁只能靠现场人员的经验和事先准备。搞清楚了这三点整个项目的工作重心就很明确了离线介质准备阶段花的时间越多现场部署阶段踩的坑就越少。这是一条非常朴素的真理后面所有操作都围绕它展开。2. 离线安装包的准备像给无人区补给一样做依赖清单2.1 影子环境架构一致的“练兵场”准备离线介质的第一步得先有一台与目标机同架构aarch64、同操作系统版本银河麒麟V10 ARM版、且有网络的机器。我管它叫“影子环境”。为什么必须同架构因为RPM包和编译好的二进制都是架构相关的。你要是拿一台x86的机器去yumdownloader下载下来全是x86_64的包拿到飞腾机器上根本装不了。如果实在找不到aarch64的在线机器可以用qemu-user模拟ARM64环境凑合用但实测下来效率很低而且某些包在模拟环境下会装不上容易出现“影子环境能装、真机装不上”的假象。最可靠的做法还是找一台真机哪怕是云上的ARM64实例都行。影子环境的另一个用途是预演。我在影子环境里把完整的部署流程跑了一遍成功之后再开始做介质。这一步相当于给整个项目上了一道保险既然在影子环境能装通到了现场只要介质和系统环境一致理论上也能装通。2.2 RPM依赖下载与本地仓库搭建对于系统的基础软件Nginx、Redis、gcc、依赖库等我推荐用本地RPM仓库的方式。具体做法分三步。第一步在影子环境上用yumdownloader把目标软件的依赖包全部拉下来mkdir -p /opt/offline-rpms yumdownloader --resolve --destdir/opt/offline-rpms nginx redis mariadb-server gcc如果你的系统里没有yumdownloader可以用yum-plugin-downloadonly的方式或者直接yum install --downloadonly --downloaddir/opt/offline-rpms nginx redis第二步在/opt/offline-rpms目录下执行createrepo生成仓库元数据createrepo /opt/offline-rpms第三步把这个目录拷贝到目标机的/opt/offline-rpms在目标机/etc/yum.repos.d/下新建一个repo文件[offline-rpms] nameLocal Offline RPMs baseurlfile:///opt/offline-rpms gpgcheck0 enabled1之后目标机上的yum install就会从本地源安装自动解决依赖。这里有一个非常关键的教训--resolve参数只解决当前系统能识别的依赖。如果某个RPM包在影子环境里没有被安装过它的依赖可能不会被完整拉取。所以我在影子环境里先试装了一遍目标软件把报错提示缺的包补齐再重新生成repo。只有这样反复验证过才算是一个可靠的离线源。2.3 Java和Python依赖的离线化DataAI Portal的后端是Spring Boot应用JAR包本身是纯Java的跨平台没问题但有两个隐患需要注意。第一个隐患是JAR内部内嵌了JNA或其他native库。很多Java中间件为了性能会在JAR里带上C语言的动态库比如snappy-java、rocksdb-jni、jna。这些库是分架构的如果打包时只带了x86_64版本到了ARM64机器上加载就会报错。这个在打包阶段就要确认后面我也会细说。第二个隐患是JDK本身。银河麒麟V10自带OpenJDK 8可以直接用系统源安装也可以单独携带一个aarch64的JDK tarball。我们是直接把影子环境里的JDK目录整个tar打包带过去的保证版本完全一致。如果DataAI Portal还有Python相关的服务离线打包用pip downloadpip download -r requirements.txt -d /opt/pypkg \ --platform manylinux2014_aarch64 --only-binary:all:到了目标机用pip install --no-index --find-links/opt/pypkg -r requirements.txt注意--platform参数不能省否则pip会在在线环境下下载当前机器的架构包又回到老问题上。2.4 介质校验与版本台账别让你的U盘毁了一切离线介质最怕什么最怕的是拷贝过程中文件损坏或者版本拿错到了现场装到一半才发现。我的对策是两件事校验和台账。校验很简单在影子环境里对所有安装包生成SHA256find /opt/offline-rpms -type f -name *.rpm -exec sha256sum {} \; /opt/offline-rpms/checksum.sha256到了目标机执行sha256sum -c checksum.sha256确认所有文件完整。台账是一张表格记录每个包的名称、版本、架构、来源、校验值前8位、用途。别小看这个动作离线环境里没有外网搜索能力现场工程师拿到你的介质包全靠这个台账判断该装什么、不装什么、装错了怎么排查。组件版本架构用途部署方式OpenJDK8u312aarch64Java运行时tar包Nginx1.20.1aarch64前端静态资源与反向代理rpmRedis6.2.7aarch64缓存rpmDM88.1.2aarch64关系型数据库bin安装包RabbitMQ3.9.15aarch64消息队列rpmMinIO2023-08-01aarch64对象存储二进制这份台账我建议统一命名为manifest.txt放在介质包的根目录。现场部署时第一件事就是对着台账清点文件缺什么立刻反馈不要等到安装时才意识到介质不全。3. 麒麟V10飞腾环境的初始化与预检3.1 系统基线内核参数、字符集与时区到了现场第一步不是急着装DataAI Portal而是把操作系统基础环境调好。我按顺序做这几件事。先看系统基本信息确认没拿错机器cat /etc/os-release uname -m lscpu | grep Model name再看内核参数。信创环境下跑Spring Boot微服务有几个参数必须调cat /etc/sysctl.conf EOF vm.max_map_count 655360 vm.swappiness 10 fs.file-max 6553560 net.core.somaxconn 4096 EOF sysctl -pvm.max_map_count不调的话Elasticsearch这类组件或者JVM的mmap文件操作会报错vm.swappiness调低是为了减少swap抖动毕竟数据库和应用都在同一批机器上频繁换页会很影响性能。字符集必须确认是UTF-8echo $LANG localectl set-locale LANGzh_CN.UTF-8这个坑很隐蔽。如果系统字符集是POSIX或C应用写入中文数据可能乱码报表和日志中的中文全都变成问号。我们这次直接一步到位改成了zh_CN.UTF-8。然后是时区和时间同步。离线环境没有外网不能走公网NTP但通常企业内部会有NTP服务器。配置chrony指到内网NTP地址yum install -y chrony cat /etc/chrony.conf EOF server 192.168.10.5 iburst local stratum 10 EOF systemctl restart chronyd chronyc sources -v时间不同步会导致两个严重后果一是分布式组件之间的消息乱序二是SSL证书校验失败。特别是在离线环境里系统时间如果跑偏应用启动时的证书相关报错会让人误判成介质问题排查半天才发现是时间差了几分钟。3.2 数据库与中间件的离线安装数据库我们最终选了达梦DM8这也是信创环境里最常见的组合。DM8的离线安装包是一个bin文件直接执行./DMInstall.bin可以选择命令行或图形界面安装。命令行方式适合远程操作推荐用dmdba用户来安装不要用rootgroupadd dmdba useradd -g dmdba -m -d /home/dmdba dmdba mkdir -p /opt/dmdbms chown -R dmdba:dmdba /opt/dmdbms su - dmdba -c /data/install/DMInstall.bin -q创建实例的时候有两点提醒字符集选UTF-8大小写敏感配置要跟应用需求一致。我们第一次创建实例时大小写敏感选项没估算好后面应用连上后表名大小写对不上重建了一次实例才解决。达梦对Oracle和MySQL的兼容模式有选项DataAI Portal如果原本是基于MySQL开发的建议用兼容MySQL的模式初始化能省很多SQL方言的适配工作。Redis和Nginx的离线安装就简单多了直接用本地RPM源yum install -y redis nginx装完后把Redis的maxmemory、requirepass按生产要求配好。Nginx要注意的是编译模块如果只用反向代理和静态文件麒麟源里的默认版本完全够用没必要非得自己编译。自己做编译的话要带gcc、make、pcre-devel、openssl-devel等一堆工具链离线环境下亏得很。3.3 运行用户、目录与systemd服务规划生产环境部署最忌讳用root跑业务应用。我统一建了一个dataai用户useradd -m -d /home/dataai dataai mkdir -p /opt/dataai/{bin,conf,lib,logs} mkdir -p /var/log/dataai chown -R dataai:dataai /opt/dataai /var/log/dataai每个服务写一个systemd unit文件。这一步很多人会偷懒用nohup启动但在离线交付场景我强烈建议用systemd。原因很简单现场的运维习惯是systemctl管理服务而且systemd能实现宕机自动拉起这在没人值守的服务器上太重要了。以网关服务为例unit文件长这样cat /etc/systemd/system/dataai-gateway.service EOF [Unit] DescriptionDataAI Portal Gateway Afternetwork.target mysqld.service redis.service [Service] Userdataai WorkingDirectory/opt/dataai ExecStart/usr/bin/java -Xmx4g -jar /opt/dataai/lib/dataai-gateway.jar ExecStop/bin/kill -s TERM \$MAINPID Restarton-failure RestartSec10 LimitNOFILE65535 [Install] WantedBymulti-user.target EOF写完记得systemctl daemon-reload然后逐一启动。服务规划的原则是基础组件先起业务服务后起所有服务都有明确的启动顺序说明写进交付文档里。现场工程师不一定懂你的业务但只要能照文档按顺序执行就不会有大的偏差。4. DataAI Portal安装执行与逐项验证4.1 配置文件的“信创改动点”DataAI Portal的配置主要分为几类数据库连接、缓存连接、文件存储地址、各微服务的注册中心地址。在信创环境里最需要留意的是数据库驱动的替换。假设应用原本连的是MySQL连接串长这样spring.datasource.urljdbc:mysql://192.168.10.10:3306/dataai spring.datasource.usernamedataai spring.datasource.password******换成达梦DM8后spring.datasource.urljdbc:dm://192.168.10.10:5236/dataai spring.datasource.driver-class-namedm.jdbc.driver.DmDriver spring.datasource.usernameSYSDBA spring.datasource.password******问题来了Spring Boot的默认配置里并没有达梦的驱动依赖。如果打包时没把DmJdbcDriver18.jar放进去运行时就会报ClassNotFoundException: dm.jdbc.driver.DmDriver。这个驱动JAR需要提前从达梦的安装包里找到手动放进应用的lib目录或者用-Dloader.path/opt/dataai/lib指定外部依赖加载路径。另一个容易忽略的连接配置是连接池校验SQL。不同数据库的校验语句不一样MySQL是SELECT 1达梦同样可以用SELECT 1但有些版本需要写成SELECT 1 FROM DUAL。如果配置不对应用启动后连接池会持续报错接口全部超时。建议在部署前就用数据库客户端验证一遍JDBC连接串和驱动兼容性别等应用起来再排查。4.2 启动顺序与服务健康检查服务的启动顺序很重要。我们的顺序是达梦数据库→Redis→RabbitMQ→MinIO→注册中心→各业务微服务→Nginx前端。为什么要按这个顺序因为业务服务启动时会去连接依赖的基础组件。如果数据库还没起来业务服务启动时连接失败可能直接退出或者进入无限重试。虽然大多数框架支持重试但重试期间服务状态是“半死不活”的现场人员不好判断到底有没有问题。所以按照依赖关系逐层启动每层确认健康后再启动下一层是最稳妥的方式。健康检查我建议用两条腿走路。第一是进程层面systemctl status dataai-gateway.service第二是应用层面。DataAI Portal的微服务如果暴露了Actuator端点就通过HTTP检查curl -s http://127.0.0.1:8081/actuator/health | jq .返回status:UP才算真正就绪。如果没暴露Actuator就检查应用的启动日志找到“Started XXXApplication in x seconds”这样的标志性日志来确认。我还写了一个简单的巡检脚本可以循环检查所有服务的端口和健康接口#!/bin/bash services(8080:web 8081:gateway 8082:data-service 8083:model-service) for item in ${services[]}; do port${item%%:*} name${item##*:} if ss -tlnp | grep -q :$port ; then echo [OK] $name listening on $port else echo [FAIL] $name not listening on $port fi done这个脚本在每次部署或重启后跑一遍30秒就能给出结论现场排查问题时非常好用。4.3 首次登录与端到端链路联调服务全部启动后打开浏览器访问门户地址用管理员账号登录。这里我强调一个原则一定要做一遍完整的核心链路而不是只看登录页能打开就宣布部署成功。我的核心链路是登录→添加数据源→测试数据源连通→创建数据开发任务→提交离线调度任务→任务执行成功→在报表模块创建可视化图表→导出PDF。每一步都实际执行一遍并把结果记录下来。只有核心链路全部走通才敢说是真正部署完成。为了加速验证我通常会写一个Postman集合或者一个简单的shell脚本按顺序调用这些核心接口每步输出响应码curl -s -X POST http://127.0.0.1:8080/api/login \ -H Content-Type: application/json \ -d {username:admin,password:xxx} -o /tmp/login.json cat /tmp/login.json如果每个步骤耗时都在合理范围、返回码都是200那基本可以确认部署没问题了。这里要提醒一句首次登录通常要重置密码这个环节虽然小但最容易漏掉。之前有次交付客户反馈“部署成功但登录不了”结果是因为我们用的默认密码过期策略管理员账号首次登录强制改密而文档里没写清楚。5. 功能测试与稳定性验证不能只证明“能跑起来”5.1 功能测试用例的设计思路部署完成只是开始测试才是重头戏。我的测试策略是以核心业务链路为主线覆盖周边功能模块兼顾异常和边界场景。用例设计按模块拆分每个模块一张表。以登录认证为例用例编号前置条件测试步骤预期结果实际结果LOGIN-001系统已部署输入正确用户名密码登录登录成功跳转首页通过LOGIN-002系统已部署输入错误密码提示“用户名或密码错误”通过LOGIN-003用户已登录等待会话超时后操作跳转登录页并提示重新登录通过LOGIN-004系统已部署连续5次输错密码账号锁定提示联系管理员通过数据源管理模块要覆盖新增MySQL数据源、新增达梦数据源、测试连通性成功/失败、编辑数据源、删除数据源。其中“测试连通性失败”这个负向用例特别重要因为很多现场环境的内网网段做了隔离数据库端口可能不通一定要在功能测试阶段就暴露出来。数据开发模块重点测新建任务、配置调度周期、手工触发执行、查看执行日志、任务失败重跑。AI模型管理模块重点测模型上传、模型部署上线、发起在线推理、查看推理结果。报表模块重点测创建报表、选择图表类型、渲染展示、导出PDF/Excel。关于前端自动化我多说两句。信创环境常用的浏览器是奇安信浏览器、铨兴浏览器这类基于Chromium内核的产品它们的WebDriver版本和架构ARM64是否能适配必须在影子环境里提前验证。如果driver不兼容Selenium根本驱动不了浏览器。如果时间紧手工回归加接口自动化测试的组合更实际别在前端自动化上死磕。5.2 性能基准与容量估算功能测试通过后还要回答“这台机器能扛多大的并发”这个问题。我们用的是JMeter因为JMeter是纯Java应用在ARM64上跑没问题。压测分两个阶段。第一阶段是单接口基准。选登录接口、报表查询接口、模型推理接口各跑一轮每轮5分钟并发从10到50逐级增加记录TPS和响应时间。以我们的环境为参考20并发下登录接口TPS约320P95响应80ms报表查询接口TPS约45P95响应1.2s。这个数据本身没有绝对意义重要的是建立基准线后续如果系统升级或数据量增长可以对比这个基准判断是否劣化。第二阶段是混合场景。模拟真实用户行为30%用户在看报表、20%用户在跑数据开发任务、30%用户在做模型推理、20%用户在做数据源管理。混合压测能暴露组件间的资源竞争问题比如数据库连接池不够、内存和CPU的争抢导致部分接口P95飙升。压测过程中要同步监控系统资源top -b -d 5 | grep -E Cpu|Mem free -h iostat -x 5还有一个容易被忽略的指标是GC日志。Spring Boot应用启动时加上GC打印参数-Xloggc:/var/log/dataai/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps压测结束后检查GC日志看Full GC的频率和耗时。如果压测过程中Full GC次数暴增说明JVM堆配置不对或者有内存泄漏迹象需要回查代码和配置。5.3 72小时稳定性与故障切换测试性能达标之后我建议做一轮72小时的稳定性测试。做法很简单用JMeter跑一个低并发的混合场景脚本比如10并发持续72小时期间观察四个指标内存曲线是否持续上升持续上升意味着内存泄漏GC频率是否稳定应用日志有没有ERROR堆积定时任务是否按时触发并且执行成功72小时结束后把每天的TPS和响应时间画成趋势图如果曲线平稳没有明显劣化就可以认为稳定性达标了。故障切换测试也是交付前必须做的。我们做了三个场景第一个场景是kill掉一个网关实例观察流量是否自动切换到另一个实例。如果网关做了负载均衡Nginx upstream配置了多个后端kill掉一个后Nginx应该自动将请求转发到健康实例客户端无感知或只有一次重试。第二个场景是停掉Redis观察应用的降级表现。缓存挂了之后查询接口应该降级为查询数据库而不是直接报500。即使有些接口会变慢也不能让核心业务完全不可用。第三个场景是数据库主备切换。如果达梦配置了主备集群把主库停掉备库接管后应用应该能自动重连并继续提供服务。Spring Boot的数据源如果配置了HikariCP重连机制相对成熟但要确认初始连接失败后不会永久性失败。这些故障测试看起来麻烦但非常值得做。信创环境里硬件和系统软件都比较新稳定性问题比成熟的x86生态更容易出现。提前暴露问题总比交付后客户那边出事再救火强。6. 踩坑记录离线部署中最容易翻车的几个环节6.1 glibc和OpenSSL版本引发的“装好即失败”最典型的一个坑某个组件在影子环境里装得好好的rpm也没报依赖缺失但到目标机上一启动就报./xxx: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.29 not found (required by ./xxx)原因很直接影子环境里的系统版本比目标机新二进制文件编译时链接的glibc版本在目标机上不存在。这种情况在离线环境特别尴尬因为没法现下兼容包。排查方法是用objdump看二进制依赖了哪些GLIBC版本objdump -T /opt/xxx/xxx | grep GLIBC看到GLIBC_2.29就说明目标机的glibc麒麟V10一般是2.28不满足要求。解决办法是换用更老的构建版本或者干脆用源码在目标机上重新编译。如果必须用新版本就只能评估升级系统glibc的风险——这个动作在信创现场一般不建议做风险太大。所以我在影子环境准备介质时现在都会给每件工具记录一个“glibc需求版本”对照目标机的glibc版本核对。这个检查项我已经写进了交付前的前置检查清单。OpenSSL也有类似问题。有些安全工具和Python扩展在编译时链接了OpenSSL 3.x但麒麟V10默认是OpenSSL 1.1.1。即使能装上运行时报的也是version OPENSSL_3.0.0 not found这种诡异错误。遇到这种问题优先找目标系统软件源里已有的版本不要随便从网上拉新版本。6.2 ARM64架构下原生库缺失的典型症状我们第一次启动某个微服务时日志里直接报了一个原生库加载错误java.lang.UnsatisfiedLinkError: no snappy-jni-aarch64 in java.library.path这个报错信息非常直白应用在加载s snappy压缩库时没有找到aarch64版本的JNI库。如果你用的是x86环境这里会加载snappy-jni-x86_64但ARM64平台上需要单独带aarch64版本的依赖。排查方法把JAR包解压开看里面的.so文件unzip -l dataai-model-service.jar | grep -E \.so|\.dll|\.dylib jar tf dataai-model-service.jar | grep -iE native|jni|natives如果发现只有x86_64的.so就需要去Maven仓库找对应的aarch64版本替换后重新打包。JNA库的兼容性也要检查如果应用用了JNA需要把平台相关的jnidispatch.so换成aarch64版本或者在启动参数里加-Djna.nosystrue让JNA走纯Java实现但性能会有一定损耗。这个坑的难点在于它不会在安装阶段暴露而是在应用运行初期才报错而且报错信息五花八门。有的报UnsatisfiedLinkError有的报ExceptionInInitializerError还有的干脆是NoClassDefFoundError。所以我的经验是在影子环境做预演时要把每一个微服务的启动日志都过一遍专门搜索UnsatisfiedLinkError、ClassNotFoundException、ExceptionInInitializerError这三个关键词全部确认没有才做介质。6.3 离线环境的DNS超时与字体问题两个看起来很不起眼但对体验影响极大的问题。第一个是DNS超时。离线环境没有外网的DNS服务器但应用配置里还残留了一些公网域名比如某个开源组件默认连接NTP服务器或者应用配置了外网回调地址。每次请求这些域名时系统先尝试DNS解析等超时之后才返回失败这一等就是5到30秒。现象就是接口偶尔特别慢过一会儿又好了极难排查。我的排查思路是抓应用日志看是不是卡在InetAddress解析上。确认是DNS问题后处理方式有两个一是把涉及的外网域名在/etc/hosts里直接写死指向本地回环地址二是确认应用代码里有没有外网地址配置统统改成内网地址。最简单的排查命令strace -f -e tracenetwork -p pid 21 | grep -E connect|DNS第二个问题是中文字体缺失。离线环境为了精简通常会砍掉中文字体包而应用生成报表或导出PDF时如果调用了系统字体渲染中文就会显示成方块。这个在功能测试阶段很容易漏掉因为界面上大多数是数字和英文。直到我们导出第一张中文报表才发现所有中文都变成了“□□□”。解决办法是提前把中文字体包放进介质。在影子环境执行yum install -y fonts-noto-cjk wqy-microhei然后把/usr/share/fonts目录一起打包到目标机解压覆盖最后fc-cache -fv提醒一点字体包在很多人眼里不是“软件依赖”所以离线介质准备时特别容易被漏掉。我建议把字体、时区数据、CA证书这些“隐形依赖”也纳入台账管理。6.4 部署脚本的幂等性别让现场跑两遍就翻车最后一个坑来自我们自己部署脚本不幂等。某个初始化脚本在全新环境跑一遍没问题但现场工程师不小心执行了两次就报错——用户已存在、目录已存在、SQL插入了重复数据。离线交付场景下脚本能不能重复执行决定了现场运维的体验。我在这次项目里把脚本全部改成了幂等写法# 幂等创建用户 id dataai /dev/null || useradd -m -d /home/dataai dataai # 幂等创建目录 mkdir -p /opt/dataai/{bin,conf,lib,logs} # 幂等初始化数据库SQL里先判断表是否存在 CREATE TABLE IF NOT EXISTS t_user (...);还有一点初始化SQL里的数据插入能加唯一约束的就加唯一约束或者用INSERT ... ON DUPLICATE KEY UPDATE。否则重复执行脚本会导致测试数据翻倍正式数据重复后面排查起来很痛苦。写完脚本后我会在影子环境里把脚本连续执行三遍确认第三遍和第一遍的结果一致才交付。这个习惯我保持到现在因为它真的能拯救现场工程师的头发。最后再说一点个人体会。信创环境离线部署技术栈本身并不神秘难的是“闭环”两个字。在线环境下遇到问题可以随时安装、更新、搜索、绕路离线环境下每一样东西都要提前想到、提前准备想不周全就得现场加班。做完这次项目之后我养成了一个习惯每次交付都附一张“环境预检清单”让客户在部署前先跑一遍确认系统版本、架构、磁盘空间、glibc版本、中文字体、时区这些前置条件全都正常再动安装。算下来这张清单能省掉现场至少一半的排查时间。这大概是这次踩坑换来的最大收获。
