行為面試：講一次你因可靠性風險暫停發布並用證據重啟的經歷

題目

請講一次你發現發布存在未量化可靠性風險，推動暫停或縮小範圍，之後用證據重新取得發布許可的經歷。面試官關心你的判斷、溝通、行動與結果，而非故事中的技術名詞數量。

場景與邊界

故事應來自真實專案，包含明確時間壓力、受影響使用者或服務、當時可見的訊號和你的決策權限。可以暫停全量發布、改為小流量灰度，或先補齊回滾能力；不能把事後才知道的事實當成當時已有的證據。

核心考點

考察能否把直覺擔憂轉成可驗證風險，把分歧轉成共同決策門檻，並在保護可靠性的同時維持交付節奏。Google SRE 的發布協調實踐強調可靠性優先與跨團隊溝通；GitLab 事件複盤強調理解決策過程而非尋找個人歸因。

參考回答結構

使用 STAR-L：Situation 說明發布窗口和風險訊號；Task 說明要保護的使用者目標與可用權限；Action 說明如何提出暫停、定義指標、安排驗證、同步利害關係人並保留回滾路徑；Result 給出發布結果、使用者影響與後續改進；Learning 說明新的發布門檻如何進入流程。

關鍵細節

說清風險如何量化，例如錯誤率上限、關鍵路徑延遲、灰度樣本量、回滾耗時或依賴版本。說明誰擁有最終決定權、如何讓對方看到同一份資料，以及哪些條件滿足後才恢復發布。結果要包含避免的損失與實際付出的成本。

常見誤區

把「我堅持正確所以大家聽我」當成行動；只描述技術修復而不說溝通；把同事寫成風險來源；聲稱零風險；只報成功不解釋暫停代價；用泛泛的「加強監控」代替具體門檻。

評估標準

高品質回答有具體時間線、個人行動和可核驗結果，能同時承認業務壓力與可靠性風險，解釋何時升級、何時恢復，並把學習沉澱為流程。一般回答只有抽象衝突、沒有數字或沒有自己的決策貢獻。

追問

如果產品負責人不同意暫停，你會怎麼做？

先把風險、未知項、可逆選項和截止時間寫成同一頁決策記錄，提出最小範圍灰度或短時驗證；若仍超出權限，按既定升級路徑請有決策權的人裁決，並記錄異議與接受的風險。

你如何證明暫停沒有變成無限期阻塞？

為每個未知項指定負責人、驗證方法和截止時間，設定明確恢復門檻；每日更新狀態，達標就推進，未達標就調整範圍或重新評估。

複盤時如何避免把責任歸給個人？

描述系統條件、訊號缺口、決策上下文與流程改進，使用事實時間線而非動機推斷；同時明確你個人可改進的行為，並追蹤行動項是否關閉。