云安全运营中心：模块化设计精准适配业务演进

　　去年二月那会儿，运维组老张蹲在机房角落里抽烟，烟灰缸堆得像小山——他刚被云安全中心的模块化设计坑了一波。说是模块化能精准适配业务演进，结果业务刚要变道，模块直接卡死了。“优胜劣汰？”他吐了口烟，“优的模块倒是能活，劣的模块死得透透的，可业务它不按优劣走啊！”

　　那天下午三点，我盯着监控屏上的告警列表，发现威胁检测模块突然不报了。点开日志一看，好家伙，它和流量分析模块的API版本不兼容——流量分析模块上周刚升级，威胁检测模块还停留在半年前的版本。运维组小李在工位上接了个电话，声音大得全组都能听见：“什么？要回滚流量分析模块？那业务那边刚上线的功能又得停！”显示器右下角的时间跳到15:27，窗外的雨开始砸玻璃，冷风机嗡嗡响，像在给这场混乱打拍子。

　　我原以为模块化设计最大的问题是依赖管理，结果发现更坑的是“精准适配”这四个字。业务演进哪有什么精准？上周还说要做AI风控，这周就改大数据分析，下周又说要上零信任架构。模块化设计倒是能拆能合，可拆的时候得改配置，合的时候得调接口，改着改着就发现，某些模块的代码里硬编码了业务ID——比如用户画像模块，当初为了快速上线，直接把业务线ID写死在SQL里，现在业务线要拆分，这模块直接报废。

　　老张后来跟我说了个更绝的例子。他们有个日志审计模块，设计时号称能“自动适配所有日志格式”，结果业务部门用了种非标准的JSON格式，模块解析失败，直接把日志丢进了黑洞。更搞笑的是，这模块的开发者早就离职了，文档里只写了“支持标准JSON”，没写“不支持非标准JSON”。运维组花了三天时间反编译代码，才在某个if语句里找到硬编码的字段名——那字段名还是前开发者用自己名字拼音缩写命名的。

文章配图，仅供参考

　　那天晚上八点多，运维组的灯还亮着。小李盯着构建工具的进度条，卡在87%不动了——是那个日志审计模块在编译。他转头跟我说：“这模块要是再编译不过，我就把它从模块库里删了，反正也没人用。”我笑了笑，没接话。桌上的外卖早就凉了，塑料盒上凝了层水珠，像极了那些被模块化设计“精准适配”掉的需求——刚开始还热乎，过会儿就没人理了。

　　其实模块化设计最坑的，是它让“优胜劣汰”变成了一种自我实现的预言。好的模块因为用的人多，迭代快，越来越好；差的模块因为用的人少，没人维护，越来越差。最后模块库里就剩两种模块：一种是万金油，什么都能干但什么都干不好；另一种是专精怪，特定场景下无敌，但换个场景就废。业务部门来要模块的时候，安全组只能摊手：“没有完全匹配的，您凑合用个差不多的吧。”

　　上周和同行吃饭，聊到这个话题。他说他们公司也用模块化设计，但加了个“模块健康度”评分系统——用的人多、迭代快、问题少的模块得分高，反之得分低。得分低的模块会被标记为“僵尸模块”，定期清理。我听了直摇头：“这不就是把优胜劣汰机制化了？可业务它不认这个分啊！”他叹了口气：“所以现在我们在考虑，要不要让业务部门参与模块评分——他们说好用的，才算真好用。”

　　现在回想起来，老张那句话其实没说全。模块化设计确实能精准适配业务演进，但前提是业务得按模块化设计的规则演进。可现实是，业务演进从来没什么规则——它像条野狗，想到哪儿跑哪儿，模块化设计再精准，也追不上它的脚步。至于“优胜劣汰”？那不过是模块化设计给自己贴的金，真到了业务变天的时候，该淘汰的从来不是模块，是那些坚信模块能解决一切问题的人。

　　下午开会的时候，安全总监又提了次“模块化设计精准适配业务演进”。我低头记笔记，没吭声。窗外的雨停了，冷风机还在响，显示器右下角的时间跳到14:15。小李在工位上敲键盘，声音清脆，像在给这场会议打节拍。我知道，等会儿散会后，他又要开始改那个日志审计模块的配置文件了——这次业务部门又调了日志格式，说是为了“更好的数据分析”。

　　至于模块化设计到底能不能精准适配业务演进？我说不准。但我知道，明天早上来上班的时候，模块库里肯定又会多几个“僵尸模块”——它们曾经“精准适配”过某些业务场景，但现在，那些场景早就变了。

（编辑：站长网）

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