上周三凌晨两点，网站服务器监控突然报警，情况主站响应时间从平均180毫秒飙到2.3秒。汇报爬起来查日志，网站发现是情况某个爬虫在疯狂抓取商品详情页，单IP每秒请求超过400次。汇报临时封了IP段，网站又加了一层限流规则，情况才算把服务拉回来。汇报这事让我意识到，网站网站表面看着平稳，情况底下其实一直有暗流。汇报

先交代下基本盘。网站目前站点日均PV大概12万，情况UV不到3万，汇报注册用户累计8.7万，但月活只有1.1万左右。这个数字不太好看。去年这时候月活还有1.8万，掉了将近四成。技术层面没出大问题，但用户流失是事实。我翻了下后台的访问路径数据，发现一个很明显的现象：超过60%的用户只访问首页和一个分类页就离开了，平均停留时间47秒。这说明内容吸引力不够，或者加载速度有问题。测了一下，移动端首屏完全加载要3.8秒，确实偏慢。

服务器配置方面，目前用的是2核4G的云主机，带宽5M。数据库和Web服务跑在同一台机器上，MySQL的慢查询日志里每天能抓到两三百条执行超过2秒的SQL。最慢的一条是商品搜索的模糊匹配，用了LIKE '%关键词%'，全表扫描了将近8万行数据。这个必须改，要么上全文索引，要么单独做搜索服务。缓存用的是Redis，但只缓存了首页和分类页，详情页和用户中心全是直接查库。命中率不到30%，等于白装。

安全这块也有隐患。上个月做了一次简单的渗透测试，发现三个问题：后台登录接口没有验证码，可以无限尝试密码；用户上传图片的接口只检查了Content-Type，把.php文件改成.jpg就能传上去；还有几个老页面的SQL查询直接拼接了URL参数，虽然现在数据量小没被拖库，但迟早出事。已经修了后两个，登录验证码还没加，因为前端要改的地方比较多，排期排到下个月了。

再说说CDN。目前只对静态资源做了加速，图片、CSS、JS走的是某云厂商的CDN，命中率92%，还行。但HTML页面没有走CDN，所有动态请求都回源到那台2核4G的机器。晚上八点到十点是高峰，CPU能跑到85%以上，负载经常破4。短期办法是加一台机器做负载均衡，长期看得把架构拆开，数据库单独一台，Web至少两台，再加一台专门跑Redis和队列。预算大概每月多花600块，能接受。

内容层面，我观察到一个细节。站内点击量最高的十个页面里，有七个是工具类内容，比如“XX计算器”“XX对照表”，而不是资讯或攻略。这些工具页的跳出率只有22%，平均停留时间4分半。反过来，那些长篇攻略的跳出率超过70%。用户来这儿就是解决具体问题的，不是来看文章的。这个判断如果成立，接下来的内容方向应该往工具化、轻量化走，少写大段文字，多做可交互的小功能。

最后提一嘴备份。现在每天凌晨3点自动备份数据库到对象存储，保留最近7天。但上周测试恢复的时候发现，备份文件解压后少了两张表。查了半天，是备份脚本里mysqldump的参数写错了，漏了--databases选项，导致只导出了部分库。已经修了，但这事挺后怕的。以后每季度得做一次真实的恢复演练，不能光看备份日志显示“成功”就完事。

网站这东西，不出事的时候觉得哪都挺好，一出事就是连锁反应。上面这些点，有些是急茬，比如SQL优化和备份验证；有些是慢工，比如架构拆分和内容转型。先干哪个后干哪个，得看下周的流量趋势再定。