開始前先說個背景運維開發工程師這幾年在游戲行業校招里一直是香餑餑。搜狐暢游2019年校招筆試題我當年拿到手的時候第一感覺是題目看著不嚇人但覆蓋面特別廣Linux、網絡、Python、數據庫、場景設計一鍋端而且越做越能察覺到出題人在試探你的自動化思維和業務理解能力。這篇文章就把這套典型筆試的考點拆開揉碎從答題者的視角講講每類題背后想考什么、怎么準備最穩也順便聊聊這類筆試題對后續面試和實際工作的參考意義。不管是準備校招的應屆生還是想轉崗運維開發的老人都能從里面找到能直接用的東西。1. 筆試整體設計與考察邏輯1.1 游戲公司為什么專門考運維開發很多同學第一次看到“運維開發工程師”這個崗位名會愣一下運維就運維為什么后面還要掛“開發”兩個字這個崗位在游戲公司里其實非常具體——運營的游戲區服動輒幾十上百組服務器數量多、變更頻繁、監控告警、日志采集、發布排期全部靠手工敲命令根本不現實所以必須有人把這些重復性工作做成平臺、做成工具。這個角色既要懂系統、網絡、數據庫這些運維基本功又要能寫代碼把流程自動化這就是“運維開發”的由來。搜狐暢游這種體量的游戲公司業務特點決定了它對運維開發有明確要求游戲版本更新頻繁合服、開服、滾服是日常操作線上流量有明顯波峰波谷節假日活動期間短時壓力極大玩家數據分散在多個數據庫實例里出了問題要能快速定位。這些場景決定了筆試不會只考死記硬背的命令參數而是考你能不能理解業務能不能用代碼和腳本解決問題。我后來也參與過類似規模的校招筆試命題出題人腦子里其實就一條邏輯線先確認你有沒有基礎功底再確認你有沒有開發能力最后看你面對真實運維場景時有沒有解決問題的思路。所以整套卷子并不是為了難倒你而是想通過有限的時間快速判斷一個人能不能在入職后獨立上手。這也解釋了為什么題目看起來雜但每道題背后都有明確的考察目標。1.2 考點分布與題型拆解從這類筆試的常見安排來看考點分布大概有這樣一個規律Linux 基礎占兩到三成網絡基礎占一成半左右Python 和 Shell 腳本能力能占到三成以上數據庫和中間件基礎知識占一到兩成最后一定有一道開放性的場景設計題。選擇題、簡答題、編程題、設計題四種形式基本都會出現選擇題考廣度簡答題考理解深度編程題考代碼熟練度設計題考系統思維。這里我先給一個大概的題型和占比參考方便你做復習規劃考察模塊常見題型大致占比核心目標Linux 基礎與命令選擇、簡答20% - 25%排查問題的基本能力網絡協議與排障選擇、簡答10% - 15%理解連接與故障鏈路Python / Shell 編程編程題30% - 35%自動化落地能力數據庫與中間件簡答、選擇10% - 15%數據存儲與緩存意識監控、發布等場景設計題10% - 15%全局架構與運維思維時間分配上我的建議是選擇題遇到沒把握的不要死磕先標記整個選擇題區塊控制在25到30分鐘之間簡答題分點作答每題控制在10分鐘以內編程題是分值大戶建議留出充足時間先寫思路再寫代碼別一上來就翻小抄式地硬寫最后那道場景設計題一定要寫滿哪怕方案不是最優也要讓閱卷人看到你有完整的思考過程。時間管理本身就是這類筆試考察的一部分一個能在有限時間內合理分配精力的人通常也是工作中更靠譜的人。2. 操作系統與網絡基礎的關鍵考點2.1 Linux 高頻命令與系統排查思路Linux 命令這塊筆試很少直接考“top 用來看什么”更多是給一個故障場景讓你選排查命令。比如“一臺服務器 CPU 負載飆升到 20你第一步怎么做”這種題表面上考命令實際上考排查思路。正確的順序一般是先用 top 看進程級別的 CPU 占用再配合 ps 看具體進程啟動時間、運行狀態必要時用 strace 追蹤系統調用。top 的交互命令也要熟按 P 按 CPU 排序、按 M 按內存排序、按 C 顯示完整命令行這些細節都會在場景題里派上用場。內存和磁盤的排查也經常出現。free -h 看內存總量和緩存占比注意區分真正的內存瓶頸和 page cache 占用——后者通常是正常的文件緩存可回收不要誤判df -h 看分區使用率df -i 看 inode 是否耗盡這是經常被忽略的坑文件沒刪多少但 df 報滿很多時候是 inode 用完了。再往下就是 iostat重點是 %util 和 await如果 %util 很高但 await 還好說明設備利用率充分如果 await 很高但 %util 不高可能是有 IO 隊列競爭或者磁盤本身有問題。這里給你一個排查負載高問題的標準路徑先 top 看 CPU再看 load average然后區分是 CPU 密集還是 IO 密集。CPU 密集就看哪個進程占資源IO 密集就用 iostat 看磁盤狀態同時用 vmstat 看 r 列運行隊列和 b 列不可中斷睡眠進程。我在實際操作中發現很多新手一看到 load 高就慌其實只要按這個鏈路拆下去十分鐘內基本能定位到根因。筆試里如果遇到這種場景題把你腦海中完整的排查鏈路寫出來哪怕不完美也比只寫一兩條命令強得多。2.2 網絡協議、連接狀態與常見故障網絡這塊TCP 連接狀態是筆試和面試都繞不開的點。TIME_WAIT 應該是出鏡率最高的詞比如“線上大量 TIME_WAIT 怎么辦”。先說原理主動關閉連接的一方在收到對方的 FIN 后會進入 TIME_WAIT 狀態并等待 2MSLMaximum Segment Lifetime超時后才會完全釋放連接。這個機制是為了保證最后一個 ACK 能可靠到達對方同時讓舊連接的報文在網絡中徹底消失避免污染新連接。大量 TIME_WAIT 本身不一定代表系統有問題關鍵看端口資源有沒有耗盡如果客戶端端口不夠用了才會表現成連接建立失敗。針對 TIME_WAIT 的處理我建議先做合理調優再考慮繞過。內核參數方面可以調整 net.ipv4.tcp_fin_timeout 縮短 FIN-WAIT-2 的等待時間也可以讓長連接復用但我不建議直接粗暴開啟某些快速回收參數因為可能帶來報文亂序識別問題尤其在 NAT 環境下容易誤傷正常連接。更穩的方案是改應用層連接池復用、減少頻繁的短連接、使用 HTTP 長連接這些都是治本的辦法。筆試和面試里你能把“為什么會有 TIME_WAIT”“什么時候才需要擔心”“治本方案是什么”一條線說清楚已經很加分了。端口連通性排查也是網絡部分的常客。我給你一個通用排查鏈路先 ping 看網絡層通不通再 telnet 或 nc 看端口通不通然后 curl 或查看應用日志看服務本身有沒有正常響應。很多同學一個問題直接拿 curl 去試如果應用層沒起來curl 報錯也無法判斷是網絡問題還是服務問題。正確做法是逐層排查每一層都有明確的結論。比如 curl 超時先 telnet 一下端口如果端口是通的說明 TCP 層面沒問題問題出在 HTTP 響應慢這時候再考慮是應用處理慢還是后端依賴慢。筆試里的網絡題這種分層排查的思路比單純背命令值錢得多。3. 編程能力與自動化腳本考點3.1 Python 編程題的典型解法Python 編程題通常都不會太難重點集中在文件讀取、日志分析、字符串處理、基本數據結構這幾個方向。有一類非常經典的題給一個 Nginx 訪問日志文件統計訪問次數最多的 IP 前十個。這題在考試里出現頻率極高因為它能一次性驗證 Python 基礎、文件操作和數據聚合能力。我給出一個參考答案你可以對照著自己的寫法看差距from collections import Counter ip_counter Counter() with open(/var/log/nginx/access.log, r) as f: for line in f: # 按空格切分訪問日志第一列是 IP ip line.split( , 1)[0] ip_counter[ip] 1 # 取出訪問次數最多的 10 個 IP top10 ip_counter.most_common(10) for ip, count in top10: print(ip, count)這段代碼里有幾個細節值得注意。第一用 with 打開文件文件用完之后自動關閉不會出現句柄泄漏第二用 for line in f 而不是先 f.readlines() 后遍歷前者是逐行讀取文件很大時內存占用恒定后者會一次性加載全部內容到內存日志量大的時候直接打爆第三用 Counter 類干計數和排序的活比手寫字典再排序優雅得多。這些細節在閱卷時都是加分項說明你有真實的大數據處理意識而不是只會寫練習題。如果題目要求更高一點讓你處理一個超大文件比如幾個 GB 級別的日志這時候逐行掃描雖然能跑但速度可能不夠理想。更進階的做法是用生成器分批處理配合多進程或者 awk 先做預聚合。筆試時如果遇到這種題我建議在代碼里先用注釋寫出你的思路比如“先分片讀取再按 IP 哈希分發到多個 worker 進程聚合最后合并結果”即使不寫完整代碼閱卷人也能看出你有性能意識。畢竟筆試時間有限把思路寫清楚比盲目敲出一堆跑不起來的代碼更有意義。3.2 Shell 腳本與文本處理三劍客Shell 腳本同樣是運維開發的基本功。筆試中常見的 Shell 題包括寫一個清理過期日志的腳本、寫一個批量修改配置文件的腳本、用 awk 從某個命令輸出里提取指定字段等。grep、sed、awk 這“三劍客”一定要熟練到條件反射級別。grep 負責行匹配過濾sed 負責行內替換編輯awk 負責字段提取和格式化輸出。這三者的分工基本覆蓋了文本處理里 90% 的需求。以清理日志腳本為例很多服務會按天分目錄存放日志比如 /data/logs/app/2025-01-01.log需求是刪除 7 天前的日志文件。我見過不少人第一反應就是寫一堆循環加判斷實際上 find 一行就能搞定#!/bin/bash BASE_DIR/data/logs/app KEEP_DAYS7 find $BASE_DIR -name *.log -type f -mtime $KEEP_DAYS -exec rm {} \;這段腳本的關鍵知識點在 find 的參數-type f 限定只刪除文件避免誤刪目錄-mtime 7 表示修改時間在 7 天之前-exec rm {} ; 是對匹配到的每個文件執行刪除。有些同學會問為什么不用管 crontab實際上生產環境中這個腳本就是配合 crontab 每天跑一次的一般會在凌晨低峰期執行。筆試如果只讓你寫腳本你就把腳本本身寫清楚如果還問你怎么定時執行那就補一句 crontab -e 加上“0 3 * * * /opt/scripts/clean_logs.sh 21”這種定時配置。這里有一個我在實際生產環境中踩過的坑用 find 刪除文件千萬不要用 rm -rf 直接拼接路徑因為如果路徑變量讀出來是空的整條命令就變成了“rm -rf /”后果不堪設想。安全做法是先用 find 列出匹配到的文件確認一遍再刪或者用 -exec 時嚴格限定路徑和文件名條件。另外腳本里建議加上 set -u 防止未定義變量加 set -e 或對關鍵命令做返回值判斷。筆試時寫上這些防御性寫法馬上就能拉開和大多數考生的差距。我甚至在批改卷子的時候遇到過腳本邏輯完全正確的一個人因為沒考慮變量為空的問題被我在評語里點名提醒。這些小細節平時多注意考試不吃虧。4. 數據庫與中間件基礎考點4.1 MySQL 索引與慢查詢優化游戲公司的業務天生依賴數據庫所以 MySQL 在運維開發筆試里幾乎是必考的。考點集中在索引原理、慢查詢分析、基本優化手段上。關于索引我建議一定先把原理理解透MySQL 的 InnoDB 引擎底層是 B 樹結構索引就是一顆排好序的樹通過它能夠快速定位到目標數據避免全表掃描。但是索引不是越多越好每多一個索引寫入和更新都要同步維護反而拖慢寫性能。筆試里常見的索引題是一張玩家信息表有 player_id、server_id、level、login_time 等字段查詢條件經常是“WHERE server_id ? AND player_id ?”問你索引怎么建。這種題考察的是“最左前綴原則”也就是聯合索引里查詢條件必須從最左側的字段開始匹配索引才會生效。所以索引應該建在 (server_id, player_id) 上而不是反過來因為反過來 player_id 單獨過濾性雖然強但無法滿足 server_id 作為第一個查詢條件的場景。當然具體還要看哪個字段枚舉值更少、哪個更常用筆試里把最左前綴原則寫清楚再結合實際查詢條件給出建議基本就能拿高分。慢查詢這塊運維開發工程師至少要知道怎么定位慢 SQL。第一步是確保慢查詢日志打開并設置合理閾值在 MySQL 配置中有兩個關鍵參數slow_query_log 設為 ON 開啟日志long_query_time 設置為 1 秒線上我一般建議 1 到 2 秒太短會把日志刷爆太長又發現不了問題。然后定期用 mysqldumpslow 工具匯總慢查詢日志找出那些累計執行次數多、總耗時長的 SQL。定位到之后用 EXPLAIN 查看執行計劃重點看 type 列是不是 ALL全表掃描、key 列有沒有用上索引、rows 列預估掃描了多少行。這三個字段幾乎是慢查詢分析的“三板斧”筆試和面試都會問到。4.2 Redis 與消息隊列的基本認知中間件部分Redis 是出鏡率最高的。Redis 的核心考點是緩存穿透、緩存擊穿、緩存雪崩以及常用的數據結構。緩存穿透指查詢一個必然不存在的數據請求直接打到數據庫緩存的 key 都沒對應但 database 也沒有于是緩存形同虛設大量請求穿透到數據庫。解決方案是布隆過濾器前置過濾或者把空值也緩存起來設置較短過期時間。緩存雪崩指大量 key 在同一時間失效導致請求全部落到數據庫上解決思路是把過期時間分散加隨機值。緩存擊穿指一個熱 key 在失效瞬間有大量并發請求同時打過來這時候可以用互斥鎖或邏輯過期來解決。數據結構方面游戲排行榜是一個經典場景玩家積分實時變化需要快速獲取前 100 名。這種需求用 Sorted Set有序集合就非常合適key 是排行榜名稱member 是玩家 IDscore 是積分。ZADD 更新積分ZREVRANGE 取分數從高到低的排行榜ZSCORE 查單個人分數復雜度都是 log(N)性能很好。這個問題幾乎是游戲公司筆試里的常客我強烈建議你背熟這幾個命令并理解為什么用 Sorted Set 而不是 List 或者普通 Set。消息隊列在運維開發里更多是作為應用架構的組件出現。考題一般會問“為什么需要消息隊列”答案核心是解耦、削峰、異步。游戲服務器在高并發活動時玩家行為日志、跨服消息等如果全部同步處理后端壓力會非常大引入消息隊列可以先寫隊列再消費讓系統平滑扛住峰值。筆試遇到這種題把“削峰填谷、異步解耦”這八個字展開再結合一個具體業務場景說明就夠了。至于 RocketMQ、Kafka、RabbitMQ 各自的優劣屬于進階內容有時間可以了解但不是筆試重點。5. 運維開發場景實操從筆試到落地5.1 監控告警系統設計筆試最后一道場景設計題通常會給一個業務場景讓你設計一套監控告警系統或者設計一個自動化發布流程。這種題沒有唯一標準答案考察的是全局架構能力。以監控系統為例我建議你按“采集 - 存儲 - 展示 - 告警”四個層次來回答這是最不容易漏點、也最容易讓閱卷人捕捉到你的結構感的方式。第一層是數據采集。需要明確采集哪些指標一般分三類機器指標如 CPU、內存、磁盤、網絡流量業務指標如每分鐘請求量、錯誤率、響應時間 P99日志指標如錯誤日志條數、慢查詢條數。采集周期也要注意機器指標一般 15 到 30 秒一次業務指標根據重要程度可以做到秒級。這里可以列一個表格幫助表達指標類型典型指標采集周期告警示例機器指標CPU、內存、磁盤、IO15 - 30sCPU 持續 5 分鐘超過 85%業務指標QPS、錯誤率、響應時間5 - 10s錯誤率超過 1% 持續 2 分鐘日志指標ERROR 日志數、慢查詢數1minERROR 日志數突增 3 倍第二層是存儲。時序數據要選擇合適的時序數據庫像 Prometheus 搭配 Thanos 或 VictoriaMetrics。這一層重點說明數據保留策略比如原始數據保留 15 天、降精度數據保留 6 個月避免存儲無限增長。第三層是展示。Grafana 是常規選擇需要規劃好面板結構不能所有指標堆在一個大屏上而是按業務維度分面板比如“游戲服狀態總覽”“數據庫性能”“網絡層狀態”。展示層有一個容易被忽略的點指標要有對比視圖比如今天的數據跟昨天同時段對比、跟上周同時段對比這樣異常更容易暴露出來。第四層是告警。告警要分級比如 P0 表示核心功能不可用需要立即通知接入電話P1 表示服務質量下降告警到值班群P2 表示資源趨勢性緊張記錄到日報即可。關鍵一點是告警一定要避免“狼來了”效應閾值設得太敏感受眾會麻木設得太松又起不到預警作用。我在實際設計告警閾值時的經驗是先觀察一周基線數據再基于波動幅度設定閾值并且每條告警都要有對應的處理預案。筆試時你把“分級”和“避免告警疲勞”這兩點寫出來閱卷人基本能判斷出你有實戰經驗。5.2 自動化發布與故障排查自動化發布流程是另一個高頻設計題。游戲公司上線新版本非常頻繁如果每次靠手動登錄所有機器傳包、重啟進程效率低且容易出錯。所以設計題一般會讓你描述一個完整的發布流程。我建議分成前置檢查、構建打包、分發部署、驗證回滾四個階段來答。前置檢查階段要做的是確認代碼分支和版本號正確跑一遍自動化測試檢查服務器磁盤空間和端口占用避免發到一半發現空間不夠。構建打包階段如果是 Python 項目可能就是安裝依賴打 tar 包如果是 C 游戲服務端則是編譯并收集產物。分發部署階段可以設計先發布一臺灰度服務器確認啟動日志無異常再批量推送批量推送時最好分批進行比如一次 20 臺觀察監控指標穩定后再推下一批避免一次推完導致問題面過大。驗證階段除了檢查進程存活和端口監聽還要看關鍵業務指標比如客戶端心跳數、登錄成功率。回滾策略也必須提前想好最常見的就是保留上一版本的完整目錄發布失敗時快速切換軟鏈接回滾。故障排查題在筆試里更多以簡答題或者選擇題出現但設計題里也會要求你附帶說明某種故障的處理思路。比如線上出現大量 502 錯誤怎么排查正確鏈路是先確認是網關問題還是后端服務問題。看 Nginx 錯誤日志確認后端連接被拒還是超時再 telnet 后端服務端口確認端口有沒有監聽接著看后端進程 CPU 和內存用 top 看是否資源耗盡最后看數據庫連接池是否被打滿。排查的過程中每一步都要有結論排查完要有恢復動作比如臨時擴容、重啟故障節點、限流保護。這種分步排查的描述方式在筆試里特別能拿分因為它展示的不只是知識點而是解決問題的能力。6. 筆試實戰經驗與常見陷阱6.1 答題順序與時間管理這類筆試的時間通常是 90 到 120 分鐘題量不算小如果沒有章法很容易在選擇題上耗太久導致后面大片空白。我建議拿到卷子先花兩三分鐘完整瀏覽一遍對難度和分值心里有數。然后做題順序堅持“先易后難、先分多后分少”的原則選擇題雖然多但分值小40 道選擇題做 25 分鐘左右就該收手遇到猶豫的直接標記跳過簡答題控制在 35 分鐘內每道題先列點再展開編程題哪怕只寫核心函數也要寫注意先寫思路注釋再碼代碼不會的題目把算法過程描述清楚也能拿到部分分最后的設計題至少留 20 分鐘這種題分值高、能寫的內容多千萬不要留白。時間分配上還可以用一個小技巧每做完一個板塊在草稿紙上記錄一下實際用時超時太多就強制收尾。我當年考試的時候就是這樣做的選擇題有一道網絡題拿不準果斷放棄后把時間留給了后面的 Shell 腳本題最后那道腳本題拿了滿分彌補了前面的小失誤。筆試考的是綜合得分率不是單題正確率這個思路一定要建立起來。另外編程題如果環境允許先本地跑一遍再提交很多筆試題的代碼要在瀏覽器里現場運行語法錯誤都能立刻發現這時候多花一分鐘檢查代碼規范比多寫一行注釋更值得。6.2 閱卷視角面試官看重什么這里我從閱卷人的角度給你交個底。批改這類筆試題的時候我最先看的是編程題。代碼邏輯是不是完整、有沒有考慮空值和異常分支、變量命名是否清晰、有沒有關鍵注釋這些都能在幾十秒內看個大概。很多人容易犯的毛病是題目要求統計日志中訪問量前 10 的 IP代碼只寫了統計沒有排序輸出或者輸出了但沒限制前 10這些都是扣分點。另一個常見問題是只寫了主流程完全沒有異常處理比如打開文件可能會失敗、字段可能格式不對這些邊界條件是閱卷人非常關注的因為運維開發工程師寫出的腳本是要在真實服務器上長期跑的不可能永遠拿到格式完美的數據。簡答題里我比較反感只寫結論不寫理由的答案。比如問“為什么用緩存”只寫“為了性能”跟沒答一樣但如果能寫出“降低數據庫壓力、減少響應時間、扛住峰值流量”再補一句“同時要注意緩存一致性問題”那這個答案的層次就完全不同了。我建議你答題時分點每一點都是“現象 原因 解決思路”的完整結構這樣閱卷人一眼能看到你的邏輯鏈。最后是設計題。設計題沒有標準答案但閱卷人很容易看出一個人是真做過還是背模板。真做過的人會在方案里自然地提到灰度發布、回滾策略、告警閾值、指標對比這些細節背模板的人只會寫“高可用、擴展性、穩定性”這些無效詞匯。所以我給備考同學的建議是考前至少親手搭一套簡單的監控系統或者自動化部署腳本哪怕是測試環境也能幫你在答題時寫出有血有肉的方案。6.3 一次完整的備考路線參考說到備考我結合自己帶新人和參與校招的經驗給出一套三個月左右的路線參考適合筆試前系統準備。第一個月主攻基礎Linux 命令每天練一小時重點把 top、free、df、netstat、ss、lsof、grep、sed、awk 這九個命令用熟能用它們完成日常的進程查看、端口排查、日志提取同時每天刷 20 道 Python 基礎題從列表、字典、字符串到文件操作、異常處理把基本功打好。第三個月開始加強度每天至少寫兩個小腳本比如清理臨時文件、批量重命名、自動備份同時做幾套真題和模擬題總結錯題和高頻考點把之前的基礎知識串聯起來。第二個月進入經驗積累階段主要可以看《鳥哥的 Linux 私房菜》基礎篇、Python 相關的核心編程配合 “高性能 MySQL” 理解索引和查詢優化。同時可以開始接觸真實運維場景找一臺云服務器把日志采集、進程守護、定時任務、簡單監控手動搭一遍。這個階段你會發現很多筆試里的題目在真實環境里操作一遍之后印象會深很多比如你在服務器上真的經歷過一次磁盤滿、TCP 連接數過多的問題以后再遇到相關題目時不需要死記硬背。三個月下來你不僅能應付這類筆試題日常工作中很多基礎問題也能獨立處理了。備考的核心從來不是刷題庫而是建立“看到問題 - 定位原因 - 用代碼或命令解決”這個閉環。筆試只是這個能力的一小次檢驗真正讓你走得遠的是養成的工程習慣。寫在最后這些年看過的校招筆試和面試有不少個人最大的體會是運維開發工程師的筆試題變化不大但要求越來越高。2019 年那會兒會寫 Python 腳本就算亮點現在很多應屆生已經能交出帶單元測試的完整工具代碼了。基本功永遠是最值錢的Linux、網絡、數據庫、腳本這四板斧走到哪里都不過時。如果你現在還在準備筆試題建議別只盯著一兩套卷子刷而是把每個考點背后“為什么這樣考”想明白。我面試過不少筆試高分但一問項目就露餡的候選人也見過筆試馬馬虎虎但聊到真實故障能滔滔不絕的選手后者在實際工作中往往走得更遠。祝愿你在秋招季能碰到一套讓自己答得痛快的題也早點找到適合自己成長節奏的團隊。