工作總結

發表時間：2026-04-12

2026年信息科年度工作總結。

年初機房那臺核心交換機高溫告警，我盯著監控屏上85℃的紅色數字，手邊是剛從庫房領出來的替換風扇模塊。這種事不能等——拔掉兩根電源線，等30秒放電，十字螺絲刀拆防塵蓋，排線方向記清楚，新風扇扣上去，力矩別太大。十五分鐘后溫度回到52℃，我補了一份《核心設備風扇更換標準化操作卡》，連防靜電手環的佩戴步驟都寫進去了。這是今年第6起二級故障，也是讓我下決心把“救火”改成“巡檢”的直接原因。

全年下來，三個硬指標：核心網絡可用率從99.82%提到99.97%，門診自助機日均使用量從320筆提到870筆，故障平均修復時間從47分鐘壓到18分鐘。數字背后全是坑，一個一個說。

先講網絡。去年每個季度都有兩三次全院卡頓，查到最后不是環路就是廣播風暴。我拉上科室兩個兄弟，連續兩個周末把42臺交換機的配置全部捋了一遍。發現問題：STP參數還是七年前的默認值，VLAN劃分純屬憑感覺，甚至有3臺交換機的登錄密碼是出廠默認。我畫了張物理拓撲圖，又畫了張邏輯拓撲圖，兩張疊一起——有三個匯聚節點的冗余鏈路根本沒啟用負載分擔，反而因為優先級配置錯誤，成了故障擴散的活靶子。

改配置本身不復雜，難在驗證。我用三臺舊設備搭了個模擬環境，每條改動先在模擬環境跑24小時。有次改了根橋優先級，模擬環境穩得很，上線后卻開始間歇性丟包。查了兩小時才發現，一臺接入交換機的固件版本太老，不支持新的STP模式。最后方案是分批次升級固件，配合端口隔離和BPDU保護。整個項目干了三周，我養成了一個習慣：每次變更前寫《變更影響評估表》，里面必須包含回退方案、影響范圍、驗證步驟。后來科室把這個表模板固定下來，成了標準動作。

再說自助服務終端。這東西是醫院的門面，護士長投訴過好幾次：“又卡紙了”“身份證讀不出來”“繳費成功票據沒出”。我蹲在門診大廳，上午高峰期站了兩個半天，發現80%的問題不是硬件故障，而是操作流程不連貫。比如熱敏打印紙裝反了會出白紙，但系統沒有自檢提示；身份證讀卡器偶爾接觸不良，重啟設備就能恢復，但護士不懂要去拔電源。

我把近三個月的167條反饋拉出來分類：硬件故障占34%，操作流程占52%，系統響應占14%。硬件里最煩的是熱敏打印機，切刀機構磨損導致切紙偏移。廠家一開始說是我們用的紙不行，我拍了顯微鏡下的切刀磨損照片，做了對照實驗——原廠紙和我們采購的紙磨損速度幾乎一樣。最后逼著廠家換了一種刀片材質，同時把驅動參數里的切紙延遲從200毫秒調到350毫秒，切刀壽命從兩萬次提到五萬次。操作流程類的問題，我錄了三個短視頻，每個不超過40秒，貼在設備側面二維碼上。護士掃一下就能看“換紙教程”和“重啟讀卡器”。另外在后臺加了遠程復位功能，護士在管理端點一下就能重置讀卡器驅動，不用再跑現場。

有一次中午在食堂吃飯，護士長順路跟我說：“最近自助機沒找我換過紙了?！本瓦@一句，比什么表揚信都管用。

系統故障響應機制的改造，源于七月份一個周五下午。HIS系統突然變慢，門診掛號排起長隊。我查了數據庫連接池、應用服務器負載、存儲IO，最后定位到一條慢SQL——藥房庫存統計的視圖沒有索引，加上當天藥品入庫量大，全表掃描把數據庫拖死了。加索引只用了三分鐘，但故障已經持續了四十分鐘。為什么排查這么久？因為我們缺乏有效的監控分層。

事后我重新設計了告警體系：把故障分為四級，每一級對應不同的響應流程和升級機制。同時建立了“故障復盤文檔庫”，每次事件都寫成案例，包含現象、排查路徑、根因、解決方案、預防措施?，F在庫里有23個案例。但有一件事我做得不好：今年有一次數據庫連接池參數被誤改，導致全院慢。排查時發現上次修改的記錄在某個聊天群里，沒進文檔。后來我強制要求所有變更必須同步到Confluence，并設置郵件知會全科。這是今年最大的教訓——文檔沉淀不及時，代價是重復踩坑。

述職報告之家（yS575.coM）近期爆火: