小程序工程师避而不谈的5大技术困境

　　去年四月那会儿，我原以为小程序工程师天天就改改UI、调调接口，结果被拉去联调的时候才发现——他们连日志都打不利索。那天晚上十点，监控突然狂闪，告警灯红得跟过年似的，我一看，小程序后端服务挂了，负载直接飚到99%，磁盘inode全满，连swap都占了一半。开发那边说“不可能啊，我们刚发了新版本”，结果我登上去一看，好家伙，日志文件把/var目录撑爆了——他们居然没做日志轮转，直接往根目录狂吐，吐了三个G的debug日志，连启动脚本里的echo都算进去了。

　　这事儿后来越聊越离谱。我跟他们说“你们得限制日志量，或者切到日志服务”，结果开发小哥挠头：“日志服务要钱啊，老板不让用。”我差点没把键盘摔了——合着你们为了省云厂商那点存储费，直接让服务崩了？更绝的是，他们居然用本地文件存日志，还开了debug模式，说是“方便排查问题”。可问题来了：服务都挂了，你拿什么查日志？跳板机密码又过期了，我蹲在机房改密码的时候，冷风机在旁边嗡嗡响，外卖袋子上的水汽把桌角都弄湿了，开发还在群里问“能不能先重启服务？”——重启个鬼啊，磁盘都满了，重启也起不来！

　　后来复盘的时候，我发现这帮人避而不谈的困境，全是些“说出来显得不专业”的破事儿。比如第一个困境：日志量爆炸。他们为了“方便调试”，把所有级别的日志都开着，连用户点击按钮这种破事儿都记，结果一个版本下来，日志文件比代码包还大。我原以为他们不知道日志分级，结果一问，人家说“分级太麻烦，反正本地存着也不占空间”——结果空间真不够了，服务就崩了。这哪是技术问题？这是认知问题啊！

　　第二个困境更搞笑：监控盲区。他们只监控了服务是否存活，根本没监控磁盘、inode、负载这些关键指标。我问“你们不看磁盘使用率吗？”，开发说“看啊，但一般用df命令手动查”——大哥，服务都挂了，你手动查个鬼啊！后来我给他们上了Prometheus，结果他们嫌配置麻烦，直接关了告警，说“太吵了，影响写代码”。结果那周我值班，告警灯闪了一夜，我爬起来一看，全是“磁盘使用率超过90%”的告警，开发那边连个回音都没有——人家早睡着了，根本不看工单。

文章配图，仅供参考

　　说到老板，这第四个困境跟成本强相关。他们为了省钱，连日志服务都不肯用，非要自己搭ELK，结果搭了个半吊子，索引分片乱成一锅粥，查询日志要等五分钟。我跟他们说“你们这ELK配置有问题”，开发说“我们知道，但改起来太麻烦，反正现在也能用”——能用个鬼啊，用户反馈问题，你们查个日志要半小时，用户早跑光了！更绝的是，他们为了省云厂商的带宽费，把日志回源到本地，结果本地网络抖了一下，日志全丢了，用户报的bug根本查不到记录。我问“你们没做多副本吗？”，开发说“多副本要加机器，老板不让”——行吧，你们赢了，省钱第一，服务第二。

　　第五个困境，我原以为是最技术性的，结果发现是最“人性”的：开发跟运维的信任危机。他们总觉得运维在“找茬”，比如我让他们限制日志量，他们觉得“运维就是不想让我们打日志，方便自己偷懒”；我让他们上监控，他们觉得“运维就是想多卖云服务，赚回扣”；我让他们做灰度，他们觉得“运维就是不想让我们快速迭代，拖慢进度”。结果呢？服务崩了，用户骂了，老板急了，最后还是运维背锅——我值班那晚，老板在群里@我：“为什么服务又挂了？”，我回“因为日志撑爆磁盘了”，老板转手就@开发：“你们怎么打的日志？”，开发回“我们按需求打的，运维没限制”——得，锅又甩回来了。

　　后来我琢磨明白了，这些困境之所以“避而不谈”，是因为它们涉及的不是技术，而是利益。开发想快速迭代，运维想稳定运行，老板想省钱赚钱，云厂商想卖服务——大家目标不一致，自然矛盾重重。但优胜劣汰的道理在这儿也适用：那些不重视日志、监控、回滚、成本、信任的小程序团队，迟早会被用户抛弃，被市场淘汰。而那些愿意花时间解决这些“脏活累活”的团队，才能活得更久。

　　不过话说回来，我睡不好那阵子，天天担心服务崩了，现在想想，可能也是因为太较真了。毕竟，有些问题，不是靠运维能解决的——比如老板的决策，开发的认知，云厂商的套路。我现在值班的时候，偶尔也会想：要是哪天我不干了，这些小程序团队，能自己扛住这些困境吗？可能吧，但大概率，他们会继续避而不谈，直到某天，服务真的崩了，用户真的跑了，老板真的急了——到那时，他们才会明白，运维说的那些“废话”，其实都是保命的真话。

（编辑：草根网）

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