安全人跨界搞 tech：3个月跑通盈利模型

　　去年清明节那晚，我蹲在机房改安全策略，开发突然推了个需求过来——说他们搭的监控平台要加用户画像模块，让我帮忙搞搞数据采集。我原以为顶多搭个Kafka集群，结果他们连存储方案都没定，开发拍着胸脯说“你先跑起来，盈利模型我们三个月就能跑通”。我当时就乐了，安全人搞tech？行啊，反正监控告警我熟，大不了当练手。

　　第一周挺顺利，三台机器跑着ES，开发说“数据量小，先凑合”。我盯着屏幕，看着日志量从每秒几百条涨到几千条，心里直犯嘀咕——这要是存半年，磁盘不得爆？开发倒淡定：“盈利模型跑通前，数据留一个月就够了。”我信了，结果第三周凌晨三点半，告警响了——磁盘空间只剩5%。我爬起来一看，好家伙，ES索引没设TTL，开发之前写的脚本也没跑，数据全堆在/data目录下，好几台机器的磁盘都红了。

文章配图，仅供参考

　　第二天开发来了，我举着手机里的监控截图问：“你们说的‘先凑合’是这么凑合的？”他挠挠头：“盈利模型跑通前，数据量不会这么大。”我火了：“盈利模型跑通前，机器先炸了怎么办？”他沉默两秒，说：“要不我们加个备份？”我差点把键盘砸他脸上——备份？现在才想起来备份？我原以为开发至少会考虑数据持久化，结果他们连最基本的存储策略都没定，全靠“跑通盈利模型”的口头承诺撑着。

　　但骂归骂，活还得干。我拉着开发重新规划存储：ES索引设TTL，每天自动清理；重要数据走S3备份，每小时同步一次；监控告警加磁盘空间阈值，低于20%就发钉钉。开发一边改代码一边嘟囔：“这比写业务逻辑麻烦多了。”我怼他：“你们要是早考虑这些，我至于半夜爬起来删数据？”他没接话，低头敲键盘的声音挺响。

　　其实那段时间我挺矛盾的——安全人搞tech，到底是跨界还是越界？我熟悉的是防火墙规则、漏洞扫描、日志审计，可现在要管存储策略、数据清洗、备份恢复，这些活开发觉得“麻烦”，运维觉得“不该安全管”，可出了问题，第一个背锅的还是我。有天晚上值班，同事递了包泡面：“你最近咋跟开发杠上了？”我撕开包装：“不是杠，是怕他们把锅甩给我。”他笑：“安全人搞tech，图啥？”我嗦了口面：“图个‘优胜劣汰’——要是连存储都管不好，这盈利模型跑通了，我也得被淘汰。”

　　后来盈利模型真跑通了，第三个月月流水破了百万。开发请我吃饭，举着酒杯说：“多亏你盯着存储，不然数据丢了，我们连哭的地方都没有。”我喝了口啤酒，心想：这哪是多亏我？是你们之前太自信，觉得“先凑合”能撑到盈利。其实安全人搞tech，最大的优势不是技术多强，是知道“凑合”的代价有多大——漏洞可以补，数据丢了可补不回来，机器炸了能换，口碑砸了可换不了。

　　现在回头看，那三个月挺值的。我学会了怎么跟开发“吵架”——不是争对错，是争谁该为数据负责；也明白了“优胜劣汰”不是口号，是每天盯着磁盘空间、告警阈值、备份日志的琐碎。有天晚上加班，窗外天快亮了，我盯着监控面板，突然想起清明节那晚的告警——要是当时没删错索引，现在会不会还在改安全策略？

　　其实这事本来能避免——开发要是早定存储方案，我要是早点查索引名，哪用得着半夜爬起来删数据？可现在说这些没用，盈利模型跑通了，数据没丢，机器没炸，就够了。下一步我打算补个存储策略文档，把TTL、备份、清理的规则写死，省得下次开发又“先凑合”。

（编辑：站长网）

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