平台创业：重构资源流动的容器化毛细血管

　　凌晨三点半，告警炸了。三台机器的磁盘水位同时飙到98%，我原以为又是监控脚本抽风，结果登录进去一看——好家伙，开发新推的容器镜像把日志路径写死了，直接往根目录灌。更绝的是，他们用的还是debug模式，日志量是平时的二十倍。我边删日志边骂街，开发小李电话打进来，第一句是“我们测试环境没问题啊”，第二句是“你们运维是不是该做下磁盘监控的自动扩容？”

　　其实这事儿要搁半年前，我肯定得跟他吵一架。可现在？我盯着屏幕上还在疯狂滚动的日志，突然想起上周老板在会上说的那句“平台创业要重构资源流动的毛细血管”。当时我还觉得这词儿玄乎，现在倒有点品出味儿了——容器化不就是把资源拆成最小的单元，让它们像血液里的红细胞似的，哪儿需要往哪儿跑吗？可问题是，红细胞多了会堵血管啊！

　　我原以为资源流动是靠调度算法自动优化的，结果这半年踩的坑告诉我：优胜劣汰才是硬道理。上周我们刚把一批老旧的物理机淘汰了，换成了更小的容器节点。本来想着能提高资源利用率，结果发现有些服务根本不适合容器化——比如那个写死日志路径的破服务，在物理机上跑的时候，磁盘空间不够了至少会报错，现在倒好，直接把整个节点撑爆，连带着旁边的几个容器一起挂。

　　机房的空调吹得我脖子发凉，我裹紧了外套，继续删日志。小李的电话还没挂，我能听见他那头键盘敲得噼里啪啦响。“你们能不能先停一下服务？”我试着商量。“停不了啊，”他说，“现在正是用户高峰期，停一秒损失好几万。”我盯着屏幕上已经删到85%的磁盘水位，突然有点羡慕那些能直接拔电源的同行——至少他们不用面对这种“删日志还是停服务”的二选一。

　　其实类似的坑我们踩过不少。上个月有个开发非要把数据库跑在容器里，说这样“弹性伸缩更方便”。结果测试的时候发现，容器重启后数据全丢了——他忘了挂载持久化存储。更搞笑的是，他居然把责任推给我们，说“你们运维没提醒我”。我当时就火了：“提醒？我提醒过你八百次了！是你自己说‘不用那么麻烦，测试环境而已’！”

　　但说到底，这些坑也让我们更清楚容器化的边界在哪儿。就像上周淘汰物理机的时候，我们特意留了两台作为“特殊服务专用机”——那些不适合容器化的、对资源要求奇奇怪怪的服务，全扔到这两台机器上跑。虽然看起来有点“倒退”，但至少不用再半夜爬起来删日志了。

　　磁盘水位终于降到70%了，我松了口气，准备去泡碗面。窗外天快亮了，机房的灯还是那么刺眼。小李在电话那头还在唠叨：“你们运维得想想办法啊，不能每次都靠人工干预……”我打断他：“办法我们一直在想，但你们开发也得配合啊。比如那个日志路径，能不能别写死？或者至少加个轮转？”他沉默了两秒，说：“行，我改。”

文章配图，仅供参考

　　泡面还没泡好，新的告警又来了。这次是证书过期，好几个服务的HTTPS访问都挂了。我叹了口气，放下泡面，开始处理。小李的电话又打进来，这次他没说话，只听见键盘敲得更快了。我笑了笑，心想：这大概就是平台创业的日常吧——一边踩坑，一边填坑，一边骂街，一边成长。

　　证书更新完的时候，天已经大亮了。我吃了口已经凉透的泡面，突然想起老板上周说的另一句话：“容器化不是终点，而是起点。”当时我没懂，现在好像有点明白了——容器化只是把资源拆成了更小的单元，但要让这些单元真正流动起来，还得靠我们不断优化、不断淘汰、不断适应。就像人体的毛细血管，得不断新陈代谢，才能保持健康。

　　下一步该补什么呢？我想，得把那些不适合容器化的服务列个清单，再跟开发们开个会，明确一下容器化的边界。还有，得做个自动化的磁盘监控和清理脚本，别再让我半夜爬起来删日志了——虽然我知道，这可能只是暂时的解决方案，但至少能让我睡个好觉。

　　其实这事儿本来能避免的。如果开发能多听听运维的建议，如果测试环境能更接近生产环境，如果我们能早点淘汰那些老旧的服务……但说这些都没用了，坑已经踩了，只能往前看。就像我常跟新来的同事说的：“在运维这行，踩坑不可怕，可怕的是踩了同样的坑还不长记性。”

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!