題幹與適用場景
企業客戶害怕修改自動化策略後誤傷大量資源。你需要判斷 SaaS 是否應在提交變更前提供 Dry Run 預覽，展示潛在允許、拒絕和受影響物件。
題目考察產品取捨，不要求綁定 OPA、Terraform 或某個工作流引擎。重點是預覽與真實執行之間的差異、使用者信任、權限和漸進發布。
面試官考察點
使用者問題
能否區分「我想知道會影響誰」與「我想驗證最終執行一定如此」，並識別高風險策略和關鍵角色。
準確性邊界
能否說明預覽使用的狀態快照、外部事實和時間點，避免把過期模擬包裝成保證。
產品範圍
能否選擇首批支援的策略類型、物件規模、差異展示、審批和回復，而不是承諾所有規則都可完美模擬。
價值驗證
能否用誤傷率、撤銷率、預覽採用率、執行差異和支援工單驗證功能價值。
回答前需要釐清的問題
- 哪類策略最容易造成大規模或不可逆影響？
- 客戶希望預覽物件清單、摘要、差異還是成本估算？
- 預覽需要即時外部狀態，還是允許基於快照？
- 變更是否需要多人審批、回復或稽核留存？
- 結果是否包含敏感資源名稱或跨租戶資訊？
- 預覽延遲和物件數量上限是什麼？
30 秒回答框架
「我會先驗證高風險策略客戶是否真的因缺少影響可見性而延遲或誤提交。首版只覆蓋可解釋、可列舉的規則，基於帶時間戳的狀態快照返回新增、移除、允許、拒絕和不確定項。預覽明確不是執行保證，提交時重新評估並顯示差異。權限沿用真實執行權限，結果可稽核，超大範圍非同步生成。透過預覽採用率、執行差異、撤銷率和事故率決定擴展。」
分步驟深入解答
第一步：驗證問題與分群
訪談管理員、稽核員和一般操作者，收集因策略誤傷、審批延遲或回復困難產生的損失。按不可逆性、物件數量和客戶合規要求分級。
第二步：定義預覽契約
規定輸入策略版本、評估時間、狀態快照、外部事實版本和輸出類型。結果至少區分將改變、保持、不適用和無法判斷，並給出原因。
第三步：選擇首批範圍
優先支援規則明確、物件可列舉、結果可解釋的策略。暫不支援依賴即時亂數、人工操作或不可觀測外部系統的規則，提供明確「不確定」狀態。
第四步：設計互動與護欄
顯示摘要、物件樣例、下載清單、敏感欄位遮罩和差異警告。高風險變更要求重新確認、雙人審批或分階段執行；預覽和提交使用同一權限檢查。
第五步：處理競態與隱私
提交時重新評估目前狀態，比較預覽版本與執行版本；差異超過門檻則暫停並要求確認。結果按租戶隔離、最小化展示並保留稽核記錄。
第六步：發布與衡量
從內測和低風險客戶開始，記錄預覽耗時、採用率、執行差異、撤銷、誤傷和支援工單。若預覽經常與執行不同，先修復狀態快照或縮小承諾，再擴大範圍。
高品質示範回答
「我不會把 Dry Run 當成全域安全保證。先選擇刪除、批量授權等高風險且結果可列舉的策略，驗證客戶是否需要影響清單來降低誤提交。預覽輸入綁定策略版本、租戶、評估時間和狀態快照，輸出新增、移除、保持和不確定物件，並解釋規則命中。
預覽結果明確標注有效期，提交時用同一執行引擎重新計算；狀態變化造成差異就暫停或要求確認。沿用真實權限，敏感資源只展示摘要，超大結果非同步生成並可下載。先在低風險客戶灰度，透過執行差異、撤銷率、誤傷率和工單衡量，結果穩定後再支援更多規則。」
常見錯誤
- 把模擬結果說成執行保證。
- 忽略預覽和提交之間的狀態競態。
- 首版承諾支援任意策略、任意物件規模和所有外部依賴。
- 只展示一個總數，沒有原因、樣例或不確定狀態。
- 預覽權限比真實執行更寬，洩露跨租戶資源。
- 不保留策略版本、狀態時間點和稽核證據。
- 只看頁面點擊量，不衡量執行差異和誤傷。
- 預覽不一致時繼續擴展，而不是修復邊界。
追問及應對
追問一：預覽和真實執行不一致怎麼辦？
提交時重新評估並顯示差異；超過門檻就暫停。記錄預覽和執行的策略、狀態、時間和決策 ID，持續分類差異來源。
追問二：為什麼不直接複製生產資料做模擬？
複製會增加隱私、成本和新鮮度問題。優先使用權限隔離的快照或脫敏投影，只保留預覽所需欄位，並標注快照時間。
追問三：哪些客戶最適合先用？
選擇物件邊界清晰、審批成熟、可回復且願意提供回饋的客戶；高合規客戶需先確認稽核、留存和資料隔離要求。
追問四：預覽結果太大怎麼辦？
先展示分組摘要和代表樣例，再提供非同步清單與完成通知；設定上限和成本提示，避免大查詢拖垮執行系統。
追問五：如何證明功能值得長期維護？
比較啟用客戶與對照組的誤提交、撤銷、事故、審批耗時和支援工單，結合預覽與執行差異率判斷準確性和實際節省。