題目
請講一次你發現建置雖然通過測試，卻無法驗證來源或簽章，因此推動改變發布決定的經歷。面試官關注你如何判斷證據是否足夠、如何影響沒有直接匯報關係的團隊，以及最後如何恢復交付。
場景與適用邊界
選擇一個真實發布、依賴升級或供應鏈稽核場景。說明當時有哪些證據、哪些未知項、發布窗口多緊，以及你擁有哪些權限。不要把「沒有簽章」直接等同於「惡意程式碼」，也不要把事後補上的證明假裝成當時已存在。
面試官考察點
核心能力是證據判斷與風險溝通：把「建置成功」與「建置來自獲授權流程」區分開，用可驗證的摘要、簽章、身分和時間戳定義門檻。GitHub 文件將 artifact attestation 用於證明軟體由何處、如何建置，並要求驗證簽章和簽署者身分；Google SRE 則強調以事實記錄決策並把改進項落入後續工作。
回答前可以先確認：
- 發布對象是內部服務、客戶可下載套件還是容器映像？
- 缺少的是簽章、建置身分、來源連結、SBOM，還是這些證據之間的綁定？
- 誰擁有發布批准權，哪些動作可逆，最晚何時必須決定？
- 你能否先限制範圍、保留舊版本或產生一份可稽核的重建結果？
30 秒回答框架
用 STAR-L：Situation 說明發布目標與證據缺口；Task 說明你要保護的使用者或合規目標；Action 說明你如何核對摘要、簽章和工作流程身分，提出分級門檻並協調補證；Result 給出延遲、涵蓋範圍和風險變化；Learning 說明新的證明檢查如何進入流水線。
分步驟深入解答
- 先凍結結論：記錄待發布工件摘要、測試結果、建置工作流程和現有證明，區分事實與推測。
- 定義最低證據：工件摘要必須與待發布物件一致，證明要能綁定儲存庫、提交、工作流程和簽署身分；缺任一項就標記為 Unknown。
- 提出分級方案：高風險工件暫停；低風險工件可保留舊版本或小範圍內部灰度，但不得繞過稽核記錄。
- 讓相關團隊共同驗證：與建置、發布、安全和業務負責人共享同一份證據清單，指定負責人和截止時間。
- 恢復並追蹤：驗證通過後只發布符合摘要的工件，記錄例外原因、批准人和後續行動項。
高品質示範回答
「一次緊急修復已通過全部測試，但發布系統拿不到與提交 SHA 綁定的簽章證明。我先記錄映像摘要、測試結果和建置日誌，確認問題是證明缺失而非摘要不一致。由於該版本面向客戶，我建議暫停外部發布，同時保留舊版本並為內部環境產生灰度包。接著我和建置團隊補上工作流程身分與簽署步驟，讓安全團隊用獨立憑證驗證簽章，並讓發布負責人確認最晚恢復時間。最後發布延遲 90 分鐘，灰度和回滾都按計畫完成；之後我們把摘要比對、簽章驗證和例外批准加入必要門檻。我的學習是：證據門檻必須在壓力來臨前寫成自動檢查，人工判斷只處理有記錄的例外。」
常見錯誤
- 把測試全綠當成來源可信的充分證據。
- 只說「加簽章」，沒有說明簽章綁定了什麼物件、由誰簽署、如何驗證。
- 用安全風險壓過業務目標，卻沒有提供舊版本、灰度或截止時間方案。
- 把建置團隊描述成阻礙者，忽略跨團隊共同驗證。
- 只報發布是否成功，不報延遲成本、涵蓋範圍和後續門檻。
評估時看事實時間線、工件摘要與建置來源的區分、與風險匹配的可逆方案、無匯報關係下的推動方式和數字結果。一般回答停留在「加強安全」或把個人直覺當作證據。
追問及應對
如果業務負責人要求先發再補證明，你怎麼辦？
先確認發布對象和最壞影響，提出舊版本、內部灰度或縮小範圍等可逆方案；若仍要例外發布，記錄未驗證項、批准人、截止時間和回滾條件，不能把例外假裝成合規通過。
簽章有效但提交不在允許的儲存庫或分支，可以發布嗎？
不能只看簽章有效。還要驗證簽署身分、儲存庫、提交、工作流程和環境是否符合策略；任一綁定關係不滿足就進入人工複核或阻斷。
如何證明新門檻沒有讓團隊無限等待？
為每項證據指定自動檢查、負責人和時限，統計阻斷次數、平均恢復時間和例外比例；每次例外都進入複盤，持續減少人工等待。
面試作答要點
一句話總結
把「建置通過」升級為「工件、來源、身分和決策均可驗證」，再用可逆方案兼顧交付與風險。