工作總結
發表時間：2026-04-25IT工程技術員工作總結[2026免費]。
干了八年技術員，去年開始兼項目技術經理。這篇東西不是給領導看的匯報，是給自己和團隊捋一捋這些年踩過的坑、補過的墻。不講大道理，只講真問題怎么摸出來的。
一、一個讓我記了三年的故障
去年夏天，某數據中心項目驗收前夜，核心交換機出現間歇性丟包。客戶第二天早上八點來復驗，現場施工隊十幾個小伙子盯著我。機房空調壞了，溫度計指到42度，汗順著安全帽帶子往下淌。
我先查物理層：光模塊收發光功率正常（-9.2dBm，在華為S5720的閾值范圍內），網線通斷沒問題，端口CRC校驗錯誤計數為零。接著看生成樹協議狀態，發現某臺接入交換機的G0/0/24端口每三分鐘up/down一次，日志里mac地址漂移告警刷屏。
說實話，當時腦子有點懵。這種間歇性故障最磨人。我強迫自己按OSI模型一層層剝：物理層正常，數據鏈路層有flapping，那大概率是環路或者IP沖突。抓包！用Wireshark在核心交換機鏡像口上抓了五分鐘，過濾條件設成arp or icmp，結果發現一個攝像頭的MAC地址（00:11:22:33:44:55）同時在兩個端口出現，并且這個MAC對應的IP竟然是核心網關192.168.1.1。
拔掉那根網線，網絡立刻恢復。施工隊一個新人昨天偷偷把攝像頭接上調試，沒走變更流程，又把IP設成了網關地址。從發現問題到定位，用了兩小時四十分鐘。客戶來的時候網絡已經穩定跑了四小時，我沒提故障的事，驗收通過了。
但這事我記了三年。后來我讓團隊做三件事：第一，建立IP分配電子臺賬，每申請一個IP必須項目經理簽字；第二，每個機柜側面貼一張A4紙，寫著“接入新設備前，必須確認IP不沖突、VLAN正確、端口無環路”；第三，所有施工隊進場前，必須做一次網絡基礎培訓，重點講ARP原理和IP沖突的危害。你懂的，有時候就是這種基礎問題，能把整個項目搞黃。
二、規范落地，不是背條文，是做卡片
GB50348、GB50174這些標準，技術員都頭疼。我花了兩個月時間，把公司常用到的二十幾條規范翻譯成現場工人能看懂的東西。比如光纖彎曲半徑，標準說“不應小于線纜外徑的10倍”，我們在現場做了個模板——用一根內徑5厘米的PVC管切一半，施工時線纜必須能在這個半圓管里自由通過才算合格。這法子土，但管用。去年一年，我們綜合布線驗收一次性通過率從67%提到了89%。
設備維護也有教訓。一次機房擴容，新來的技術員沒戴防靜電手環就直接拔了板卡，結果兩塊萬兆網卡燒了，損失一萬多。我定的規矩：開柜操作前，必須兩人在場，一個人操作，另一個人喊“靜電已釋放、接地線已夾好”才能動手。誰忘了喊，當月績效扣一分。半年下來，沒人再犯。
三、團隊成長，全靠拉出來真刀真槍練
我不喜歡做PPT培訓。我的方法是，每次出故障，把團隊里所有人叫到現場，我一邊查一邊講思路。有一次存儲陣列一塊盤亮黃燈，RAID5陣列開始重構。我把三個年輕技術員叫到機柜前，讓他們看控制器上的重構進度條，然后問：“如果現在再壞一塊盤，數據能不能恢復？熱備盤什么時候頂上？”他們答不上來，我就現場演示用命令行查RAID狀態，算重構時間——按240GB/小時的速率，2TB的盤需要8.3小時。那之后，他們自己主動去學了RAID級別原理和rebuild計算公式。
我們還有一個規矩：每個處理過的故障，責任人必須寫復盤文檔。格式很簡單：現象、排查步驟（按時間順序）、根因、修復動作、預防措施。到今年3月，累積了63份復盤記錄，存在一個共享文件夾里。新來的技術員遇到類似問題，先翻這個文件夾，80%能找到參考。我不是搞什么知識管理，就是覺得同樣的問題如果被問三遍，那就是我帶隊失敗。
四、驗收不只看結果，還要看過程抓痕
做項目驗收，很多人只看系統通不通。我吃過虧。前年一個樓宇自控項目，施工方只抽測了10%的點位，我就簽字了。結果上線后，空調VAV箱的閥門開度反饋有3個點位偏差超過5%，導致部分房間溫度失控。甲方投訴到老板那，我寫了檢討。
現在我的做法是：所有模擬量輸入輸出點位必須100%測試，而且測試記錄里要附上現場照片和儀表讀數。光纖熔接損耗值必須≤0.3dB（單模），超過的重熔，并記錄重熔次數。UPS電池組每節電池的單體電壓、內阻全部測一遍，不合格的直接換。去年一個項目，我堅持全測，發現四個傳感器的4-20mA信號在低端有非線性漂移，廠家承認是批次問題，重新校準后才通過。如果當時只抽測10%，這些隱患根本發現不了。
五、三個讓我自己脫層皮的認知轉變
第一個轉變：從“敲命令”到“懂原理”。剛入行時覺得會配置就行，直到有一次改了一臺交換機的IP地址，忘了改DHCP中繼的指向，整個子網癱瘓了半小時。那天晚上我翻《TCP/IP詳解》到凌晨三點。現在我要求團隊每個人必須能畫出二層交換和三層路由的數據流圖，不然不許獨立上架設備。
第二個轉變：從“死要面子”到“主動求援”。以前覺得找廠家支持顯得自己沒本事。有一次精密空調高壓報警，我折騰了一下午沒搞定，最后打給廠家工程師，對方問了三個參數就判斷出是冷凝器風扇電容壞了。十分鐘換好，空調恢復。從那以后，我手機里存了所有主要供應商的技術支持電話，遇到拿不準的先打電話，別硬扛。
第三個轉變：從“滅火”到“防火”。現在我做巡檢，不看報警燈，看趨勢。比如華為存儲的SSD壽命，我用命令行收集smartctl -a /dev/sda里的Media_Wearout_Indicator，這個值從100降到90，我就安排備盤。還有UPS電池，每個月測一次內阻，如果同一組電池里最大內阻差超過30%，就必須整組更換。去年一年，用這種預判方式，我們提前更換了7塊有隱患的硬盤和12節電池，避免了至少三次夜間緊急搶修。
六、說點實在的
干我們這行，別指望不出事，但要爭取出事不慌亂。我電腦里有個記事本，記著每個項目交工后半年內的所有故障記錄。翻看這些記錄，發現一半以上的問題都是同一個原因——變更沒走流程、測試不充分、或者直接就是忘了。所以我們團隊現在有個習慣：每次動設備之前，先在群里發一條“準備操作XX設備，如有異議請10分鐘內提出”。沒人反對就開干，干完立刻恢復確認。這個習慣救了我們三次。DSBJ1.com
- 需要更多的工作總結網內容，請訪問至：工作總結
