簡(jiǎn)介一份面向運(yùn)維工程師崗位的面試題庫(kù)聚焦 Linux、Shell、Python、MySQL、Docker、Kubernetes 與網(wǎng)絡(luò)七大高頻方向適合正在準(zhǔn)備中高級(jí)運(yùn)維面試的求職者也適合團(tuán)隊(duì)開(kāi)展技術(shù)摸底與知識(shí)查漏補(bǔ)缺。內(nèi)容按模塊組織覆蓋進(jìn)程與文件系統(tǒng)管理、Shell 變量及腳本編寫(xiě)、Python 數(shù)據(jù)類(lèi)型與迭代器、MySQL 主從原理和事務(wù)隔離級(jí)別、Docker 容器狀態(tài)與 Dockerfile 指令、K8s 核心組件與數(shù)據(jù)持久化方式以及 TCP/UDP、HTTP 等網(wǎng)絡(luò)基礎(chǔ)題。題目不是簡(jiǎn)單羅列還穿插場(chǎng)景化問(wèn)題與命令排查示例例如根分區(qū)滿如何定位、判斷在線 IP、檢查 URL 可用性、啟動(dòng)并掛載 Nginx 容器等。資源整理為一份 PDF 文檔大小約 890KB雖僅 1 個(gè)文件但知識(shí)點(diǎn)密度較高便于集中翻閱和考前沖刺。目前已有 674 人瀏覽學(xué)習(xí)是一套貼合運(yùn)維面試高頻考點(diǎn)的實(shí)用復(fù)習(xí)資料。1. 運(yùn)維面試到底在考什么七個(gè)技術(shù)點(diǎn)的同一張考卷先說(shuō)一個(gè)反直覺(jué)的觀察運(yùn)維面試被刷的人大多不是不會(huì)技術(shù)而是把技術(shù)答成了背課文。面試官問(wèn)“線上CPU飆高你怎么查”有人能從top背到vmstat卻不說(shuō)先看哪個(gè)指標(biāo)、什么時(shí)候該懷疑誰(shuí)。這份面試題的標(biāo)題圈定了七個(gè)技術(shù)點(diǎn)——Linux、Shell、Python、MySQL、Docker、K8s、網(wǎng)絡(luò)看似各自獨(dú)立實(shí)際考的是同一件事你知不知道組件原理你能不能動(dòng)手把事情查出來(lái)、修好并驗(yàn)證。對(duì)帶運(yùn)維崗的團(tuán)隊(duì)來(lái)說(shuō)他們要的是一個(gè)能進(jìn)生產(chǎn)環(huán)境接手事故的人不是一個(gè)默寫(xiě)命令的人。下面按這七塊拆解高頻考點(diǎn)、手寫(xiě)題目與踩坑記錄適合準(zhǔn)備運(yùn)維和SRE崗位面試的人也適合需要把“會(huì)背”變成“會(huì)做”的開(kāi)發(fā)同學(xué)。2. Linux與Shell高頻命令與手寫(xiě)腳本的思路2.1 高頻命令題在問(wèn)什么top、ss、ps 背后是一條定位鏈運(yùn)維面試的Linux題很少直接讓背參數(shù)開(kāi)場(chǎng)通常是“線上CPU高了你怎么辦”隨后用top不斷追問(wèn)。所以答題順序本身就是考點(diǎn)先用top看負(fù)載與CPU比例接著用ps -eo pid,comm,%cpu --sort-%cpu找進(jìn)程再用top -H -p看線程必要時(shí)用perf top看熱點(diǎn)函數(shù)。這一串不是命令清單而是一條“負(fù)載→進(jìn)程→線程→熱點(diǎn)”的定位鏈答完這條鏈面試官才會(huì)認(rèn)為你是真排過(guò)障。端口類(lèi)是另一個(gè)高頻場(chǎng)景問(wèn)“8080端口被占你怎么查”。我一般答ss -lntp | grep 8080看監(jiān)聽(tīng)狀態(tài)ss -tpn | grep 8080看已有連接再配合lsof -i:8080確認(rèn)進(jìn)程。面試官常追問(wèn)為什么不優(yōu)先用netstat這時(shí)要答ss直接讀內(nèi)核socket信息在連接量大時(shí)比netstat遍歷文件描述符更快這也是新系統(tǒng)默認(rèn)裝ss的原因。順著這個(gè)點(diǎn)還能帶出“監(jiān)聽(tīng)端口”和“已建立連接”的區(qū)別說(shuō)明你分得清服務(wù)是否真的在對(duì)外提供能力。進(jìn)程狀態(tài)題也常出現(xiàn)重點(diǎn)是ps輸出里的D和Z。D是不可中斷睡眠通常和IO排隊(duì)有關(guān)磁盤(pán)慢或存儲(chǔ)設(shè)備卡住會(huì)積壓一堆D進(jìn)程Z是僵尸代表子進(jìn)程退出后父進(jìn)程沒(méi)有調(diào)用wait回收。這類(lèi)題想聽(tīng)的是“看到D能不能想到IO、看到Z能不能想到父進(jìn)程”而不是背字母意義?；卮饡r(shí)補(bǔ)一句“僵尸進(jìn)程要看父進(jìn)程能不能重啟或回收不能直接kill -9”就能和只背概念的人拉開(kāi)差距。磁盤(pán)與IO題同樣高頻iostat -x 1看util和awaitdf -h看空間du -sh *看目錄占用。追問(wèn)“磁盤(pán)滿了卻找不到大文件”時(shí)要想到已刪除但還被進(jìn)程占用的文件用lsof L1列出再確認(rèn)進(jìn)程能否重啟。這個(gè)案例能體現(xiàn)排查鏈路不只在命令本身還在于你知道文件系統(tǒng)“空間被占”和“文件被刪”是兩回事。systemd題也一樣。systemctl status看服務(wù)狀態(tài)和最近日志journalctl -u看單元日志systemctl list-unit-files看開(kāi)機(jī)自啟。我會(huì)把“查服務(wù)→查日志→查自啟”串成一句話回答面試官順著問(wèn)“服務(wù)起不來(lái)怎么辦”再補(bǔ)systemctl status里的Active狀態(tài)與journalctl -xeu的報(bào)錯(cuò)片段整條鏈路就閉合了。2.2 手寫(xiě)Shell腳本清理日志與CPU監(jiān)控兩類(lèi)典型題一類(lèi)是日志清理腳本面試官常要求寫(xiě)出“保留近7天日志刪除更早文件”#!/bin/bash # 保留近7天日志刪除目錄下更早的.log文件并輸出清理明細(xì) LOG_DIR/var/log/myapp KEEP_DAYS7 if [ ! -d $LOG_DIR ]; then echo 目錄不存在: $LOG_DIR exit 1 fi # -mtime N 匹配修改時(shí)間超過(guò)N天的文件-print 在刪除前記錄文件名 find $LOG_DIR -type f -name *.log -mtime $KEEP_DAYS -print -delete df -h $LOG_DIR邏輯說(shuō)明腳本先做目錄存在性判斷避免在cron環(huán)境里因變量為空而跑進(jìn)錯(cuò)誤路徑find的-mtime 7匹配超過(guò)7天未修改的文件-print先打印再-delete刪除方便留審計(jì)記錄。參數(shù)說(shuō)明KEEP_DAYS按日志保留策略調(diào)整LOG_DIR必須寫(xiě)絕對(duì)路徑因?yàn)閏ron的PATH很精簡(jiǎn)相對(duì)路徑是常見(jiàn)翻車(chē)點(diǎn)。生產(chǎn)接入前建議先用-ls替代-delete試跑一輪確認(rèn)命中文件數(shù)和預(yù)期一致再放開(kāi)刪除。另一類(lèi)是CPU監(jiān)控腳本考察“采樣和判斷”而不是語(yǔ)法#!/bin/bash # 當(dāng)CPU空閑率低于20%時(shí)記錄Top5進(jìn)程并寫(xiě)入系統(tǒng)日志 # CPU_IDLE 取 vmstat 兩次采樣中的第二次避免啟動(dòng)瞬時(shí)值干擾 CPU_IDLE$(vmstat 1 2 | tail -1 | awk {print $15}) THRESHOLD20 if [ $CPU_IDLE -lt $THRESHOLD ]; then # 先留現(xiàn)場(chǎng)再告警防止故障現(xiàn)場(chǎng)被后續(xù)操作覆蓋 ps -eo pid,comm,%cpu,%mem --sort-%cpu | head -6 /var/log/cpu_alert_$(date %Y%m%d_%H%M%S).log logger -t cpu_monitor CPU idle ${CPU_IDLE}%, below threshold ${THRESHOLD}% fi邏輯說(shuō)明vmstat 1 2表示間隔1秒采樣兩次第一次是調(diào)用瞬間的值第二次更穩(wěn)定tail -1取最后一行awk取第15列idle判斷寫(xiě)成“空閑率低于閾值”而不是“使用率高于閾值”數(shù)值關(guān)系更直觀。參數(shù)說(shuō)明THRESHOLD與采樣次數(shù)可按監(jiān)控粒度調(diào)整生產(chǎn)上建議由cron每5分鐘調(diào)度不要常駐循環(huán)避免監(jiān)控腳本本身抬高了負(fù)載這一點(diǎn)面試官經(jīng)常追問(wèn)。2.3 綜合排查思路現(xiàn)象、定位、確認(rèn)、恢復(fù)面試官常把Linux與Shell串成綜合題“用戶反饋?lái)?yè)面打不開(kāi)你怎么排查”這時(shí)候背命令無(wú)效要答步驟。我一般按四步走先確認(rèn)現(xiàn)象是超時(shí)、報(bào)錯(cuò)還是拒絕再按“客戶端→網(wǎng)絡(luò)→服務(wù)端”分段定位關(guān)鍵操作前先留現(xiàn)場(chǎng)抓包或保存日志恢復(fù)后主動(dòng)驗(yàn)證。這套順序能串聯(lián)零散考點(diǎn)也是我處理線上故障攢下來(lái)的血淚經(jīng)驗(yàn)。具體展開(kāi)現(xiàn)象登記要明確偶發(fā)還是必現(xiàn)、影響范圍多大常見(jiàn)做法是先用ping和telnet端口做分層能擋掉一半問(wèn)題。定位順序建議是系統(tǒng)層先看load與CPU、內(nèi)存、磁盤(pán)IO再進(jìn)程層看top和ps狀態(tài)最后應(yīng)用層看日志與慢查詢順序反了很容易被應(yīng)用日志里的表面錯(cuò)誤帶偏。留現(xiàn)場(chǎng)環(huán)節(jié)dmesg、journalctl、抓包文件先落盤(pán)再操作重啟會(huì)毀掉事故現(xiàn)場(chǎng)?；謴?fù)與驗(yàn)證階段先止血再根治恢復(fù)后模擬請(qǐng)求確認(rèn)服務(wù)真的可用而不是進(jìn)程活著就算好。這套框架答下來(lái)比單獨(dú)堆命令更接近生產(chǎn)環(huán)境里真正要做的事。3. Python與MySQL日志腳本與數(shù)據(jù)庫(kù)優(yōu)化的高頻題3.1 Python運(yùn)維題的真面目不考框架考處理思路運(yùn)維面試?yán)锏腜ython通常不考Web框架考腳本能力和自動(dòng)化意識(shí)。常見(jiàn)三類(lèi)日志文本處理、批量運(yùn)維操作、小工具編寫(xiě)?？疾禳c(diǎn)集中在會(huì)不會(huì)用標(biāo)準(zhǔn)庫(kù)、會(huì)不會(huì)控制內(nèi)存與異常、能不能把腳本接到現(xiàn)有流程里。答題順序建議先講思路再動(dòng)筆面試官更關(guān)心對(duì)數(shù)據(jù)的遍歷邏輯而不是語(yǔ)法技巧。比如處理一個(gè)大文件先問(wèn)清楚文件格式、行數(shù)級(jí)、要不要保留中間態(tài)再?zèng)Q定用正則還是字符串切分。批量操作題也經(jīng)常出現(xiàn)常見(jiàn)做法是寫(xiě)一個(gè)分發(fā)腳本用并發(fā)池限制同時(shí)執(zhí)行的機(jī)器數(shù)每臺(tái)機(jī)器單獨(dú)拿到結(jié)果。我一般會(huì)強(qiáng)調(diào)三點(diǎn)連接要設(shè)置超時(shí)避免一臺(tái)機(jī)器卡死拖垮整個(gè)任務(wù)結(jié)果要按IP落盤(pán)方便對(duì)賬執(zhí)行前先打印要執(zhí)行的命令做一次演練而不是直接鋪到幾百臺(tái)機(jī)器上。這三點(diǎn)比“會(huì)用paramiko”更能證明你有批量操作的經(jīng)驗(yàn)。3.2 手寫(xiě)日志分析腳本從正則到統(tǒng)計(jì)#!/usr/bin/env python3 # 統(tǒng)計(jì)Nginx access.log 中訪問(wèn)次數(shù)Top5的IP # 常見(jiàn)做法是逐行匹配行首IP而不是一次性 read() 全部讀入 import re from collections import Counter LOG_PATH /var/log/nginx/access.log # 匹配IPv4地址四段數(shù)字分組用于提取完整IP ip_pat re.compile(r^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})) counter Counter() with open(LOG_PATH, r, errorsignore) as f: for line in f: m ip_pat.match(line) if m: counter[m.group(1)] 1 for ip, cnt in counter.most_common(5): print(f{ip}\t{cnt})邏輯說(shuō)明open使用errorsignore避免日志中個(gè)別亂碼行讓整個(gè)腳本中斷for line in f按迭代器逐行讀取不會(huì)把幾十GB的日志一次性加載進(jìn)內(nèi)存most_common(5)直接返回計(jì)數(shù)最高的前5項(xiàng)。參數(shù)說(shuō)明如果要統(tǒng)計(jì)請(qǐng)求路徑或狀態(tài)碼把正則的可變段替換成對(duì)應(yīng)分組即可LOG_PATH建議由命令行參數(shù)傳入方便復(fù)用而不是每次改腳本。面試官如果追問(wèn)“日志有幾十GB怎么辦”重點(diǎn)不是換語(yǔ)言而是講清楚逐行處理已把內(nèi)存壓平瓶頸在IO要更快可以按時(shí)間切片做并行分片或者把統(tǒng)計(jì)結(jié)果落成流式中間值。能講出這條思路比貼一段pandas代碼更能體現(xiàn)運(yùn)維視角。如果日志里混了IPv6地址正則就要按冒號(hào)分段的規(guī)則調(diào)整這也是數(shù)據(jù)格式意識(shí)的一個(gè)體現(xiàn)。3.3 MySQL高頻題主從復(fù)制、索引失效與慢查詢MySQL題目的高頻區(qū)間很集中主從復(fù)制原理、索引失效、慢查詢、事務(wù)隔離級(jí)別。答主從復(fù)制時(shí)我習(xí)慣按一條鏈路講應(yīng)用寫(xiě)主庫(kù)→主庫(kù)寫(xiě)binlog→從庫(kù)IO線程拉日志寫(xiě)入relay log→SQL線程重放。面試官通常接著問(wèn)binlog格式row格式記錄變更后每一行的值最準(zhǔn)確但日志量大statement格式記錄原始SQL量小但部分函數(shù)在主從執(zhí)行結(jié)果可能不一致mixed是兩者折中。能區(qū)分三種格式就明顯區(qū)別于只會(huì)背“主從同步”的候選人。索引題里反復(fù)出現(xiàn)的坑是在索引列上套函數(shù)、隱式類(lèi)型轉(zhuǎn)換、左模糊like都會(huì)讓索引失效。EXPLAIN輸出重點(diǎn)看type、key、rows三列type為ALL時(shí)基本能斷定全表掃描。SQL優(yōu)化題的標(biāo)準(zhǔn)回答順序先EXPLAIN看執(zhí)行計(jì)劃再確認(rèn)where條件字段的索引再看查詢字段能否只走覆蓋索引最后才調(diào)整SQL結(jié)構(gòu)不能上來(lái)就改語(yǔ)句。慢查詢定位也?？即_認(rèn)slow_query_log是否開(kāi)啟分析慢SQL日志里的Rows_examined與耗時(shí)再用EXPLAIN驗(yàn)證優(yōu)化效果-- 慢查詢定位先確認(rèn)執(zhí)行計(jì)劃再?zèng)Q定是否補(bǔ)索引或調(diào)整查詢結(jié)構(gòu) EXPLAIN SELECT u.id, u.name, o.order_no FROM user u LEFT JOIN orders o ON u.id o.user_id WHERE u.status 1 AND o.created_at 2024-01-01;邏輯說(shuō)明EXPLAIN不會(huì)真正執(zhí)行SQL只輸出執(zhí)行計(jì)劃關(guān)注type列是否從ALL變成ref或rangekey列是否用到目標(biāo)索引rows列估算掃描行數(shù)是否明顯下降。參數(shù)說(shuō)明u.status 1如果有索引但區(qū)分度低優(yōu)化器可能放棄索引o.created_at列上如果沒(méi)索引說(shuō)明需要補(bǔ)一個(gè)復(fù)合索引覆蓋user_id created_at兩個(gè)條件會(huì)更有效。回答時(shí)給結(jié)論生產(chǎn)環(huán)境優(yōu)先保證數(shù)據(jù)一致性與刷新再談性能調(diào)優(yōu)。4. Docker與K8s容器編排面試的完整回答鏈4.1 Docker考點(diǎn)鏡像分層、生命周期與數(shù)據(jù)持久化Docker的面試題一般圍繞三條線鏡像怎么構(gòu)建、容器怎么跑、數(shù)據(jù)怎么持久化。鏡像分層是最該講透的題目Dockerfile每條指令生成一個(gè)只讀層層可復(fù)用容器運(yùn)行時(shí)才在只讀層上疊加可寫(xiě)層寫(xiě)時(shí)復(fù)制發(fā)生在容器層。答到“多個(gè)容器共享同一個(gè)基礎(chǔ)鏡像的只讀層”就抓住了核心這也能解釋為什么鏡像比虛擬機(jī)輕以及為什么構(gòu)建時(shí)要把不常變的依賴放在Dockerfile前面。生命周期題常借“為什么kill不掉容器”來(lái)問(wèn)。答案要點(diǎn)是PID命名空間、進(jìn)程信號(hào)和主進(jìn)程的處理邏輯docker stop先發(fā)SIGTERM超時(shí)后發(fā)SIGKILL如果容器內(nèi)的主進(jìn)程沒(méi)有正確捕獲SIGTERM做優(yōu)雅退出容器就會(huì)在超時(shí)后才被殺。排查順序一般是docker top看進(jìn)程、docker inspect看State.ExitCode和OOMKilled、docker logs看退出前日志三步能定位多數(shù)情況。數(shù)據(jù)持久化是容易答漏的點(diǎn)。volume由Docker管理適合數(shù)據(jù)庫(kù)等需要長(zhǎng)期保存的數(shù)據(jù)bind mount直接映射宿主機(jī)路徑方便調(diào)試但權(quán)限處理麻煩tmpfs放臨時(shí)文件不落盤(pán)。值得強(qiáng)調(diào)的細(xì)節(jié)是容器刪除后volume不會(huì)跟著刪這個(gè)常被忽略也是誤刪容器后找回?cái)?shù)據(jù)的重要兜底。4.2 K8s考點(diǎn)Pod生命周期、探針與網(wǎng)絡(luò)模型K8s高頻題我歸成三組Pod生命周期與狀態(tài)、探針、網(wǎng)絡(luò)模型。Pod生命周期題常問(wèn)“Pod一直P(pán)ending怎么辦”。答題時(shí)先說(shuō)kubectl describe pod看Events再按優(yōu)先級(jí)查節(jié)點(diǎn)資源、鏡像拉取、親和性與污點(diǎn)約束。Events是K8s故障排查的第一現(xiàn)場(chǎng)比看Pod狀態(tài)本身更有信息量很多人一上來(lái)就盯著STATUS列其實(shí)是走錯(cuò)了方向。探針題考三個(gè)概念的分工livenessProbe決定容器是否重啟readinessProbe決定流量是否放入startupProbe解決啟動(dòng)慢的容器被探針?lè)磸?fù)打斷的問(wèn)題?；卮饡r(shí)把三者職責(zé)講清再順帶提一嘴YAML字段。比如Java應(yīng)用啟動(dòng)慢如果只配liveness很可能在啟動(dòng)階段就被連續(xù)失敗重啟配一個(gè)startupProbe給足啟動(dòng)窗口才是符合實(shí)際的解法。網(wǎng)絡(luò)模型題我一般用“每個(gè)Pod一個(gè)IP、Pod內(nèi)容器共享網(wǎng)絡(luò)?！遍_(kāi)頭再講Service通過(guò)標(biāo)簽選擇器關(guān)聯(lián)Endpointskube-proxy用iptables或ipvs轉(zhuǎn)發(fā)CNI插件負(fù)責(zé)為Pod分配IP常見(jiàn)的是Bridge模式或Overlay模式。要點(diǎn)是把Pod、Service、kube-proxy、CNI四者的職責(zé)說(shuō)成一條鏈而不是單獨(dú)背名詞。被追問(wèn)“Service找不到后端Pod時(shí)怎么辦”我習(xí)慣答先kubectl get endpoints看Endpoints是否有地址再看Service的selector與Pod標(biāo)簽是否一致最后確認(rèn)Pod是否Ready三條查完基本能定位問(wèn)題。4.3 資源限制與鏡像不可變兩個(gè)易答偏的落地細(xì)節(jié)資源限制題問(wèn)“容器內(nèi)存超了會(huì)怎樣”Docker層面會(huì)發(fā)生OOM KillK8s層面則可能殺掉容器甚至驅(qū)逐Pod。這里有個(gè)常見(jiàn)混淆點(diǎn)requests與limits的職責(zé)不同requests是調(diào)度依據(jù)決定Pod能落在哪個(gè)節(jié)點(diǎn)limits是運(yùn)行時(shí)硬上限內(nèi)存超限就會(huì)觸發(fā)OOMKilled。答出“l(fā)imit不等于預(yù)留request才是調(diào)度依據(jù)”會(huì)明顯加分。# 典型Pod資源限制示例request是調(diào)度依據(jù)limit是運(yùn)行上限 apiVersion: v1 kind: Pod metadata: name: demo-app spec: containers: - name: app image: demo-app:latest resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi邏輯說(shuō)明requests里的cpu 500m表示半個(gè)核心調(diào)度器按各節(jié)點(diǎn)可用量判斷放置位置limits里的cpu 1表示最多用一個(gè)核心memory 1Gi是硬上限超限容器會(huì)被殺掉。參數(shù)說(shuō)明Mi/Gi是二進(jìn)制單位m是千分之一核內(nèi)存limit不建議與request差太多否則節(jié)點(diǎn)內(nèi)存會(huì)因超賣(mài)被清空或驅(qū)逐。生產(chǎn)上還需要結(jié)合壓測(cè)結(jié)果確定不是照抄模板。鏡像倉(cāng)庫(kù)相關(guān)考題我提醒答兩個(gè)點(diǎn)鏡像tag不是不可變標(biāo)識(shí)相同tag可能被覆蓋生產(chǎn)推薦用digest精確定位鏡像鏡像刪除后不能從倉(cāng)庫(kù)層直接恢復(fù)正確做法是保留構(gòu)建產(chǎn)物和digest記錄必要時(shí)做制品備份。誠(chéng)實(shí)說(shuō)“沒(méi)有后悔藥”比假裝能找回更可信。被追問(wèn)“線上鏡像被覆蓋了怎么辦”時(shí)我的回答是先切回上一個(gè)可用digest再?gòu)腃I產(chǎn)物重建推送同時(shí)補(bǔ)一條tag不可變策略把問(wèn)題從“急救”變成“根治”。5. 網(wǎng)絡(luò)與綜合排查從TCP到DNS的高頻題與避坑記錄5.1 TCP與HTTP高頻題握手異常與狀態(tài)碼網(wǎng)絡(luò)基礎(chǔ)必考TCP三次握手、四次揮手但運(yùn)維面試更偏向異常狀態(tài)。我常用框架握手看SYN、SYN-ACK、ACK是否成對(duì)半連接隊(duì)列或全連接隊(duì)列滿時(shí)會(huì)表現(xiàn)為連接超時(shí)或拒絕TIME_WAIT堆積通常出現(xiàn)在高并發(fā)短連接場(chǎng)景。回答時(shí)把“現(xiàn)象→隊(duì)列/狀態(tài)→驗(yàn)證命令”串成一條線比背狀態(tài)含義更穩(wěn)。比如連接超時(shí)先看ss -s里的SYN-RECV數(shù)量再判斷是半連接隊(duì)列溢出還是丟包。HTTP狀態(tài)碼也?？肌?02一般代表網(wǎng)關(guān)拿不到上游正常響應(yīng)504是上游響應(yīng)超時(shí)和502的區(qū)分在于是“沒(méi)有響應(yīng)”還是“響應(yīng)太慢”。答題時(shí)我會(huì)補(bǔ)排查方向502先看上線上游的連接與健康檢查504先看上游處理耗時(shí)與超時(shí)配置。只說(shuō)含義不說(shuō)排查在運(yùn)維面會(huì)顯得單薄。如果被追問(wèn)“502時(shí)后端進(jìn)程還活著”答案要點(diǎn)是進(jìn)程活著不代表端口正常也不代表健康檢查通過(guò)要用curl直接打后端探活而不是看進(jìn)程列表。5.2 一條命令鏈?zhǔn)諗n網(wǎng)絡(luò)排查現(xiàn)場(chǎng)題“用戶說(shuō)網(wǎng)站打不開(kāi)”我一般按這個(gè)命令鏈走# 1. 先確認(rèn)三層連通性ping只證明ICMP可達(dá)不代表服務(wù)端口可用 ping -c 3 example.com # 2. 確認(rèn)四層端口與TCP握手-z 只探測(cè)不發(fā)送數(shù)據(jù)-w 設(shè)置超時(shí) nc -zv -w 3 example.com 443 # 3. 看DNS解析結(jié)果排查解析到錯(cuò)誤IP或本地緩存臟數(shù)據(jù) dig short example.com # 4. curl帶超時(shí)拿響應(yīng)碼和耗時(shí)區(qū)分網(wǎng)絡(luò)問(wèn)題還是應(yīng)用問(wèn)題 curl -sS -o /dev/null -w %{http_code} %{time_total}\n --connect-timeout 5 https://example.com/ # 5. mtr看鏈路每一跳的丟包與延遲適合跨公網(wǎng)鏈路定位 mtr -rw -c 10 example.com邏輯說(shuō)明ping、nc、dig、curl分別驗(yàn)證三層、四層、DNS、七層哪一步先異常就往哪一層深入避免在錯(cuò)誤層浪費(fèi)排查時(shí)間。參數(shù)說(shuō)明nc的-z表示只探測(cè)端口不傳輸數(shù)據(jù)-v輸出詳情-w 3是超時(shí)3秒curl的--connect-timeout建議5秒避免長(zhǎng)時(shí)間掛起mtr的-c 10表示探測(cè)10個(gè)包-r是報(bào)告模式-w是寬行輸出適合腳本化記錄。面試官接下來(lái)大概率追問(wèn)“為什么ping通了但業(yè)務(wù)不通”。答案很直接ping只測(cè)ICMP證明不了TCP端口和HTTP服務(wù)必須用nc確認(rèn)端口再用curl確認(rèn)應(yīng)用響應(yīng)。這條回答能擋住一長(zhǎng)串網(wǎng)絡(luò)排查追問(wèn)。如果每跳都通但業(yè)務(wù)仍異常就要考慮防火墻策略、安全組或云平臺(tái)轉(zhuǎn)發(fā)規(guī)則這些不會(huì)在ping結(jié)果里體現(xiàn)。5.3 避坑記錄三個(gè)我見(jiàn)過(guò)最多人答錯(cuò)的網(wǎng)絡(luò)題現(xiàn)象1把“一次完整的HTTPS請(qǐng)求”答成“先TCP三次握手再發(fā)請(qǐng)求”漏了DNS、TLS握手和連接復(fù)用。原因把課本分層和真實(shí)鏈路揉在一起。解決按“DNS→TCP握手→TLS握手→HTTP請(qǐng)求→響應(yīng)解析→連接關(guān)閉或復(fù)用”排成一條可復(fù)述鏈路面試官一般會(huì)順著鏈路追問(wèn)每一步異常時(shí)看什么鏈條完整就不會(huì)突然卡殼。現(xiàn)象2被問(wèn)TIME_WAIT堆積只答“調(diào)小time_wait”沒(méi)說(shuō)是哪一方觸發(fā)、影響在哪個(gè)環(huán)節(jié)。原因只背了優(yōu)化項(xiàng)不理解狀態(tài)機(jī)。解決先說(shuō)明大量TIME_WAIT常見(jiàn)于服務(wù)端主動(dòng)關(guān)閉短連接不要盲目調(diào)tcp_tw_reuse優(yōu)先排查應(yīng)用是否在頻繁主動(dòng)斷開(kāi)考慮連接池或長(zhǎng)連接方案。調(diào)參是最后手段而且新內(nèi)核里tcp_tw_reuse的生效條件很?chē)?yán)格背錯(cuò)參數(shù)比不答更扣分?，F(xiàn)象3看到抓包里有TCP重傳就直接說(shuō)“網(wǎng)絡(luò)丟包”。原因沒(méi)確認(rèn)對(duì)端ACK與亂序情況。解決對(duì)比seq與ack的差值觀察重復(fù)ACK和重傳距離結(jié)合業(yè)務(wù)流量判斷是整鏈路丟包還是單條連接抖動(dòng)判定后再?zèng)Q定要不要切鏈路或調(diào)TCP參數(shù)。抓包文件里同樣一段數(shù)據(jù)亂序?qū)е碌目焖僦貍骱驼嬲膩G包重傳處理方向完全不同?，F(xiàn)象4DNS排查只用ping不用dig拿到錯(cuò)誤IP還繼續(xù)查網(wǎng)絡(luò)。原因排查順序不對(duì)習(xí)慣先ping。解決先dig short拿到解析結(jié)果再ping解析出的IP如果懷疑本地緩存臟先刷新緩存再走后續(xù)排查。域名解析是HTTP鏈路的最前端這步錯(cuò)了后面所有網(wǎng)絡(luò)結(jié)論都會(huì)跑偏。6. 面試現(xiàn)場(chǎng)技巧把會(huì)的東西用五步框架講清楚面試過(guò)半剩下考察的往往是“會(huì)不會(huì)表達(dá)”。我自己的習(xí)慣是準(zhǔn)備面試不靠刷題而是把一臺(tái)測(cè)試虛擬機(jī)刻意搞崩再修好練到手指記得住命令。答題時(shí)我用一個(gè)五步模板“現(xiàn)象—定位—確認(rèn)—恢復(fù)—驗(yàn)證”能套住絕大部分故障場(chǎng)景。先說(shuō)答題順序。面試官問(wèn)CPU高不要從Linux啟動(dòng)講到進(jìn)程調(diào)度先給結(jié)論“我先用top看us與sy比例us高查應(yīng)用sy高查系統(tǒng)調(diào)用與鎖”然后按定位鏈展開(kāi)。原理題也一樣先給結(jié)論再給依據(jù)例如主從復(fù)制先答“主庫(kù)寫(xiě)binlog、從庫(kù)IO線程拉取、SQL線程重放”再展開(kāi)格式細(xì)節(jié)。這樣面試官能立刻抓到你的邏輯主干追問(wèn)也有抓手。其次是寫(xiě)代碼時(shí)主動(dòng)講邊界。面試官看著你寫(xiě)Shell或Python時(shí)強(qiáng)調(diào)“逐行讀文件防內(nèi)存占用”“find先試跑再delete”“腳本路徑用絕對(duì)路徑”這些細(xì)節(jié)比完整寫(xiě)完腳本更體現(xiàn)生產(chǎn)經(jīng)驗(yàn)。寫(xiě)腳本前先問(wèn)一句“數(shù)據(jù)量大概多大、跑在什么環(huán)境”比悶頭寫(xiě)更容易得分因?yàn)槊嬖嚬倏嫉木褪悄懿荒馨凑鎸?shí)場(chǎng)景收斂方案。最后一個(gè)技巧是主動(dòng)暴露驗(yàn)證方式?；卮鹜辍拔矣胕ptables做轉(zhuǎn)發(fā)”后補(bǔ)一句“驗(yàn)證方式是臨時(shí)加規(guī)則后從對(duì)端實(shí)際請(qǐng)求一次確認(rèn)生效再寫(xiě)持久化配置”回答完“我開(kāi)了慢查詢?nèi)罩尽焙笱a(bǔ)一句“取一條慢SQL做EXPLAIN對(duì)比優(yōu)化前后rows變化”。這套“怎么驗(yàn)證它真的對(duì)了”的表達(dá)是區(qū)分老手和新手最明顯的地方。我組織過(guò)很多次備考最深的教訓(xùn)是面試中答不出的點(diǎn)平時(shí)在測(cè)試環(huán)境也多半沒(méi)有親手排過(guò)。與其背題不如把七個(gè)領(lǐng)域的關(guān)鍵路徑各練順手。祝面試順利希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取