工作總結(jié)
發(fā)表時間：2026-04-12【全面】運(yùn)維總監(jiān)年度工作總結(jié)。
今年跟去年比，有一個變化我自己都覺得意外——去年半夜被叫醒，我先罵兩句娘再爬起來；今年被叫醒，第一反應(yīng)是“哪個環(huán)節(jié)又沒按規(guī)范走”。說白了，不是脾氣好了，是團(tuán)隊(duì)把該堵的漏洞堵得差不多了，剩下的才是真意外。
一、從“救火隊(duì)長”到“查火種的人”，中間踩了多少坑
去年上半年，我們生產(chǎn)環(huán)境平均每月4起P3級以上故障。最典型的一次，某業(yè)務(wù)系統(tǒng)凌晨2點(diǎn)大面積超時，我?guī)е鴥蓚€兄弟查了三個多小時，最后發(fā)現(xiàn)是半年前一個同事為了趕進(jìn)度，在Nginx配置里寫死了上游IP。后來那臺機(jī)器退役了，健康檢查根本沒覆蓋到。那天早上六點(diǎn)解決問題后，我一個人在工位上坐了十分鐘，心里特別窩囊——不是技術(shù)多難，是我們明明有變更規(guī)范，但執(zhí)行全靠自覺。
今年我干了一件讓團(tuán)隊(duì)一開始很不爽的事：所有變更必須帶“回退預(yù)案”和“影響半徑評估”，缺一項(xiàng)就不給上。有個老員工直接找我：“一個小補(bǔ)丁至于嗎？這要花半小時填單子。”我說至于。你懂的，運(yùn)維這行，小改動捅大簍子的例子還少嗎？我把去年的故障復(fù)盤數(shù)據(jù)貼出來：6起故障里4起是變更引起的，其中3起只需要一個簡單的回退步驟就能在5分鐘內(nèi)搞定，但因?yàn)闆]人提前想這一步，硬是拖了半小時以上。
具體怎么推的？我弄了個變更管理看板，每次變更前強(qiáng)制填三個字段：回退操作命令（必須是具體命令，不準(zhǔn)寫“回滾”兩個字）、影響范圍（精確到哪個接口、哪個數(shù)據(jù)表）、驗(yàn)證方法（怎么確認(rèn)改好了）。開始有人敷衍，寫“重啟服務(wù)”。我直接退單，附上我寫的標(biāo)準(zhǔn)模板。前兩周退了11次單，團(tuán)隊(duì)里有人私下說“這總監(jiān)事兒真多”。我沒吭聲，第三周開始，退單率降到2次。兩個月后，新人第一次提變更單，老員工主動攔住：“你回退方案寫清楚沒？別給總監(jiān)添堵。”
但說實(shí)話，這中間也有反復(fù)。9月份有一次，我們一個核心服務(wù)做擴(kuò)容，變更單填得漂漂亮亮，回退方案寫的是“停止新實(shí)例，恢復(fù)負(fù)載均衡配置”。結(jié)果真出問題時，發(fā)現(xiàn)回退腳本里漏了一條iptables規(guī)則，導(dǎo)致流量切不回去。那一次我們用了25分鐘才恢復(fù)，比預(yù)期多了15分鐘。復(fù)盤時我第一個檢討：預(yù)案驗(yàn)證機(jī)制有漏洞——只審核了文檔，沒審核腳本的可執(zhí)行性。后來加了一條硬杠杠：所有回退腳本必須在預(yù)發(fā)布環(huán)境跑通一遍，截圖附在變更單里。這玩意兒說起來簡單，干起來全是坑，但總比半夜炸了再現(xiàn)寫強(qiáng)。
二、團(tuán)隊(duì)能力不是培訓(xùn)出來的，是被故障逼出來的
去年我花了很多精力搞培訓(xùn)，講內(nèi)核參數(shù)調(diào)優(yōu)、講TCP擁塞控制，底下記得挺認(rèn)真，回頭遇到真實(shí)故障照樣抓瞎。今年我換了個路子：每個人輪流當(dāng)“值班架構(gòu)師”，一周內(nèi)所有變更和故障排查的第一責(zé)任人不是我，是他。我的角色從“拍板的人”變成“最后一道防線”。說實(shí)話，剛開始那一兩個月，我比自己干還累——得忍著不插嘴，得看著他走彎路，得在他實(shí)在搞不定的時候才伸手。
有個場景印象特別深。今年6月，數(shù)據(jù)庫連接池突然飆升，值班的是入職剛一年的小張。他按照我們沉淀的故障排查SOP，先看監(jiān)控、再看慢查詢、最后鎖定了某個業(yè)務(wù)SQL。但他不敢確認(rèn)，跑過來問我“能不能重啟應(yīng)用”。我沒給答案，反問他三個問題：重啟能解決根因嗎？會不會引發(fā)雪崩？業(yè)務(wù)方能不能接受這個窗口？他愣了幾秒，自己回去查連接狀態(tài)，最后定位到一個定時任務(wù)批量更新沒有加索引。那天晚上他主動加班把索引加上，第二天還寫了個文檔發(fā)給全團(tuán)隊(duì)。那次之后，他像換了個人，主動把數(shù)據(jù)庫設(shè)計(jì)規(guī)范翻了兩遍，還提出了三個改進(jìn)點(diǎn)。
但我也有判斷失誤的時候。8月份一次演練，我模擬了Redis集群主節(jié)點(diǎn)宕機(jī)，值班的是另一個同事。他按照SOP切了從節(jié)點(diǎn)，業(yè)務(wù)恢復(fù)用了4分鐘，指標(biāo)達(dá)標(biāo)。我當(dāng)時覺得沒問題，就讓他下班了。結(jié)果第二天早上真實(shí)故障發(fā)生了，同樣的場景，他用了15分鐘才恢復(fù)。后來我復(fù)盤發(fā)現(xiàn)，演練時我漏了一個關(guān)鍵變量——演練是在白天低峰期做的，真實(shí)故障發(fā)生在凌晨批量任務(wù)高峰期，從節(jié)點(diǎn)扛不住寫入壓力，他又要臨時擴(kuò)容。這件事讓我很慚愧：我設(shè)計(jì)的演練場景太“干凈”了，沒有把真實(shí)負(fù)載考慮進(jìn)去。從那以后，所有演練必須在生產(chǎn)流量的鏡像環(huán)境里做，并且要壓上峰值數(shù)據(jù)。
三、工藝標(biāo)準(zhǔn)和施工規(guī)范，是磨出來的，不是寫出來的
去年我們雖然有各種文檔，但執(zhí)行起來打折扣。比如服務(wù)器初始化標(biāo)準(zhǔn)寫的是“關(guān)閉不必要的端口”，但有人只關(guān)了常見的21、22、23，留了一堆像111、2049這樣的端口敞著。今年我把所有操作提煉成“工藝卡片”——每個動作必須有對應(yīng)的腳本或命令，不允許手工敲。誰再手工改配置，我就讓他把鍵盤吃了。這話我說過，也真的退回過兩次單。
拿設(shè)備維護(hù)來說，以前硬盤更換靠人工記序列號，出過一次換錯盤的事故——把A機(jī)器的盤拔了插到B機(jī)器上，數(shù)據(jù)全亂套。今年我們上了帶外管理系統(tǒng)，換盤之前必須掃碼錄入，系統(tǒng)自動比對槽位和序列號，不匹配直接報錯。這套流程跑通后，硬件故障平均修復(fù)時間從2小時降到40分鐘。有兄弟開玩笑說“現(xiàn)在換硬盤跟換樂高似的”，我說樂高插錯了還能拔，你插錯了數(shù)據(jù)就沒了，別開玩笑。
故障排除這塊，我強(qiáng)制要求每起故障都要輸出“五分鐘快報”和“兩周復(fù)盤”。快報只寫三樣：現(xiàn)象、根因、臨時方案，發(fā)到團(tuán)隊(duì)群里@所有人。復(fù)盤必須動代碼或配置，不允許寫“加強(qiáng)責(zé)任心”這種廢話。今年我們累計(jì)復(fù)盤了17起故障，其中12起都輸出了永久性修復(fù)——要么改了代碼，要么加了監(jiān)控，要么優(yōu)化了架構(gòu)。剩下的5起因業(yè)務(wù)邏輯太復(fù)雜，也至少把監(jiān)控告警補(bǔ)上了。舉個例子，有一次發(fā)現(xiàn)某個服務(wù)的日志量突然暴增，排查下來是一個循環(huán)里打了debug日志。復(fù)盤后，我們把所有日志級別在配置中心做了動態(tài)開關(guān)，并且給每個服務(wù)設(shè)置了日志量閾值告警。
四、跨部門扯皮這事，真是讓人深感無奈
- 【讀書筆記吧dsBJ1.com】新銳作者力作集合:
- 運(yùn)維工作總結(jié)?|?年度工作總結(jié)?|?物業(yè)年度工作總結(jié)?|?質(zhì)量年度工作總結(jié)?|?運(yùn)維年度工作總結(jié)?|?運(yùn)維年度工作總結(jié)
今年最讓我頭疼的不是技術(shù)問題，而是跨部門協(xié)調(diào)。有一次存儲設(shè)備擴(kuò)容，我們按標(biāo)準(zhǔn)流程提前三天提了變更申請，郵件也發(fā)了、周會也同步了。結(jié)果網(wǎng)絡(luò)組那邊沒看到，擴(kuò)容過程中出現(xiàn)路由環(huán)路，業(yè)務(wù)抖動了一刻鐘。事后復(fù)盤，網(wǎng)絡(luò)組的理由是“沒看到你們在群里@我”。這簡直令人難以置信——我們有正式的變更系統(tǒng)、有郵件通知、有周會同步，結(jié)果還是靠群里@才有用。
后來我牽頭搞了一個“變更握手”機(jī)制：所有依賴其他團(tuán)隊(duì)的變更，必須得到對方書面確認(rèn)（釘釘回復(fù)“確認(rèn)”就算），截圖附在變更單里。這個辦法土是土了點(diǎn)，但管用。今年第四季度，跨團(tuán)隊(duì)變更導(dǎo)致的故障降到了零。不過我也知道，這不是因?yàn)榇蠹遗浜隙雀吡耍俏野选安淮_認(rèn)就不給上”這條寫進(jìn)了變更系統(tǒng)的強(qiáng)制校驗(yàn)里。說白了，制度不如工具，工具不如自動化。
還有一次，開發(fā)團(tuán)隊(duì)非要在一個周四下午上線一個緊急功能，說“客戶等著要”。我看了變更內(nèi)容，涉及數(shù)據(jù)庫表結(jié)構(gòu)變更，回退方案不清晰。我直接拒了。開發(fā)經(jīng)理跑到我工位前拍了桌子：“你們運(yùn)維就是拖后腿的！”我沒跟他吵，拿出我們上半年的故障統(tǒng)計(jì)表，指給他看：“上兩次你們說的‘緊急變更’，一次把訂單表鎖了十分鐘，一次把索引刪錯了，都是周四下午。這周四我可以放你過，但下次故障復(fù)盤會上，你敢不敢當(dāng)著老板的面說‘是我要求強(qiáng)上的’？”他愣了一下，回去重新排期到周六凌晨。后來他私下跟我說，那天我說話挺沖，但理不虧。
五、幾個實(shí)實(shí)在在的數(shù)字和還沒填的坑
團(tuán)隊(duì)現(xiàn)在6個人，管著200多臺服務(wù)器、40多個微服務(wù)。今年做成的幾件事，我列一下：
- 部署頻率：從每周一次提到每天三次（別笑，我們這種傳統(tǒng)行業(yè)出身的，能到這一步已經(jīng)脫了層皮）。代價是回滾率從2%升到了5%，但每次回滾都在5分鐘內(nèi)完成，業(yè)務(wù)影響控制在分鐘級。
- 監(jiān)控覆蓋率：從70%提到95%，漏報率下降了八成。具體怎么做的？我把所有服務(wù)的健康檢查、業(yè)務(wù)指標(biāo)、資源指標(biāo)拆成了三張清單，每個服務(wù)一條條打勾。
- 文檔：從散落在各個Wiki的碎片變成了統(tǒng)一的結(jié)構(gòu)化知識庫。每個服務(wù)必須有：架構(gòu)圖、依賴關(guān)系、常見故障處理、變更歷史。
但我心里清楚，還有很多坑沒填。比如配置中心還在用老掉牙的SVN，每次改配置要提交代碼、走CI、重啟服務(wù)，效率低得要命。比如全鏈路追蹤只覆蓋了核心鏈路，邊緣服務(wù)出問題還是要靠猜。比如災(zāi)備切換演練一年只敢做一次——因?yàn)樯洗巫龅臅r候，切換腳本里有個路徑寫的是絕對路徑，換到備環(huán)境就找不到文件了，差點(diǎn)真的切不過去。這些明年必須啃，而且我已經(jīng)把優(yōu)先級排好了：一季度上新的配置中心，二季度擴(kuò)全鏈路追蹤，三季度再做兩次災(zāi)備演練。
- 我們精彩推薦工作總結(jié)專題，靜候訪問專題：工作總結(jié)
