上周在南京软件大道的产业园沙龙散场，我被个穿洗得发白的格子衫的老运维拽住吐槽。他说去年公司硬推容器化，砸了小二十万的人力成本把核心订单系统迁进K8s，跑了八个月，上个月还是全量拆回了虚机。
不是容器不好用。是从一开始，大家算的账就错了。
没算过的隐性成本
隐性成本从来不是采购合同上写的那笔钱。大部分团队做容器化选型的时候，只会算硬件采购的钱，算虚机和容器的资源利用率差，算下来好像能省30%的硬件成本，觉得这买卖稳赚不赔。可没人算过，原来熟门熟路管虚机的运维团队，要花三个月啃完K8s的网络插件、存储卷挂载、权限体系的文档；没人算过，原来几百兆的应用安装包，换成带完整基础系统的镜像之后，动不动几个G，几百个版本存下来，光私有镜像仓库的对象存储费用，每个月就要多掏小两万；更没人算过，原来虚机出问题登上去敲两行命令就能定位的故障，现在容器飘在不同节点上，日志要从统一采集系统里捞，链路要从全链路追踪平台里翻，上次一个订单超时的小问题，团队查了整整三天，最后发现是某个网络插件的版本兼容bug，跟业务代码半毛钱关系没有。
说实话，这事真的不怪业务部门抵触。我见过太多团队，把容器化的ROI算得太乐观，把所有能省的钱都算进去，把所有要花的成本都藏起来。等真的跑了半年，发现多花的钱比省的钱还多，又开始骂容器化是智商税。
那种一天访问量波动不到10%的内部办公系统，那种一年发两次版本的政务申报平台，你硬要上容器化干嘛？原来虚机跑的好好的，资源利用率才30%，换容器省下来的那点硬件钱，还不够付运维团队每天写YAML配置、调网络规则的时间成本。真的不值。
被神化的”环境一致性”
我刚入行那几年，为了个”本地能跑线上崩”的Java版本问题，熬了两个通宵，当时确实觉得容器是救星。把代码和所有依赖封在镜像里，从开发到测试到生产全用同一个镜像，听起来完美无缺。
环境一致性的前提是所有环节都严格对齐镜像版本。可麻烦在于，镜像从来不是封好就不用动的。基础镜像的高危漏洞要打补丁吧？打了补丁要不要全量回归测试？去年有个做财税系统的团队，为了补Log4j的漏洞，把基础镜像从Debian 11升到12，没测出来某个C语言写的发票生成库不兼容，线上批量开出来的几千张发票全是乱码，停了两个小时才回滚到旧镜像。
还有更离谱的。我见过开发图方便，把本地带调试工具、带默认root密码的镜像直接推到生产，安全团队扫到的时候，整个镜像仓库被封了半天，所有发版流程全停。这种所谓的”环境一致性”，别说帮你省时间，不给你捅娄子就不错了。
之前在杭州的技术峰会上，有个厂商的PPT上写着”所有系统100%容器化是云原生的终极目标”，我当时举手问，你们自己的官网现在是跑在虚机上还是容器上？台上的人愣了三秒，说官网跑了快十年，太稳定了，没必要迁。
你看。吹到天上去的技术，落到自己身上，还是要算实际的账。
什么时候真的该上容器化
别听那些厂商瞎忽悠，这事真的有明确的适用边界。容器化从来不是目的，只是解决特定问题的手段。
我之前采访过一个做直播技术的团队，他们的业务逻辑很简单：每次有主播开播，要临时拉几十个计算节点做视频转码，下播之后立刻把所有节点释放掉。算下来，用原来的虚机模式，每个月的资源成本比容器高60%——毕竟申请虚机要走半天的审批流程，等虚机开好，主播都下播了。这种场景，你就算拦着他们上容器化都拦不住，因为弹性能力带来的收益，是实打实能落到账上的。
反过来，如果你现在的运维团队总共就两个人，一个管数据库一个管基础网络，你让他们去维护一个几百个节点的K8s集群，那不是给自己找罪受。如果你现在的业务迭代频率是一个季度发一次版，每次发版的流程都顺的很，那你费那劲迁容器干嘛？
现在行业里对容器化的态度其实挺分裂的。一拨人把它吹成银弹，什么问题都要往容器里塞；另一拨人被坑过一次，就把容器化骂成花架子。说白了，技术工具从来没有对错，只有适不适合。你拿螺丝刀去砸墙，最后把螺丝刀柄砸断了，不能怪螺丝刀不好。
真的。别着急赶时髦。先算清楚自己要解决什么问题，再决定要不要掏那笔成本。