引言
在大型企業中，功能管理（Feature Management）是影響產品迭代效率與系統穩定性的關鍵因素。eBay 面臨多重挑戰，包括代碼審查流程緩慢、多個配置平臺導致的使用者體驗混亂，以及開發者缺乏統一平臺思維。為解決這些問題，eBay 選擇採用 Open Feature 作為核心解決方案，並透過規模化實踐，成功實現從 0 到數十億次功能評估的轉變。
背景與挑戰
eBay 為全球最大的在線零售平臺之一，擁有 132 億 buyers、21 億 listings 及 15,000 員工，其中 4,000+ 工程師參與系統開發。核心問題包括：
- 代碼審查流程緩慢，導致功能無法快速部署
- 多個配置平臺（移動端、後端、實驗框架）導致使用者體驗混亂
- 無平臺思維，開發者傾向自建解決方案
解決方案與策略
技術選型
eBay 選擇 Open Feature 作為統一平臺，結合內部系統，並參與 Open Feature 規範制定，自建 Java SDK 以確保與 Open Feature 的兼容性。
平臺設計
- Touchstone：實驗生命週期平臺，包含五步驟流程，從實驗設計到逐步發佈。
- 單一 API：整合特徵標誌與實驗，降低開發者學習門檻。
- 精準目標設定：支持基於瀏覽器、地區、購物車內容等細粒度標註，提升實驗針對性。
實施步驟
平臺建設
- 自建 Java SDK 並參與 Open Feature 規範制定。
- 統一 25+ 結構化 API，簡化開發者使用。
- 建立錯誤監測與目標設定工具，確保平臺穩定性。
開發者教育
- 首步：教育開發者理解特徵標誌用途與使用場景。
- 選擇 3 名開發者作為導師，推動平臺採用。
- 建立技術程式管理員，簡化上手流程。
尺度化推廣
- 三階段測試：
- 第一階段：確保功能可用性（擴展支援平臺、加入 XT 標籤）。
- 第二階段：提升工程師使用價值（增加目標設定能力、錯誤監測）。
- 第三階段：優化規模化效能（將變更傳播時間從 15 分鐘縮短至 1 分鐘，評估延遲從 25ms 縮短至 3ms）。
- 遷移策略：
- 為各團隊分配 10% 的 Velocity 預算。
- 提供簡化遷移指引與自服務監控工具（Sherlock 資料看板）。
- 透過內部通報與升級郵件確保全公司參與。
現狀與未來方向
當前成果
- 覆蓋 2,500 個實驗，每日處理數十億次特徵評估。
- 運營效率提升：變更傳播時間 1 分鐘，評估延遲 3ms。
未來計劃
- 建立開發者工作流：從功能測試、內部測試到實驗與逐步發佈。
- 持續優化平臺，強化工程師與業務的協同效率。
技術關鍵指標
- 變更傳播時間：1 分鐘（原 15 分鐘）
- 評估延遲：3ms（原 25ms）
- 實驗數量：2,500 個（同時進行）
- 開發者數量：千人級（覆蓋 25+ 結構化 API）
- 遷移策略：
- 預算與資源：請求10%預算支持遷移，確保技術團隊有足夠資源。
- 簡化流程：提供明確、易遵循的遷移指引，降低工程師學習門檻。
- 承諾機制：透過Velocity論壇要求工程領導者簽署承諾書，確保遷移動機。
- 監控工具：部署Sherlock監控平臺，實時追蹤遷移進度與異常，提升問題排查效率。
開發者體驗與未來方向
開發者體驗
- 千名開發者使用平臺，實現快速迭代與實驗，提升內部開發效率。
未來方向
- 開發者工作流程：設計從實驗測試到逐步發版的全週期流程，強化Trunk-Based Development與Beta測試。
- 教育與培訓：投入4000+工程師的教育資源，建立課程、工作坊，推動現代化功能管理實踐。
- 開發者體驗優化：定期進行開發者滿意度調查，持續改進工具與流程，強化社區互動與支持。
Open Feature合作
功能擴展
- 討論批量評估多個功能旗標、旗標層級結構（如節日活動統一管理）等技術方案。
內部推廣
- 培育更多功能旗標專門人才，舉辦社區活動，促進開放生態合作。
協作機會
創新與實驗
內部創新機制
- 透過創新專案組、黑客松與發明週，加速想法驗證與實驗。
開放未來
- 整合功能旗標與AI技術，強化實驗流程，支持快速驗證與迭代。