我把自己當(dāng)年刷京東2018秋招技術(shù)運(yùn)維工程師筆試題的經(jīng)歷整理了一遍同時也把市面上能搜到的同批次回憶版題目做了交叉比對。結(jié)論是這套題雖然時間過去好幾年但它的考點(diǎn)框架放到今天依然不過時。無論你是在準(zhǔn)備運(yùn)維崗筆試還是想系統(tǒng)梳理自己的Linux、網(wǎng)絡(luò)、數(shù)據(jù)庫、容器、監(jiān)控知識這篇文章都值得你花半小時看完。我不會去逐字復(fù)述原題而是把題目背后真正想考察的能力拆開講清楚順便把那些“看起來會、一寫就錯”的坑也一并填上。1. 打開真題之前先看清京東到底要什么樣的人1.1 一場筆試背后的崗位畫像2018年的京東正處于向技術(shù)轉(zhuǎn)型的關(guān)鍵期彼時“技術(shù)運(yùn)維工程師”這個崗位的目標(biāo)非常明確既要能扛住大促流量下的系統(tǒng)穩(wěn)定性也要能推動運(yùn)維自動化、平臺化建設(shè)。所以筆試不是單純考命令背沒背熟而是通過一套題去篩三類能力基礎(chǔ)功底扎不扎實、故障排查有沒有章法、對運(yùn)維發(fā)展趨勢有沒有判斷。筆試題目一般分成幾塊選擇題覆蓋Linux、網(wǎng)絡(luò)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)簡答題考命令輸出、配置文件含義、故障處理思路最后往往有一兩道綜合設(shè)計題比如“設(shè)計一個支撐百萬并發(fā)的Web架構(gòu)”“線上CPU飆高怎么排查”。如果你以為運(yùn)維就是敲敲命令、看看監(jiān)控那這套題會讓你清醒過來。1.2 2018年秋招的技術(shù)背景為什么今天仍然值得刷2018年正值容器和編排系統(tǒng)大規(guī)模落地的前夜很多公司還在用虛擬機(jī)和傳統(tǒng)發(fā)布方式但Docker已經(jīng)開始進(jìn)入生產(chǎn)環(huán)境Kubernetes也從小范圍試點(diǎn)走向主流。京東內(nèi)部自研的容器平臺已經(jīng)承擔(dān)了大量核心業(yè)務(wù)所以筆試題里出現(xiàn)容器相關(guān)內(nèi)容并不奇怪。刷這套題的價值不在于題目本身而在于它能幫你建立一個完整的運(yùn)維知識坐標(biāo)系。2018年的考點(diǎn)是Linux網(wǎng)絡(luò)數(shù)據(jù)庫容器的交叉現(xiàn)在絕大多數(shù)公司運(yùn)維工程師筆試還在考同一套底層的東西無非是增加了云原生、DevOps、智能運(yùn)維等新詞。把老題吃透你相當(dāng)于把一個運(yùn)維工程師最核心的能力底盤練了一遍。2. Linux與操作系統(tǒng)考點(diǎn)拆解從命令到內(nèi)核2.1 高頻命令與文件系統(tǒng)題選擇題里最常見的是給一條命令讓你選輸出結(jié)果。當(dāng)年考過top、ps、netstat、df、du、find、grep、awk、sed的混合用法其中awk和sed是重災(zāi)區(qū)。很多人能用awk取列但一到“按條件篩選之后再做統(tǒng)計”就卡殼。我建議把下面這組套路練到形成肌肉記憶用ps aux查進(jìn)程CPU和內(nèi)存占用配合sort -k3 -rn按CPU排序sort -k4 -rn按內(nèi)存排序。用netstat -tunlp看端口監(jiān)聽狀態(tài)注意-t必須帶上否則看不到TCP連接信息。用df -h看磁盤容量iostat -x 1看磁盤IOdstat看整體性能。用find /var/log -name *.log -mtime 7 -exec rm {} \;做日志清理注意-exec后面必須以\;結(jié)尾。文件系統(tǒng)考點(diǎn)里inode耗盡是一個經(jīng)典陷阱。很多人只知道磁盤滿了卻不知道df -h顯示有空間但應(yīng)用報錯“No space left on device”時要用df -i查看inode是否用完。當(dāng)年題目里就有一道場景小文件過多導(dǎo)致inode占滿問怎么定位和解決。正確思路是先df -i確認(rèn)再find / -xdev -printf %h\n | sort | uniq -c | sort -k1 -rn找出小文件集中的目錄最后清理或調(diào)整文件系統(tǒng)。2.2 進(jìn)程、內(nèi)存、負(fù)載的排查套路選擇題經(jīng)常考load average的含義。很多人誤以為負(fù)載高就代表CPU忙實際上它是進(jìn)程狀態(tài)的一個綜合指標(biāo)。top里顯示的load average分別對應(yīng)1分鐘、5分鐘、15分鐘的均值它統(tǒng)計的是處于運(yùn)行狀態(tài)和不可中斷睡眠狀態(tài)的進(jìn)程數(shù)。如果機(jī)器負(fù)載很高但CPU使用率不高優(yōu)先檢查是不是有大量進(jìn)程處于D狀態(tài)不可中斷睡眠。這種狀態(tài)一般和磁盤IO有關(guān)比如NFS掛載卡住、磁盤硬件故障、IO調(diào)度慢。排查命令是top后按D鍵看D狀態(tài)進(jìn)程或者直接用ps -eo stat,pid,cmd | grep ^D。配套考的是內(nèi)存分析。free -m輸出中很多人分不清used和available。在較新的內(nèi)核版本里available是真正可被新進(jìn)程使用的內(nèi)存它包含了可回收的page cache。而used并不等于“實際占用”因為buff/cache占用的內(nèi)存可以在需要時釋放。當(dāng)年有道題是“系統(tǒng)內(nèi)存顯示用了80%要不要擴(kuò)容”正確答案是先看available而不是used。2.3 系統(tǒng)啟動與初始化排查Linux啟動流程也是?？鸵话銜糂IOS - BootLoader - kernel - init/systemd - 用戶態(tài)服務(wù)這條鏈。2018年很多公司還在用CentOS 6所以SysVinit和systemd并存是個考點(diǎn)?，F(xiàn)在基本都切systemd了但啟動流程的原理依然要理解。結(jié)合故障場景的題目更實用服務(wù)器重啟后某個服務(wù)沒起來怎么排查我的標(biāo)準(zhǔn)路徑是systemctl status service看服務(wù)狀態(tài)和報錯信息。journalctl -u service -n 100查日志。如果服務(wù)沒設(shè)置開機(jī)自啟用systemctl enable service。如果服務(wù)依賴網(wǎng)絡(luò)、數(shù)據(jù)庫等外部資源檢查啟動順序是否配置了After依賴。這類題目說到底是考定位能力不是單純考命令。我之前在文章里也分享過處理“重啟后服務(wù)起不來”最忌諱的是反復(fù)重啟服務(wù)試運(yùn)氣一定要先看journal日志和配置依賴。3. 網(wǎng)絡(luò)考點(diǎn)拆解TCP、HTTP、DNS和故障排查3.1 TCP三次握手與time_wait網(wǎng)絡(luò)部分選擇題濃度很高而且喜歡圍繞TCP展開。三次握手、四次揮手的流程是送分題但要拿分必須把狀態(tài)流轉(zhuǎn)背清楚?？紙隼锔菀族e的是TIME_WAIT相關(guān)題因為涉及細(xì)節(jié)比較多。TIME_WAIT出現(xiàn)在主動關(guān)閉連接的一方作用是確保最后的ACK能讓對方收到同時防止舊連接的報文干擾新連接。高并發(fā)短連接場景下TIME_WAIT會大量堆積導(dǎo)致端口耗盡典型優(yōu)化手段是開啟net.ipv4.tcp_tw_reuse并配合tcp_timestamps。不過有個坑要提醒tcp_tw_recycle在NAT環(huán)境下會引發(fā)嚴(yán)重問題因為它依賴時間戳而NAT后面的多臺機(jī)器時間戳可能不遞增導(dǎo)致丟包。2018年面試官喜歡追問這個點(diǎn)能從“為什么不能隨便開tcp_tw_recycle”說到“NAT環(huán)境下可能會丟包”的候選人基本能拿高分。3.2 HTTP狀態(tài)碼與常見場景HTTP狀態(tài)碼屬于必考。1xx、2xx、3xx、4xx、5xx的大類要清楚幾個高頻狀態(tài)碼必須記住301永久重定向、302臨時重定向注意301會緩存302不會。403權(quán)限不足404不存在499是客戶端主動斷開Nginx特有500服務(wù)端內(nèi)部錯誤502網(wǎng)關(guān)收到無效響應(yīng)503服務(wù)不可用504網(wǎng)關(guān)超時。429請求過多在限流場景下經(jīng)常出現(xiàn)。京東這類大流量業(yè)務(wù)尤其看重502/504的排查。題目可能這樣出Nginx返回502后端PHP-FPM日志沒有報錯怎么排查思路是先確認(rèn)后端進(jìn)程是否存活再確認(rèn)端口和Unix Socket是否可訪問接著看PHP-FPM的request_terminate_timeout和慢日志最后檢查Nginx和后端之間的keepalive配置。做題時不能只寫答案要把排查順序?qū)懬宄?.3 DNS解析問題定位DNS的問題年年出現(xiàn)因為它直接影響用戶訪問。常見考點(diǎn)包括查看解析用的命令是nslookup、dig、host其中dig信息最全。/etc/resolv.conf里search和ndots參數(shù)會影響域名解析行為這在Kubernetes里尤其重要。DNS緩存導(dǎo)致解析不生效刷新緩存的方法因系統(tǒng)而異CentOS 6用service nscd restartsystemd系統(tǒng)用systemd-resolve --flush-caches。筆試題里典型場景是“用戶反饋域名解析到了錯誤的IP但是本地dig 114.114.114.114結(jié)果正確怎么排”答案要先判斷是不是使用了本地DNS服務(wù)器再查hosts文件、DNS緩存、DNS服務(wù)器的解析記錄。注意/etc/hosts優(yōu)先級高于DNS很多人排查半天最后發(fā)現(xiàn)是hosts里寫了一個舊IP。3.4 負(fù)載均衡與LVS、Nginx2018年筆試題對負(fù)載均衡的熱情非常高京東作為電商平臺負(fù)載均衡是核心基礎(chǔ)設(shè)施。選擇題可能考LVS的三種工作模式DR模式、NAT模式、TUN模式。其中DR模式和NAT模式的區(qū)別是高頻考點(diǎn)要記住NAT模式請求和響應(yīng)都經(jīng)過LVSLVS修改目標(biāo)IP和端口回包要改源IP性能受限。DR模式請求經(jīng)過LVS響應(yīng)直接回給客戶端LVS只改目標(biāo)MAC地址性能最好但要求后端和LVS在同一二層網(wǎng)絡(luò)。TUN模式通過隧道封裝跨網(wǎng)段場景用但復(fù)雜度高。Nginx作為七層負(fù)載均衡也要掌握。題目常問“Nginx和LVS有什么區(qū)別”標(biāo)準(zhǔn)回答是LVS工作在四層、基于內(nèi)核轉(zhuǎn)發(fā)、性能高Nginx工作在七層支持HTTP協(xié)議級別的路由、rewrite、緩存但性能上限不如LVS。實際架構(gòu)里經(jīng)常是LVS在前面做流量入口Nginx在后端做應(yīng)用路由。4. 數(shù)據(jù)庫與中間件考點(diǎn)MySQL、Redis、消息隊列4.1 MySQL索引與慢查詢數(shù)據(jù)庫這塊MySQL是絕對主力。選擇題愛考索引失效場景簡答題愛考慢查詢優(yōu)化?；A(chǔ)必須過關(guān)的內(nèi)容包括B樹索引結(jié)構(gòu)、聚簇索引與非聚簇索引的區(qū)別。最左前綴原則聯(lián)合索引(a,b,c)能用上a、ab、abc但不能直接用b或c?；乇聿樵兒透采w索引。覆蓋索引是優(yōu)化利器查詢字段都在索引里就能避免回表減少IO。慢查詢?nèi)罩鹃_啟方法set global slow_query_log ON;配合long_query_time 1然后用mysqldumpslow分析。真題里有一道我印象很深select * from t where age 18 order by id desc limit 10數(shù)據(jù)量很大問怎么優(yōu)化。除了給age加索引還要考慮order by和limit的組合。如果單純加索引還不夠可以進(jìn)一步利用覆蓋索引或者在業(yè)務(wù)上改成從游標(biāo)位置翻頁避免深分頁。4.2 Redis緩存雪崩、穿透、擊穿Redis作為高頻考點(diǎn)每年都會出現(xiàn)。2018年考的是緩存三兄弟現(xiàn)在依然考只不過場景更新了。緩存穿透查詢一個不存在的key每次打到數(shù)據(jù)庫。解決方法是布隆過濾器或者緩存空值并設(shè)置較短過期時間。緩存擊穿一個熱點(diǎn)key過期瞬間大量請求打到數(shù)據(jù)庫。解決方法是互斥鎖重建緩存或者讓熱點(diǎn)key不設(shè)置過期時間改為邏輯過期。緩存雪崩大量key同時過期導(dǎo)致數(shù)據(jù)庫壓力暴增。解決方法是過期時間加隨機(jī)值或者采用多級緩存、集群部署。答題時不要只寫方案名稱要把原理講透。比如互斥鎖其實用的是Redis的setnx加鎖重建緩存后釋放鎖但要注意鎖的過期時間防止線程異常導(dǎo)致死鎖。能夠把“為什么”講清楚閱卷人一眼就能看出你做過實際項目。4.3 消息隊列選型與可靠性消息隊列在2018年時主流選擇是Kafka、RabbitMQ、RocketMQ。選擇題會問適用場景比如Kafka高吞吐、適合日志收集和流處理但會有消息重復(fù)和亂序需要業(yè)務(wù)側(cè)做冪等。RabbitMQ適合復(fù)雜路由、可靠性要求高的業(yè)務(wù)但吞吐量相對低。RocketMQ在電商場景里表現(xiàn)均衡京東內(nèi)部大量使用?？煽啃缘目键c(diǎn)集中在消息丟失和重復(fù)消費(fèi)。生產(chǎn)者端要確認(rèn)機(jī)制Broker端要刷盤策略和副本機(jī)制消費(fèi)者端要手動提交offset。筆試題常問“怎么保證消息不丟失”答案必須分層說。如果只說“開啟確認(rèn)”沒有把三層都覆蓋到會扣掉大部分分。5. 容器、虛擬化與云計算運(yùn)維5.1 2018年容器化處在哪個階段2018年是一個有趣的節(jié)點(diǎn)Docker已經(jīng)火了兩三年Kubernetes開始在社區(qū)里占據(jù)主導(dǎo)但很多運(yùn)維還沒真正在生產(chǎn)環(huán)境大規(guī)模使用。京東屬于走得比較早的我記得當(dāng)時的容器平臺已經(jīng)在支撐核心交易鏈路所以筆試把容器作為一個加分項來考。今天的你看到這道題可能覺得簡單但站在當(dāng)時的環(huán)境里“容器和虛擬機(jī)的區(qū)別”“Docker鏡像和容器的關(guān)系”“容器如何做網(wǎng)絡(luò)隔離”這些內(nèi)容已經(jīng)能篩掉一批只會傳統(tǒng)運(yùn)維的人。5.2 Docker核心原理題Docker考點(diǎn)集中在鏡像、容器、網(wǎng)絡(luò)、存儲。大題可能會讓你畫一下docker run之后發(fā)生了什么或者讓解釋overlayfs。知識點(diǎn)清單鏡像層是只讀的容器加了一層可寫層。修改文件采用寫時復(fù)制所以容器內(nèi)改文件不會影響鏡像。容器網(wǎng)絡(luò)模式bridge、host、none、container。如果題目問“容器里訪問宿主機(jī)服務(wù)用什么地址”答案是host.docker.internal或者在Linux下用網(wǎng)關(guān)IP。數(shù)據(jù)卷用-v掛載注意容器刪除后數(shù)據(jù)是否保留取決于掛載方式。還有一道經(jīng)典題容器內(nèi)PID 1進(jìn)程是什么角色為什么容器里不推薦運(yùn)行多個進(jìn)程因為PID 1在容器里承擔(dān)信號轉(zhuǎn)發(fā)和僵尸進(jìn)程回收職責(zé)如果PID 1不是init類進(jìn)程子進(jìn)程變?yōu)榻┦鬅o法被回收時間久了可能出問題。這題雖然偏原理但能看出你有沒有真在生產(chǎn)環(huán)境見過容器“僵死”。5.3 Kubernetes調(diào)度與Pod生命周期雖然2018年筆試不一定深入Kubernetes但如果你簡歷上寫了容器編排面試官一定會追著問。核心概念必須搞清楚Pod是最小調(diào)度單元一個Pod里的容器共享網(wǎng)絡(luò)命名空間和存儲卷。kubelet負(fù)責(zé)Pod生命周期管理容器崩潰后根據(jù)restartPolicy決定是否重啟。調(diào)度器根據(jù)資源請求、節(jié)點(diǎn)標(biāo)簽、親和性等條件把Pod分配到合適節(jié)點(diǎn)。Deployment控制副本數(shù)滾動更新時默認(rèn)maxSurge和maxUnavailable都默認(rèn)25%。當(dāng)前云原生環(huán)境下“從原理到實體調(diào)用”經(jīng)常被問kubectl apply之后kube-apiserver如何把Pod寫入etcdkube-scheduler如何選擇節(jié)點(diǎn)kubelet如何通過CRI調(diào)用containerd最終通過runc啟動容器。建議把這個調(diào)用鏈畫一遍比死背Pod的階段名字有用得多。5.4 私有云、混合云下的運(yùn)維思維轉(zhuǎn)變京東的運(yùn)維體系早已不是傳統(tǒng)機(jī)房的模式筆試中的設(shè)計題經(jīng)常會把場景設(shè)定在私有云或混合云里。要體現(xiàn)思維轉(zhuǎn)變至少要能談兩點(diǎn)從“管理單臺機(jī)器”到“管理資源池”。機(jī)器故障不再是每天手工處理而是通過平臺自動替換。運(yùn)維要寫的是調(diào)度策略、健康檢查、自愈腳本。從“穩(wěn)態(tài)”到“敏態(tài)”。傳統(tǒng)運(yùn)維以穩(wěn)定為最高目標(biāo)云原生下的運(yùn)維要兼顧快速交付。不可變基礎(chǔ)設(shè)施理念下修復(fù)不是改配置而是重新發(fā)布版本。這類題目沒有標(biāo)準(zhǔn)答案但踩分點(diǎn)在于你有沒有表達(dá)出“人工操作不可擴(kuò)展必須自動化”這個核心認(rèn)知。6. 監(jiān)控、自動化與故障排查綜合題6.1 監(jiān)控體系怎么設(shè)計監(jiān)控設(shè)計題幾乎是秋招綜合題的保留項目。題干一般是這樣“線上有幾百臺機(jī)器業(yè)務(wù)包括Nginx、應(yīng)用、MySQL、Redis請你設(shè)計一套監(jiān)控方案?！贝痤}框架建議按“指標(biāo)采集-數(shù)據(jù)存儲-告警通知-可視化”展開采集層Zabbix、Prometheus、Node Exporter注意區(qū)分系統(tǒng)指標(biāo)和業(yè)務(wù)指標(biāo)。存儲層時序數(shù)據(jù)庫Prometheus適合容器環(huán)境Graphite、InfluxDB在傳統(tǒng)環(huán)境用得多。告警層閾值告警、趨勢告警、智能告警。告警規(guī)則不能只是簡單的多指標(biāo)拼湊要有依賴關(guān)系避免海量告警轟炸?？梢暬疓rafana配Prometheus或者Zabbix自帶圖表?！爸悄苓\(yùn)維”熱詞現(xiàn)在很流行但筆試?yán)锊挥枚迅拍睢Ｄ阋f明白“告警降噪”“根因定位”“故障預(yù)測”是怎么用數(shù)據(jù)實現(xiàn)的。例如把分鐘級指標(biāo)按時間序列存下來用波動檢測去發(fā)現(xiàn)異常而不是單純設(shè)一個固定閾值。6.2 Shell、Python自動化腳本考點(diǎn)筆試題里經(jīng)常出現(xiàn)“寫一個Shell腳本統(tǒng)計日志中某個接口的平均響應(yīng)時間”之類題目。這種題回答時要注意風(fēng)格不是讓你在IDE里寫完整項目而是考察你能否快速用管道實現(xiàn)需求。經(jīng)典答案是grep GET /api/order access.log | awk {print $NF} | awk {sum$1; count} END {print sum/count}如果日志字段更復(fù)雜可以用awk直接匹配awk /GET \/api\/order/ {sum$NF; count} END {if (count0) print sum/count} access.logPython自動化題則更偏向場景比如“給出一份主機(jī)清單寫一個腳本批量執(zhí)行命令并把結(jié)果匯總”。往paramiko或fabric方向答即可重點(diǎn)寫清楚異常處理和結(jié)果收集生產(chǎn)環(huán)境沒人愿意看裸的subprocess循環(huán)。6.3 經(jīng)典故障定位案例故障類題目最考驗綜合能力。舉一個高頻案例線上接口突然變慢CPU使用率100%你怎么排查我的排查順序是先用top -H -p pid定位哪個線程占用CPU高。用printf 0x%x\n pid把線程PID轉(zhuǎn)成十六進(jìn)制或者用jstack pid | grep -A 20 nidJava應(yīng)用場景。如果是Java應(yīng)用jstack看線程棧定位到業(yè)務(wù)代碼。如果不是Java用perf top看熱點(diǎn)函數(shù)。這種題的精髓不在于某個命令多高級而在于排查路徑清晰。你答的時候要邊講步驟邊解釋為什么比如“先用top -H是因為CPU高是線程級別的現(xiàn)象光看進(jìn)程PID不夠細(xì)”這種表達(dá)會讓閱卷人覺得你真的處理過線上事故。6.4 筆試題里的算法和數(shù)據(jù)結(jié)構(gòu)很多運(yùn)維候選人會忽略筆試中的編程題但京東這類公司不會因為你面的是運(yùn)維就不考算法。一般來說會有1到2道手寫代碼題難度在LeetCode簡單到中等之間比如字符串處理、數(shù)組遍歷、實現(xiàn)一個棧。運(yùn)維崗的算法題更偏實用。當(dāng)年出現(xiàn)過“統(tǒng)計日志里IP出現(xiàn)次數(shù)并排序”的題本質(zhì)就是Hashmap計數(shù)排序但要用腳本處理。如果你能寫出性能可觀的版本再補(bǔ)一句“如果日志量大用外部排序或者把統(tǒng)計邏輯直接下推到流處理平臺”會顯得你更有全局視野。7. 常見的問答題庫與避坑經(jīng)驗7.1 容易答錯的細(xì)節(jié)題我把當(dāng)年考試和后來復(fù)盤時最容易踩的細(xì)節(jié)坑整理成一張表大家可以對照自查考點(diǎn)易錯點(diǎn)正確理解df -h和df -i只看容量不考慮inode小文件場景必須看inodetcp_tw_recycle以為開啟就能解決TIME_WAITNAT環(huán)境開啟會丟包不推薦軟鏈接和硬鏈接以為支持目錄和跨文件系統(tǒng)硬鏈接不支持目錄不能跨文件系統(tǒng)緩沖區(qū)和緩存以為buff/cache是“正在用”的內(nèi)存可回收內(nèi)存內(nèi)核需要時會釋放HTTP 301和302忽略緩存差異301會被瀏覽器緩存302不會索引最左前綴忽略聯(lián)合索引的順序查詢條件要能匹配最左列才能用索引Docker鏡像層以為容器啟動后鏡像不變?nèi)萜鲗訉憰r復(fù)制鏡像本身不會變負(fù)載均衡四層和七層混淆LVS和Nginx定位LVS四層轉(zhuǎn)發(fā)能力強(qiáng)Nginx七層功能豐富7.2 做題順序和拿分技巧筆試時間有限我的建議是“先掃全卷先易后難”。運(yùn)維筆試很多知識是“看一眼就知道會不會”的選擇題答得快簡答題寫得多。遇到設(shè)計題不要留白把你想到的架構(gòu)分層寫出來哪怕只有一張圖配文字說明也會比空白多拿分。具體策略選擇題控制在2分鐘內(nèi)一道拿不準(zhǔn)的先標(biāo)記不要戀戰(zhàn)。簡答題先列點(diǎn)再展開。尤其“排查思路”類的題每個步驟寫一行有思路分。設(shè)計題先畫結(jié)構(gòu)框架再寫模塊說明。一個完整的“負(fù)載均衡層-應(yīng)用層-緩存層-存儲層-監(jiān)控層”分層結(jié)構(gòu)能覆蓋大部分踩分點(diǎn)。代碼題先寫自己能通過的簡單版本再優(yōu)化。不要因為想寫出最優(yōu)解而卡殼空著是最虧的。7.3 從真題延伸到面試現(xiàn)場筆試過了還有面試所以做完題不要急著對答案就完事要把錯題整理成知識點(diǎn)尤其是那些“好像理解、實際沒懂”的判斷。面試官大概率會拿筆試?yán)锏囊坏李}做切入點(diǎn)深挖下去。比如筆試題考了LVS的DR模式面試可能會追問DR模式為什么后端要配置lo上的VIP響應(yīng)包為什么能直接回給客戶端隱藏的arp問題怎么解決這些連問的目的就是測試你是不是真的理解原理而不是背過概念。我的建議是每一道錯題都給自己準(zhǔn)備一個“為什么”和一個“如果場景變化怎么處理”比如“如果后端和LVS跨網(wǎng)段怎么辦”這類追問。筆試只是起點(diǎn)把追問都考慮清楚面試才真正穩(wěn)。我個人刷這套題的最大體會是運(yùn)維崗位考察的核心從來不是“某個工具會不會用”而是“遇到問題是否有清晰的分析路徑”。Docker、K8s、Zabbix、Prometheus這些工具會一代代更替但網(wǎng)絡(luò)抓包分析的思路、性能排查的層次感、數(shù)據(jù)庫索引設(shè)計的原則這些底層方法論是長期有效的。所以如果你現(xiàn)在正準(zhǔn)備運(yùn)維崗筆試別只顧著刷最新熱詞把Linux、網(wǎng)絡(luò)、數(shù)據(jù)庫和故障排查的底子打牢比什么都有用。最后再分享一個習(xí)慣每刷完一套題把錯題按“原理缺失”和“場景經(jīng)驗不足”分類原理缺失去補(bǔ)書場景經(jīng)驗不足去搭虛擬機(jī)復(fù)現(xiàn)。堅持一個招聘季下來你的運(yùn)維體系會比刷題前扎實一大截。