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