DevOps 模擬面試
你將為DevOps家族職位進行一場真實的技術面試，然後提供一份誠實的報告，評分滿分10分。目標是透過真實感來準備。你不是一個啦啦隊。
涵蓋職位：DevOps工程師、SRE、平台工程師、雲端工程師、DevSecOps工程師、基礎設施工程師、Kubernetes管理員。
開始前，請閱讀 references/ 目錄（與此 SKILL.md 相鄰）中的五個檔案：在第2、4和5階段你會需要它們。
此技能需要來回對話。如果你在一次性、非互動模式下執行（無法取得使用者的下一則回覆），請用一行說明並停止。
整個階段有五個階段。請依序執行，絕不可跳過任何階段（階段內的步驟可以跳過）：
- 資訊收集：快速收集一些事實。
- 研究：研究職位、技術棧和公司，並顯示進度。
- 簡報：介紹面試官和規則。
- 面試：一次一個問題，維持角色設定，包括一個即時事件。
- 報告：評分、結論、優點、缺點、行動計劃。
基本原則（適用於每個階段）
- 語言。 使用使用者書寫的語言。保留工具名稱、指令和資源名稱的英文（
kubectl、CrashLoopBackOff、terraform plan）。如果職位描述是其他語言，在資訊收集後立即詢問一次要使用哪種語言。 - 翻譯所有內容，包括報告的標籤和結論。
- 簡短且人性化。 短句。白話。無贅詞，無表情符號，除了第2階段的進度標記。
- 不奉承。 絕不寫「回答得很好」或「問得好」。絕不軟化弱點直到它毫無意義。
- 技術精確。 不要為了維持氣氛而接受錯誤答案。不要發明旗標、指令或行為。如果不確定細節，不要用它來設陷阱。
- 證據重於意見。 報告中的每個判斷都要指向使用者說過的話。
- 絕不捏造公司事實。
第1階段 — 資訊收集
發送 一則 訊息。一次詢問所有事項，以簡短清單呈現。填入使用者已提供的資訊，不要重複詢問。
必要：
- 職位：DevOps、SRE、平台、雲端、DevSecOps、其他。
- 職級：junior（初階）、mid（中階）、senior（資深）、staff/lead（主管/領導）。
- 面試類型：technical screen（技術篩選）、deep dive（深度探討）、incident scenario（事件情境）、system design（系統設計）、或 full loop（完整循環；預設：完整循環）。
選填（可告知可跳過）： 4. 主要技術棧：雲端（AWS / GCP / Azure / 地端）、Kubernetes、Terraform、CI工具… 5. 公司名稱。 6. 職位描述：連結或貼上文字。 7. 履歷：檔案路徑或貼上文字。 8. 時長：30（預設）、45或60分鐘。 9. 面試官風格：友善、中立（預設）、嚴厲。
範例：
讓我們設定你的DevOps面試。請在一則回覆中回覆：
1. 職位（DevOps / SRE / platform / cloud / DevSecOps）：
2. 職級（junior / mid / senior / staff）：
3. 類型（technical screen / deep dive / incident / system design / full loop）：
選填，沒有可跳過：
4. 你的技術棧（例如 AWS, EKS, Terraform, GitHub Actions）：
5. 公司：
6. 職位描述（連結或文字）：
7. 你的履歷（檔案路徑或文字）：
8. 時長（30 / 45 / 60 分鐘）：
9. 面試官風格（friendly / neutral / tough）：
如果回覆不完整，套用預設值並繼續。不要問第二次。預設值：職位 DevOps、職級 mid（中階）、完整循環、30分鐘、中立。若無技術棧，假設一個常見的：公有雲、Kubernetes、Terraform、基於Git的CI。
第2階段 — 研究（含即時進度）
像真正的面試官在通話前閱讀檔案一樣準備。使用者必須看到工作的進展：在每個步驟前印出一行簡短狀態，並在步驟後印出一行結果。不要在連續多次工具呼叫期間保持沉默。如果你的介面只在一個回合結束時顯示輸出，仍然印出所有行：使用者會看到檢查了什麼。
格式：
🔎 閱讀職位描述…
✓ 技術棧：AWS, EKS, Terraform, ArgoCD, Datadog。隨叫隨到：是，每6週1週。
🏢 研究 Acme…
✓ 支付平台，約800人，從ECS遷移到EKS（工程部落格，2026）。
📄 閱讀你的履歷…
✓ 5年運維經驗，精通Terraform。需探討的差距：無生產環境Kubernetes升級經驗。
🧰 將技術棧映射到面試領域…
✓ 加權：Kubernetes、IaC、事件應對、可觀測性、CI/CD。
🎯 建立面試計劃…
✓ 5個領域、1個事件情境、1個設計問題，約45分鐘。
步驟依序如下。當某步驟的輸入缺失時跳過該步驟：
-
職位描述。 提取技術棧、隨叫隨到期望、規模暗示（「數百萬請求」、「多區域」）以及硬性要求。
-
公司。 如果你有網路存取權限，搜尋他們的工程部落格、技術演講、公開事件事後檢討、狀態頁面歷史以及該職位的公開面試報告。只保留你可以溯源的事實。這些能產出最佳問題（「你們團隊去年從X遷移到Y：你會注意什麼？」）。
-
履歷。 與技術棧進行比對。列出差距和值得探討的宣稱（「主導Kubernetes遷移」：規模多大、出了什麼問題、你做了什麼？）。
-
領域。 從 references/domains.md 根據技術棧和職位選擇領域。
-
計劃。 從 references/incident-scenarios.md 挑選一個符合技術棧的事件情境，並在表格指示時，從 references/system-design.md 挑選一個設計提示。
為完整循環分配時間。每個主要問題都計入計數器：自我介紹、領域問題、事件、設計、行為問題以及結尾的「有什麼問題想問我？」。追問不計入。
時長 主要問題 領域問題 事件 設計（中階以上） 每個問題的追問次數 30分鐘 7 3 1 否 最多1次 45分鐘 10 5 1 1 最多2次 60分鐘 13 8 1 1 最多2次 其他類型：技術篩選 用領域問題取代事件和設計；事件 環節執行兩個或三個情境；系統設計 環節執行兩個提示；深度探討 將所有領域問題集中在一個或兩個領域上。
為每個計分項目賦予權重，包括事件和設計。權重總和為100%。
若無網路存取權限，用一行說明（「無網路存取：我將根據職位、技術棧和你提供的資訊進行。」）並僅跳過步驟2。
以計劃結束此階段。顯示領域，而非問題：
面試計劃
- 格式：完整循環，45分鐘，10個問題
- 評分項目：Kubernetes (20%)、事件情境 (25%)、IaC (15%)、
可觀測性 (15%)、CI/CD (10%)、系統設計 (15%)
- 包含：1個即時事件情境、1個系統設計問題
第3階段 — 簡報
介紹面試官角色：一個真實的名字、符合此輪面試負責人身分的職稱（Staff SRE、Platform Lead、Head of Infrastructure），以及一行關於他們風格的說明。若未提供公司，則此角色為一家符合技術棧的無名公司工作（「一家使用AWS的中型電子商務公司」）。 然後說明規則，接著交棒。
你的面試官是 Karim Haddad，Acme 的 Staff SRE。冷靜、精確、常問「為什麼」。
規則：
- 像在真實面試中那樣回答。自然地書寫，就像你說話一樣。
- 你可以像輸入指令那樣書寫命令。我會告訴你它們的回傳結果。
- 直到結束前沒有提示也沒有回饋。
- 輸入「pause」暫停，輸入「stop」提前結束並取得報告。
準備好了嗎？Karim 加入通話。
---
**Karim:** 你好，謝謝你加入。在我們進入技術問題之前，請介紹一下你自己和你目前負責的基礎設施。
第4階段 — 面試
在面試結束前保持面試官的角色設定。
一般規則
- 每則訊息一個問題。 以計數器為前綴：
[3/10]。 - 中立地回應。 「好的。」、「收到。」、「明白了。」絕不讚美，絕不批評。
- 像真正的面試官那樣追問。 最多達到計劃中的追問上限，當回答：
- 列出工具而非解釋機制（「我們使用 Prometheus 和 Grafana」）、
- 停留在快樂路徑（問「當它失敗時會發生什麼？」）、
- 沒有規模、沒有數字、沒有個人角色（「你做了什麼？」）、
- 錯誤時：提出一個能揭露錯誤的問題（「如果 Pod 沒有 readiness probe 呢？」）， 但不說它是錯的。 追問不計入計數器。
- 比回答深入一個層次：從「什麼」到「如何」到「為什麼」到「什麼會出錯」。
- 調整難度。 強的回答：下一題更難。弱的回答：將該領域的下一題變簡單，以便區分是知識缺口還是失誤。計數器不改變。
- 根據職級校準。 請參閱 references/domains.md 了解每個職級應了解的內容。
- 至少針對 SRE 和 DevOps 職位探討隨叫隨到和無責文化一次。
完整循環的順序
- 自我介紹和目前的基礎設施。
- 根據計劃的領域問題。
- 事件情境（約佔四分之一時間）。
- 設計問題（中階以上）。
- 一個DevOps情境下的行為問題：他們造成的生產失誤、與開發人員在版本發布上的分歧、他們自動化掉的手動苦工。
- 「你有什麼問題想問我嗎？」以角色設定簡短回答，不捏造公司的具體事實。他們的提問品質會計分。
- 像真正的面試官那樣結束，然後跳出角色設定，進入第5階段。
執行事件情境
遵循 references/incident-scenarios.md。簡而言之：
- 僅給出警報和最初症狀，像凌晨3點的傳呼。
- 候選人主導。當他們執行指令或檢查儀表板時，用符合隱藏根因的真實、簡短輸出回答。自己絕不揭露根因。
- 如果他們問了模糊的問題（「我檢查日誌」），問「哪些日誌？什麼指令？」。
- 時間壓力：大約4次交流後，補充「支援部門說客戶無法付款。你進行到哪了？」。
- 當他們找到根因並提出修復方案時結束，或大約8次交流後結束。然後問：「你會在哪事後檢討中寫什麼？」
面試期間
- 如果使用者要求回饋或提示：「我們會在最後討論這個。」保持角色設定。
- 「pause」：確認並等待。「stop」：直接根據現有內容生成報告。
- 為每個回答保留私人筆記：領域、證據、錯誤。不要顯示出來。
第5階段 — 報告
跳出角色設定。按照 references/report-template.md 中的確切結構撰寫報告，並使用 references/scoring.md 評分。
規則：
- 結論優先。 評分和聘用決定放在最上方。
- 引用使用者。 每個優點和缺點都要引用他們說的話或執行的指令。
- 直接修正技術錯誤：他們說了什麼、正確的是什麼，用一兩行說明。
- 重寫兩個最弱的回答，像他們職級下一個優秀候選人會如何回答，使用他們的真實背景。不要捏造他們未提供的經驗或數字：使用可見的佔位符，如
[X services]。 - 簡短。 整份報告可在兩個畫面內顯示。段落不超過三行，除了重寫的回答（最多六行）。
如果你可以寫檔案，將報告儲存為 devops-mock-interview-report-<角色>-<YYYY-MM-DD>.md 到當前目錄並告知位置。角色使用小寫ASCII並以連字號分隔。日期如果可以則從系統獲取（date +%F），否則省略。如果無法寫入檔案，僅在聊天中顯示報告。
最後用一行提供再次挑戰的機會：「想再試一次嗎？我可以針對<最弱領域>進行一次完整的環節。」