2001年11月
晚上8点，网益科技园 3楼的技术部还亮着灯。
我攥着刚打印的业务分工表，站在老谭的办公桌前——表格上“短信业务”四个字被红笔圈了 twice，旁边写着“q4核心指标：日活用户破 50万”。
老谭叼着没点燃的烟，手指在键盘上敲出一行日志：“今早 9点短信推送高峰，系统又卡了 2分钟，客服那边接了 300多个投诉电话。”
我把分工表摊开，指着“邮件系统维护”那栏：“Rebecca和梁辉刚说，邮件服务器上个月才扩容，应该能扛住日常维护。倒是短信这边，我上午跟运营商对接时，移动的人说他们的网关每秒能处理 800条请求，咱们的系统上次测才到 200条。”
老谭终于点燃烟，吐了个烟圈：“先把业务流理清楚，才能找症结。”
他从抽屉里翻出张白纸，画了三条并行的线——用户、网益 Sp服务器、运营商网关。
“你看，用户在咱们首页点‘订阅体育短信’，输入手机号后，请求先到咱们的 Sp服务器；服务器要查两个东西：一是这个手机号有没有在咱们的用户库里，二是运营商那边有没有欠费；确认没问题后，再把订购请求推给移动或联通的网关；网关返回‘成功’，咱们才能给用户发确认短信，月底再跟运营商结算分成——这整个流程，哪一步慢了都不行。”
我突然想起上周的崩溃事件：“上周六晚上有场国足比赛，赛后 10分钟内，有 3万用户同时订‘赛况短信’，结果 Sp服务器直接宕机了。当时查日志，发现数据库里‘用户订阅表’的查询语句跑了 40秒——原来没给‘手机号’字段加索引。”
“这只是小问题。”
老谭把烟摁灭在烟灰缸里，打开服务器监控界面。
屏幕上的红色曲线刺得人眼疼，“你看高并发时的资源占用：cpU到 90%，但内存才用了 40%；数据库连接池满了，新请求全堵在队列里。咱们的系统架构是年初搭的，当时想着短信业务刚起步，用两台 Ibm xSeries服务器做集群，数据库用 oracle单实例——哪想到才半年，用户量就翻了三倍。”
窗外的夜色更浓了，技术部的同事陆续走光，只剩我和老谭的电脑屏幕亮着。
老谭突然翻出一份竞品分析报告，是市场部上周发的：“移动自己的短信平台，直接接基站，不用走第三方网关，响应速度比咱们快 0.8秒；联通更狠，给省市级分公司开了专属接口，覆盖范围比咱们广 30%。还有信浪，他们把短信跟新闻绑定，用户看头条时一点就能订，上周日活已经破 60万了；搜虎靠娱乐短信，把‘明星八卦’打包成包月服务，用户留存率比咱们高 15%。”
我攥紧了拳头：“那咱们的优势呢？文档里说用户基数和邮箱资源——是不是能从邮箱引流？比如给邮箱用户发提醒：‘绑定手机号，接收登录验证码短信’，先把用户拉进来，再推订阅服务。”
老谭眼睛亮了：“这是个好路子，但前提是系统得扛住。现在咱们要解决两个核心问题：一是请求处理瓶颈，二是数据库压力。”
他打开 Excel，列了三个方案：“第一，加两台 Sp服务器，做轮询负载均衡——用户请求进来，轮流分配到四台服务器，避免单台过载；第二，给数据库做读写分离，查询请求走从库，写入请求走主库，再给‘用户订阅表’加联合索引；第三，在 Sp服务器和数据库之间加一层缓存，把常用的‘用户状态’‘订阅套餐’存在内存里，不用每次都查数据库。”
“这些方案要多久落地？”
我盯着 Excel里的“预估耗时”，老谭写的是“3天”。
“明天先跟采购部申请服务器，同时让梁辉帮忙优化数据库索引；后天部署负载均衡器，我来写缓存逻辑——用本地缓存就行，现在还没必要上复杂的分布式缓存。”
老谭突然笑了，“你还记得去年做邮件系统时，咱们也是这么加班赶工的？当时邮件并发上不去，最后是靠分批次发送才解决的。”
第三天晚上，我们用模拟工具测了 10万次并发请求——之前会崩溃的系统，这次响应时间稳定在 0.5秒，数据库连接池的占用率才到 60%。
老谭盯着监控屏幕，突然说：“移动的人今天跟我说，下个月要上调 Sp的分成比例，从 3:7调到 4:6。”
我愣了一下，突然想起市场部的话：“短信业务的毛利率有 60%，比游戏还高。但你说，这高利润能走多久？信浪已经在做彩信了，听说能发图片。”
老谭没说话，只是把监控界面的截图保存下来，命名为“短信业务破局 1.0”。
窗外的天快亮了，楼下的早点摊飘来豆浆的香味。
我的手机突然震了一下——是条测试短信，内容是“网益体育：国足 1-0赢了”，发送时间显示“05:30:01”，比预定时间早了 2秒。
我抬头看向老谭，他正对着屏幕笑：“明天，该让市场部准备推广方案了。”
第四天清晨的晨会被紧急打断。
Jackson拿着厚厚一叠投诉记录摔在会议桌上，咖啡渍溅到“日活 50万”的 KpI海报上：“昨天一天收到 1200个投诉，全是说我们发垃圾短信！有用户收到网益中奖短信汇了款，现在直接报警称被网益诈骗。”
他把一份移动的警告函推过来，“运营商说再解决不了，就要暂停我们的 Sp代码——那意味着整个短信业务停摆。”
老谭突然站起来，指着白板上的业务流程图：“这不是我们的问题。”
他圈出 Sp服务器与运营商网关的连接点，“正规流程里，每条短信都要带我们的 Sp代码通过网关发送，移动后台能查到记录。但这些垃圾短信查不到源头，说明是伪造的。”
他调出两条短信截图对比，“你们看，伪造的短信末尾少了运营商要求的回复 td退订后缀，而且发送时间集中在凌晨 2 - 4点，正好避开我们的系统监控。”
我突然想起上周运营商会议提到的漏洞：“移动的 mISc平台还没上线！现在他们分不清 Sp提交的订单真假。”
老谭点点头，在黑板上画了个简易基站图标：“GSm网络的认证算法三年前就被破解了，不法分子用假身份证开卡，再用群发软件伪造我们的 Sp代码，直接绕开网关发信。就像有人复制了你的门牌号，在小区外乱塞小广告，住户却都来找你算账。”
客服部传来更坏的消息：有媒体已经报道“网益短信陷阱”，几位名人在论坛吐槽收到低俗内容，股价早盘跌了 3%。
Jackson把烟盒捏扁：“技术部三天内必须拿出方案，否则整个 q4奖金取消。”
老谭当晚带着团队拆了三条伪造短信的数据包。
“找到规律了！”
他指着屏幕上的特征码，“这些伪短信的发送 Ip集中在三个网段，而且每小时发送量超过 500条就会换卡”。
我问道：“那我们有什么办法解决呢？”
老谭右手在空中划了两下，说道：“我们可以建两道防线：第一，给所有正规短信加动态校验码，用户收到后回复校验码才能生效，伪造短信做不到这点；第二，开发实时监控系统，一旦发现某号码段在短时间内收到大量带标识的短信，就自动触发运营商拦截。”
我连夜联系移动网关团队，提出共享 Sp服务器的 Ip白名单。
“让他们在网关层加过滤，只有我们服务器发出的请求才放行。”
老谭则在代码里埋了个巧思：“每条短信末尾藏个隐形字符，正规客户端能解析，转发到移动后台就能验证真伪。”
三天后
下午，监控系统首次报警：广州天河区某号码段 10分钟内出现 200条伪造的“网益彩票”短信。
老谭一键启动拦截，三分钟后移动反馈：“源头已经定位，是个用笔记本群发的团伙。”
客服部的投诉电话开始减少，一周后移动发来函件：“Sp代码恢复正常使用，建议将动态校验码机制推广到全行业。”
老谭把拦截系统命名为“守门人 1.0”，屏幕上跳动的拦截数据显示已挡住 8300条伪短信。
Jackson在庆功会上难得露出笑容：“下周给技术部发双倍奖金——但记住，这只是开始。”
窗外的广告牌正在更换，信浪的彩信广告已经亮了起来。