題幹與適用場景
一款 B2B SaaS 服務記錄登入、權限變更、資料匯出和管理操作。客戶提出不同保留需求：小客戶只想查詢最近 90 天，大客戶希望保存 7 年並能向稽核員提供證據。團隊擔心長期儲存成本、敏感資料暴露、刪除請求和複雜查詢體驗。
請判斷是否提供租戶級保留策略，並說明最小可行範圍、定價、預設值、不可竄改和刪除流程。NIST SP 800-92 將日誌管理視為涵蓋產生、保護、保留與審查的流程；題目考察你能否把合規訴求轉成可營運的產品邊界。
面試官考察點
重點包括客戶問題與合規證據、保留層級與預設策略、冷熱分層成本、日誌完整性、存取控制、個人資料最小化、刪除與法律保全衝突、查詢延遲、稽核匯出，以及成功指標和風險護欄。
回答前需要釐清的問題
- 哪些產業、地區和合約條款要求特定保留期或不可變儲存？
- 稽核員要查什麼事件、時間範圍與欄位，是否需要匯出到客戶 SIEM？
- 7 年資料的寫入量、查詢頻率、加密和資料駐留要求是什麼？
- 客戶可刪除個人資料時，日誌中的主體、目標和原因如何最小化？
- 團隊目前的儲存、索引、權限和成本基線是多少？
30 秒回答框架
「我先按合規風險和客戶稽核任務分層驗證需求，再提供有限檔位而非任意天數。預設短期熱儲存，長期進入低成本、加密、不可變的歸檔，並提供非同步檢索和簽名匯出。租戶策略需要權限、審批、計費和資料駐留約束；刪除請求與法律保全分開處理。用採用率、稽核任務成功率、查詢延遲、成本和隱私事件作護欄。」
分步驟深入解答
第一步：驗證問題與客戶分層
訪談安全負責人、合規負責人和一線稽核員，收集最近一次稽核的事件類型、證據格式和回應時間。把需求分成調查、合規留存、法律保全和日常排障，避免把所有「想留久一點」都當成同一問題。
用客戶產業、合約義務、地區和席位規模建立分層；小客戶可使用統一預設檔位，受監管客戶再開放較長檔位與匯出能力。保留期不是越長越有價值，必須與可檢索性和證據可信度一起評估。
第二步：設計有限檔位與預設值
先提供 90 天、1 年和 7 年等少量檔位，避免任意天數造成大量快取、索引和計費變體。預設檔位應滿足多數排障場景；升級到長期保留要展示預計容量、費用、查詢延遲和不可逆影響。
策略變更需要管理員權限、二次確認和稽核事件。縮短保留期不應立即刪除可能受法律保全約束的記錄，而應進入待刪除狀態並顯示預計生效時間。
第三步：建立熱、溫、冷分層
近期日誌進入可篩選的熱層，支援按時間、主體、操作和資源查詢；較舊日誌轉入物件儲存或歸檔層，使用壓縮、加密和生命週期規則降低成本。長期歸檔可非同步恢復，產品必須顯示預計等待時間，而不是偽裝成即時搜尋。
容量模型按租戶事件量、欄位大小、索引比例、複製和保留天數計算。把儲存、索引、恢復和匯出成本拆開，避免只看物件儲存單價。
第四步：保證完整性、權限與隱私
每筆事件包含時間、主體、動作、目標、結果、請求追蹤和來源；敏感欄位最小化、去識別或分離儲存。寫入路徑使用追加式權限，歸檔啟用加密、版本保護和日誌完整性校驗，查詢按租戶、角色和欄位授權。
管理員查看高敏事件應留下二次稽核記錄。匯出包應包含範圍、產生時間、雜湊和簽章，方便客戶驗證內容沒有被替換。
第五步：處理刪除請求與法律保全
把應用資料刪除、個人資訊最小化、稽核證據保留和法律保全建模為不同狀態。刪除主體資訊時可採用穩定的不可逆替代識別，但不能破壞事件順序、動作和結果的稽核意義。
法律保全必須有授權人、範圍、原因、起止時間和解除流程；保全中的記錄不可被租戶自行縮短。產品介面顯示衝突原因和預計處理者，避免讓客戶誤以為刪除按鈕已完成所有動作。
第六步：驗證查詢、匯出與商業價值
用真實稽核任務做可用性測試：定位一次權限變更、匯出指定期間事件、驗證簽章並交給外部稽核員。測量熱層查詢 p95、冷層恢復時間、匯出成功率、結果完整性和權限誤報。
商業上比較高檔位採用率、淨收入留存、儲存毛利和支援工單下降。若長期檔位只有少數客戶採用，可先做受控銷售和按量計費，再決定是否產品化全部自助設定。
高品質示範回答
我會先驗證客戶的稽核任務和合約義務，再提供有限保留檔位。預設將近期日誌放在可查詢熱層，長期日誌進入加密、不可變的低成本歸檔，冷資料採用非同步恢復。租戶策略需要管理員權限、計費、資料駐留和審批；刪除請求與法律保全分開建模。透過稽核任務成功率、查詢 p95、匯出完整性、單位儲存成本和隱私事件決定是否擴展。
常見錯誤
- 允許任意保留天數 → 產生複雜計費和索引變體 → 先提供有限檔位。
- 只承諾長期保存 → 客戶仍無法在稽核時找到證據 → 同時定義查詢、恢復和匯出體驗。
- 把所有欄位永久保存 → 隱私和刪除風險擴大 → 欄位最小化、去識別和分離儲存。
- 把租戶刪除當成法律保全刪除 → 證據可能被破壞 → 分離狀態、權限和解除流程。
- 只看儲存單價 → 忽略索引、恢復和支援成本 → 按完整生命週期建模。
追問及應對
追問一：為什麼不直接支援客戶自訂任意天數？
任意天數會放大快取、計費、測試和生命週期複雜度。先驗證少量高頻檔位，再根據採用率和合約需求擴展。
追問二：7 年日誌如何保證可驗證？
使用加密和不可變歸檔，保留事件範圍、雜湊、簽章、版本與產生時間，並提供可驗證的匯出包和恢復演練。
追問三：客戶要求立即刪除個人資訊怎麼辦？
先識別法律保全和合規例外，再對主體資訊做不可逆替代或分離刪除，同時保留必要的事件順序和結果證據，並記錄處理決定。
追問四：怎樣判斷該功能值得做？
看目標客戶的付費意願、稽核任務成功率、採用率、毛利、支援工單和隱私風險；用受控銷售驗證，不以單一客戶的最長保留要求決定全量開發。