Honeycomb：Production Excellence 與 Test in Production
Honeycomb 團隊是 test in production 理念的主要推動者之一。Production excellence 的核心責任是把 production 觀測能力提升到可以安全驗證變更的水準。當觀測能力足夠細緻，團隊可以在真實流量下驗證行為，降低對 staging 環境的依賴。
問題場景
Staging 跟 production 之間的差異是結構性的 — 資料量不同、流量模式不同、依賴行為不同、cache 狀態不同。團隊投入大量精力維護 staging parity，但差異仍然存在，staging 通過但 production 失敗的事故反覆出現。
Honeycomb 提出的替代思路是：與其追求 staging 完美複製 production，不如提升 production 的觀測能力，讓驗證可以安全地在 production 執行。這個思路的前提是三個能力同時到位：high-cardinality observability 能即時看見異常、feature flag 能控制變更的可見範圍、automated rollback 能在問題擴大前收回變更。
決策機制
| 機制 | 核心問題 | 交付結果 |
|---|---|---|
| Observability readiness | 觀測能否按 tenant / path / feature 切分 | high-cardinality trace / structured event |
| Feature flag safety | 變更可見範圍是否可控 | dark launch + kill switch |
| Progressive validation | 每一步放量是否有即時回饋 | canary → observe → expand 循環 |
| Rollback readiness | 異常出現時能否自動收回 | automated rollback on anomaly trigger |
Observability readiness 是整個流程的前提。high-cardinality tracing 讓團隊可以按 tenant、feature flag 狀態、request path 等維度切分觀測資料，在問題只影響少量使用者時就被發現。若觀測只有聚合指標（平均 latency、總 error rate），異常會被稀釋到看不見，等到聚合指標也惡化時影響已經擴大。
Feature flag safety 控制變更的 blast radius。dark launch 讓新邏輯在 production 執行但結果不對外可見，用來驗證效能與正確性。kill switch 讓團隊在異常出現時立即關閉新邏輯，不需要等 redeploy。
可觀測訊號
| 訊號 | 判讀重點 | 對應章節 |
|---|---|---|
| trace cardinality coverage | 觀測維度是否足以切分異常 | 4.3 |
| flag rollout anomaly | 新 flag 開啟後行為是否偏離 | 6.17 |
| production validation pass | 驗證結果是否支持繼續放量 | 6.8 |
| rollback trigger count | 自動回退是否被觸發 | 6.23 |
常見陷阱
把 test in production 當成「跳過 staging 測試」的簡稱會帶來嚴重風險。test in production 的安全性建立在三個前提上：觀測能力能即時看見異常、feature flag 能控制影響範圍、rollback 能在秒級生效。缺少任何一個前提就直接在 production 測試，只是把風險從 staging 搬到 production，而且 production 的失敗成本更高。
下一步路由
先回到 6.15 Environment Parity 評估 staging 差異的實際風險，再到 6.17 Feature Flag Governance 建立 flag safety 機制。production validation 的證據回寫 6.23 與 6.8 Release Gate。