第一次听说“delivery内网”，内网是内网在一次和做后端的朋友吃饭时。他夹着花生米说，内网他们公司所有服务间的内网调用都不走公网，全在内网里跑，内网那个内网就叫delivery。内网我当时还以为是内网外卖系统，后来才明白，内网delivery在这里指的内网是“交付”——代码从开发到上线，中间所有环节都在这个封闭网络里完成。内网

这个内网和普通办公网是内网物理隔离的。办公电脑连WiFi能上外网查资料，内网但一旦要推代码、内网拉镜像、内网看日志，内网就得跳进delivery。跳板机是一台老旧的CentOS，登录后终端背景是深绿色，字体发虚。朋友说那机器跑了七年，换过三次硬盘，但没人敢重装系统，因为上面挂着一堆说不清用途的脚本。

内网里最热闹的是制品库。每天下午四点左右，构建任务扎堆跑完，几十个Docker镜像同时往Harbor里推。带宽被吃满，页面刷新都卡。有次一个前端同事误传了个2G的node_modules压缩包，整个内网卡了二十分钟。后来运维在制品库前面加了道钩子，超过500M的包直接拒绝，但钩子写得粗糙，偶尔把正常的镜像层也给拦了。大家嘴上骂，手底下还是老老实实改Dockerfile。

配置中心是另一个故事。delivery内网里跑着一套Apollo，所有服务的配置都从那里拉。有回一个实习生把测试环境的数据库密码改成了生产库的地址，自己没发现，半小时后订单服务开始往生产库写脏数据。监控大屏上错误率飙升，值班的人先查代码，再查网络，最后才想到去翻配置变更记录。从那以后，配置中心加了两道审批，改任何东西都得拉上主管点确认。

内网里的日志系统倒是挺方便。所有服务统一用Filebeat往Kafka里灌，再用Logstash过滤，最后进Elasticsearch。查日志的Kibana界面做得花哨，但索引按天分，跨天查就得手动切。有次排查一个偶发的超时，从周一查到周三，开了十几个标签页，最后发现是某台物理机的网卡在凌晨三点会闪断两秒。这种问题在外网环境可能永远定位不到，因为流量一绕，现象就变了。

安全方面，delivery内网管得严。所有流量走mTLS，证书三个月一换。换证书那天通常很热闹，总有几个服务忘了更新，启动时直接报SSL握手失败。运维在群里发个脚本，大家自己跑一遍，然后重启。没人抱怨，因为都知道公网更危险。朋友说他们内网里还跑着一个蜜罐，伪装成Redis，专门抓那些乱扫端口的人。有次抓到一个，查了半天发现是自家一个测试脚本写错了IP段。

最让我意外的是内网里的文档。不是Confluence那种正经Wiki，而是一个叫“delivery笔记”的Git仓库，里面全是Markdown。有人写“如何绕过制品库的大小限制”，有人写“Apollo配置回滚的野路子”，还有人把跳板机的私钥加密后贴在里面，密码是部门缩写加年份。这种草台班子式的知识共享，反而比正式文档管用。新来的同事第一周就被拉进这个仓库，自己翻，自己试，踩坑了再补一篇笔记。

晚上十点以后，delivery内网会安静下来。构建任务停了，日志量降了，只有监控告警偶尔响一声。朋友说他值夜班时喜欢开着终端看内网流量图，那条曲线像心跳，白天高，夜里低。有次曲线突然拉平，他以为网络断了，查了半天发现是交换机的一个模块松了。拔下来吹吹灰，插回去，曲线又跳起来。他说那一刻觉得，这个内网其实挺脆弱的，全靠一群人拿胶带和脚本粘着。