題幹與適用場景
把它視為繁忙程式碼儲存庫的產品決策，而不是簡單開啟功能。GitHub 對合併佇列的定義包含在最新目標分支和佇列中其他變更上套用拉取請求，再執行必要狀態檢查。因此決策會同時影響回饋時間、計算成本、主分支穩定性與貢獻者自主性。
假設團隊擁有分支保護設定和拉取請求事件資料，並有兩週進行受控試點。目標是在不讓作者無限等待的前提下減少預設分支的壞建置。
面試官考察點
高品質回答會把使用者痛點連接到可測量的介入。回答應區分衝突、易失敗檢查、慢檢查和發布風險，不能把所有失敗都歸因於佇列。還要給出基線、護欄指標、試點範圍與回滾觸發條件。
普通回答只說「開啟佇列並觀察 CI」。強回答會說明適用儲存庫、批次如何改變檢查負載，以及推測批次失敗時如何讓開發者得到可行動的回饋。
回答前需要澄清的問題
- 痛點是失敗合併、衝突處理、主分支損壞，還是發布事故？答案不同，產品方案也不同。
- 必要檢查是否穩定並且可以平行？易失敗檢查會被佇列放大。
- 從批准到合併的 p95 可接受多久？哪些團隊不能接受這段延遲？
- 單體儲存庫需要一個佇列，還是應按獨立擁有區域拆分？
- 緊急修復能否在審計記錄完整的例外流程下暫停佇列並合併？
如果基線顯示多數失敗來自易失敗測試，應先修復測試。如果主要問題是批准後基線繼續變化導致的回歸，佇列更直接對應痛點。
30 秒回答框架
「我會先量化主分支損壞分鐘數、衝突返工、排隊等待、易失敗檢查率和 CI 成本。然後選擇檢查穩定的高頻儲存庫做兩週試點，設定合併耗時和失敗率護欄，並保留暫停開關。我會與相似儲存庫或試點前基線比較，按變更大小和團隊分組；只有在減少整合失敗且沒有突破等待時間和成本上限時才保留佇列。」
分步驟深入解答
- 診斷問題。 從近期拉取請求建立失敗分類：衝突、變更導致的測試失敗、基線導致的失敗、易失敗、逾時和策略拒絕。
- 設定門檻。 例如要求主分支損壞分鐘數下降 30%，批准到合併的 p95 增幅不超過 10%，並限制 CI 成本增幅。
- 設計試點。 選擇吞吐量足夠且檢查穩定的儲存庫，固定必要檢查，記錄緊急繞過規則，並說明佇列位置和失敗展示方式。
- 建立批次模型。 佇列會在最新基線和佇列變更上評估。上線前估算額外檢查次數、快取命中率和並發，避免試點耗盡執行器。
- 建設回饋。 記錄入隊時間、出隊原因、批次組成、檢查時長、失敗歸屬、重試次數和定位耗時；批次失敗時盡可能給出最小嫌疑集合。
- 複盤與回滾。 與基線或對照組比較，按團隊檢查異常；如果等待、易失敗放大或緊急交付超過護欄，就暫停佇列。
替代方案包括更及時的基線更新提醒、衝突自動化、更快檢查、發布列車或只保護更小的分支集合。當整合排序是主要風險時，佇列才有明顯價值。
高品質示範回答
「我不會把它作為全公司的預設設定。先從提交量最大的服務儲存庫開始，因為它同時有主分支回歸和穩定的檢查。兩週試點記錄主分支損壞分鐘數、批准到合併的 p95、放棄率、易失敗檢查率和檢查計算小時。成功標準是損壞分鐘數至少下降 30%、等待 p95 小於 20 分鐘、計算量增加不超過 15%。介面展示佇列位置、失敗歸屬，並提供暫停控制。如果佇列只是反覆重試易失敗檢查或阻塞緊急修復，我會暫停並優先投入檢查可靠性或提速。」
常見錯誤
- 錯誤表現： 把所有檢查失敗都當作上線佇列的理由 → 失敗原因： 易失敗和慢檢查的根因仍在 → 修正方法： 先分類失敗並設定上線前提。
- 錯誤表現： 只優化合併正確性 → 失敗原因： 貢獻者承擔不可見等待和不清晰失敗 → 修正方法： 加入等待 p95 和定位耗時護欄。
- 錯誤表現： 忽略批次計算量 → 失敗原因： 推測檢查可能耗盡執行器 → 修正方法： 先建立並發、快取和成本模型。
- 錯誤表現： 不提供緊急路徑 → 失敗原因： 事故中會出現不安全繞過 → 修正方法： 定義可審計的暫停或例外流程。
追問及應對
佇列讓主分支損壞時間下降，但 CI 成本翻倍，怎麼辦？
保留條件化結論。嘗試選擇性佇列、更強快取或縮小必要檢查，再比較每減少一分鐘損壞時間所需的成本。未滿足成本上限前不能宣布試點成功。
必要檢查很容易抖動，如何處理？
把易失敗率設為上線門檻，隔離或修復檢查，並明確展示重試。靜默重試可能保住吞吐，卻會破壞訊號可信度。
團隊說緊急修復被佇列阻塞，怎麼改？
加入有審核、審計事件和後續合併的緊急流程，並統計例外頻率。頻率過高說明佇列策略或拆分方式不對。
什麼時候永久停止推廣？
調校後等待或放棄率仍越過護欄、佇列失敗無法定位，或更快檢查和分支自動化能以更低成本得到同樣結果時，應停止推廣。