工作总结
发布时间：2026-04-20日常工作总结（推荐）。
今年上半年，核心支付链路可用性压在99.95%这条线上，比去年同期的99.82%高了0.13个百分点。数字看着不大，但对应到故障时长——平均发现从12分钟缩到4分钟以内，修复从35分钟压到18分钟。客户满意度回访里，工单系统上的评分从4.2拉到4.7，我自己翻了翻记录，凡是给五星的，备注栏里多半写着“没废话，直接解决问题”。
一、凌晨两点的故障，绕了五分钟弯路
五月中旬那次半夜被叫起来，告警说支付接口超时率15%。我第一反应是网络抖动，先ping了后端数据库——延迟正常。又看了眼CPU idle和iowait，也都平稳。绕了五分钟，最后才去查数据库连接池，发现活跃连接数冲到了800，池子最大才500。顺着慢查询日志往下翻，一条新上线的对账SQL没带索引，全表扫了200万行。
当时脑子里的决策树是这样的：直接kill慢查询，风险最小，但业务方还在不停重试，kill完可能又被拉起来。我选了先限流——网关层的令牌桶从1000/秒往下调到200/秒，超时率立刻掉到2%以内。这期间大概有30%的请求被限流拒绝，返回了429状态码，我们事前在SDK里做了指数退避重试，所以用户侧只感觉到稍微慢了一点，没有报错。然后我kill掉那条慢查询的会话，给表加上联合索引。从收到告警到业务恢复，11分钟。事后统计影响了300多笔订单，全部走人工补单脚本处理掉，没有一笔丢单。
第二天我拉开发看现场。我直接打开慢查询日志，指着那条SQL问：“你们上线前跑过explain吗？”开发承认只看了测试环境的小数据量。后来我们定了三条硬规矩：第一，所有DDL和复杂查询必须用pt-query-digest分析，输出报告附在发布单上；第二，连接池告警阈值从80%降到60%，留出预警时间；第三，混沌工程里加了数据库连接数突增的演练，每个月跑一次。这周三又遇到类似问题，监控提前20分钟报了“连接池使用率超65%”，我们趁低峰期就加上了索引，用户全程无感。
二、硬盘那点事儿，阈值16是怎么来的
机房里有24块SAS盘，去年因为固件bug出过两次慢盘故障。我把这批盘的型号和固件版本挨个对了一遍，发现是三批不同时期采购的盘混在一起，各自的SCT超时阈值不一样——有的设30秒，有的设120秒，这就埋了雷。
我写了个脚本，每周拉一次smartctl输出，重点盯“Current_Pending_Sector”和“Reallocated_Sector_Count”。阈值为啥设16？我翻了过去两年所有坏盘的更换记录，pending sector超过16的盘，两周内必然出现reallocated sector，与其等它变成坏道影响性能，不如提前换。脚本跑了一个季度，提前揪出4块隐患盘。其中一块pending sector涨到32的时候，我们主动做了全盘读写校验，发现逻辑坏道已经扩散，直接下线换新盘，避免了生产故障。
我把这个流程写进了每周维护清单，现在组里新人照着做，第一步先跑smart检查，第二步看电源冗余状态，第三步检查光纤模块收发光功率。上个月新来的两个同事，按这个清单独立完成了12台服务器的上下架，零失误。
三、CDN切换，多出来的30毫秒
四月份那次CDN域名切换，原计划切完观察半小时就收工。但我用curl -w 写了个循环脚本，对比新旧节点的首包时间，发现新节点平均多了30毫秒。业务方说“就30毫秒，用户感知不到”，我没签字。我打开tcpdump分别抓了新老节点的握手包，对比发现老节点发SYN后能收到带TFO cookie的ACK，新节点没有。再翻内核参数，果然新节点的net.ipv4.tcp_fast_open是0，老节点是3。改完参数重启服务，再测，新节点的首包时间反而比老节点快了10毫秒。
那天改完已经是凌晨两点，我签了验收单，在变更记录里补了一行：“验收标准需包含tcp fast open状态检查。”第二天我把这个案例写进了故障预防清单，以后所有新节点上线，必须跑一遍内核参数对比脚本，不能光看服务端口通不通。
四、压测验收，三组数据说话
每次变更后的验收，我不看“感觉没问题”，只看三组压测数据。上周升级负载均衡器内核版本，验收时我跑了三组场景：第一组用正常流量跑五分钟，记录P99延迟和抖动幅度；第二组模拟单台后端宕机，观察健康检查生效时间和流量重新分配是否均匀；第三组用wrk打突发流量，验证限流策略是否准确。三组跑完，每个指标和升级前的基线对比，偏差超过5%就不签收。
这套验收标准不是拍脑袋定的。去年有一次没压测直接上线，结果健康检查间隔没调对，导致后端重启时流量切不过来，影响了十分钟。从那以后我坚持“不上压测不签收”，哪怕半夜变更也得跑完。
五、还有根没拔掉的刺
也不是所有问题都完美解决了。目前MySQL主从切换时，应用层还有5%左右的连接报错，靠SDK里的重试机制兜底，用户无感，但我自己知道根因还没找到。我怀疑是proxy层在切换瞬间没有提前预热连接池，导致新建连接超时。下季度我计划引入proxy层的连接预热方案，先在预发环境跑两周，看能否把那5%的报错压到0。
这半年写了12份故障报告和18份变更方案，每份报告固定在wiki里留三个板块：故障时间轴（精确到秒）、根因分析（必须贴出日志或监控截图）、改进措施验收标准。以前写“加强监控”这种空话，现在写清楚“新增哪个指标的监控，阈值多少，谁来验证，验证结果附在最后”。上个月组里开复盘会，有人翻出我二月份写的一份报告，照着验收标准一项项打勾，全过了。那感觉比收到感谢电话还踏实。
-
欲了解工作总结网的更多内容，可以访问：工作总结
