昨天下午四点十七分，网站站点的管理数据库连接数突然飙到1024，直接把MySQL拖挂了。通报页面白屏，网站后台登录不进去，管理连SSH都卡得没法操作。通报值班的网站小李在群里扔了张截图，CPU负载冲到187。管理我扫了一眼慢查询日志，通报发现是网站商品详情页的一个联合查询没走索引，每次请求扫了将近三十万行。管理这个查询是通报上周改版时新加的，测试环境数据量小，网站没暴露出来。管理

问题定位到之后，通报先临时把详情页的缓存开关打开，让请求打到Redis上。数据库压力降下来，页面恢复访问。接着在从库上加了复合索引，主库用pt-online-schema-change工具同步。整个过程花了四十分钟，期间大约有十二分钟的全站不可用。影响订单量粗估在两百单左右，具体数字还在对。

这不是这个月第一次出状况。月初的时候，图片服务器磁盘写满，导致用户上传头像全部失败。原因是有个定时任务在清理缩略图时，误把原图目录也扫了进去，删了将近四十个G。好在之前配置了每日增量备份，从备份里恢复了一部分，但仍有大约百分之三的图片永久丢失。用户投诉了十几条，客服那边挨个打电话道歉，补偿了优惠券。

两件事暴露的是同一个问题：变更没有走完整的审核流程。商品详情页的查询改动，开发直接在线上热更新了代码，没经过DBA审核。图片清理脚本是运维为了省事，手动改的crontab时间，绕过了配置管理平台。说白了，就是图快。快是快了，代价也来了。

我翻了一下上个月的变更记录，总共有四十七次线上变更。其中走完审批流程的只有二十三次。剩下的二十四次里，有九次是“紧急修复”，十五次是“小改动，没必要”。这个“没必要”三个字，害死人。去年双十一大促前，就是因为一个“小改动”把购物车结算接口的限流阈值改错了，导致大促开始后十分钟内订单创建失败率超过百分之六十。那次损失更大，直接上了公司年度事故通报。

现在运维组定了个硬规矩：任何涉及数据库、缓存、消息队列的变更，必须提前一天提交申请，附带回滚方案和影响范围评估。紧急变更需要CTO或我本人签字。执行层面，所有线上操作必须通过跳板机，禁止直连生产环境。跳板机会记录所有命令，每周抽查一次。

另外，监控也补了几个盲区。数据库连接数超过八百就告警，慢查询超过五秒就抓堆栈。图片服务器的磁盘使用率阈值从百分之九十降到百分之七十五。定时任务全部纳入配置管理，禁止手动改crontab。Redis的内存使用率也加了告警，之前一直没管，其实已经到百分之八十二了，离出事不远。

说句实在话，这些措施不复杂，也不新鲜。很多团队早就在做。我们之前没做，说到底还是侥幸心理，觉得业务量不大，扛得住。但业务量是在涨的，上个月日均PV已经过千万了。系统复杂度也在涨，微服务拆了十几个，中间件用了七八种。靠人肉盯，盯不过来。

今天上午开了个复盘会，开发、运维、测试都到了。吵了两个小时，最后达成一致：下周三之前，把所有线上变更流程重新梳理一遍，该补的审批补上，该加的监控加上。谁再绕过流程，直接扣绩效。狠是狠了点，但总比半夜被叫起来修数据库强。

通报就这些。各小组对照检查，周五前把整改结果报到运维组。有问题在群里说，别私聊。