1. 筆試整體情況與備考思路1.1 從筆試安排看網易的考察邏輯先說結論網易2023校招的運維工程師筆試正式第二批整體風格偏重基礎扎實度和問題排查思路而不是單純考你背了多少命令。我是在正式第二批參加考試的整個筆試大約90分鐘題型覆蓋單選、多選、填空、簡答和兩道編程題內容橫跨Linux系統、網絡原理、MySQL、Shell/Python腳本、監控告警和故障場景分析。和互聯網大廠其他崗位的校招筆試比起來運維工程師的卷子風格很務實——沒有太多腦筋急轉彎更多是模擬你入職后真實會遇到的場景。比如給你一段線上日志問你怎么定位問題給你一個CPU飆升的告警問你的處理思路給你一張表問你慢查詢該怎么優化。這些題目如果只是考前突擊背一背很容易翻車因為它考察的是你平時積累的排障嗅覺。我自己備考時把這套卷子的考點拆成了三大塊Linux與操作系統基礎、網絡與數據庫原理、腳本與自動化能力。后面的復盤也基本按這個邏輯展開。對于目標是大廠運維崗的同學來說這三塊是繞不開的基本盤無論筆試還是面試都會反復出現。1.2 題型分布與分值策略我記得很清楚整套題里選擇題占了大概45%的分值簡答和場景題占35%編程題占20%。這個比例其實透露了一個關鍵信息大廠運維筆試不只是看你知不知道更看你能不能把知道的講清楚。選擇題還能蒙一蒙簡答題如果思路混亂閱卷人一眼就能看出來你的真實水平。我的做題策略是選擇題控制在25分鐘內解決拿不準的先標記跳過不戀戰簡答和場景題留足50分鐘因為這類題要寫清楚排查思路和命令非常耗費時間最后15分鐘做兩道編程題優先保證第一道的完整性和正確性。這個節奏幫我穩住了整體得分第一道編程題得了滿分第二道只寫了一半但前面簡答題答得比較充分最終順利進入面試環節。注意筆試里最忌諱的是在選擇題上反復糾結。一道題兩分鐘做不出來直接憑第一感覺選一個并標記后面有時間再回來看。運維筆試的簡答和場景題往往一道就頂好幾道選擇題的分值絕對不能在前面丟了西瓜撿芝麻。2. 基礎考點復盤Linux與操作系統2.1 命令類題目不能只會背要懂原理Linux命令是運維筆試的絕對主力網易這次考了不少比較基礎的命令題比如查看端口占用、查看進程、查找大文件、查看系統負載但真正的區分點在于你知不知道為什么用這個參數。比如有一道題問如何查看某個進程監聽的端口表面上答案是ss -lntp或者netstat -lntp | grep 進程名但如果你能說明白ss比netstat快是因為它直接讀取內核的socket哈希表而不是遍歷/proc下的文件這道題的高分就屬于你了。還有一道關于find的命令題要求找出/var/log下7天前修改且大于100MB的日志文件正確命令是find /var/log -type f -mtime 7 -size 100M。這里有幾個容易被忽略的點-type f必須寫否則會匹配到目錄-mtime 7表示修改時間超過7天-mtime 7表示正好第7天這兩個語義差別經常被搞混-size 100M的M必須是大寫小寫m代表的是512字節塊。我給準備筆試的同學一個建議每個命令至少想清楚三個問題——這個命令從哪里讀取數據、常用參數的含義、它和同類命令相比的優劣。以top為例說明%CPU的計算方式是單核百分比還是整體百分比說明load average的三個數分別代表什么說明在容器環境里top看到的數據和宿主機有什么差異。能把這些問題串起來命令題基本不會丟分。2.2 進程與內存一道題的完整推演這次筆試有一道讓我印象深刻的關于進程狀態和僵尸進程的題。題干大意是線上機器出現大量僵尸進程問怎么排查和解決。這道題我試著按實際排障的思路來寫第一步用top或ps aux查看進程狀態確認僵尸進程數量。ps aux里 STAT 列為 Z 的進程就是僵尸進程這個狀態表示進程已經終止但父進程還沒有調用wait()回收它的退出狀態。第二步定位僵尸進程的父進程用ps -o ppid -p 僵尸進程PID查父進程PID或者直接看/proc/僵尸進程PID/status里的 PPid 字段。第三步分析父進程為什么沒有回收子進程。這是整道題的核心也是在實際工作中最需要花時間的地方。可能是父進程本身出現了阻塞、異常也可能是父進程的代碼邏輯有問題沒有正確調用wait()。筆試時我給出了兩個方向的處理如果父進程還能正常操作優先重啟或修復它讓它完成對子進程的回收如果父進程已經不可控只能選擇重啟父進程甚至重啟機器。kill -9殺掉僵尸進程本身是沒用的因為它已經死了需要處理的是它的父進程。第四步預判后續的系統影響。大量僵尸進程會占滿進程表項導致新進程無法創建表現為 fork: Cannot allocate memory 錯誤。我當時補充了一個排查命令sysctl kernel.pid_max查看系統最大PID數量以及ps -eLf | wc -l看當前進程線程總數。這類題目最能拉開差距的地方就在第四步大多數人只寫了kill僵尸進程但真正有經驗的運維會知道僵尸進程是殺不掉的必須處理父進程并且在處理前先評估影響面。這種多想一層的習慣建議在備考階段就有意識地訓練。3. 網絡與數據庫運維的任督二脈3.1 TCP三次握手與TIME_WAIT的實戰理解網絡基礎在運維筆試里從來都不會缺席。今年網易有道這批題目里三次握手和四次揮手屬于必考內容但考察方式比較靈活不是讓你默寫狀態變化而是給場景讓你判斷問題。比如有一道題問線上出現大量TIME_WAIT連接可能是什么原因怎么處理。我的答題思路是先解釋TIME_WAIT的產生機制主動關閉連接的一方在收到對方的FIN后進入TIME_WAIT狀態需要等待2MSL最大報文段生存時間才能徹底關閉主要是為了保證最后一個ACK能夠到達對方、以及讓舊連接中的遲到報文自然消亡。所以出現大量TIME_WAIT說明這臺機器上主動關閉了大量連接常見于高并發的短連接場景比如Nginx代理、Redis客戶端頻繁建連。然后是解決方案。我在筆試中寫了三個層級第一層是業務優化讓客戶端盡量使用連接池復用連接減少頻繁建連這是最治本的方式第二層是內核參數調優比如net.ipv4.tcp_tw_reuse僅在客戶端場景安全配合tcp_timestamps、net.ipv4.ip_local_port_range擴大端口范圍來緩解端口耗盡第三層是在架構層面引入LVS、HAProxy這類負載均衡組件把連接管理下沉到專門的組件里。同時我強調了tcp_tw_recycle這個參數不建議開啟因為它會在NAT場景下導致丟包這類我知道這個參數存在但知道它有哪些坑的表達通常能給閱卷人留下更好的印象。3.2 MySQL索引與慢查詢優化數據庫題是運維筆試的另一座大山。有道這批考了一道典型的慢查詢優化題給出一張訂單表order_info其中包含user_id、order_status、create_time等字段問針對某個高頻查詢語句如何建立索引并解釋索引失效的場景。我在回答中首先強調了聯合索引的最左前綴原則。針對高頻查詢SELECT * FROM order_info WHERE user_id ? AND order_status ? ORDER BY create_time DESC我會建議建立(user_id, order_status, create_time)的聯合索引這樣user_id用于等值匹配order_status用于等值匹配create_time用于排序可以直接覆蓋索引進行排序避免filesort。如果只建立(user_id)單列索引order_status仍然可以過濾但ORDER BY create_time就可能觸發文件排序性能差一個量級。接著我舉了幾個索引失效的反例對索引字段使用函數運算比如WHERE DATE(create_time) 2023-09-01會導致索引失效隱式類型轉換也會失效比如user_id是 varchar 類型卻用整數去查最左前綴原則被打破時比如跳過第一個字段直接查order_status聯合索引就無法發揮作用。這道題的加分點在于我補充了一個慢查詢排查的完整閉環先用SHOW FULL PROCESSLIST抓當前運行的慢SQL再開啟慢查詢日志slow_query_log和long_query_time用EXPLAIN分析執行計劃重點關注type、key、rows三個字段。type如果是ALL或index說明走了全表或全索引掃描大概率需要優化rows預估掃描行數遠超實際返回行數時往往是索引選擇不當。把排查方法論寫進答案比單點背命令更有說服力。4. 腳本與自動化筆試里的送分題怎么拿穩4.1 Shell腳本真題拆解這次筆試的兩道編程題里有一道Shell題給定一個Nginx訪問日志文件access.log每行格式為IP - - [時間] 請求方法 路徑 協議 狀態碼 響應字節數要求統計訪問次數最多的前10個IP并輸出對應次數。這道題在運維筆試里屬于老朋友級別但每年都有人因為細節丟分。我的標準答案是組合使用awk、sort、uniq和headawk {print $1} access.log | sort | uniq -c | sort -rn | head -10很多同學會在這道題上忽略一個關鍵問題uniq只能去重連續行所以必須先sort再uniq -c否則統計的數字完全是錯的。另一個容易失誤的點是sort -rn里的-n必須寫如果不寫-nsort -r會按照字典序排列結果就是 9 排在 89 前面統計排名完全亂掉。我在這道題的回答里額外寫清楚了sort的內存開銷問題當日志文件達到幾個GB時sort會把所有內容讀入內存和臨時文件建議用sort -S 1G限制內存使用或者用awk的關聯數組先做聚合再對聚合結果排序。例如awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10這個方案在超大日志文件下更穩因為它先聚合再排序排序的數據量只有IP數量級而不是日志行數。我在筆試時把兩種方案都寫了出來并解釋了各自的適用場景這種不僅會寫還知道在什么場景下選哪個的表達方式更容易拿高分。4.2 Python與自動化思維的考察第二道編程題是Python題題目大意是有一個進程列表每個進程包含PID、PPID和進程名給定一個PID要求找出該進程及其所有子孫進程的PID集合。這本質上是一道樹的遍歷題要求熟悉基本的遞歸或棧操作。我的解法是先用字典構建PPID - [子進程列表]的映射然后用深度優先或廣度優先遍歷收集所有后代def get_all_subprocesses(processes, target_pid): children {} for pid, ppid in processes: children.setdefault(ppid, []).append(pid) result [target_pid] stack [target_pid] while stack: current stack.pop() for child in children.get(current, []): result.append(child) stack.append(child) return result這道題考察的其實不只是Python語法而是自動化腳本能力。運維日常要寫大量腳本來處理日志、巡檢服務器、批量執行命令所以大廠筆試里Python題通常圍繞列表處理、字典操作、文件讀寫、簡單的數據結構應用這幾個方向。備考時不需要刷算法競賽題把常見場景的腳本練熟就夠了。關于自動化思維筆試里的場景題也順手考察了。比如有一道問如何給100臺服務器批量執行磁盤檢查命令除了寫循環腳本之外我還提到了配置管理工具的思路比如使用Ansible的ansible all -m shell -a df -h或者用pssh這類批量執行工具。雖然這超出了筆試的編程題范圍但表現了你對效率工具的敏感度。5. 故障排查與場景題高分與低分的分水嶺5.1 CPU飆高的排查鏈路場景題是運維筆試最貼近真實工作、也最考驗綜合能力的部分。今年有道這批有一道題是某服務報警CPU使用率持續高于90%你如何排查。我在筆試中按照一個標準排障閉環來寫后來復盤下來這類題的答題邏輯其實是完全可以套用的。我的思路第一步是確認現象。先用top或htop查看整體負載和CPU占用最高的進程PID確認到底是用戶態CPU高還是內核態CPU高。再用top -Hp PID查看該進程內線程級別的CPU消耗找到具體是哪個線程在消耗CPU。第二步是抓取現場。使用pidstat -t -p PID 1持續觀察線程CPU變化再用jstackJava應用或gdbC/C應用導出線程棧把耗CPU最高的線程ID轉換為十六進制在線程棧里搜索對應的線程名。如果應用不支持這些工具可以臨時用perf top或perf record -g -p PID采集熱點函數。第三步是分析原因。CPU飆升通常有幾類原因代碼死循環或長事務、頻繁GCJava應用、大量正則匹配、線程爭搶鎖導致自旋。我在筆試里特別強調了不能看到CPU高就立刻重啟服務那只是掩蓋問題。要把線程棧保存下來結合最近的發布記錄判斷是不是新代碼引入了問題必要時保留現場、回滾版本。第四步是臨時緩解與根因處理并舉。臨時緩解是擴容或切流把故障節點從負載均衡摘除根因處理是定位到具體代碼邏輯。整個排查鏈路寫下來閱卷人一眼就能看出你有沒有真實排障經驗。5.2 磁盤滿了的正確處理姿勢磁盤空間不足是運維最常遇到的故障之一筆試里也考到了。題面是某臺服務器根分區使用率100%可能導致服務異常你如何處理。這道題我原本以為大家都會答但實際筆試復盤時發現很多人漏掉了關鍵步驟。最關鍵的一個點是先定位是什么文件占滿了磁盤而不是直接刪文件。我用df -h確認文件系統使用率用du -sh /* 2/dev/null | sort -rh | head -10逐層定位大目錄或者用ncdu這種交互式工具快速找到大文件。但這里有個隱蔽的坑如果某個大文件已經被進程打開并刪除du是看不到它的磁盤空間卻仍然被占用。需要用lsof | grep deleted找出被刪除但仍被進程持有的文件句柄然后重啟相關進程或釋放句柄空間才能真正釋放。另一個需要留意的點是inode耗盡。即使df -h顯示還有空間如果df -i顯示inode使用率100%同樣無法創建新文件因為小文件太多了。我遇到過好幾次這種場景所以筆試里我也把這條寫了進去。這題的作答思路體現了運維的一個核心原則先搞清楚狀況再動手處理。處理動作本身不難難的是在緊急情況下保持冷靜、按步驟排查。筆試里能把這一層邏輯寫出來分數不會低。5.3 業務連續性場景題的答題模板有道這批的簡答題里還有一類關于業務連續性的題目大致是數據庫主庫宕機了怎么恢復服務或服務出現大面積超時如何應對。這類場景題看似沒有標準答案但如果答得有條理反而很容易拿高分。我總結了一個四步模板。第一步評估影響范圍。確認是單機故障、單機房故障還是全局故障通過監控系統查看錯誤率、超時率、告警范圍盡快判斷故障邊界。第二步止損優先。如果數據庫主庫宕機且有高可用架構優先觸發主從切換如果是應用層故障考慮重啟集群或回滾最近發布如果是依賴的外部服務故障評估是否啟用降級方案或限流。止損的目標是先把影響面控制住而不是立刻找到根因。第三步保留現場與排查根因。在止損的同時保存日志、線程棧、監控截圖方便后續定位根因。常見根因包括慢SQL打爆數據庫、緩存雪崩打垮下游、配置變更引入錯誤、流量突增超過容量水位等。第四步復盤與治理。恢復服務之后要輸出故障報告核心內容包括故障時間線、根因分析、處理過程、改進項和后續計劃。筆試里寫出這一步會很加分因為很多新人只關注怎么修忽略了故障之后的總結沉淀才是運維工作最重要的部分。6. 筆試現場的踩坑與備考建議6.1 我在筆試中踩過的三個坑第一別在選擇題上做學術探討。有一道Linux命令題我在兩個選項之間糾結了很久后來發現題目本身是在問最常用/最便捷而不是唯一正確我在一道兩分的題上浪費了七八分鐘導致后面簡答題時間緊張。復盤下來做選擇題時應該按最佳實踐去選擇而不是鉆牛角尖去論證某種極端場景下另一個選項也成立。第二簡答題一定要寫命令和關鍵參數不能只描述思路。比如問如何排查內存泄漏如果你只寫用工具看內存占用找到增長最快的進程這種朦朧的表述很難拿分。但如果你直接把free -m、top、pidstat -r、pmap -x PID這串工具鏈寫出來并解釋如何對比內存增長曲線閱卷人立刻知道你確實動手排查過問題。第三編程題如果時間不夠先寫偽代碼和注釋也有分。我第二道Python題其實沒完全寫完但我把構建子進程列表的核心邏輯用注釋寫了出來最后代碼只差最后一層遍歷沒寫完但思路已經清晰呈現勉強拿到了部分分數。血淚教訓是筆試時就算代碼寫不完也要把思路和關鍵步驟展示出來。6.2 時間分配與心態管理再展開說一下時間分配。90分鐘的筆試我建議按10分鐘選擇題 15分鐘填空題 40分鐘簡答/場景題 20分鐘編程題 5分鐘檢查來分配。但這不是固定的因為每張卷子的題型分布可能會有調整。最重要的原則是簡答和場景題不可壓縮。編程題做不出來最多丟20分的部分分數但簡答和場景題如果寫得潦草丟掉的可能就是40%以上的分數。心態方面運維筆試的題目往往偏工程化沒有標準答案的題目占相當比例所以在考場上遇到這題我沒背過的情況不要慌。職場上的運維本來就是持續面對未知問題的崗位筆試有時候考察的就是你在不確定環境下組織思路、輸出方案的能力。按發現問題 - 定位問題 - 止損 - 根因分析 - 預防的框架答題即使無法答出完美答案也能保證基本盤。6.3 從這次筆試看大廠運維的新要求最后聊聊我考完這套題之后對運維崗位的一些新認識。以前提到運維很多人第一反應是會敲Linux命令、會看監控、會重啟服務但近兩年大廠運維筆試明顯在往開發能力 架構思維 數據敏感度的方向傾斜。這次網易的筆試里編程題占了一定比例場景題也需要你具備系統設計的感覺。比如有一道關于監控系統設計的問題問如果讓你為一個高并發服務設計監控指標你會關注哪些這就不是單純背監控工具能搞定的需要你理解QPS、RT、錯誤率、可用性、飽和度這些核心指標之間的關系。類似的傾向在互聯網大廠運維筆試里越來越明顯運維不再是后臺的輔助角色而是需要懂業務、懂架構、懂自動化的專項工程師。備考運維的同學建議在扎實掌握Linux、網絡、數據庫的基礎上把Python或Go學好了解至少一種配置管理工具理解CI/CD、容器化和監控鏈路。這些內容在這次筆試里直接或間接都有涉及。至少從網易這輪的題目來看懂開發的運維確實比只懂命令的運維要吃香得多。我在實際準備和參加這場筆試過程中最大的體會是運維筆試真的不是靠考前突擊就能搞定的它更像一面鏡子照出你平時積累的厚度。命令可以臨時背但排查思路、腳本能力和對系統原理的理解需要長期實踐才能沉淀下來。如果你正在準備運維校招不妨從今天開始每天花半小時讀一份真實故障記錄、寫一個小腳本、理清一個系統原理堅持一兩個月你會明顯感覺到自己和一個月前的差距。 網易2023運維筆試復盤：Linux、MySQL與故障排查全解析
1. 筆試整體情況與備考思路1.1 從筆試安排看網易的考察邏輯先說結論網易2023校招的運維工程師筆試正式第二批整體風格偏重基礎扎實度和問題排查思路而不是單純考你背了多少命令。我是在正式第二批參加考試的整個筆試大約90分鐘題型覆蓋單選、多選、填空、簡答和兩道編程題內容橫跨Linux系統、網絡原理、MySQL、Shell/Python腳本、監控告警和故障場景分析。和互聯網大廠其他崗位的校招筆試比起來運維工程師的卷子風格很務實——沒有太多腦筋急轉彎更多是模擬你入職后真實會遇到的場景。比如給你一段線上日志問你怎么定位問題給你一個CPU飆升的告警問你的處理思路給你一張表問你慢查詢該怎么優化。這些題目如果只是考前突擊背一背很容易翻車因為它考察的是你平時積累的排障嗅覺。我自己備考時把這套卷子的考點拆成了三大塊Linux與操作系統基礎、網絡與數據庫原理、腳本與自動化能力。后面的復盤也基本按這個邏輯展開。對于目標是大廠運維崗的同學來說這三塊是繞不開的基本盤無論筆試還是面試都會反復出現。1.2 題型分布與分值策略我記得很清楚整套題里選擇題占了大概45%的分值簡答和場景題占35%編程題占20%。這個比例其實透露了一個關鍵信息大廠運維筆試不只是看你知不知道更看你能不能把知道的講清楚。選擇題還能蒙一蒙簡答題如果思路混亂閱卷人一眼就能看出來你的真實水平。我的做題策略是選擇題控制在25分鐘內解決拿不準的先標記跳過不戀戰簡答和場景題留足50分鐘因為這類題要寫清楚排查思路和命令非常耗費時間最后15分鐘做兩道編程題優先保證第一道的完整性和正確性。這個節奏幫我穩住了整體得分第一道編程題得了滿分第二道只寫了一半但前面簡答題答得比較充分最終順利進入面試環節。注意筆試里最忌諱的是在選擇題上反復糾結。一道題兩分鐘做不出來直接憑第一感覺選一個并標記后面有時間再回來看。運維筆試的簡答和場景題往往一道就頂好幾道選擇題的分值絕對不能在前面丟了西瓜撿芝麻。2. 基礎考點復盤Linux與操作系統2.1 命令類題目不能只會背要懂原理Linux命令是運維筆試的絕對主力網易這次考了不少比較基礎的命令題比如查看端口占用、查看進程、查找大文件、查看系統負載但真正的區分點在于你知不知道為什么用這個參數。比如有一道題問如何查看某個進程監聽的端口表面上答案是ss -lntp或者netstat -lntp | grep 進程名但如果你能說明白ss比netstat快是因為它直接讀取內核的socket哈希表而不是遍歷/proc下的文件這道題的高分就屬于你了。還有一道關于find的命令題要求找出/var/log下7天前修改且大于100MB的日志文件正確命令是find /var/log -type f -mtime 7 -size 100M。這里有幾個容易被忽略的點-type f必須寫否則會匹配到目錄-mtime 7表示修改時間超過7天-mtime 7表示正好第7天這兩個語義差別經常被搞混-size 100M的M必須是大寫小寫m代表的是512字節塊。我給準備筆試的同學一個建議每個命令至少想清楚三個問題——這個命令從哪里讀取數據、常用參數的含義、它和同類命令相比的優劣。以top為例說明%CPU的計算方式是單核百分比還是整體百分比說明load average的三個數分別代表什么說明在容器環境里top看到的數據和宿主機有什么差異。能把這些問題串起來命令題基本不會丟分。2.2 進程與內存一道題的完整推演這次筆試有一道讓我印象深刻的關于進程狀態和僵尸進程的題。題干大意是線上機器出現大量僵尸進程問怎么排查和解決。這道題我試著按實際排障的思路來寫第一步用top或ps aux查看進程狀態確認僵尸進程數量。ps aux里 STAT 列為 Z 的進程就是僵尸進程這個狀態表示進程已經終止但父進程還沒有調用wait()回收它的退出狀態。第二步定位僵尸進程的父進程用ps -o ppid -p 僵尸進程PID查父進程PID或者直接看/proc/僵尸進程PID/status里的 PPid 字段。第三步分析父進程為什么沒有回收子進程。這是整道題的核心也是在實際工作中最需要花時間的地方。可能是父進程本身出現了阻塞、異常也可能是父進程的代碼邏輯有問題沒有正確調用wait()。筆試時我給出了兩個方向的處理如果父進程還能正常操作優先重啟或修復它讓它完成對子進程的回收如果父進程已經不可控只能選擇重啟父進程甚至重啟機器。kill -9殺掉僵尸進程本身是沒用的因為它已經死了需要處理的是它的父進程。第四步預判后續的系統影響。大量僵尸進程會占滿進程表項導致新進程無法創建表現為 fork: Cannot allocate memory 錯誤。我當時補充了一個排查命令sysctl kernel.pid_max查看系統最大PID數量以及ps -eLf | wc -l看當前進程線程總數。這類題目最能拉開差距的地方就在第四步大多數人只寫了kill僵尸進程但真正有經驗的運維會知道僵尸進程是殺不掉的必須處理父進程并且在處理前先評估影響面。這種多想一層的習慣建議在備考階段就有意識地訓練。3. 網絡與數據庫運維的任督二脈3.1 TCP三次握手與TIME_WAIT的實戰理解網絡基礎在運維筆試里從來都不會缺席。今年網易有道這批題目里三次握手和四次揮手屬于必考內容但考察方式比較靈活不是讓你默寫狀態變化而是給場景讓你判斷問題。比如有一道題問線上出現大量TIME_WAIT連接可能是什么原因怎么處理。我的答題思路是先解釋TIME_WAIT的產生機制主動關閉連接的一方在收到對方的FIN后進入TIME_WAIT狀態需要等待2MSL最大報文段生存時間才能徹底關閉主要是為了保證最后一個ACK能夠到達對方、以及讓舊連接中的遲到報文自然消亡。所以出現大量TIME_WAIT說明這臺機器上主動關閉了大量連接常見于高并發的短連接場景比如Nginx代理、Redis客戶端頻繁建連。然后是解決方案。我在筆試中寫了三個層級第一層是業務優化讓客戶端盡量使用連接池復用連接減少頻繁建連這是最治本的方式第二層是內核參數調優比如net.ipv4.tcp_tw_reuse僅在客戶端場景安全配合tcp_timestamps、net.ipv4.ip_local_port_range擴大端口范圍來緩解端口耗盡第三層是在架構層面引入LVS、HAProxy這類負載均衡組件把連接管理下沉到專門的組件里。同時我強調了tcp_tw_recycle這個參數不建議開啟因為它會在NAT場景下導致丟包這類我知道這個參數存在但知道它有哪些坑的表達通常能給閱卷人留下更好的印象。3.2 MySQL索引與慢查詢優化數據庫題是運維筆試的另一座大山。有道這批考了一道典型的慢查詢優化題給出一張訂單表order_info其中包含user_id、order_status、create_time等字段問針對某個高頻查詢語句如何建立索引并解釋索引失效的場景。我在回答中首先強調了聯合索引的最左前綴原則。針對高頻查詢SELECT * FROM order_info WHERE user_id ? AND order_status ? ORDER BY create_time DESC我會建議建立(user_id, order_status, create_time)的聯合索引這樣user_id用于等值匹配order_status用于等值匹配create_time用于排序可以直接覆蓋索引進行排序避免filesort。如果只建立(user_id)單列索引order_status仍然可以過濾但ORDER BY create_time就可能觸發文件排序性能差一個量級。接著我舉了幾個索引失效的反例對索引字段使用函數運算比如WHERE DATE(create_time) 2023-09-01會導致索引失效隱式類型轉換也會失效比如user_id是 varchar 類型卻用整數去查最左前綴原則被打破時比如跳過第一個字段直接查order_status聯合索引就無法發揮作用。這道題的加分點在于我補充了一個慢查詢排查的完整閉環先用SHOW FULL PROCESSLIST抓當前運行的慢SQL再開啟慢查詢日志slow_query_log和long_query_time用EXPLAIN分析執行計劃重點關注type、key、rows三個字段。type如果是ALL或index說明走了全表或全索引掃描大概率需要優化rows預估掃描行數遠超實際返回行數時往往是索引選擇不當。把排查方法論寫進答案比單點背命令更有說服力。4. 腳本與自動化筆試里的送分題怎么拿穩4.1 Shell腳本真題拆解這次筆試的兩道編程題里有一道Shell題給定一個Nginx訪問日志文件access.log每行格式為IP - - [時間] 請求方法 路徑 協議 狀態碼 響應字節數要求統計訪問次數最多的前10個IP并輸出對應次數。這道題在運維筆試里屬于老朋友級別但每年都有人因為細節丟分。我的標準答案是組合使用awk、sort、uniq和headawk {print $1} access.log | sort | uniq -c | sort -rn | head -10很多同學會在這道題上忽略一個關鍵問題uniq只能去重連續行所以必須先sort再uniq -c否則統計的數字完全是錯的。另一個容易失誤的點是sort -rn里的-n必須寫如果不寫-nsort -r會按照字典序排列結果就是 9 排在 89 前面統計排名完全亂掉。我在這道題的回答里額外寫清楚了sort的內存開銷問題當日志文件達到幾個GB時sort會把所有內容讀入內存和臨時文件建議用sort -S 1G限制內存使用或者用awk的關聯數組先做聚合再對聚合結果排序。例如awk {count[$1]} END {for (ip in count) print count[ip], ip} access.log | sort -rn | head -10這個方案在超大日志文件下更穩因為它先聚合再排序排序的數據量只有IP數量級而不是日志行數。我在筆試時把兩種方案都寫了出來并解釋了各自的適用場景這種不僅會寫還知道在什么場景下選哪個的表達方式更容易拿高分。4.2 Python與自動化思維的考察第二道編程題是Python題題目大意是有一個進程列表每個進程包含PID、PPID和進程名給定一個PID要求找出該進程及其所有子孫進程的PID集合。這本質上是一道樹的遍歷題要求熟悉基本的遞歸或棧操作。我的解法是先用字典構建PPID - [子進程列表]的映射然后用深度優先或廣度優先遍歷收集所有后代def get_all_subprocesses(processes, target_pid): children {} for pid, ppid in processes: children.setdefault(ppid, []).append(pid) result [target_pid] stack [target_pid] while stack: current stack.pop() for child in children.get(current, []): result.append(child) stack.append(child) return result這道題考察的其實不只是Python語法而是自動化腳本能力。運維日常要寫大量腳本來處理日志、巡檢服務器、批量執行命令所以大廠筆試里Python題通常圍繞列表處理、字典操作、文件讀寫、簡單的數據結構應用這幾個方向。備考時不需要刷算法競賽題把常見場景的腳本練熟就夠了。關于自動化思維筆試里的場景題也順手考察了。比如有一道問如何給100臺服務器批量執行磁盤檢查命令除了寫循環腳本之外我還提到了配置管理工具的思路比如使用Ansible的ansible all -m shell -a df -h或者用pssh這類批量執行工具。雖然這超出了筆試的編程題范圍但表現了你對效率工具的敏感度。5. 故障排查與場景題高分與低分的分水嶺5.1 CPU飆高的排查鏈路場景題是運維筆試最貼近真實工作、也最考驗綜合能力的部分。今年有道這批有一道題是某服務報警CPU使用率持續高于90%你如何排查。我在筆試中按照一個標準排障閉環來寫后來復盤下來這類題的答題邏輯其實是完全可以套用的。我的思路第一步是確認現象。先用top或htop查看整體負載和CPU占用最高的進程PID確認到底是用戶態CPU高還是內核態CPU高。再用top -Hp PID查看該進程內線程級別的CPU消耗找到具體是哪個線程在消耗CPU。第二步是抓取現場。使用pidstat -t -p PID 1持續觀察線程CPU變化再用jstackJava應用或gdbC/C應用導出線程棧把耗CPU最高的線程ID轉換為十六進制在線程棧里搜索對應的線程名。如果應用不支持這些工具可以臨時用perf top或perf record -g -p PID采集熱點函數。第三步是分析原因。CPU飆升通常有幾類原因代碼死循環或長事務、頻繁GCJava應用、大量正則匹配、線程爭搶鎖導致自旋。我在筆試里特別強調了不能看到CPU高就立刻重啟服務那只是掩蓋問題。要把線程棧保存下來結合最近的發布記錄判斷是不是新代碼引入了問題必要時保留現場、回滾版本。第四步是臨時緩解與根因處理并舉。臨時緩解是擴容或切流把故障節點從負載均衡摘除根因處理是定位到具體代碼邏輯。整個排查鏈路寫下來閱卷人一眼就能看出你有沒有真實排障經驗。5.2 磁盤滿了的正確處理姿勢磁盤空間不足是運維最常遇到的故障之一筆試里也考到了。題面是某臺服務器根分區使用率100%可能導致服務異常你如何處理。這道題我原本以為大家都會答但實際筆試復盤時發現很多人漏掉了關鍵步驟。最關鍵的一個點是先定位是什么文件占滿了磁盤而不是直接刪文件。我用df -h確認文件系統使用率用du -sh /* 2/dev/null | sort -rh | head -10逐層定位大目錄或者用ncdu這種交互式工具快速找到大文件。但這里有個隱蔽的坑如果某個大文件已經被進程打開并刪除du是看不到它的磁盤空間卻仍然被占用。需要用lsof | grep deleted找出被刪除但仍被進程持有的文件句柄然后重啟相關進程或釋放句柄空間才能真正釋放。另一個需要留意的點是inode耗盡。即使df -h顯示還有空間如果df -i顯示inode使用率100%同樣無法創建新文件因為小文件太多了。我遇到過好幾次這種場景所以筆試里我也把這條寫了進去。這題的作答思路體現了運維的一個核心原則先搞清楚狀況再動手處理。處理動作本身不難難的是在緊急情況下保持冷靜、按步驟排查。筆試里能把這一層邏輯寫出來分數不會低。5.3 業務連續性場景題的答題模板有道這批的簡答題里還有一類關于業務連續性的題目大致是數據庫主庫宕機了怎么恢復服務或服務出現大面積超時如何應對。這類場景題看似沒有標準答案但如果答得有條理反而很容易拿高分。我總結了一個四步模板。第一步評估影響范圍。確認是單機故障、單機房故障還是全局故障通過監控系統查看錯誤率、超時率、告警范圍盡快判斷故障邊界。第二步止損優先。如果數據庫主庫宕機且有高可用架構優先觸發主從切換如果是應用層故障考慮重啟集群或回滾最近發布如果是依賴的外部服務故障評估是否啟用降級方案或限流。止損的目標是先把影響面控制住而不是立刻找到根因。第三步保留現場與排查根因。在止損的同時保存日志、線程棧、監控截圖方便后續定位根因。常見根因包括慢SQL打爆數據庫、緩存雪崩打垮下游、配置變更引入錯誤、流量突增超過容量水位等。第四步復盤與治理。恢復服務之后要輸出故障報告核心內容包括故障時間線、根因分析、處理過程、改進項和后續計劃。筆試里寫出這一步會很加分因為很多新人只關注怎么修忽略了故障之后的總結沉淀才是運維工作最重要的部分。6. 筆試現場的踩坑與備考建議6.1 我在筆試中踩過的三個坑第一別在選擇題上做學術探討。有一道Linux命令題我在兩個選項之間糾結了很久后來發現題目本身是在問最常用/最便捷而不是唯一正確我在一道兩分的題上浪費了七八分鐘導致后面簡答題時間緊張。復盤下來做選擇題時應該按最佳實踐去選擇而不是鉆牛角尖去論證某種極端場景下另一個選項也成立。第二簡答題一定要寫命令和關鍵參數不能只描述思路。比如問如何排查內存泄漏如果你只寫用工具看內存占用找到增長最快的進程這種朦朧的表述很難拿分。但如果你直接把free -m、top、pidstat -r、pmap -x PID這串工具鏈寫出來并解釋如何對比內存增長曲線閱卷人立刻知道你確實動手排查過問題。第三編程題如果時間不夠先寫偽代碼和注釋也有分。我第二道Python題其實沒完全寫完但我把構建子進程列表的核心邏輯用注釋寫了出來最后代碼只差最后一層遍歷沒寫完但思路已經清晰呈現勉強拿到了部分分數。血淚教訓是筆試時就算代碼寫不完也要把思路和關鍵步驟展示出來。6.2 時間分配與心態管理再展開說一下時間分配。90分鐘的筆試我建議按10分鐘選擇題 15分鐘填空題 40分鐘簡答/場景題 20分鐘編程題 5分鐘檢查來分配。但這不是固定的因為每張卷子的題型分布可能會有調整。最重要的原則是簡答和場景題不可壓縮。編程題做不出來最多丟20分的部分分數但簡答和場景題如果寫得潦草丟掉的可能就是40%以上的分數。心態方面運維筆試的題目往往偏工程化沒有標準答案的題目占相當比例所以在考場上遇到這題我沒背過的情況不要慌。職場上的運維本來就是持續面對未知問題的崗位筆試有時候考察的就是你在不確定環境下組織思路、輸出方案的能力。按發現問題 - 定位問題 - 止損 - 根因分析 - 預防的框架答題即使無法答出完美答案也能保證基本盤。6.3 從這次筆試看大廠運維的新要求最后聊聊我考完這套題之后對運維崗位的一些新認識。以前提到運維很多人第一反應是會敲Linux命令、會看監控、會重啟服務但近兩年大廠運維筆試明顯在往開發能力 架構思維 數據敏感度的方向傾斜。這次網易的筆試里編程題占了一定比例場景題也需要你具備系統設計的感覺。比如有一道關于監控系統設計的問題問如果讓你為一個高并發服務設計監控指標你會關注哪些這就不是單純背監控工具能搞定的需要你理解QPS、RT、錯誤率、可用性、飽和度這些核心指標之間的關系。類似的傾向在互聯網大廠運維筆試里越來越明顯運維不再是后臺的輔助角色而是需要懂業務、懂架構、懂自動化的專項工程師。備考運維的同學建議在扎實掌握Linux、網絡、數據庫的基礎上把Python或Go學好了解至少一種配置管理工具理解CI/CD、容器化和監控鏈路。這些內容在這次筆試里直接或間接都有涉及。至少從網易這輪的題目來看懂開發的運維確實比只懂命令的運維要吃香得多。我在實際準備和參加這場筆試過程中最大的體會是運維筆試真的不是靠考前突擊就能搞定的它更像一面鏡子照出你平時積累的厚度。命令可以臨時背但排查思路、腳本能力和對系統原理的理解需要長期實踐才能沉淀下來。如果你正在準備運維校招不妨從今天開始每天花半小時讀一份真實故障記錄、寫一個小腳本、理清一個系統原理堅持一兩個月你會明顯感覺到自己和一個月前的差距。