2026年凭证工作那些事儿
2026-04-01 工作总结 运维工作总结 故障处理总结工作总结
干了这几年凭证相关的活儿，说句实在话，最怕的就是半夜电话响。去年夏天那个事儿，现在想起来还觉得窝火。
那天凌晨两点四十七分，手机震了。我迷迷糊糊摸过来一看，监控群里炸了锅——核心凭证生成服务大面积超时，报警级别从Warning一路飙到Critical。我当时第一反应是数据库又死锁了？但转念一想不对，白天刚做过压测，各项指标都正常，怎么偏偏半夜崩了？
爬起来开电脑，VPN连上，先看数据库负载，正常。再看Redis缓存，也正常。心里稍微松了半口气，但紧接着翻应用日志，就发现不对劲了。日志里密密麻麻全是“凭证号生成失败”的报错，而且都是同一个错误码。
当时手是有点抖的，毕竟生产环境。我顺着堆栈往下查，发现问题出在凭证号生成器的乐观锁重试逻辑上。这个生成器是去年一个同事写的，为了保证高并发下凭证号唯一，用了数据库版本号做乐观锁，重试次数上限设了5次。逻辑上没毛病，但那天晚上有个大客户的批量导入任务，一次性扔过来两万多条数据，并发请求瞬间把乐观锁冲突率从平时的不到1%干到了将近40%。每次生成都要重试到上限才能返回，响应时间从正常的40毫秒直接拉到4.8秒，服务线程池被迅速占满，新请求进不来，连锁反应就来了。
找到根子，接下来就是怎么处理。说实话，大半夜改生产配置，心里是真没底。但监控曲线已经快成直线了，不动不行。我先把重试上限从5次临时降到2次，让服务先喘口气。改完配置那一刻，盯着监控屏幕，看着曲线一点一点往下掉，那种感觉就像看着病人心跳慢慢恢复正常。大概二十分钟后，服务基本稳住了。
但这事儿没完。我紧接着在日志里查那个批量导入任务，发现它跟实时生成服务用的是同一个线程池。这等于说，一个批处理任务把业务系统的资源给抢了。我临时把它切到独立的线程池，固定配了20个线程，跟实时业务隔离开。 zc530.cOM
折腾到凌晨四点左右，业务全恢复。第二天上班，我跟那个同事碰了个头，把压测数据翻出来一看，发现问题出在我们只做了常规并发压测，没模拟过这种“突发批量+实时业务”的混合场景。后来我们定了个新规矩：所有涉及共享资源竞争的服务，压测必须包含混合场景，而且要把乐观锁冲突率这个指标加进监控。
说起来挺丢人，这种事儿其实完全可以提前避免。
再说一个打印机的事儿，这让我特别无奈。我们有一套凭证打印模块，对接了好几种不同品牌的打印机。按理说这都是成熟技术，但就是隔三差五出问题——不是字体偏移，就是条形码扫不出来。每次报障，现场操作员都说“我是按操作手册做的”，但问题就是反复出现。
后来我干脆不坐办公室了，直接去现场蹲了两天。这一蹲，发现问题根本不在代码。操作手册里写的“纸张类型选A”，但不同批次的打印机驱动界面翻译不一样，有的显示“普通纸”，有的显示“自定义纸张”。有个大姐跟我说：“我每次打印都要重新调一遍，因为昨天的设置第二天就变了。”我一看，是驱动自动更新给重置了。
更离谱的是条形码打印失败的问题。我查了半天，发现有个操作员为了省墨，把打印浓度从“默认”调成了“省墨模式”。条形码的对比度不够，扫码枪自然识别不出来。问题是她自己都忘了调过这玩意儿，其他人也就跟着用。
这事儿让我深刻体会到，规范不能只停留在文档里。我后来干了一件事：把每种型号打印机的驱动界面截了图，在关键选项上用红框标出来，做成“傻瓜式”的图文指引，直接贴在打印机旁边的墙上。同时，在程序里加了个打印参数自检功能，每次打印前自动校验浓度、纸张类型这些关键设置，不符合标准就弹窗提醒，不允许继续打印。
这招见效挺快。这类故障工单从原来每周五六起，降到一两个月才有一回。关键是操作员们不用再记那些乱七八糟的设置了，跟着图点就行。
最后一个案例，是关于归档服务器的。我们有个老旧的凭证归档服务器，每年年底归档高峰期就会出幺蛾子。去年更绝，直接磁盘满了，归档任务全挂。按常规流程，清理磁盘就行。但我在查日志的时候，发现磁盘使用率从78%到100%，只用了三天。按正常速度，至少得一个月才能到这个程度。
这个异常增长率让我警觉了。我往前翻日志，发现有个归档压缩模块的逻辑有bug——它本该把原始文件压缩成tar.gz，然后删除原始文件，结果代码里少写了一行删除逻辑，导致原始文件和解压后的文件都保留了一份，磁盘占用直接翻倍。
这个bug其实存在了两年，但之前每次磁盘满，大家都习惯性地删文件、扩磁盘，没人去追根究底。我当时就觉得挺无语的，这种“头疼医头”的做法，简直是给自己埋雷。
处理完这次故障，我不光修了bug，还把归档模块的监控粒度细化到每个任务执行后的磁盘变化量。一旦某个任务的磁盘增长异常，第一时间告警到具体负责人。运维手册里也加了一条：定期审查任务日志，不能只看成功失败，还得看资源消耗趋势。
这几年干下来，我越来越觉得，凭证这个活儿，光懂技术不够。你得懂业务场景，知道什么时候并发会暴涨；你得懂现场操作，知道那些“规范”在执行层面会走样；你还得有那种“不放过任何一个异常”的较真劲儿。很多时候，真正的隐患就藏在那些大家习以为常的细节里。
说白了，就是别信什么“理论上没问题”，要信监控数据，信现场反馈，信那些让你不舒服的“小概率事件”。每一次故障，都是一次倒逼自己把流程、规范、代码打磨得更严丝合缝的机会。以后还是这个路子，继续跟这些“确定性”较劲。没啥捷径，就是多看、多问、多动手，把每个环节的坑都摸清楚，然后想办法填平它。
- 我们精彩推荐工作总结专题，静候访问专题：工作总结
