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