字節跳動運維開發面試經歷：K8s+監控+自動化全考察

背景介紹

先交代一下我的背景吧，本科計算機科學，畢業後在一家中型網際網路公司做了2年運維開發，主要用Python和Go寫自動化腳本，管理幾百台伺服器，也搞過一些監控系統的搭建。說實話，字節跳動的SRE崗位一直是我非常想去的，畢竟字節的基礎設施規模在國內是頂級的，能接觸到很多大廠的運維實踐。

投履歷是在7月份，透過內推管道投的。大概一週後HR聯繫我約了一面，整個流程是三輪技術面+一輪HR面，大概兩週走完。字節的面試節奏很快，每輪之間間隔也就2-3天，不像有些公司拖很久。下面詳細說說每輪面試的情況。

面試流程覆盤

一面：Linux基礎+網路（約60分鐘）

一面的面試官是個看起來很幹練的小姐姐，開場直接進入正題，沒有太多寒暄。

Linux基礎：

第一個問題就很有字節風格——「說一下Linux的程序和執行緒的區別」。我從地址空間、資源佔用、排程、建立開銷等角度說了，面試官追問：「那程序間通訊有哪些方式？各自的特點是什麼？」我列舉了管道、訊息佇列、共用記憶體、號誌、訊號、Socket，並分別說了適用場景和優缺點。

然後問了一個很實際的問題：「說一下Linux的檔案系統，inode是什麼？」我從inode的結構（元資料、資料區塊指標）、硬連結和軟連結的區別、目錄項等方面說了。追問：「如果磁碟空間滿了但du顯示還有剩餘空間，可能是什麼原因？」這個我答了可能是已刪除但被程序佔用的檔案，用lsof可以查看。

網路基礎：

面試官問：「說一下TCP三次交握和四次揮手的過程」。這個我答得很流暢，畫了狀態轉換圖，詳細說了每個階段的報文和狀態變化。追問：「為什麼三次交握不是兩次？為什麼四次揮手需要TIME_WAIT？」我從防止已失效連線請求到達伺服器、確保對方收到最後一個ACK等角度回答了。

還問了一個關於HTTP的問題：「HTTP/1.1、HTTP/2、HTTP/3分別有什麼改進？」我從持久連線、多工複用、頭部壓縮、伺服器推送、QUIC協定等方面對比了。追問：「HTTPS的交握過程是怎樣的？」我從憑證驗證、金鑰交換、對稱加密通訊等方面詳細說了。

Shell和工具：

最後問了一些Shell相關的：「寫一個命令，統計nginx日誌中存取量前10的IP」。我寫了awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10，面試官說可以。還問了一個：「如何查看一個程序開啟了哪些檔案？」我答了lsof -p PID。

二面：K8s+監控體系（約75分鐘）

二面的面試官明顯更資深，應該是SRE團隊的技術骨幹。這輪面試的深度和廣度都有提升。

Kubernetes：

第一個問題就很大——「說一下Kubernetes的架構元件」。我從控制平面（API Server、etcd、Scheduler、Controller Manager）和工作節點（kubelet、kube-proxy、容器執行時）詳細說了，並解釋了各元件的職責和互動方式。面試官追問：「Pod的建立流程是怎樣的？」我從kubectl提交請求到API Server、etcd儲存、Scheduler排程、kubelet建立容器等方面詳細說了整個流程。

還問了一個關於服務發現的問題：「K8s中Service和Ingress的區別是什麼？各自適用什麼場景？」我從ClusterIP/NodePort/LoadBalancer類型的Service和Ingress的七層路由能力對比了，並說了各自的適用場景。

追問了一個關於排程的問題：「如果某個節點資源不足，Pod會怎麼處理？」我答了Pending狀態、排程失敗、可能觸發叢集自動擴縮容等。

監控體系：

面試官問：「說一下你們之前的監控體系是怎麼搭建的？」我從Prometheus+Grafana+Alertmanager的架構說了，詳細講了指標採集、儲存、視覺化、告警的完整鏈路。追問：「Prometheus的拉模型和推模型（Pushgateway）各有什麼優缺點？」我從服務發現、時間序列一致性、適用場景等方面對比了。

還問了一個關於告警的問題：「告警太多導致告警疲勞怎麼解決？」我說了幾個方法：告警分級（P0-P3）、告警聚合和抑制、動態閾值、基於SLO的告警策略等。面試官對這個回答比較滿意。

日誌體系：

「說一下ELK/EFK的架構」。我從Filebeat採集、Logstash處理、Elasticsearch儲存、Kibana視覺化說了完整鏈路。追問：「如果日誌量太大，Elasticsearch效能下降怎麼辦？」我說了冷熱資料分離、索引生命週期管理、增加節點、最佳化查詢等方案。

三面：故障排查+自動化（約70分鐘）

三面是SRE團隊的負責人面的，主要考察故障排查能力和自動化思維。

故障排查：

面試官給了一個故障場景：「線上服務突然回應變慢，你會怎麼排查？」我從應用層（日誌、trace、profile）、系統層（CPU、記憶體、IO、網路）、基礎設施層（資料庫、快取、訊息佇列）三個層面說了排查思路，並強調了先止損再排查的原則。面試官追問了幾個場景：「如果是資料庫慢查詢導致的呢？」「如果是網路抖動導致的呢？」「如果是GC問題呢？」我分別給出了針對性的排查方法。

還問了一個關於容量規劃的問題：「如何評估一個服務的容量上限？」我說了壓測（wrk/locust）、效能指標（QPS、延遲、錯誤率）、資源瓶頸分析、容量模型建立等方法。

自動化：

面試官問：「你在之前的工作中做過哪些自動化？」我說了自動擴縮容、自動故障恢復、自動發布流水線等。追問：「自動擴縮容的指標怎麼選擇？有哪些坑？」我說了基於CPU/記憶體/QPS的擴縮容策略，以及冷啟動延遲、指標滯後、突發流量等常見坑。

還問了一個關於混沌工程的問題：「你了解混沌工程嗎？怎麼在生產環境中實施？」我說了Chaos Monkey等工具、爆炸半徑控制、漸進式實驗、可觀測性保障等原則。

On-Call相關：

面試官最後問了一個很實際的問題：「你對On-Call怎麼看？有什麼好的On-Call實踐？」我說了輪值制度、告警分級、Runbook、事後覆盤等實踐，並強調了On-Call不應該是「救火」，而應該是「防火」——透過自動化和預防性措施減少On-Call的負擔。

真題彙總

Linux基礎：

1. 程序和執行緒的區別

2. 程序間通訊方式及特點

3. Linux檔案系統和inode

4. 磁碟空間滿但du顯示有剩餘的原因

網路：

5. TCP三次交握和四次揮手

6. 為什麼三次交握不是兩次？TIME_WAIT的作用

7. HTTP/1.1、HTTP/2、HTTP/3的改進

8. HTTPS交握過程

Shell和工具：

9. 統計nginx日誌中存取量前10的IP

10. 查看程序開啟的檔案

Kubernetes：

11. K8s架構元件及職責

12. Pod的建立流程

13. Service和Ingress的區別

14. 節點資源不足時Pod的處理

監控：

15. Prometheus+Grafana+Alertmanager架構

16. 拉模型vs推模型的優缺點

17. 告警疲勞的解決方案

18. ELK/EFK架構

19. Elasticsearch效能最佳化方案

故障排查與自動化：

20. 服務回應變慢的排查思路

21. 容量評估方法

22. 自動擴縮容的指標選擇和常見坑

23. 混沌工程實踐

24. On-Call最佳實踐

心得建議

1. Linux和網路基礎是SRE的地基。字節的面試雖然會問K8s、監控這些進階話題，但基礎不牢的話，面試官一追問就露餡了。建議把《TCP/IP詳解》和《UNIX環境進階程式設計》認真過一遍，不是為了背，而是為了真正理解。

2. K8s要理解架構原理，不能只會kubectl。很多人用K8s就是kubectl apply一下，但面試官問的是Pod建立流程、排程演算法、服務發現機制這些底層原理。建議看看K8s的原始碼，至少理解API Server和Controller的工作機制。

3. 監控體系要有全域視野。不要只會配Prometheus規則，要理解從指標定義、採集、儲存、視覺化到告警的完整鏈路，以及每個環節的權衡取捨。字節的面試官很看重你對監控體系的整體理解。

4. 故障排查要有方法論。不要一上來就瞎猜，要有系統的排查思路：先定影響範圍，再分層排查，先止損再治本。面試中展現這種系統性的排查思維會加分很多。

5. 自動化思維要貫穿始終。SRE的核心價值不是手動運維，而是透過自動化提升效率和可靠性。面試中多從自動化的角度思考問題，會讓面試官覺得你有SRE的思維方式。

FAQ

Q：字節SRE面試對程式設計能力要求高嗎？

A：有一定要求。雖然不像開發崗那樣考演算法，但需要能寫自動化腳本和工具。面試中會考一些Shell和Python的程式設計題，建議提前準備。

Q：沒有K8s經驗能面試字節SRE嗎？

A：比較難。字節的SRE崗位幾乎都要求K8s經驗，因為字節的基礎設施是全面K8s化的。如果沒有K8s經驗，建議先自己搭個叢集練手。

Q：字節的On-Call強度大嗎？

A：說實話，字節的On-Call強度不低，特別是核心業務團隊。但字節的自動化程度很高，很多故障可以自動恢復，On-Call的負擔在逐步減輕。

Q：面試中會考演算法題嗎？

A：會，但難度比開發崗低。一般考的是中等難度的題，更看重你的編碼能力和工程思維，而不是演算法技巧。

Q：薪資待遇怎麼樣？

A：2年經驗的話，字節SRE的薪資在北京算很有競爭力的，基本和同級別的開發崗持平。另外字節的期權也有一定吸引力。