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