1. 背景：公司有专门的 k8s 运维，做的我的项目是酒店自助机，根本业务：自助机前端有刷身份证查订单 / 现场预约 / 退房 / 办理入住 / 生成房卡等性能，后端对接不同的酒店零碎以及公安系统，业务办理须要公安和原生酒店零碎都要对接。
2. 问题形容：如家酒店有两套环境，私有化环境和公网环境，公网环境性能少，私有化环境的零碎部署到如家本人的服务器上，公网的后端是部署在阿里云。当然，测试环境也是两套。后果就再一次公布生产（私有化）的时候，对接如家的 java 我的项目启动失败
3. 抽丝剥茧：看报错日志，发现是连贯配置核心连不上，连的是公网的配置核心。也就是说用公网的 docker 镜像部署到了私有化环境（公网用的配置核心是阿里云的 acm, 私有化用的配置核心是 nacos），私有化环境是连不了外网的。运维说是代码问题，可查看了配置也没故障，而后让运维帮忙查，运维始终认为是代码的故障不给查。他还凶我。很受伤。
4. 持续抽丝剥茧：那就本人查。先让如家的开发把生产环境的镜像给发过来，解压进去，找到 jar, 再解压，发现的确用的是公网的 jar（acm 的 jar, 没有 nacos 的 jar），那就要看 devOps 是怎么把私有化的镜像打包成公网镜像的，就去查 jenkins 的打包部署日志。日志里找到了打包生成的镜像 id, 而后问运维这个镜像 id 的逻辑是什么样的，他说是这个镜像 id 是测试和生产环境专用的 id, 也就是部署到生产和测试的镜像是一样的。那就是说，生产的那个镜像 id 是在测试环境部署的时候生成的，而后问他，生产的镜像 id 是怎么来的，他说是最新一次部署的，也就是说，测试测的是哪个镜像，部署就用哪个镜像上生产。而后我就去拿生产环境镜像的 id 去测试 jenkins 的两套环境里的部署日志里找，果然，在公网的环境 jenkins 上找到了这个镜像 id.
5. 起因：找到了“私有化生产环境的镜像 是 公网测试环境所打的镜像包”，且生产环境是用一个我的项目的最新的镜像，问题的起因就浮出水面：原本测试是在私有化的测试环境测的，可过后有些性能是在公网的，测试就部署了公网的测试环境，巧在 正好在这次部署后，就公布了生产（私有化）
6. 解决方案：运维给两套环境生成的镜像 id 减少了环境的前缀 public/private, 用来示意公网还是私有化，部署的时候，取最新一个对应前缀的镜像 id 去部署。