系統設計面試：如何建立能自動發現實驗品質問題的 A/B 平台？
題幹與適用場景
產品團隊每天執行數百個 A/B 實驗，平台負責分配使用者、記錄觸發事件、計算指標並監控實驗品質。過去出現過分流不均、樣本比例失配和反覆查看導致的錯誤結論。請設計從實驗設定到結論審核的系統，並說明資料延遲、統計方法、告警和權限邊界。
面試官考察點
- 是否先釐清實驗單位、隨機化層級、互斥平面和指標口徑。
- 是否把 assignment、trigger、exposure 和 outcome 事件分開。
- 是否能設計隨機性檢查、SRM 偵測和資料品質告警。
- 是否知道固定樣本量方法不能任意 peeking，能提出 sequential 或 anytime-valid 方法。
- 是否能把告警、稽核、重跑和發布閘門接入完整工作流。
回答前需要釐清的問題
- 實驗按使用者、裝置、工作階段還是請求隨機化？是否允許跨實驗正交執行？
- 每天實驗數量、單實驗流量、指標延遲和保留視窗是多少？
- 主要指標、護欄指標和最小可偵測差異如何宣告？
- 發現 SRM 或埋點缺失後，是暫停流量、標記無效還是自動重跑？
- 誰能查看原始分流、修改停止規則和批准發布？
30 秒回答框架
「我會把平台分成設定與隨機化服務、事件採集管線、實驗分析服務和結論閘門。分流服務用穩定雜湊把使用者映射到固定桶，並區分互斥與正交實驗；事件鏈路分別記錄 assigned、triggered、exposure 和 outcome。品質服務持續檢查桶分布和 SRM，分析服務用支援持續監控的 sequential 或 anytime-valid 方法處理提早停止。所有結論帶資料版本、程式碼版本和稽核記錄，品質告警會阻止發布，而不是只發一則聊天通知。」
分步驟深入解答
1. 先定義實驗與隨機化邊界
實驗設定包括實驗 ID、版本、隨機化單位、流量比例、互斥平面、目標指標、護欄、最小可偵測差異和停止規則。分流雜湊必須使用穩定的使用者鍵和實驗種子，避免請求級隨機導致同一使用者跨變體。互斥實驗共用平面，正交實驗使用不同平面並記錄碰撞策略。
2. 拆分 assignment 到 outcome 事件
只記錄最後轉化無法判斷使用者是否真正看到變體。事件至少要包含分配、觸發、曝光和結果，並帶實驗版本、變體、時間、匿名使用者鍵雜湊和來源。事件模式版本化，遲到事件進入可重算視窗，重複事件用幂等鍵去重。
{
"experiment": "checkout-copy-v3",
"experimentVersion": 7,
"unitHash": "u_8f2c",
"variant": "treatment",
"event": "exposure",
"eventTime": "2026-08-01T12:00:03Z",
"schemaVersion": 2,
"idempotencyKey": "u_8f2c:checkout-copy-v3:7:exposure"
}分配服務與分析管線之間透過不可變事件和版本號連接，避免設定修改後歷史資料被重新解釋。
3. 做隨機性與 SRM 監控
隨機性檢查比較分流桶與預期分布，SRM 檢查實際觸發樣本與設定比例是否一致。監控 assigned 和 triggered 兩個層級，因為埋點、資格條件或客戶端版本可能只在觸發後造成偏差。告警需要區分暫時資料延遲、真實分流錯誤和外部流量變化，並保存診斷切片。
4. 處理持續查看與提早停止
固定樣本量檢驗若每天查看並在顯著時停止，會放大第一類錯誤。平台可以採用 group sequential、SPRT 或 anytime-valid confidence sequence，並把停止邊界、alpha、beta、MDE 和查看時間寫入實驗版本。產品方看到「領先」不代表可以繞過統計閘門；護欄失敗或信賴區間越過安全邊界時應優先停止流量。
5. 設計即時與批次處理路徑
即時路徑消費 Kafka 等事件流，分鐘級更新分流品質和資料延遲告警；批次路徑負責去重、遲到修正、分層指標和最終報告。兩條路徑共用事件 schema、實驗版本和指標定義，即時結果標記為 provisional，只有批次水位達到要求才能成為發布依據。
6. 把結論接入稽核和發布閘門
實驗狀態包括 draft、running、paused、invalid、concluded 和 archived。任何修改隨機種子、指標定義或停止規則都產生新版本並凍結舊結果。結論服務輸出資料水位、統計方法、樣本量、SRM 狀態、護欄狀態和稽核連結；發布系統只接受狀態為 concluded 且所有品質檢查通過的版本。
高品質示範回答
「我會先固定隨機化單位和實驗版本，再拆分分流、觸發、曝光與結果事件。隨機化服務用穩定雜湊和互斥/正交平面管理衝突，事件管線用 schema 版本和幂等鍵處理重複、遲到和重放。品質服務在 assigned 與 triggered 層級檢查桶分布和 SRM，並提供根因切片。統計服務不能讓固定樣本量檢驗被任意 peeking 破壞，因此採用 sequential 或 anytime-valid 方法，記錄停止邊界和查看時間。即時結果只做告警，批次水位達標後才產生報告。結論帶設定、程式碼、資料版本和稽核記錄，SRM、埋點缺失或護欄失敗會阻止發布。」
常見錯誤
- 只存最後指標 → 無法定位分流或曝光缺失 → 保存 assignment、trigger、exposure、outcome 鏈路。
- 用請求隨機化替代使用者隨機化 → 同一使用者看到多個變體 → 固定單位鍵和實驗種子。
- 每天看 p 值並提早停止 → 固定樣本量假設被破壞 → 使用 sequential 或 anytime-valid 方法。
- 把 SRM 告警當成統計顯著 → 樣本比例異常代表實驗可能無效 → 先暫停結論並診斷分流與資格條件。
- 即時結果直接驅動發布 → 遲到資料和重複事件會改寫結論 → 設定批次水位和發布閘門。
追問及應對
為什麼要同時檢查 assigned 和 triggered？
分配可能完全均勻，但只有符合資格並真正進入頁面的使用者才觸發實驗。資格邏輯、客戶端版本、攔截器或埋點缺失會讓 triggered 比例失真；兩個層級一起看才能區分隨機化錯誤和曝光鏈路問題。
如何支援互斥與正交實驗？
互斥實驗共用同一流量平面和種子，使用者在該平面只進入一個實驗。正交實驗使用不同平面，允許獨立組合，但必須記錄碰撞矩陣和高風險組合的禁用規則。
anytime-valid 方法解決了什麼？
它允許持續監控並在資料依賴的時點停止，同時提供時間均勻的誤差控制。平台仍需宣告目標效應、功效、護欄和業務損失，不能把任意指標或任意停止理由包裝成統計保證。
發現 SRM 後是否自動重跑？
先凍結實驗結論並保留原始資料，按時間、客戶端、國家、資格條件和實驗平面切片定位根因。只有確認分流或埋點修復且產品同意重新定義分析視窗後才重跑；自動重跑不能掩蓋一次無效實驗。