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