你的企业Wi-Fi可能正在慢性自杀——每天5MB的日志垃圾悄悄填满存储，直到某天连系统更新都装不进去。这不是黑客攻击，是思科自己的代码在搞事情。
230多款设备集体"便秘"
思科本周紧急发布安全公告，承认超过230款无线接入点（无线接入点）存在存储空间耗尽风险。这些设备运行特定的思科网络操作系统版本：17.12.4、17.12.5、17.12.6和17.12.6a。
问题核心是一个名为cnssdaemon.log的日志文件。系统每天自动生成5MB数据写入该文件，且无法通过命令行删除。
思科原话很直接：「接入点运行受影响软件的时间越长，因磁盘空间不足导致软件下载失败的概率就越高。」
更棘手的是修复路径本身被堵死——想升级系统清掉垃圾？抱歉，垃圾已经占满空间，新系统镜像根本放不下。
17.12版本线的"遗产"
把时间线拉回这几个版本号的发布周期。17.12.x属于思科网络操作系统的长期维护分支，企业级网络设备通常追求稳定而非追新，大量生产环境仍停留在此版本线。
日志文件膨胀的根源是某次库更新引入了cnssdaemon服务的调试日志，但开发团队显然没做存储配额管理。5MB/天的增速在闪存容量紧张的嵌入式设备上堪称灾难——按常见128MB配置计算，26天即可写满。
思科的修复建议呈现典型的企业级产品困境：理想方案是升级到无此缺陷的版本，但现实是设备可能已陷入"空间不足→无法升级→继续膨胀"的死锁。
公告因此附带了完整的检测流程和应急操作手册，包括如何通过命令行确认当前版本、如何评估剩余空间、以及在极端情况下如何避免启动循环（启动循环）。
企业IT的隐形债务
这个案例戳中了B端基础设施的一个长期痛点：设备资产管理。
思科在公告末尾半开玩笑地写道：「我们确信所有运行思科Wi-Fi设备的读者都拥有准确且最近更新的接入点清单，能够迅速识别和修复需要关注的硬件。」
紧接着补刀：「那些手头没有这些信息的人，无疑是从邋遢的前任那里继承了一堆烂摊子，现在有机会成为收拾残局的英雄。」
这话刻薄但真实。企业网络设备的版本碎片化、配置漂移、文档缺失是行业常态。很多IT团队对"能跑就别动"的设备采取鸵鸟策略，直到某天补丁安装失败才被迫面对技术债。
5MB/天的日志本身不是致命设计，致命的是缺乏监控、缺乏清理机制、缺乏升级路径的容错设计——这三重缺失叠加，把一个可管理的问题变成了生产事故。
另一个倒计时
思科在同一份公告里还埋了另一个提醒：微软即将关闭Exchange Web Services（Exchange网络服务），可能导致语音邮件同步功能异常。
两件事并置很有意思。一边是操作系统层面的自我污染，一边是外部依赖服务的生命周期终结。企业基础设施的脆弱性从来不止于单一组件，而是版本矩阵、供应商生态、运维实践的多重耦合。
对于正在维护思科无线接入点的工程师，现在需要做的很具体：导出设备清单，过滤17.12.4-17.12.6a版本，检查闪存使用率，按思科提供的流程分批处理。没有清单的，先花两天把资产盘点做出来——这本身就是技术债务的利息。
这件事的启示或许在于：当我们谈论"稳定的企业级软件"时，到底在谈论什么？是版本号冻结带来的表面平静，还是可观测、可维护、可演进的真正韧性？思科的日志炸弹提醒我们，有时候稳定只是问题被藏得更深而已。
你的网络设备上次完整资产盘点是什么时候？如果答案需要想超过三秒，可能该找个周末当一回"收拾残局的英雄"了。
热门跟贴