1. 題目拆解與考察方向分析1.1 這份第二部分到底在考什么先說個整體印象。金山辦公的校招筆試尤其是運維開發這個崗和單純背命令、背配置的傳統運維筆試有本質區別。它叫運維開發不是系統運維不是網絡運維這個名字本身就是在告訴你你的核心價值是用開發能力解決運維問題。我在一線做運維開發也有些年頭了帶過不少新人也幫朋友公司出過類似的筆試題。我的整體感受是這類第二部分的筆試通常是在第一輪基礎考核Linux命令、網絡基礎、SQL這類之上做一次篩選式進階。什么意思呢就是它不再問某條命令怎么用而是問在什么場景下你會選擇哪條命令、為什么給你一個具體問題你如何設計一套自動化解決方案。前者考記憶后者考工程思維。所以如果你打算裸考或者以為把《鳥哥的Linux私房菜》翻一遍就夠那大概率會在第二部分翻車。真正能拉開差距的是這幾類題目腳本編程與邏輯設計、數據庫與緩存的實際應用、故障排查與性能分析、CI/CD與容器化思路。后面我會逐個拆開講。1.2 考察重點與崗位需求的對應關系金山辦公的產品線很重WPS、云文檔、協同辦公這些業務對服務的穩定性、API的響應速度、數據的一致性都有很高要求。運維開發崗在這樣一家公司里日常要做的事包括但不限于維護大規模服務器的穩定運行、推動發布流程自動化、設計監控告警體系、處理線上故障、優化中間件性能。這就決定了筆試題目會往這些方向傾斜。我總結下來第二部分的題目的核心考察點大概有四塊第一腳本和編程能力。也就是你能否自動化地處理文件批量操作、日志分析、文本抽取這種真實場景。第二數據庫和緩存設計。你的MySQL慢查詢優化、Redis緩存策略是不是真的有實際經驗支撐而不是只背了八股文。第三系統排查和性能分析。給你一臺高負載服務器你如何定位瓶頸、怎么處理。第四運維開發工具鏈和CI/CD。你對Git、Jenkins、Docker、K8s這些工具的理解深度是否停留在用過層面。整份卷子的邏輯其實是先考你會不會寫代碼解決問題再考你懂不懂系統底層最后考你有沒有全局工程化思維。我把這套邏輯反過來從應試者的角度拆解一下每類題目的準備方法。2. 腳本編程與自動化處理筆試題的重頭戲2.1 Shell與Python的典型考題形式先說Shell。凡是考運維開發Shell腳本幾乎是必出的而且一般不會直接問你echo是什么意思而是給你一段殘缺的腳本讓你補全或者讓你實現一個具體的功能。比如統計Nginx訪問日志中IP出現的次數并按次數降序排列。找出某個目錄下7天前修改過、大于100MB的日志文件并清理。檢查一組服務器的端口連通性異常時輸出報警信息。這些題目表面上看是在考命令實際上考的是你懂不懂真實運維場景下的自動巡檢思路。執行順序、退出碼處理、定時任務怎么對接這些才是題目想看的。再一個高頻考點是Python。注意這里考的不是語法而是腳本的健壯性。比如讓你寫一個腳本讀取一個CSV文件過濾出特定條件的數據再寫入另一個文件。這時候考官在意的點包括你有沒有處理文件不存在的情況、有沒有考慮內存占用用流式逐行讀而不是一次性readlines、有沒有處理異常并輸出日志。如果你只是寫出能跑的代碼分數可能不會太高。如果你能多寫一個裝飾器記錄運行耗時或者加上參數解析支持命令行傳參這就能明顯拉開差距。我在實際工作中寫自動化腳本的習慣是能復用函數就復用不寫一坨到底的面條代碼所有可能拋異常的地方一定要有捕獲和錯誤日志腳本執行結束后必須有明確的輸出提示。這些習慣可以直接遷移到筆試答題里。2.2 一種更高效的答題思路先設計再動手很多同學看到編程題第一反應是直接打開編輯器想到哪寫到哪。這個習慣在筆試里特別吃虧因為筆試題給的空格有限閱卷人看的是你的邏輯不是你敲代碼的速度。我建議的答題順序是先在草稿紙上把輸入、處理、輸出三個環節列出來明確每一步可能出現的異常情況再動筆寫代碼。舉個例子如果題目要求讀取某個配置文件解析出所有keyvalue的鍵值對并檢查有沒有重復key你在動手前就要想清楚配置文件格式是統一的keyvalue嗎有沒有可能包含注釋行或者空行重復key怎么處理是報錯、忽略還是保留最后一個如果value本身含有符號呢比如urlhttp://a.com/bc這種情況split()以后要不要限制分割次數想清楚這三件事你寫出來的代碼結構是完全不同的。第一種寫法可能是config_dict {} with open(config.ini) as f: for line in f: key, value line.strip().split() if key in config_dict: raise ValueError(fduplicate key: {key}) config_dict[key] value但如果你考慮到了value中可能含就會寫成config_dict {} with open(config.ini) as f: for line in f: line line.strip() if not line or line.startswith(#): continue key, _, value line.partition() key key.strip() if not key: continue if key in config_dict: raise ValueError(fduplicate key: {key}) config_dict[key] value.strip()兩種寫法高下立判。后者我一眼看過去就知道這人的生產環境經驗豐富因為我實際處理配置文件時就踩過value里藏著等號的坑。你答題時能讓閱卷人產生這種這人是同行的感覺分數一定低不了。2.3 文本處理的常用命令組合Shell筆試里文本處理三劍客grep、sed、awk屬于必考內容建議你不光會用還得會組合。這里分享幾個我從實際工作里總結出來的高頻組合公式從日志中統計某個關鍵詞的分布grep ERROR app.log | awk {print $1} | sort | uniq -c | sort -rn按時間范圍拉取日志片段sed -n /2020-06-01 10:00:00/,/2020-06-01 10:30:00/p app.log替換配置文件的某個字段要求整行匹配才替換sed -i /^max_connections/c\max_connections2000 /etc/mysql/my.cnf考試時大概率會出現類似的組合場景建議你別只背單條命令要理解管道符串聯之后的每一步作用。面試的時候考官如果追問中間這步輸出什么格式能準確答上來的人不到三成。3. 數據庫與緩存從基礎語法到性能思維3.1 MySQL考點索引與慢查詢校招筆試考數據庫幾乎繞不開MySQL。但我發現一個現象很多同學對SQL語法背得滾瓜爛熟什么left join、子查詢、group by都用得很溜但一遇到為什么這個查詢慢就答不上來。這說明什么說明他們缺少性能視角。針對金山這類互聯網辦公產品數據庫題目大概率會圍繞如何優化一條慢SQL和如何設計表結構支撐某業務場景來出。我強烈建議你在復習時每一道SQL題都追問自己三個問題這張表的字段長度合理嗎有沒有為所有where條件里的字段建立索引這條查詢會不會產生全表掃描explain的結果是什么樣的如果數據量到100萬、1000萬級這條SQL還能扛住嗎能問出這三個問題說明你是真的在生產環境里見過數據量級而不是只在本地練習庫里跑過幾千行數據。舉個典型的考題例子有一個訂單表orders字段包括order_id、user_id、status、created_at查詢某用戶最近10筆訂單的SQL請優化。最差的答案就是直接select * from orders where user_id 123 order by created_at desc limit 10;因為當數據量大時MySQL需要先篩出該用戶所有訂單再排序。更好的思路是創建(user_id, created_at)的聯合索引讓索引直接按用戶和時間排序避免額外排序操作。加上索引之后這條SQL基本可以走索引覆蓋掃描性能提升往往是幾十倍級別。這不是憑空說的是實際線上優化過的經驗。3.2 Redis考點緩存穿透、擊穿與雪崩數據庫之外的第二個高頻考點就是Redis。字節也好、金山也好互聯網公司基本都重度依賴Redis做緩存。校招題里最常見的三種極端情況這里先給你說清楚緩存穿透查詢一個根本不存在的數據Redis里沒有DB里也沒有惡意請求直接打到DB上。解法一般是布隆過濾器或者緩存空值并設置短過期時間。緩存擊穿某個熱點key在過期瞬間大量請求同時落到DB上。解法是互斥鎖重建緩存熱點數據邏輯上永不過期后臺異步續期。緩存雪崩大量key在同一時間段集中過期導致DB壓力驟增。解法是給過期時間加一個隨機值打散過期時間點。我不會只丟概念下面用一個題來演示答題思路。題目可能是某系統使用Redis緩存用戶信息key為user:{id}請設計一個方案避免緩存雪崩。常規答法是過期時間設置為setex user:{id} 3600 value但3600秒就是固定值所有用戶同時過期。優化方案是過期時間設置為3600 random.randint(0,300)這樣同一秒內過期的key大幅減少。如果再進一步可以引入多級緩存比如本地緩存一層Redis一層徹底兜底。筆試的考察深度通常到方案設計這個層級就夠了但如果你能多提一嘴熱點key的過期延時續期策略閱卷人印象會非常深。3.3 數據一致性場景題除了直接考語句和緩存策略第二部分還經常給一個業務場景來考數據一致性。比如用戶修改頭像后需要展示新頭像但CDN/緩存里還是舊頭像你怎么處理這類題的考察點很明確你有沒有真正思考過寫更新和緩存失效之間的順序。我個人推薦的經驗公式是先更新數據庫再刪緩存。為什么不是先更新緩存因為并發場景下先更新緩存再寫庫一旦寫庫失敗緩存里就是錯誤數據。而先更新庫哪怕刪緩存失敗最多是下一次請求打回一個舊值再過一次過期時間就自愈了。這個順序問題是我在真實項目中踩過坑后才徹底明白的。筆試時把這個順序邏輯寫清楚比堆一堆術語要強得多。4. 網絡與系統排查思路比記參數更重要4.1 高頻網絡知識點TCP握手、HTTP狀態碼、DNS解析金山辦公的筆試中網絡部分的題目不會像網絡工程師那樣考報文級細節更多是考你能不能在應用服務出問題時順著網絡去排查鏈路。所以TCP三次握手過程、四次揮手為什么需要TIME_WAIT、HTTP的常見狀態碼含義200、301、302、403、404、500、502、503這些一定要滾瓜爛熟。另外我建議你重點準備一下HTTP和HTTPS的區別以及Nginx反向代理的工作方式因為金山這種產品線很重的公司線上一定大量使用Nginx做網關和負載均衡。常見的前置Nginx返回502的排查思路是先確認后端服務是否存活再看Nginx連接后端的超時配置最后看后端進程的連接數是否被打滿。這種排查鏈路如果能在筆試里用邏輯清晰的文字寫出來是很加分的。4.2 系統負載高你能不能在半小時內定位問題服務器CPU負載突然飆高你如何排查這幾乎是每年必出的場景題但能把整個過程答完整的人很少。我會用下面這套五步走來拆解一個典型的壓力場景也是我做線上問題定位時的習慣第一先用uptime看Load Average的整體趨勢判斷負載是在漲還是已經平穩。如果Load持續高于CPU核心數說明可能存在真正的資源爭搶而不是瞬時抖動。第二用top進入交互界面按CPU排序找到具體是哪個進程占用了大量CPU。這一步最關鍵因為負載高只是一個表象真正的問題往往集中在某一個進程。如果這個進程是Java應用接著用top -Hp 進程號找到這個進程內部的哪些線程占用了CPU再用jstack導線程快照看這些線程在干什么。第三如果不是CPU密集型而是IO等待那么top里的wa指標會明顯偏高此時需要用iostat看磁盤吞吐和IOPS看看是不是磁盤讀寫的瓶頸。很多新人只盯著CPU忽略磁盤IO結果排查了半天方向全錯。第四檢查內存用free -h看還有多少可用內存用vmstat看swap使用情況。如果你的應用在持續swap那性能一定好不了這往往是內存設置不合理導致的。第五結合上下文看看是不是流量突增、代碼死循環、緩存失效回源這三種典型因素。這套思路如果你是第一次接觸建議反復讀幾遍因為這就是一線運維開發工程師處理線上事故的底層邏輯筆試的時候把一個完整鏈路答下來絕對能讓閱卷老師覺得你不是紙上談兵。4.3 經典的端口不通排查題再給你拆一道高頻基礎題用戶反饋某個服務訪問不通你怎么排查這道題的經典答題框架必須是從底層往上層一層層排除先確認服務進程有沒有在監聽對應端口ss -lntp | grep 8080。再確認本機防火墻是否放行端口iptables -L -n或firewall-cmd --list-all。然后在客戶端測試TCP連通性telnet 目標IP 8080或nc -vz 目標IP 8080。如果TCP通但HTTP不通用curl -v看完整請求輸出重點看返回的狀態碼和響應頭。很多同學在這個題上第一反應就是重啟服務或者看日志實際上第一件該做的事是確認到底是客戶端連不上還是服務端沒響應。把鏈路拆開才能定位到具體某一層出了問題。做題和干活是一樣的先確認故障邊界再深入排查。筆試時把這個邏輯寫得越清晰得分就越高。5. 容器化與CI/CD從工具使用到鏈路思維5.1 Docker的基礎題鏡像與容器的生命周期金山辦公2020年前后的業務容器化已經是常態所以考Docker基礎毫不意外。這里有個核心概念題你務必搞清楚鏡像和容器的區別。鏡像是一個只讀的模板容器是鏡像運行時的實例。你可以把平時docker run、docker build、docker commit、docker exec這些命令都答上來但我不建議只背命令更重要的是理解容器本質上是進程級別的隔離這個理念。筆試在Docker這塊的常見問法有Dockerfile中CMD和ENTRYPOINT的區別是什么如何減小Docker鏡像體積如何讓容器里的服務優雅退出以最后一個問題為例優雅退出的核心是讓主進程能夠接收到SIGTERM信號并完成清理而不是被直接kill。很多同學壓根不知道Docker stop發的是SIGTERM而不是SIGKILL也不清楚Java應用要配合trap或者Spring Boot的Graceful Shutdown特性才能實現優雅下線。這些細節如果能在筆試里寫出來可以證明你真用容器跑過生產服務而不僅僅是在本地docker run -it過。5.2 CI/CD流程設計題不只是一個概念題既然崗位叫運維開發CI/CD相關的問題一定會占一部分比重。我覺得這部分最常考的題型是設計題比如請設計一條從代碼提交到生產環境發布的流水線。很多同學第一反應是把GitLab CI、Jenkins、Docker、K8s這些名詞懟上去但我要告訴你的是面試官想看到的不是工具清單而是階段劃分。一條合格的流水線至少包含以下幾個階段代碼提交觸發構建階段進行編譯和單元測試。構建成功后產出制品鏡像或JAR包推送到制品庫。部署到測試環境跑自動化接口測試。審核通過后部署到預發環境進行冒煙驗證。最后灰度發布到生產環境觀察監控指標逐步放量。如果筆試題目要求你畫流程圖或用語言描述流程建議你按上面的層次結構來答每一步說清楚輸入是什么、輸出是什么、誰觸發、出現問題怎么回滾。能把這四個維度講清楚你的工程化思維就已經超過大多數人。5.3 K8s重點Pod、Deployment、Service的關系近些年校招筆試題對Kubernetes的考察越來越頻繁考的倒不深但會涉及最核心的抽象模型。舉個例子Pod和Deployment的區別是什么Service怎么實現負載均衡。很多同學答Pod是最小調度單元Deployment是管理副本的控制器這話沒錯但太干了。我提供一個更貼合實操的答法Deployment負責聲明我要多少個Pod副本保持運行并且當Pod掛了的時候自動拉起新的如果業務需要升級版本Deployment會按照RollingUpdate策略逐個替換Pod避免服務中斷。而Service則是給一組Pod提供一個穩定的訪問入口實現負載均衡和服務發現。答題的時候能把升級策略副本管理服務暴露這幾個行為層面的內容帶出來比單純默寫概念好得多。6. 實戰題型演練把思路落到實處6.1 場景題一日志關鍵詞監控報警這種題我強烈建議你認真過一遍因為它太典型了幾乎每個運維開發崗位面試都會碰到。題目描述通常是線上有多個應用實例需要監控日志中出現OutOfMemory關鍵詞的實例并發送報警你會怎么實現一個完整的方案分為數據采集、實時處理、告警通知三個部分。采集端可以用Filebeat或Logstash采集應用日志發到Kafka實時處理端可以用Flink或者Go的grok庫做關鍵詞匹配也可以簡單用Logstash的filter直接過濾告警端命中關鍵詞后通過Webhook調用企業微信、釘釘或短信網關。這樣一套鏈路下來比寫個腳本crontab每分鐘grep日志要健壯得多不會漏報也能做到秒級響應。如果筆試只讓你用一個腳本一個定時任務這種輕量方案來解決也不能說錯但你要意識到它的缺陷單點問題、日志輪轉時的漏讀、多實例部署困難。答完輕量方案之后如果能主動補一句這個方案適合臨時應急長期用我會考慮引入采集鏈路這樣的作答層次會更飽滿。6.2 場景題二線上發布后性能下降還有一類高頻場景題新版本發布后線上調用響應時間明顯變長你怎么排查我的第一反應永遠不是回滾而是先確認影響范圍和變更內容。因為回滾是一種高成本操作且如果是代碼問題回滾后可能要重新排查所以除非線上已經不可用否則一般建議先定位。第二步是看監控曲線。發布前后對比CPU、內存、QPS、RT、GC情況如果GC次數和耗時明顯上升那可能是新代碼中創建了大量對象或者某個緩存設置有問題如果QPS沒變但RT變大那重點檢查有沒有慢調用、鎖競爭、數據庫連接池是否被打滿。第三步是看日志特別是error日志和慢日志。如果某個接口的耗時從200ms變成800ms用tracing工具定位到調用鏈中具體哪一環耗時最長。如果是外部依賴數據庫、第三方接口變慢那就是下游問題如果是自身代碼邏輯導致那就直接看對應代碼段的性能。排查思路比具體命令重要。答出先看監控、再分模塊定位、最后看代碼這個三層遞進邏輯基本就穩了。6.3 場景題三如何保障系統高可用這個問題范圍很大經常作為筆試最后一道論述題或設計題出現。考察面廣但沒有標準答案關鍵在于你能否覆蓋到多個層面。我習慣從入口層、應用層、數據層、基礎設施層四個角度來答。入口層DNS解析可以配置多線路Nginx做多節點負載均衡避免單點入口。應用層服務部署多副本放到不同機架/可用區自動故障轉移無狀態服務用負載均衡重新分發流量。數據層數據庫做主從復制Redis用主從加哨兵或者集群定時備份和日志備份形成災備體系。基礎設施層網絡、電源、存儲都考慮冗余監控系統全維度覆蓋出現異常時能做自動化預案。這類論述題的加分項是成本意識。如果能在方案里提到核心鏈路重點保障非核心業務降級處理這種策略性設計比單純堆一堆高可用組件要高級得多。因為我做的系統都知道把三個9還是五個9成本不是線性上漲而是指數級上漲。能夠結合業務實際去設計高可用方案才是面試官最想看到的能力。7. 備考與答題的獨家實操心得7.1 筆試題的常見扣分點早知道早避坑我說幾個閱卷時最常見的扣分點希望對你有幫助。第一題目要求寫出完整命令或寫出腳本結果只寫了核心命令沒寫流程控制。比如讓寫一個腳本檢查多個服務的端口是否存活很多人就寫nc -zv 127.0.0.1 80不寫循環、不寫判斷、不寫輸出日志。這在填空題里能得分但在實現題里只能拿一半分。第二答案里沒有體現防御性編程。舉個例子一個腳本里用了臨時文件正常運行沒問題但如果上次異常退出后臨時文件沒有清理再次運行就會報錯。有經驗的人在腳本開頭會加一句trap rm -f /tmp/xxx.$$ EXIT來保證退出時清理。這種細節寫出來就是強烈的生產經驗信號。第三只寫做了什么不寫為什么這么做。比如答Redis緩存更新方案只說更新數據庫后刪除緩存沒說為什么這個順序更安全分數就差一截。我建議答題時養成習慣結論理由例外。結論是一句話理由是把關鍵邏輯講清楚例外是說明什么場景下方案不適用。7.2 短期內高效備考的方向建議如果距離筆試只剩一到兩周我建議你把精力集中在以下三個板塊這是性價比最高的突擊路徑一是Shell文本處理和Python腳本題這是最高頻的考法占分比最大而且短期刷題效果最明顯。把常見場景題做一遍形成肌肉記憶。二是MySQL和Redis的重點應用集中看索引優化、explain的使用、緩存三類問題穿透、擊穿、雪崩的解法務必能用文字理通邏輯。三是網絡和系統排查題重點是TCP握手、HTTP狀態碼、CPU高負載排查用先定位再處理的思路來答題拒絕只堆名詞。至于Docker、K8s、CI/CD這些內容如果在筆試中出現大概率是基礎概念加簡單的設計題時間不夠的話可以先把Dockerfile核心指令、Pod/Deployment/Service區別、流水線階段劃分這三大塊吃透。7.3 一些我的個人經驗總結我做了這些年運維開發最深的感受是這個崗位筆試不是終點準確說筆試只是一個篩選信號。真正決定你能否通過后面面試的是你對為什么的理解程度。公司培養一個運維開發新人的成本并不低他們希望招到的是遇到問題不慌、能自己找到答案的人。所以備考筆試的時候不妨多地假如我是這個系統的運維負責人我會怎么做來思考問題。你在草稿紙上反復推敲過的每一個極端場景最后都會變成你面試時的底氣。還有一個小建議。筆試時如果遇到完全沒見過的題千萬不要空著不寫。你可以先把題目中你已經知道的知識點列出來再嘗試給出一個你認為合理的方案哪怕不完整也能讓閱卷人看到你分析問題的方向是對的。我在實際業務里遇到未知問題也是這個策略先把已知邊界確認掉再把問題從大化小一層層拆最后總能找一個可以落地的解法。這套思路本身其實比任何標準答案都更能代表運維開發工程師的核心能力。