工作总结
发表时间：2026-04-192026年公检法监工作总结。
去年一年，手头管着七个监所的安防系统，加上日常设备维护和突发抢修，算下来出勤了三百二十多天。先交个底：全年处理各类工单四百一十七件，核心平台累计可用时长达到99.67%，比年初预设的98.5%目标高出一个多点。故障平均确认时间压缩到九分钟以内——这个数字我解释一下，是从监控告警弹出到我在现场或远程确认故障现象的时间，不含后续处置。说实话，能跑到这个数，全靠上半年那三次半夜被叫起来的经历。
第一次是三月，看守所的视频存储集群频繁告警“写入超时”。前两次我去看了，硬盘健康度正常，网络延迟也正常，日志里只有一条“index optimization started”的普通信息。第三次又报，我干脆搬了把椅子坐机柜旁边盯着。凌晨两点，系统自动触发索引优化，同时有二十几个通道在写数据，I/O util直接飙到98%。我赶紧查了一下调度策略，发现是数据库自带的维护任务跟存储进程抢资源。解决的法子不花哨：把索引优化的cron改到凌晨四点——那时候录像写入量最小，同时给存储进程的ionice优先级设成0（实时）。改完之后连续跑了一周，再没出现过超时。后来我顺手写了段监控脚本，但凡I/O util超过85%且持续时间超过三分钟，自动把非关键任务的nice值调高。这个补丁到现在还在跑。
再说说质量验收。去年我牵头修订了《监所安防系统施工工艺标准》里关于前端设备安装和线缆敷设的两个章节。老标准太虚，“线缆应固定牢固”这种话等于没说。新标准我一条条写死了：每米不少于两个固定点，转弯半径不小于线径的六倍，屏蔽层接地电阻实测不能高于1欧姆。有人嫌我较真，但干这行久了就知道，三五年后系统稳不稳，全藏在这些细节里。举个例子：六月验收一个新监区，施工方把网线和220V电源线绑在同一根扎带上走了四十多米，中间还没加屏蔽层。我用福禄克测了一下，近端串扰超了标准快三倍。当场要求返工，对方项目经理不服，说“以前都这么干”。我没跟他吵，翻开新标准第3.2.7条，截了图发到项目群里。返工之后重测，误码率从千分之三降到万分之一以下。你说这东西玄乎吗？不玄乎，就是规矩没立起来。
设备维护这块最磨人。现有的一批DVR用了快六年，今年硬盘故障率飙到13.2%，有些主板上的电容鼓了包，看着就悬。让人无奈的是，申请更换的预算在采购科压了三个月，理由一直是“走流程”。那段时间我每天上班第一件事就是跑机房，用脚本把所有设备的S.M.A.R.T.数据扫一遍，健康度低于阈值的提前标出来。这脚本不复杂，就是每天凌晨跑一次，把预测寿命少于三十天的硬盘发邮件到团队群里。虽然解决不了根本问题，但至少让我们能在故障发生前二十四小时知道哪块盘要挂，把半夜抢修变成了白天计划性更换。这招后来隔壁分局的兄弟学去了，也算没白忙。
讲个具体的突发。八月某个周六下午，指挥中心大屏突然黑了三分之一。我骑车十五分钟赶到现场，发现是解码矩阵的一块主控板烧了，闻着有股糊味。翻备件库，同型号的板子上一批刚用完，新采购要两周才到。当时调阅系统全靠这块板子往外推画面，你懂的，关键时刻最怕这种事。我琢磨了十分钟，想了个歪招：绕开故障的解码矩阵，直接在流媒体服务器上改配置，把H.264码流用ffmpeg软解成低分辨率图像，推到几台备用监视器上。虽然从1080p掉到了720p，但关键画面一个没丢。这套土办法撑了十一天，直到新板卡到货。事后我把整个处置过程捋了一遍，写了两页纸的速查表，贴在机柜侧面，标题就叫《解码矩阵挂了怎么办》。说实话，硬件冗余不能只靠堆设备，得有应用层的降级方案。
说到短板，最让我堵心的是跨系统联调那次。检察院来调取一段历史录像，发现我们平台输出的时间戳跟他们的电子卷宗差了整整八秒。八秒啊，在法庭上这就是硬伤。排查了两天才找到原因：我们的NTP同步策略是每二十四小时对一次，他们那边是每小时对一次。两台服务器时间漂移累积下来，差出八秒。后来我统一改成了每小时同步，还加了时间偏差告警，偏差超过一秒就发短信。这种低级错误，说到底还是前期联调的时候想当然，没把时间同步当成关键验收项。
明年重点做两件事。一是把故障自愈机制往深处做，目标是让常见的硬盘故障和网络闪断能在三十秒内自动隔离，不用人工介入。目前已经在三台存储节点上跑了两个月的试验，自愈覆盖率达到六成左右。二是把施工验收的流程搬到平板上，现场拍照、打点、签字直接进系统，省得事后补资料、扯皮。这两件事都不高大上，但每一条都是从去年的坑里爬出来的教训。
干我们这行，说白了就是跟不确定性和有限的预算较劲。系统越稳定，背后的人越不显眼。但我觉得挺好，少半夜接电话就是最大的成功。
-
我们精彩推荐工作总结专题，静候访问专题：工作总结
