工作总结
发布时间：2026-04-15自考会议工作总结〔佳文〕。
一季度下来，手上负责的考务系统核心模块，从报名到排考再到成绩合成，跑了四场正式考试，现场技术保障我盯了三场。系统报警记录里我筛了一遍，真正影响业务的故障有11起，另外26次是监控探针误报或者人为操作超时。零重大事故是真的，但说零投诉就假了——第二场考试有考生排队时等了将近六分钟，因为报名照片下载接口突然变慢，虽然没上升到正式投诉，考点老师后来专门打电话来抱怨过一句。这事我记在内部复盘文档里了。
先说那个索引的事，差点把自己搞进坑里
年初模拟测试，报名数据批量导入，两千条考生记录跑一个存储过程，响应时间从0.3秒直接跳到8秒多。我当时第一反应是服务器内存不够，看了监控发现CPU也不高。那天晚上十点多，我把慢查询日志拉出来，跑了EXPLAIN，发现三个主表（考生基本信息表、报考科目表、缴费记录表）做左连接的时候，全在走全表扫描。顺着表结构查下去，去年年底做了一次分库迁移，DBA图省事，直接用CREATE TABLE ... SELECT重建了其中两张表，原来的复合索引全丢了。最要命的是，当时我以为索引还在，因为开发环境有，生产环境没同步。
我直接在从库上试了ALTER TABLE加索引，结果没加ONLINE参数，从库直接锁表，复制延迟从0秒飙到33秒，监控报警器连着响了七八声。我赶紧KILL掉进程，手都在抖。后来等到凌晨两点窗口期，用pt-online-schema-change把索引加上去。复合索引的字段顺序我反复测了三遍——(exam_id, status, create_time) 和 (status, exam_id, create_time) 查询效率差了将近四倍，因为业务里exam_id的选择率远高于status。最后定下来用前者，导入时间从42秒压到6秒。这事之后，我写了一个小脚本，每周日凌晨自动比对生产库和从库的索引差异，发现不一致直接发邮件到团队群里。
那个雨后的早晨，我蹲在机房地上骂了句脏话
四月第二个周六，大雨。第二天要考试，晚上考点机房空调漏水，正好滴在核心交换机上。我第二天早上六点半赶到现场，交换机已经自动重启过两次，端口闪断。监考老师急得围了一圈，说考生在门口排了二十多米了。
我没先动硬件。带了根console线，笔记本没串口，又翻出来一个USB转串口适配器——那玩意儿驱动经常掉，那天居然一次认上了。敲show log，看到端口GigabitEthernet0/24反复出现port-security violation。再敲show port-security address，发现该端口的MAC地址表不停地漂移，绑定的是考务服务器的MAC，但实际接入的是一台备用终端。雨水导致线路阻抗变化，交换机误判为攻击，把端口err-disable了。
我当时的判断：如果按正规流程去查环路、查ARP，至少要半小时。直接操作：先conf t，no errdisable recovery cause psecure-violation，然后把那二十台考试终端的MAC地址从DHCP lease文件里导出来，手工写进端口安全白名单。注意，不是全部关掉端口安全，而是只允许白名单内的MAC通过。整个操作十五分钟，七点前所有终端恢复。事后写了一份应急操作单，只有五条，A4纸竖着排，第一条就是“用console线看log，别乱拔网线”。
那天回去的路上，我想明白一件事：应急预案不能只写“遇到故障按流程处理”，得把最常见的几种误判原因直接印在纸上。后来每个考点技术负责人的工具包里都塞了一张塑封卡片，正面是五条快速排查，反面是七条反面案例，比如“某考点曾因为没校验MD5导致成绩汇总错位”。
UPS那摊事，差点烧了我的线
季度设备巡检，我带着电子负载仪和万用表去查四个老旧考点。其中一个考点的UPS，面板上显示电压正常，电池健康度85%。我不放心，决定做一次带载测试。负载仪没带适配线，现场翻箱倒柜找到两根废网线，剥了皮，铜芯拧成两股，临时接到负载仪的输入端。刚加到60%负载，线头发烫冒烟，我赶紧断电。拆开UPS外壳一看，里面的电解电容顶部鼓包了，用万用表测容量，标称4700μF，实测只剩2100μF。输出波形已经畸变，用示波器看，THD超过了8%（标准是5%）。
这要是等到考试当天断电暴露，整场监控和网络全得瘫痪。我后来把所有“亚健康”指标量化了：输出电压波动超过±3%、电池内阻比标称值高40%、无负载时内部温度比环境高15度，只要触发一条，直接进更换流程。季度维护报告里我新加了一张表，叫“亚健康设备清单”，比单纯的故障率指标管用得多。
跨部门那点破事，也得记一笔
考务办有个同事，非要在大规模并发查询的接口里实时统计每个考场的缺考人数。我跟她解释，缺考数据要等开考半小时后才有，而且实时COUNT(*)会把数据库拖死。她不听，说领导要看到动态数字。后来我直接在会议室拍了桌子（真拍了，桌上水杯都跳了一下），最后妥协方案：每五分钟用定时任务异步计算一次，结果存Redis，接口直接从缓存读。代码里我加了一个降级开关，如果Redis挂了或者计算超时，直接返回上一次的有效数据，不报错。
这事让我意识到，技术方案不能光讲道理，得把最坏情况演示给对方看。我在白板上画了一条曲线，标出并发峰值时数据库连接数的上限，对方看了之后才松口。
说自己一点真实感受
做自考技术保障这活，最大的教训是：别太相信监控系统。那台UPS面板显示正常，如果我只盯着面板，绝对发现不了电容鼓包。同样，那次索引丢失，监控里CPU和内存都没报警，但业务已经卡成狗。现在我每周手工跑一遍关键指标的原始数据，用命令行查，不依赖界面。
另外，技术总结别写成邀功报告。那次交换机故障，我完全可以写“快速恢复业务”，但我事后在内部文档里补了一段“应该提前为考试模式配置端口安全策略”，把具体命令都贴上了。下季度我打算把那套亚健康预警逻辑写成一个shell脚本，每天凌晨跑一遍，自动把可疑设备标红。手工查终究有遗漏，能自动化的就别让人耗神。
-
我们精彩推荐工作总结专题，静候访问专题：工作总结
