工作总结
发表时间：2026-04-182026年教务科干事工作总结。
这一年干下来，最大的感受就是：教务工作容不得半点“大概齐”。排课、成绩、选课、教室设备，哪一项出问题，直接砸在老师学生头上。我把自己定位成一个修理工加值班员，系统稳定了，大家不骂人，就算及格。下面把今年干的活、踩的坑、补的洞理一理。
几个硬数字
先说能摆上台面的：排课系统非计划中断3次，最长一次22分钟，平均恢复9分钟。这数据是按工作日8点到17点统计的，晚上和周末维护不算在内。有同事问为啥不按全年算，我说那没意义——半夜两点中断谁在乎？可用率99.86%是按中断时长除以总运行时长（每天9小时×250天左右）算的，没有水分。
成绩录入准时率98.7%，逾期5门课。我查了记录，其中3门是同一门课的外聘老师，不熟悉系统，忘了提交按钮在哪。后来我在录入截止前24小时、2小时各发一次短信提醒，下学期应该能压下去。
教室设备报修187次，重复故障占11.2%。投影灯泡老化是主因，但根子上是采购流程太长，灯泡坏了要等两周。我后来申请了5个常用型号的备件库，随坏随换，不用等审批。
学生选课峰值并发720 QPS，系统没崩。但这是有代价的——我把前端提交按钮做了防抖，1秒内只能点一次，学生那边感觉“卡了一下”，后台队列稳住了。
两场事故的来龙去脉
第一场是9月新生排课。下午两点，系教学秘书打电话，语气很急：“保存课表转了3分钟还没好，办公室三个人都在等。”我第一反应是网络问题，ping了下服务器，延迟正常。登录数据库看，慢查询堆了几十条，全是冲突检测模块的SQL。当时的临时处理很简单：把数据库里所有“等待中”的会话kill掉，重启应用服务。10分钟后恢复，但我知道这治标不治本。
晚上加班分析原因。上学期加了“合班授课”功能，冲突检测要同时检查班级、教师、教室三个维度。数据量从3000涨到8000后，原来的SQL写法做了三层嵌套循环，全表扫描。我重写了SQL，改成先按时间片过滤，再用索引定位冲突。同时在Redis里缓存教师和教室的占用时段，不用每次都查数据库。改完后单次检测从6.2秒降到0.3秒。另外我在排课页面加了个保护：检测超过5秒自动中断并提示“冲突计算量过大，请缩小范围重试”，防止拖死整个系统。 www.386h.cOM
第二场是成绩单打印乱码事件。学生拿打印单来找，上面高数85分，系统里查是76分。我第一反应是打印机驱动问题，重装了驱动还是不对。查了打印视图的SQL，发现它引用的是一个物化视图，每周日刷新。问题出在上周日刷新时，源表刚好有一条成绩更正记录被删除再插入，物化视图的增量同步漏了这个变更。我花了半天时间，手动对比了源表和视图里所有课程的成绩，找出5门有偏差的，全改回来。然后重写了刷新脚本，不用增量了，直接做全量校验，每次刷新完自动比对关键字段的MD5值，不一致就发告警到我的手机。这个事之后，我养成了习惯：任何自动同步的东西，都得有事后校验，不能信任它不出错。
日常那些磨人的细节
调停课流程之前要跑三张纸，老师抱怨说“找个领导签字比上课还累”。我把流程搬到线上：老师提交申请，系统自动判断是否与已有安排冲突——没冲突就直接走电子签，有冲突才转人工。审批通过后，自动更新教室借用状态，并推送给相关学生课表变更。这个改动让平均审批时间从2天缩到4小时，调停课漏通知的投诉降为零。有老师开玩笑说“现在调课比点外卖还快”。
教室设备维护，我定了个三级巡检：每周开机测一轮，每月除尘和查灯泡计时，每学期末做一次质量验收。验收标准我参考了施工规范里的亮度、色偏、音频延迟指标——亮度低于新灯泡的60%直接换，不凑合。今年提前发现4台投影的风扇故障，避免了高温烧灯。采购那边嫌我换得勤，我说“你算算换一个灯泡800块，烧了主板得3000，哪个划算？”
成绩录入这块，上学期有位老师把平时成绩和期末成绩的权重配反，全班挂科。我加了一道校验：如果某门课程的不及格率比往年平均值高20%以上，弹窗警告并要求二次确认。同时做了一个成绩分布预览，提交前就能看到分数段饼图。本学期误操作引起的成绩更正申请下降了67%。但还是有漏洞——全班给高分的情况校验不出来，这个明年得补上。
今年没搞定的几个事
调课冲突检测虽然快了，但复杂场景下会漏。比如一位老师代另一位老师上两周课，同时教室又被借用，时间部分重叠且人员交替——系统只认完全重叠，没拦住。直到上课前才发现。根源是规则引擎太死板，只能写死逻辑。我明年的计划是做一个规则配置界面，让教务员自己也能定义“如果A且B但非C”的组合，不用每次找我改代码。
另外，成绩更正现在还是要写SQL语句直接操作数据库，风险太高。我打算做一个工单系统，每一步操作都有审批和日志，禁止任何人直连数据库。这个事其实年初就想了，一直没排上优先级，被各种故障打断了。
备份恢复那点破事
年中我做了一次模拟恢复演练，从备份里恢复成绩库。结果发现备份文件损坏了——因为只做了定时拷贝，没做完整性校验。后来改成每天自动校验备份文件的MD5，并异地存储到另一台服务器上。现在每个月真刀真枪演练一次恢复，从备份到数据可用，要求控制在30分钟内。这事没写进KPI，但我心里有数：真出了事，这是救命的。
写给明年自己的备忘
系统可用率保住99.8%以上，不再降。教室设备重复故障率压到5%以内。排课、选课、成绩三个模块的运维手册，从文字版升级成可执行的检测脚本——一键跑完所有预设的异常场景，不用等人去读手册。
还有一句废话但必须说：别信“系统很稳”的错觉，每一次故障都是从“应该不会出事”开始的。
- 需要更多的工作总结网内容，请访问至：工作总结
