上周跟个干了快十年运维的老周在大排档撸串，他攥着冰啤酒的手都在抖。
说去年公司KPI压下来要求全量上容器化，半年砸了小两百万搭平台，现在比之前物理机时代的故障数还多三成。
他说这话的时候，烤串的烟飘得他眼睛都红了。
最先要拆穿的迷思
很多人对容器化的第一印象，是分布式架构的万能钥匙。能一键扩容，能省服务器成本，能让开发部署再也不用求运维开权限。
说白了，这事没那么玄。
容器本质上就是个带了资源隔离能力的轻量进程，跟你早年在Linux上用chroot搞的沙盒，内核上是一脉相承的，根本不是什么天外来物。
你把应用打包成镜像扔上去，确实能解决之前“我本地能跑”的环境不一致问题，但这不等于你整套技术栈的架构问题就自动消失了。比如你写的服务本身内存泄漏，之前跑在物理机上是三五天崩一次，现在跑在容器里，调度器检测到资源打满，直接给你重启换个新容器，看起来故障恢复快了，实则根源的bug根本没修。
之前碰到过一个团队，为了凑容器化的迁移率，把连数据库的连接串都硬编码进镜像里，后来改个数据库地址要重新打包几百个镜像，折腾了快一周。
迁移时最容易漏算的成本
很多人算容器化的账，只算买服务器、搭平台的显性成本，根本没算隐性的。
比如你团队之前的运维流程，是按物理机+虚拟机的逻辑搭的，现在切到容器平台，你得重新搞监控告警的规则，得写镜像的构建流水线，得给开发团队做培训。别觉得这是小事，我见过太多开发同学，之前部署应用就是scp个jar包上去，现在让他写Dockerfile，连基础的镜像分层都搞不清楚，把整个项目的源码全扔到镜像层里，最后打出来的镜像有好几个G，拉一次要十分钟，节点扩容的时候直接卡成狗。
还有个更麻烦的点，就是有状态服务的迁移。
很多人一开始上容器，全是无状态的web服务、接口服务，顺得很，转头就想把数据库、消息队列也全塞进去，结果呢？容器天生是给易失的无状态服务设计的，你要跑有状态的东西，就得额外搞持久化存储、网络策略、备份容灾，这些东西的复杂度，比你之前单独跑数据库高好几个量级。
之前老周他们就是把一套订单库直接迁到容器集群里，赶上大促的时候存储插件出了bug，整整两个小时找不到数据在哪，最后差点把CTO的头发都薅没了。
真正能拿到收益的切法
别上来就搞全量迁移，真的。
我见过最稳的团队，是先花了三个月时间，把所有线上服务的资源使用率、故障记录、依赖关系全摸了一遍，先挑那些环境差异大、部署频率高、无状态的边缘服务迁上去，比如内部的工单系统、日志查询平台，这些东西就算出点问题，影响也小，团队在练手的过程中慢慢摸透平台的脾气，再慢慢把核心业务往上挪。
还有个很实在的经验，别盲目追新。什么服务网格、Serverless插件，先别急着装。很多人搭完k8s集群，恨不得把社区里所有的开源组件全装一遍，结果平台本身的复杂度上去了，出了问题没人能排障。
容器化的核心价值从来不是搞最复杂的平台，而是把应用从底层的硬件环境里解耦出来，让开发能更专注在业务逻辑上，不是为了搞个大平台给领导汇报用的。
上次跟那个稳扎稳打的团队的技术负责人聊天，他说一开始他们也想赶时髦搞全量，后来算了笔账，要是硬上，整个团队得加班三个月，还得承担核心业务故障的风险，不如慢一点，半年迁完，虽然KPI看着没那么好看，但线上稳得很，团队也不用天天熬夜救火。
哦对，还有个容易被忽略的细节。容器平台的权限模型，一定要提前捋清楚。别让开发同学拿到集群的管理员权限，不然哪天有人不小心删了命名空间里的所有资源，哭都来不及。
昨天老周给我发微信，说他们把之前硬塞进去的数据库全迁回了独立的物理机，现在平台上只跑无状态的业务服务，告警数少了一半，这周终于能准点下班接孩子了。
他说现在终于想明白，当初费那么大劲上容器化，不是为了追什么技术潮流，就是为了让大家少加班，多留点时间干正事。