站點可靠性工程師面試問題——30+問題及專家解答
Glassdoor報告SRE的平均薪資為169,680美元，第75百分位超過每年213,000美元[1]。這一角色——2003年誕生於Google，現已被所有主要科技公司採用——位於軟體工程和系統維運的交匯處，面試過程也反映了這種雙重性[2]。SRE面試考察帶有可靠性約束的系統設計、自動化編碼、壓力下的事件管理，以及通過SLO和錯誤預算量化可靠性的特定思維方式。本指南涵蓋你將面對的行為、技術和情境問題，答案校準到頂級公司期望的深度。
關鍵要點
- SRE面試通常包括四到六輪：編碼、系統設計、故障排查、事件管理和行為——分布在一整天或多個會議中[3]。
- SRE面試的核心區分點是以可靠性為中心的系統設計——你必須設計優雅降級的系統，而不僅僅是可擴展的系統[2]。
- SLO、SLI、錯誤預算和消除重複勞動（toil）是SRE特有的詞彙，面試官期望你熟練使用。
- SRE角色的編碼問題強調自動化、基礎設施工具和維運腳本，而非純演算法題[3]。
行為問題
1. 講述你管理過的影響最大的事件。你的角色是什麼，事後分析揭示了什麼？
專家回答：「我在一次級聯故障中擔任事件指揮官，該故障使我們的主認證服務中斷了47分鐘，影響了230萬活躍使用者。一次對限流器的常規配置變更意外地將閾值設為每秒10個請求而非10,000個。認證服務觸及限制，返回429錯誤，客戶端的重試風暴將負載放大了50倍。我宣布P1級事件，建立事件頻道，分配角色並協調回應。修復方法是回滾配置變更，但我們還需要通過臨時增加容量來排空重試積壓。事後分析確定了三個根本原因：限流器配置值缺乏驗證、配置變更缺乏金絲雀部署、客戶端重試缺乏熔斷器。我們實施了所有三項修復，並新增了每30秒測試認證流程的合成金絲雀。該事件消耗了季度錯誤預算的40%，觸發了功能開發凍結，直到可靠性改進上線。」
2. 描述你消除重大重複勞動來源的經歷。
專家回答：「我們的值班工程師平均每週花6小時手動擴展資料庫讀取副本。我使用客製化Kubernetes Operator建構了自動擴縮控制器，監控CPU和查詢延遲指標，自動計算並調整副本數量。手動擴展干預從每週6小時降至0，值班負擔減少30%。」
3. 舉一個你反對認為過於激進的可靠性要求的範例。
專家回答：「產品團隊要求新通知服務達到99.999%的可用性。我計算了五個九實際意味著什麼：每年5.26分鐘的停機時間。工程成本估計為6個月和40萬美元額外基礎設施。我提議99.9%的可用性，我們現有基礎設施通過少量改進即可實現。產品團隊在看到成本-可靠性權衡曲線後同意了。這就是SRE紀律：可靠性是一項功能，與所有功能一樣，它有成本，必須以使用者影響來證明合理[2]。」
4. 講述你改進關鍵服務監控或可觀測性的經歷。
專家回答：「我們的支付服務只有基本健康檢查監控。一次靜默故障後（服務返回200但使用了3小時的過期快取資料），我重新設計了可觀測性堆疊。定義了與使用者體驗關聯的SLI，實施Prometheus指標，建立帶SLO消耗率告警的Grafana儀表板，並新增了Jaeger分散式追蹤。多視窗告警將誤報減少了60%。」
5. 描述你如何平衡功能開發速度與可靠性工作。
專家回答：「我實施了錯誤預算策略，可靠性工作和功能開發由同一指標管理。預算高於50%時全速開發功能。低於50%時五五分。低於25%時全部轉向可靠性。一年內P1事件率降低45%，產品團隊多發布了12%的功能。」
6. 你如何處理值班輪換，以及如何改善團隊的值班體驗？
專家回答：「我將值班視為工程問題。實施了告警調優、維運手冊自動化和結構化交接。告警從每週14次降至4次，值班滿意度從2.1/5升至4.3/5。」
技術問題
1. 解釋SLO、SLI和錯誤預算。它們如何相互關聯？
專家回答：「SLI是衡量服務品質特定方面的定量指標。SLO是SLI的目標值。錯誤預算是SLO的反面：如果SLO是99.9%，錯誤預算就是0.1%。錯誤預算在SRE和產品團隊之間創造了共同語言[2]。」
2. 為包含50個服務的微服務架構設計監控和告警系統。
專家回答：「三層建構：Prometheus RED指標採集，Loki日誌聚合，Jaeger分散式追蹤。基於SLO的多視窗消耗率告警。每個服務的黃金訊號儀表板和頂層SLO儀表板。核心原則：基於症狀（使用者影響）告警，而非原因（CPU高）。」
3. 一個服務回應緩慢。帶我了解你的排查方法。
專家回答：「從使用者影響開始，然後系統性地應用USE和RED方法。檢查服務本身、下游相依性、網路。使用分散式追蹤定位請求路徑中的瓶頸。」
4. 如何設計跨多個區域實現99.99%可用性的系統？
專家回答：「至少3個區域的主動-主動部署。基於健康檢查的全球負載均衡。區域內同步複製，跨區域非同步複製。每個區域金絲雀部署。定期混沌工程驗證故障轉移。」
5. 水平擴展和垂直擴展有什麼區別，何時偏好哪種？
專家回答：「垂直擴展增加單個實例的資源。水平擴展在負載均衡器後新增更多實例。無狀態服務優先水平擴展，引入複雜性的有狀態元件優先垂直擴展。」
6. 解釋基礎設施即程式碼(IaC)以及你如何用它提高可靠性。
專家回答：「IaC將基礎設施配置視為軟體：版本控制、程式碼審查、測試和可複現。使用Terraform進行雲端資源配置，Ansible進行組態管理。優勢：可複現性、可稽核性和可測試性。」
7. 如何為快速增長的服務進行容量規劃？
專家回答：「四步框架：建立負載模型、建模增長、識別瓶頸資源、自動化回應。每月審查容量計劃，將預測與實際進行比較。」
情境問題
1. 服務的錯誤預算在季度結束前兩週已耗盡。產品團隊想發布重要功能。你怎麼做？
專家回答：「根據錯誤預算策略，耗盡預算會觸發可靠性凍結。我會向產品團隊展示資料並提供替代方案：使用功能旗標進行漸進發布，或優先進行特定的可靠性改進。錯誤預算策略正是為這種情況而存在[2]。」
2. 一位初級工程師的變更導致生產中斷。你如何進行事後分析？
專家回答：「基本原則是無指責——事後分析檢查發生了什麼以及為什麼系統允許它發生，而不是誰的錯[2]。改進措施應改善系統，而非懲罰工程師。」
3. 你接手了一個沒有監控、文件和測試的遺留系統。從哪裡開始？
專家回答：「按影響範圍排列優先順序。第1週：基礎監控。第2-4週：記錄架構。第2個月：關鍵路徑整合測試。第3個月：CI/CD。核心原則：不要重寫，要穩定化。」
4. 監控顯示生產環境中存在緩慢的記憶體洩漏。服務每72小時崩潰並重啟。你如何處理？
專家回答：「首先量化影響。開啟堆疊分析，定期比較快照。短期緩解：每48小時優雅重啟。長期：識別洩漏物件類型後修復根本原因並新增記憶體使用SLI。」
5. 管理層要求在維持當前可靠性水準的同時將基礎設施成本降低30%。你如何處理？
專家回答：「四個類別的成本削減機會：實例最佳化、預留容量、競價/搶佔式實例和架構最佳化。可靠性不可談判——成本削減來自效率，而非移除冗餘。」
向面試官提問
- 「這個團隊負責的服務SLO是什麼，錯誤預算如何管理？」
- 「值班輪換是怎樣的——多少工程師，告警量是多少，升級策略是什麼？」
- 「團隊如何平衡專案工作與維運工作？」
- 「團隊與開發團隊的關係如何——SRE是嵌入式還是集中式？」
- 「團隊的事後分析方法是什麼——是否無指責，行動項完成率如何？」
- 「團隊管理什麼基礎設施和工具？」
- 「團隊目前面臨的最大可靠性挑戰是什麼？」
面試形式及預期
大型科技公司的SRE面試通常持續4-6小時[3]。編碼輪測試Python/Go/Java，側重自動化問題。系統設計輪要求明確的可靠性約束。故障排查輪呈現生產場景。行為輪評估值班經驗和事件管理。從篩選到offer通常需要3-6週。
如何準備
- 學習Google SRE手冊。 關於SLO、錯誤預算、toil和事件管理的章節是基礎[2]。
- 練習帶可靠性約束的系統設計。
- 準備事件故事。 3-5個詳細敘述。
- 複習Linux基礎。
- 練習自動化編碼。
- 了解你的可觀測性技術堆疊。
常見面試錯誤
- 只設計可擴展性不設計容錯[2]。
- 不量化可靠性。
- 將事件視為純技術問題。
- 忽視toil。
- 過度工程化解決方案[2]。
- 不理解錯誤預算模型。
- 無法展示編碼能力[3]。
關鍵要點
- SRE面試測試特定的工程思維：量化可靠性、基於資料做權衡決策、將維運視為軟體工程問題。
- SLO、SLI、錯誤預算和toil是SRE的詞彙——熟練使用。
- 準備詳細的事件故事。
- 系統設計答案必須包含明確的故障模式和優雅降級策略。
想確保你的履歷能幫你進入面試？試試ResumeGeni的免費ATS評分檢查器來最佳化你的SRE履歷。
常見問題
SRE和DevOps有什麼區別？
SRE是DevOps原則的特定實現，具有規範性實務：SLO、錯誤預算、toil預算和與開發團隊的定義協作模型[2]。
SRE面試應該了解哪些程式語言？
Python和Go是SRE中最常用的語言[3]。
作為SRE應該期望什麼薪資範圍？
薪資範圍從128,842美元到169,680美元，第75百分位為213,272美元[1]。
Google SRE手冊對面試準備有多重要？
非常重要。它定義了大多數SRE面試測試的概念[2]。
獲得SRE角色需要值班經驗嗎？
值班經驗被強烈偏好，但入門級職位不一定要求。
哪些認證對SRE面試有用？
Google Cloud Professional Cloud DevOps Engineer、AWS DevOps Engineer Professional和CKA最相關。
SRE面試與軟體工程面試有何不同？
SRE面試包括帶明確可靠性約束的系統設計、故障排查輪以及關於事件管理的行為問題[3]。
