工作总结
发布时间：2026-04-11药物管理系统运维工作盘点【2026分享】。
这一年，我们自研的药物管理系统没少给我找事。先交个底：系统可用性99.97%，比去年高了0.15个点。别急着鼓掌，这0.15%背后是三次半夜爬起来处理故障换来的。药物主数据准确率99.6%，临床试验部门的满意度从86分涨到93分。这些数字我认，但更想说说数字没写出来的东西。
讲第一个事儿。三月份，一个抗肿瘤药的稳定性数据连续三天报警。研发那边炸了锅——这批数据要拿去注册申报，溶出度指标飘了±10%以上，按规矩得重新做实验，三个月打底。我接手的时候也觉得邪门：设备日志显示溶出仪半年前校准过，超了SOP规定的季度周期，但这不是主因。真正麻烦的是数据上传接口。我们有个脚本，为了提高入库效率，把三个平行样的结果合并成一条记录取平均值。这个设计当初还被表扬过。结果呢？某几个时间点个别样品的溶出度其实偏低，一平均就掩盖了，但系统阈值偏偏又被设成了“任一原始值超标即报警”——脚本合并后只传平均值，可报警逻辑还在扫原始数据表，数据对不上，于是疯狂报假警。
当天下午我干了三件事：第一，手工回滚那批CSV，用Python逐行重算，花了四个小时，把48个时间点的真实曲线拼回来。第二，找开发商量，把脚本逻辑彻底改了——平行样不许合并，每条原始记录独立入库，同时加了个标记字段，单点异常只标黄不阻断。第三，拉着设备科把所有溶出仪重新校准，并且写了个定时任务：超期未校准，系统直接锁止该设备的数据上传入口，谁也别想绕过。这之后，同类假报警再没出现过。
再说一个内存泄漏的教训。七月中旬周三下午三点，生产环境开始丢包，用户登录超时。查了一圈，网络正常，数据库正常，最后在应用服务器上抓到一条叫“BatchDrugCodeGenerator”的线程，内存占掉4个G。这玩意儿是用来批量生成药品追溯码的，本该凌晨两点跑批处理。那天不知道哪位同事在生产环境手动执行了一次，batchSize设成了500万。五百万个条码同时生成，每个还要调物料批号校验接口，直接把JVM堆撑爆了。
处理过程说不上多高级，但很磨人。我先kill掉那个线程，应用半死不活，内存碎片散了一地。下午四点还要投料生产，重启整个服务意味着至少断线十五分钟。我硬着头皮用jmap导出堆转储，定位到一个HashMap里攒了三百多万个临时对象，全是没来得及释放的中间结果。然后写了一段Groovy脚本，用OQL把那个Map里的引用全部置空，手动触发一次Full GC。内存从3.9G掉到800M，服务恢复，前后折腾了四十分钟。
事后我和开发吵了一架。我的方案是：第一，禁止任何人直接在生产环境执行批处理脚本，所有任务走调度平台，登录权限收回；第二，batchSize上限锁死10万，超过自动拆分。开发说“改起来麻烦”，我说那你写个事故报告给领导看谁麻烦。最后改了。同时把堆内存报警从每五分钟轮询改成实时，超过70%直接钉钉+短信。
设备维护这块，我们管着三台液相色谱仪、两台质谱仪和十几个温湿度采集器。以前最头疼的是校准老忘。我写了个小脚本，不是啥高深状态机，就是每天早上七点跑一遍，把距离下次校准不到七天的设备列出来，推到大屏上，同时发到运维群。今年设备相关的人为失误从7次降到0。这活儿不值一提，但管用。
也有搞不定的时候。九月份，药物警戒系统的数据库慢查询越来越频繁，我折腾了两天，索引重建、分区裁剪、甚至怀疑过磁盘固件问题，最后也没找到根因。没办法，临时做了个读写分离，把查询类的请求切到从库，主库保写入。后来请了数据库厂商的人来，才发现是Oracle的一个优化器bug，打了补丁才消停。这事儿让我学会一个道理：有些故障不是你不够努力，而是你手里的信息不够，该认怂就认怂，先止血再深挖。
说句实在话，那天下着雨，临床试验部门项目经理打电话来说，我们修复的溶出度数据帮他们确认了仿制药的稳定性窗口比预期多了两周。她说谢谢，我说不客气，挂了电话我继续写故障报告。干这行的，最大的成就感不是不出事，是出了事你能扛住，而且下次能少踩一个坑。
明年两个硬骨头：药物警戒系统的数据库得做分库分表，现在单库已经快到极限；临床试验盲法随机化模块的自动化测试覆盖率才60%，手工回归太耗人。没别的，接着干。
-
我们精彩推荐工作总结专题，静候访问专题：工作总结
