使用 SQL 進行功能推出分析
漸進式部署需要進行比較，以保留分配、發布、產品結果、數量和觀察時間。如果沒有這些欄位，流量組合的變化可能看起來像是功能迴歸或改進。
檢測分配邊界
記錄受控功能標誌名稱、部署或控制佇列、應用程式發布、終端狀態、持續時間、環境以及重複資料刪除需要時批准的帳戶或請求識別符號。保持比較視窗的分配穩定。如果帳戶切換群組，請保留轉換時間，而不是用最新值標記其所有歷史事件。
請勿收集標記有效負載、定位規則、客戶屬性、請求正文或原始錯誤訊息。使用受控錯誤類別和有界佇列標籤。
首先比較可靠性
功能推出 SQL 配方 按標誌、佇列和版本對請求進行分組。它將請求計數、失敗計數、錯誤率和平均延遲儲存在一起。確定性夾具顯示，推出佇列有一次失敗且平均延遲較慢，而其對照佇列沒有失敗。
按順序檢視結果：
- 確認兩個佇列觀察到相同的釋放和完整的時間視窗。
- 在控制和部署方面需要足夠的請求。
- 比較錯誤率和延遲，然後檢查受控錯誤類別。
- 僅當分配和數量支援時才按計劃、路線或區域進行細分。
- 使用書面護欄暫停、繼續或擴充套件。
對於業務成果，只有在可靠性可接受後，才將相同的穩定任務加入到啟用或收入里程碑。 產品旅程指南 展示瞭如何保持計數單元顯式。
使推出決策可重複
儲存 SQL、回顧視窗、最小樣本規則、發布和部署百分比以及決策。儀表板應標記分配更改和部署，以便回應者可以區分功能效果和同時的程式碼更改。
使用 API 可靠性配方 進行錯誤預算、版本比較、客戶影響和依賴性延遲。護欄應該需要持續的證據；一次小批次故障應該引發審查，而不是自動得出不可逆轉的結論。