摸过生产集群才懂容器化的真实成本

上周去南京软件大道的一家客户机房，跟运维团队蹲到后半夜，烟灰缸堆得冒尖，几个人骂得最凶的，不是开发甩锅的烂事，是两年前拍板上容器化的那个决策。 没那么玄。 很多人对容器化的印象还停留在Docker刚爆火的阶段，觉得把应用打个标准化包扔上去，就能解决所有环境不一致、部署慢、资源利用率低的破事，真到生产环境跑过几轮才知道，哪有这么顺的事。

最先崩的从来不是应用

刚上容器化的头三个月，整个团队都在补之前欠的监控债。 麻烦在于，之前跑在物理机上的老应用，从来没考虑过会被扔在隔离环境里运行。有的写死了本地磁盘路径，有的硬依赖宿主机的内核参数，还有的应用启动脚本直接写死了要访问同网段的某台缓存服务器，网络策略稍微收紧一点，直接就趴窝。有次一个跑了五年的报表应用，每次容器重启就丢历史数据，查了半天才发现，开发当初把临时文件存在了容器的可写层里，容器一删，啥都没剩下。 一开始大家总觉得，这些问题改改就完了，真改起来才发现，老应用的源码有的都找不到原作者了，只能硬着头皮读二进制文件找依赖，前后耗了快三周，才把最核心的三个应用适配完。

现在想起来都头疼。 之前大家总觉得容器化上了之后，运维的活会变少，结果头半年的工作量是之前的三倍——要给每个应用做资源配额，要调网络策略，要给每个容器加日志采集，要排查各种之前根本没见过的网络丢包问题，天天加班到十点多，比之前管物理机的时候累多了。

算下来的账从来不是表面那点

很多人算容器化的账，只会盯着硬件成本算——之前物理机利用率只有15%，上了容器之后能冲到60%，算下来一年能省几百万的服务器采购钱，怎么算都划算。 但没人算人力成本。 之前三个运维就能管完的200台物理机，上了容器之后，得配两个专门懂K8s网络的专家，一个管镜像仓库安全的，还有两个天天排障的一线运维，光这几个人的年薪资成本，就把省下来的服务器钱吃掉大半。 上次跟一个做电商的技术负责人聊，他说当初拍板上容器化，本来想着能把部署效率提上来，结果光给容器平台做权限隔离、镜像漏洞扫描、日志归集的通用组件，就花了整整半年。这半年里业务部门要上线个新功能，还得找平台团队走审批开权限，比之前直接找运维要台物理机还慢。

说白了，容器化本质上是把之前散在各个业务团队里的运维工作，集中到了平台团队手里。你省下来的资源浪费钱，本质是把之前业务团队各自为战的成本，换成了平台团队的建设投入。 没白捡的便宜。

到最后要扛的从来不是技术问题

很多人对容器化的预期从一开始就错了。 总觉得这是个纯技术项目，只要把平台搭起来，把应用迁上去，就算大功告成，真跑起来才发现，最大的阻力根本不是技术适配，是各个团队的协作惯性。 有的业务团队觉得，我之前自己管应用管的好好的，为什么要把应用扔到你的容器平台上，出了问题找你还是找我？有的团队怕自己的核心应用被平台团队盯着，一点代码改动都要走平台的审核流程，干脆就找各种理由拖着不迁，到最后整个集群里跑的全是不重要的边缘应用，核心业务还在物理机上待着，当初采购的服务器、搭的平台，一半的资源都空着。 容器化从来不是一个一劳永逸的技术工具，更像是一套倒逼整个研发流程对齐的管理工具。你要是指望靠搭个容器平台，就能解决所有研发流程混乱、运维效率低的问题，那最后大概率要失望。毕竟工具永远是死的，人要是没对齐，再好的工具也跑不起来。 不过话说回来，容器化也不是什么洪水猛兽。真要是业务规模到了几百个应用、几百台服务器的量级，靠之前那种人工部署、人工排障的方式，迟早要被运维成本压垮，这时候容器化带来的标准化能力，确实能帮你把整个系统的可维护性提上一个台阶。 但别神化它。 别听那些厂商销售吹，说上了容器化就能实现全流程自动化，就能零停机发布，就能把资源利用率拉到天花板，真到了生产环境，你要面对的是千奇百怪的老应用，是各个部门扯不清的权责，是半夜三点突然跳出来的节点故障，这些问题，没有哪个容器平台能帮你一键解决。 这事没捷径。 之前跟一个在南京做了十年运维的老大哥聊，他说现在很多团队上容器化，就像当年大家一窝蜂上微服务一样，听着高级，用着难受，最后能不能拿到实际的收益，根本不是技术的问题，是你有没有想清楚，自己到底要不要扛这部分成本。