1. 題目與使用場景
平台團隊需要修改防火牆規則、支付限額或服務路由。提交者不能批准自己的變更，審批必須針對確切版本，執行失敗不能留下半更新狀態。系統目標是把「有人說可以」變成可驗證、可稽核、可恢復的流程。
2. 面試官考察點
- 是否能區分提案、審批、執行和回滾狀態。
- 是否保證審批人獨立、審批內容不可被靜默替換。
- 是否處理並發審批、重複請求、逾時、撤銷和權限變化。
- 是否在控制風險的同時提供小範圍試運行和穩定回退路徑。
NIST SP 800-128 要求配置變更由獨立於請求者的授權人員審查；Google SRE 強調配置版本應進入程式碼審查，並在新配置未通過檢查時繼續使用舊配置。設計應把這些原則落實到資料和狀態機。
3. 回答前需要釐清的問題
- 哪些資源和欄位屬於高風險，是否按環境或租戶區分？
- 審批是單人、多人任一通過，還是必須達到人數和角色門檻？
- 執行是全量切換、分批發布，還是需要目標實例確認？
- 回滾目標是上一個已知版本，還是提交者指定的版本？
4. 30 秒回答框架
用「提案快照—策略匹配—審批隔離—執行器—回滾稽核」回答：
我把每次變更凍結成不可變版本，策略根據資源、風險和環境選擇獨立審批人。審批記錄版本摘要和策略版本，提交者不能滿足審批門檻；達到門檻後由冪等執行器分批套用，並在每批做健康檢查。任何失敗都停止擴散、切回上一個已驗證版本，所有狀態和決定寫入不可篡改的稽核日誌。
5. 分步驟深入解答
第一步：定義核心實體與狀態機
配置提案包含資源、差異、作者、版本摘要、目標環境和過期時間；審批包含審批人、角色、決定、時間、策略版本和提案摘要；執行記錄包含批次、目標、結果和回滾版本。狀態可為 DRAFT、PENDING_APPROVAL、APPROVED、EXECUTING、SUCCEEDED、FAILED、REVOKED 或 EXPIRED，狀態轉移只能由服務端規則觸發。
第二步：實作獨立且綁定版本的審批
策略服務計算所需角色、人數、是否禁止自批和審批有效期。審批人看到的差異摘要必須與執行版本雜湊一致；提案被修改就自動失效並重新審批。權限在審批和執行時都重新檢查，避免審批後角色被撤銷仍能執行。
第三步：用冪等執行器控制發布
執行器為每個提案和目標產生冪等鍵，記錄外部系統回執。按小批次套用，先做語法、依賴和安全檢查，再觀察健康指標；重試只處理未知結果，不能盲目重複非冪等操作。佇列或工作流負責逾時、重試和並發限制。
第四步：安全回滾與稽核
發布前保存上一個已驗證版本，失敗時停止後續批次並恢復該版本。回滾本身也要記錄操作者和原因，必要時觸發緊急審批。稽核日誌至少包含提案摘要、審批鏈、執行批次、配置版本、失敗原因和回滾結果，並限制刪除和修改權限。
6. 高品質示範回答
我會把系統拆成提案 API、策略服務、審批服務、執行佇列、配置適配器和稽核儲存。提案寫入不可變版本，包含資源差異、環境、作者和過期時間；策略服務根據風險等級計算所需角色和審批人數，並排除作者本人。
>
審批人看到版本摘要和差異，審批記錄綁定提案雜湊與策略版本。提案任何修改都會回到待審批狀態。達到門檻後，執行器用提案 ID 加目標 ID 生成冪等鍵，先做靜態檢查，再按小批次套用並讀取健康訊號。重複請求讀取已有執行結果，未知結果進入人工複核。
>
每個提案保存上一個已驗證版本。某批次失敗時暫停後續批次，恢復舊版本並記錄原因；高風險緊急回滾仍需獨立審批。稽核事件寫入只追加儲存，包含誰在何時批准了哪個摘要、哪些目標已執行以及是否回滾。這樣既滿足 separation of duties，也避免審批通過後配置被悄悄替換。
7. 常見錯誤
- 審批只綁定資源 ID，不綁定具體差異和版本摘要。
- 作者可以用第二個角色自批，破壞獨立性。
- 直接把批准結果寫入配置庫，沒有執行狀態和回執。
- 失敗後繼續擴大批次，或對非冪等操作無限重試。
- 回滾沒有版本、權限和稽核記錄。
8. 追問及應對
追問一：審批人批准後提案作者離職怎麼辦？
審批結果綁定不可變提案，不依賴作者在線；執行權限由服務帳號和當前策略決定，撤銷作者不會刪除有效稽核鏈。
追問二：如何防止兩個審批流程同時執行同一資源？
按資源和環境建立互斥鎖或租約，並在執行前再次檢查當前配置版本；衝突時讓較新的提案重新計算差異和審批。
追問三：緊急變更能否跳過審批？
可以定義受限的 break-glass 流程，但仍需雙人授權、最小權限、短效期、事後複核和完整稽核，不能把緊急通道變成日常捷徑。