这周处理了47个工单,3起紧急故障,12次常规变更。故障平均响应4分多钟,系统可用性99.97%,用户满意度4.85。数据放这儿,不是想显摆——说实话,我自己清楚,这里面有运气成分。
周三下午那场数据库连接池耗尽,现在想起来后背还发凉。两点二十三分告警跳出来,核心交易系统超时。业务方在群里已经炸了:“页面转圈快半分钟了!”我第一反应不是上去就查,而是先稳住——这种时候手抖点错一个命令,事儿就大了。
登录堡垒机扫了眼应用服务器负载,cpu75%,内存正常。不对,再看数据库监控——活跃连接数卡在500上限,妥妥的池子满了。抓出pg_stat_activity,发现大量select * from order_detail where order_id=xxxxx在重复执行,而且没有走索引。正常业务走缓存,不可能这么玩命查数据库。谁在搞事?
顺着调用链往上摸,发现上游一个服务因为没有退避策略,在疯狂重试。当时只有两条路:要么杀连接,要么扩池子。杀连接杀了还会重连,等于白干。我硬着头皮把连接池上限临时拉到800——这个操作有一定风险,搞不好把别的实例也拖垮。但顾不上了。
然后去网关层对那个上游服务加了个令牌桶限流,每秒只放20个请求。两点零二分,连接数降到300,业务恢复。事后查根因:order_detail表的索引设计有问题,加上上游重试配置缺失。最让人无奈的是,今年已经第三次遇到类似的重试风暴了,每次都换一个服务。说白了,缺一个跨团队的容灾规范。我把这次的处理步骤和整改建议扔到技术群里,上游负责人回了一句“下周排期”,我当时真想骂人——你下周排期,我今晚还得盯着。
设备维护那块,我照着工艺标准做季度巡检。有一台存储节点的smart数据里,reallocated_sector_ct从8涨到47——标准里写超过50就得换。虽然还没报错,但我直接申请更换新盘。有人觉得我小题大做,我说,你可以问问隔壁组上半年那次磁盘彻底挂掉、丢了仨小时数据半夜被叫起来的滋味。换盘流程我走了1.5小时:先迁移数据到备用节点,校验一致性,热插拔,重建raid。业务没感知,但我的老腰在机房地板上蹲了半小时。
周五业务方上线新功能,让我配合压测。一个支付回调接口,100 qps起步,跑到600 qps的时候响应时间从80ms飙升到1200ms,还有0.5%的失败率。抓日志发现分布









