工作总结

时间:2026-04-09 作者:工作计划之家

2026年人力资源信息系统工作总结。

干了四年HRIS，今年算是最折腾的一年。系统从勉强能用到现在跑得还算顺，中间踩的坑、熬的夜，写下来给自己做个备份。

先说考勤模块那档子事。三月份薪酬核算组的老周直接甩了张截图到群里——月报导出白屏，数据库CPU持续100%。我登上去一看，慢查询日志里有个存储过程跑了47分钟还没结束。打开那个存储过程，两千多行，嵌套了五层子查询，每层都在全表扫打卡明细表。那表当时已经一千二百万行。这玩意儿居然用了五年没人动过，因为每次新加考勤规则就在后面补一段代码，补到现在像个臃肿的怪物。

我那天晚上没回去。先把存储过程拷到测试库，一条条拆。发现核心问题在于月汇总时重复计算每个员工的加班系数和假期折算，而这些配置一年才变两次。于是改成增量更新：每天凌晨两点跑批，只处理当天有打卡变动的员工。中间踩了个坑——第一次跑完发现漏掉了调岗员工的历史补卡记录，又加了个补偿任务。索引重建用的是(emp_id, period_year, period_month)聚集索引，把覆盖查询字段塞进去。改完第一次执行，42秒。我盯着屏幕愣了半分钟，心想早知道这么简单，至于让老周白头发多那么多根？后来CPU峰值从98%降到23%，老周说这个月他老婆终于不骂他了。

六月份的数据迁移事故才是真丢人。事业部独立，要迁300多人到新租户。脚本我写的，测试环境跑了三遍都没问题。上线跑了三个小时，报错说dept_id不存在。一查，有17条记录的部门已经被业务那边软删除了，而且这些员工身上还挂着未结的审批流程。更操蛋的是，流程引擎没做外键约束，全靠应用层校验，迁移后直接空指针。那会儿是周五晚上九点，我本来约了人吃饭，结果蹲在工位上啃面包到凌晨一点。

当时处理办法：先停掉迁移任务，用递归查出所有依赖失效部门的员工，临时挂到一个“待处理”虚拟部门下。然后手写修复脚本，遍历这些员工的未结流程实例，把dept_id挨个映射到新部门。最后在迁移脚本前置加了三道检查：部门有效性、流程节点完整性、汇报关系闭环。这简直让我上火——为什么这么基础的东西之前没人做？后来我翻了下历史，发现这类迁移都是各个开发自己写临时脚本，从来没有统一的校验库。所以第二周我搭了个迁移检查工具，集成到Jenkins流水线，每次跑批前自动出差异报告，必须业务负责人签字才能继续。

还有一个教训是权限管理。之前没提，其实三季度出过一次险情。离职员工的账号没自动回收，那个员工是做薪酬的，离职两周后居然还能登录系统。虽然日志显示他没点进去看数据，但这事捅到安全部，我被叫去谈话。根因是OA的离职流程跟HRIS之间是单向同步，而且同步接口没有处理“离职生效时间”这个字段——员工办完手续当天，系统里他的状态还是“在职”。排查发现是接口映射时用了update_time作为判断依据，但OA那边批量离职导入时update_time没更新。

修复方案：改接口逻辑，直接读OA的dimission_date字段，定时任务每小时扫一次，发现离职日期小于当前时间且状态未变，就触发权限回收。另外加了监控，每天凌晨给安全部发一份“待回收但未回收”的清单。现在这个清单上基本是零条，但当时确实吓出我一身冷汗。

今年还做了一件蠢事。六月份我想把假期计算逻辑从硬编码改成规则引擎，省得每次改国假配置都要发版。选型用了EasyRules，搞了两个星期，把调休假、年假、病假的计算规则都写进json。结果在压测时发现，单个员工算一次假要扫二十多个规则条件，响应时间从50毫秒飙到1.8秒。高峰期两千人同时打卡触发实时计算，直接拖垮了考勤接口。最后只能回滚到硬编码。这事让我明白，不是所有“优雅设计”都适合线上场景，尤其在高频低延迟的路径上，简单粗暴往往更可靠。

日常维护里最磨人的是第三方接口的破事。八月份考勤机打卡数据突然不更新了，查了两天发现供应商悄悄把接口从HTTP升级到HTTPS，我们这边证书没更新。打电话过去，对方说“发了邮件通知”。我翻了邮箱，那封邮件被归类到垃圾箱，标题写的“服务升级重要通知”，正文就一行字，连个联系人电话都没有。真他妈服了。后来我跟供应商签了SLA，要求任何接口变更必须提前15天书面确认，并且提供测试环境验证。同时自己在系统里加了接口健康检查，每分钟探测一次，不通就换备用通道。

【工作计划之家Fz76.CoM】精品手册:

人力资源 | 人力资源工作总结 | 信息系统合同 | 年终人力资源工作总结 | 人力资源信息系统工作总结 | 人力资源信息系统经理工作总结

一年下来，系统可用性从99.2%提到99.8%，月均故障时长从215分钟压到42分钟。但说实话，这些数字背后没什么神奇招数，就是把每个报错日志当回事。比如慢查询日志里看到一个全表扫描，就追根问底把那行SQL揪出来改掉。再比如员工反馈考勤数据对不上，就跟着他一天的打卡时间线一步步查，直到找到是哪个批处理任务漏了数据。

现在团队里新来的两个同事，我都让他们先背那本“故障快速定位手册”——里面整理了这两年碰到的87个异常场景，每个都写清楚了日志关键字、可能原因、处置SQL、回滚方案。上个月有个凌晨三点的告警，新人对着手册十五分钟就定位到是缓存穿透，自己解决了。我在手机上看他操作记录，觉得这手册总算没白写。

要说还有什么没做好的，那就是跟业务部门的沟通还是太被动。好几次需求变更，都是他们直接在系统里改了配置，然后出问题来找我。比如十一月份有个部门经理把加班系数从1.5改成2.0，没通知任何人，结果薪资核算炸了。我后来加了个配置变更审计日志，每次有人改关键参数就自动抄送我。但更深层的问题——为什么他们敢绕过IT直接动生产配置——这已经不是技术能解决的了。明年我得把配置变更的审批流程钉死，不然这种坑还会再踩。

推荐阅读:

工作计划之家小编为您推荐工作总结专题，欢迎访问：工作总结

热门标签:

公司人力资源工作总结

人力资源年终工作总结

人力资源岗工作总结