工作總結
發表時間：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同步策略是每二十四小時對一次，他們那邊是每小時對一次。兩臺服務器時間漂移累積下來，差出八秒。后來我統一改成了每小時同步，還加了時間偏差告警，偏差超過一秒就發短信。這種低級錯誤，說到底還是前期聯調的時候想當然，沒把時間同步當成關鍵驗收項。
明年重點做兩件事。一是把故障自愈機制往深處做，目標是讓常見的硬盤故障和網絡閃斷能在三十秒內自動隔離，不用人工介入。目前已經在三臺存儲節點上跑了兩個月的試驗，自愈覆蓋率達到六成左右。二是把施工驗收的流程搬到平板上，現場拍照、打點、簽字直接進系統，省得事后補資料、扯皮。這兩件事都不高大上，但每一條都是從去年的坑里爬出來的教訓。
干我們這行，說白了就是跟不確定性和有限的預算較勁。系統越穩定，背后的人越不顯眼。但我覺得挺好，少半夜接電話就是最大的成功。
-
我們精彩推薦工作總結專題，靜候訪問專題：工作總結
