工作总结

发表时间：2026-04-15

（经典）图书管理员年度工作总结。

今年这一摊子活儿，说多了都是细节。外人觉得图书管理员就是坐柜台刷条码，那是没见着系统崩了读者拍桌子、书上架了读者死活找不到、还有那些藏在机柜里慢慢氧化的接线端子。下面是我这一年的流水账，不唱高调，只说怎么修、怎么查、怎么跟人磨。

一、先把数据摆出来

A区流通库和电子阅览室，全年借还11.3万册次，处理读者证件和咨询大概2100件。这些数字背后我真正盯着的是一件事：核心业务系统（LibSys 6.0）的可用性。去年只有99.2%，因为服务器内存泄漏，高峰期平均每两周崩一次。今年拉到了99.95%。别小看这0.75个点——换算成读者排队时间，一年少让读者干等将近30个小时。怎么做到的？往下看。

二、五一那次系统崩溃，我现在想起来还窝火

4月30日上午9点开馆，借还柜台瞬间排了四十多米。客户端能登录，一扫ISBN就报“数据库连接超时”。读者开始骂骂咧咧，有个大爷直接把借书卡拍在台面上说“你们这系统还不如手写”。

我的第一反应不是重启服务器——那等于告诉所有人“我没办法了”。切到备用管理终端，查数据库连接池。活动会话数512，满了。正常峰值120。这不是硬件扛不住，是有东西在作妖。再看慢查询日志，一条来自批量借阅接口的SQL，执行时间380秒。

追这条SQL的源头，发现是“索书号”字段的排序。技术部上周为了配合新书架上架，改过这个字段的索引结构，但没在正式环境重建索引。这简直让我无语——测试环境明明跑通了的步骤，上生产就漏了。我手动kill掉异常会话，重建复合索引，5分钟后系统恢复。但那5分钟里，柜台同事手工登记了87位读者的证号和书名，答应他们系统好了再补借阅手续。有6位读者等不了，直接走人，回来投诉说我们浪费他们时间。

事后我写了一份《生产环境变更操作确认清单》，强制要求任何索引或配置变更，必须在备用节点先验证，并且留存执行计划。我把这份清单贴在机房门口，谁要改东西，先打勾再动手。说白了，人都会忘，流程就是用来兜底的。

三、找书这件事，比修系统更磨人

系统显示“在馆”，架位上就是没有——这是图书馆的信任危机。我干了一件事：每周日凌晨闭馆后，跑一个脚本，比对中央数据库的“在馆”记录和RFID手持终端的最后一次架位扫描。第一次跑出来210册“逻辑在馆、物理失踪”的图书。

巡架组组长看到清单，脸都绿了：“你这是找茬，我们每天巡两遍架还不够？”我没争，改成每周只给20册最有可能找回的书目，并且用热力图标出高频错架区域——文学类I区乱放率最高，计算机TP类其次。按我的提示，他们找回了其中17册。慢慢的，他们开始主动问我“这周的热力图出来没”。

针对归架漏扫的问题，我在流程里加了一道“二次确认”：归架员完成一个书架后，必须用终端随机抽取10%的图书进行点位复测。如果偏差率超过3%，全架重扫。一开始有人嫌麻烦，说“你这加活儿不加工资”。我陪着他们干了两个周末，证明这个动作只需要多花8分钟，但能减少后期40%的找书投诉。后来大家默认了。

我还建了一张表，名字很土，叫“异常在馆记录表”，专门记录那些连续三个月盘点都不在架的书。每季度跟采购清单交叉比对，确认丢失的就启动剔除流程，同时生成补采建议。这套组合拳打下来，第四季度读者自助找书成功率从91.5%升到97.2%。剩下的2.8%里，有一半是被读者塞到隔壁书架缝里了——这事儿真没招。

四、设备那点事，别动不动就喊换新的

电子阅览室50台终端，2019年的批次，一到夏天开空调，电压波动就重启。技术科来人看了一眼，说线路没问题，建议换终端。我一听就不对劲——换50台终端小二十万，这叫“没问题”？

自己买了把钳形表和一台红外热成像仪，闭馆后一台一台测。测了一圈，发现问题不在主线，在PDU（电源分配单元）的接线排上。几台老PDU的零线端子氧化松动，接触电阻大，电压一波动就跳变。解决方案很简单：换PDU。我选了工业级防脱扣型号，C13-C14接口，10A额定电流。换完之后，按《数据中心施工验收规范》逐项验收：接线端子扭力值打到1.2N·m，每条线路用绝缘电阻测试仪测绝缘阻值，最后用热成像仪跑满负载2小时，最高温升点控制在15℃以内。总成本不到三千块。

隔壁馆听说后也想这么干，结果他们图省事，换了PDU没做验收。三个月后端子松动打火，焦糊味都窜到阅览室了。这事儿让我更坚信：规范不是写着玩的，少一步都不行。

迷你日记网精选合辑: