情境式面試問題怎麼答？50 個常見情境題與回答要點整理

最近超多人來問我，DevOps 的面試到底要怎麼準備？特別是那種「情境題」，你知道的，就是面試官給你一個狀況劇，然後問你「這時候你該怎麼辦？」這種問題真的很煩，因為它沒有標準答案，但又最能看出一個人的實力深淺。

老實說，我看了網路上超多文章，包括那種列出 50 題、100 題的題庫，但我覺得...嗯，光背答案沒什麼用。面試官根本不想聽你背課文，他們想看的是你的「思考過程」。你是怎麼拆解問題的？你優先考慮什麼？你怎麼從救火隊員的角色，進階到預防火災的建築師？這才是重點。

TL;DR

一句話結論：情境題考的不是你會不會下指令，而是你腦袋裡的「處理流程」和「權衡取捨」的能力。與其背答案，不如建立自己的思考框架。

面試官真正想聽的，不是標準答案

我們先來看幾個經典到不行的狀況劇，你會發現，重點從來就不在那個「最終解法」，而在於你怎麼一步步推演出來的。

狀況一：「CI/CD Pipeline 突然掛了，顯示『dependency not found』！」

OK，pipeline 亮紅燈。我的第一個反應是... 嗯，不是驚慌，是先深呼吸。然後我的大腦會立刻切換到偵探模式。這不是一個單一問題，這是一連串的可能性，我要做的就是逐一排除。

新來的嫌犯？ 是不是有人剛加了新的套件，但忘了更新到 `requirements.txt` 或 `package.json` 裡？這大概是八成情況的兇手。
網路斷了嗎？ 聽起來很蠢，但 Build Server 連不到外面去抓套件也是常有的事。特別是在有嚴格防火牆規則的大公司。
版本衝突？ 有時候是某個套件的特定版本被移掉了，或者跟其他套件打架。這時候就得去查一下 lock file，看看是不是要鎖定一個還存在的版本，或是乾脆升級。
私有庫出事了？ 如果公司用自己的私有 repository (像 Artifactory 或 Nexus)，那也要檢查一下它是不是活著。

你看，我不會只說「我去檢查 `requirements.txt`」。我會展現一個有邏輯的、由最可能到最不可能的排查順序。這就叫經驗。

狀況二：「Production 環境的設定，跟我們 IaC 裡的定義不一樣！」

啊，這個我熟，組態漂移 (Configuration Drift)。理論上，所有變更都該透過 Infrastructure as Code (IaC) 走，但現實是... 總會有英雄爲了救火，半夜三點直接手動登入正式機改設定。面試官問這個，是想看你怎麼面對「不完美」的現實。

我的回答思路會是：

先調查，不急著動手： 第一時間不是急著把它改回來。我要先搞懂「為什麼」會不一樣？是緊急修復嗎？那個修復是合理的嗎？搞不好手動改的才是對的，只是忘了更新回程式碼。
同步狀態： 了解前因後果後，把「正確的」狀態寫回 IaC 程式碼裡。對，不管是保留手動變更，還是改回原本的設定，最終都必須讓 Code 成為唯一的真相來源 (Single Source of Truth)。
建立防護網： 然後呢，最重要的來了。我要怎麼防止下次再發生？我會建議導入自動化工具去偵測 Drift，像是 AWS Config 或用 Terraform 的 plan 來定期檢查。同時，也要加強團隊流程，讓大家知道「繞過 IaC 是技術債，遲早要還的」。

狀況三：「有個服務一直出現 OOMKilled，怎麼辦？」

這個問題超經典，馬上就能分出 junior 跟 senior。Junior 可能會說「把 memory limit 調高啊！」，然後...就沒有然後了。

一個比較有經驗的回答應該是這樣的：

「OOMKilled 啊，這表示 Container 吃掉的記憶體超過我們給它的額度了。直接調高 limit 只是治標不治本，還可能拖垮整個 Node。我的處理步驟會是：」

觀測先行： 馬上衝去看監控數據，像是 Prometheus 或 Datadog。我想知道它的記憶體用量是穩定偏高，還是在某個特定操作後突然飆升？這能幫助我判斷是常態性資源不足，還是有 memory leak。
合理設定 Request & Limit： 在 Kubernetes 裡，`requests` 是保證拿到的資源，`limits` 是上限。我會根據觀測到的平均用量來設定 `requests`，然後給一個合理的 `limits` 當作保險絲，而不是無限上綱。
應用程式優化： DevOps 不是只管維運。我會拿著數據去找開發團隊，跟他們說：『欸，我們發現這個 API call 會讓記憶體暴增，是不是有機會從程式碼層面優化一下？』
水平擴展 (HPA)： 如果記憶體用量是跟著流量走的，那設定 Horizontal Pod Autoscaler，讓它在負載高的時候自動多開幾個 Pod 來分攤壓力，會比垂直拉高單一 Pod 的記憶體更健康。

這個回答顯示了你不只會調設定檔，你還懂得以數據為基礎，跟開發協作，並且從架構層面去思考解決方案。

怎麼做：建立你的「場景題回答框架」

講了這麼多，你會發現好的回答都有一個共通點：結構。我自己是覺得，可以用一個簡單的「CPR」框架來組織你的答案，這不是醫學那個 CPR，是 Context、Process、Retrospective。

C - Context (情境說明與反問)

千萬不要面試官一問完就急著回答。先花幾秒鐘，甚至可以反問幾個問題，來釐清這個「場景」的上下文。這會讓你顯得非常穩重。

「好的，關於這個部署失敗的問題。我想先確認一下，這是一個關鍵的核心服務，還是比較周邊的應用？它的部署頻率大概是多久一次？」
「您提到的效能變慢，請問有具體的指標嗎？例如是哪個 API 的延遲變高了？還是整個網站的載入時間？」

先定義好問題的邊界，你的答案才會精準。

P - Process (處理流程)

這是你展現技術硬實力的地方。把你腦中的SOP (標準作業程序) 一步步講出來。記得，要有邏輯順序。

短期應急 (救火)： 先做什麼來止血？例如， rollback 到上一個穩定版、切換到備援系統。
中期診斷 (抓蟲)： 怎麼找出根本原因？例如，查 Log、看 Trace、分析監控圖表。
長期修復 (根治)： 找到原因後，怎麼修復？例如，寫 Patch、調整 IaC 程式碼、優化資料庫索引。

把這些步驟講清楚，面試官就能在腦中描繪出你實際工作的樣子。

R - Retrospective (回顧與預防)

這是把你跟其他人區分開來的關鍵一步。解決問題只是基本功，一個資深的工程師會思考「如何避免下次再發生」。

流程改善： 「這次事件後，我會召集一個 blameless postmortem 會議，檢討我們是不是可以在 CI 階段就加入更多測試，來提早發現這類問題。」
監控與告警優化： 「看起來我們目前的監控沒能及時發現這個問題。我會加上一個新的 dashboard，並且設定更敏感的告警規則。」
文件與知識分享： 「我會把這次的處理過程記錄下來，更新到我們的內部 Wiki，確保團隊其他人未來遇到類似狀況，能更快反應。」

當你講到 R 這個層次，面試官就知道，你不只是一個聽命令的執行者，而是一個能推動團隊和系統進步的貢獻者。

不同公司，答案差很多？新創 vs. 大企業的回答策略

對了，還有一個很多人會忽略的點。同一個問題，你在面試新創公司和面試大企業時，好的答案可能完全不一樣。如果你能展現你懂這中間的差異，絕對大加分。

比方說，面試官問：「你會怎麼設計一個高可用性的系統？」

面試新創公司： 你的答案可以更偏向「快」和「成本效益」。
「初期我會優先利用雲端託管服務，例如用 AWS 的 RDS Multi-AZ 來確保資料庫高可用，應用程式本身用 Auto Scaling Group 部署在多個可用區 (AZ)。這樣做能用最快的速度和相對低的成本，達到很不錯的基礎設施韌性，讓我們專注在產品開發上。」
面試大企業： 你的答案就要更強調「穩定」、「安全」和「流程」。
「我會設計一個多區域 (Multi-Region) 架構。除了在單一 Region 內做到 Multi-AZ，還會有一個被動的災難備援 Region。所有基礎設施的建置都會透過 Terraform 進行，並且有嚴格的 Code Review 流程。我們會定期進行災難備援演練 (DR Drill)，確保在主要 Region 失效時，我們有信心能在預定的 RTO/RPO 內切換過去。所有跟合規性 (Compliance) 相關的設定，也都會在 IaC 中體現。」

看到差別了嗎？一個強調快速迭代，一個強調風險控管。能根據對方的公司屬性，微調你的答案，代表你真的懂。

Monorepo 好還是 Multi-repo 好？萬年大哉問

說到權衡取捨，這個問題絕對是經典中的經典。基本上就像在問「vi 跟 emacs 哪個好」，沒有標準答案，只有 trade-offs。如果被問到這個，千萬不要直接說「我選 Monorepo」，而是要分析給他聽。

我自己是這樣看的啦：

考量點	Monorepo (單一程式碼庫)	Multi-repo (多個程式碼庫)
程式碼共用	超簡單，大家都在同一個家裡，要用什麼直接拿。改一個共用 library，所有用到的人立刻就更新了。	很痛苦... 你得把共用模組發布成 package，然後每個 repo 再去更新依賴。版本控制會搞死人。
跨專案重構	一個 commit 就能搞定！比如說我想改一個 API，我能同時修改 API 本身跟所有呼叫它的服務，保證一致性。	一場災難。你可能要發好幾個 PR 到不同 repo，然後協調它們的部署順序，超容易出錯。
CI/CD 建置速度	這是硬傷。如果沒做好，隨便改一行小程式碼，可能整個超大的 repo 都要重新 build 跟 test，等到天荒地老。	速度快！每個 repo 都小小的，CI/CD pipeline 只針對有變動的部分跑，非常有效率。
團隊所有權	比較模糊。大家都在同一個大鍋裡寫 code，有時候責任歸屬比較不清楚。	非常清楚。每個 repo 就是一個團隊或一個服務的領地，誰的地盤誰負責，一清二楚。
我的建議	如果你的服務之間耦合度很高，有很多共用程式碼，那 Monorepo 可能不錯。但工具鏈要設定好，不然會被 build time 拖垮。	如果你的團隊和服務都切分得很獨立 (真・微服務)，那 Multi-repo 會讓每個團隊跑得更快、更自主。

常見錯誤與修正：這些地雷千萬別踩

最後，分享幾個我在面試別人時，最常看到的一些「NG 行為」，大家有則改之，無則加勉。

只給答案，沒有思路： 直接說「用藍綠部署」，但沒解釋為什麼在這個場景下，藍綠部署比金絲雀部署 (Canary) 或滾動更新 (Rolling Update) 更好。
推卸責任，缺乏 Ownership： 「那是開發人員的程式碼有 bug」、「那是 QA 沒測到」。DevOps 文化強調的是共同承擔責任，你該說的是「我會跟開發團隊合作找出問題」、「我會跟 QA 討論如何把這個測試案例加到自動化流程裡」。
忘了監控與可觀測性： 任何解決方案，如果你不提你會怎麼監控它、怎麼知道它運作良好，那這個答案就只算做了一半。一個好的 DevOps 工程師，腦中隨時要有 dashboard。
完全不提安全性： 「我會開一個 S3 bucket 來放資料」，然後呢？權限呢？加密呢？Log 呢？在現代，安全性 (Security) 早就不是一個獨立的部門，而是每個 DevOps 工程師的內建思維。

對了，說到工具，其實大家用的東西都差不多。我之前看國外一些討論，他們可能會提到像 Pulumi 這種用程式語言來寫 IaC 的工具，這蠻酷的。不過，我自己觀察我們台灣的社群，比如說 AWS User Group Taiwan 的分享，大家還是更務實地聚焦在怎麼把 Terraform 或 CloudFormation 在本地產業的實務中用得更好。工具是其次，能解決問題的思路才是王道。