題幹與適用場景
你維護跨語言的可觀測性規範，多個 SDK、收集器、查詢面板與告警依賴同一組屬性。團隊希望把慣例從 development 升級為 stable，讓下游放心依賴；平台團隊擔心欄位含義尚未收斂，升級會產生雙寫與高基數成本。假設已有三個月真實遙測樣本與兩個試點服務。
面試官考察點
面試官考察你能否把「穩定」解釋為相容性承諾，而非文件完成度。強回答會檢查命名、型別、單位、必要等級、列舉與隱私邊界，量化採用率、查詢正確性、基數與遷移成本，並為不相容變更保留過渡路徑。
回答前需要澄清的問題
- 哪些下游已把欄位寫入告警、計費或合規報表？依賴越多，穩定承諾越謹慎。
- 慣例涵蓋哪些訊號與語言？跨 SDK 的預設行為必須一致。
- 目前屬性是否出現高基數、敏感資料或歧義列舉？這些問題應在升級前解決。
- 需要相容多久？若存在舊收集器，必須設計雙版本或 opt-in 過渡。
- 成功標準是採用率、查詢可重用性，還是減少自訂欄位？不同目標會改變試點指標。
30 秒回答框架
「我不會因欄位數量達到某個值就升級。先稽核語意、型別、單位、必要等級、列舉、隱私與跨 SDK 一致性，再用真實查詢驗證下游。只有試點服務採用穩定版本後，相容性測試通過、基數與成本在護欄內、遷移與棄用路徑明確，才進入 stable；否則保持 development 或 alpha，並記錄下一次決策條件。」
分步驟深入解答
- 定義承諾。 OpenTelemetry 慣例有 development、alpha、beta、release candidate、stable 等穩定級別；stable 意味下游可依賴其相容性保證。
- 稽核語意。 檢查名稱、值型別、單位、必要等級、列舉與範例是否一致；把「看似有用但沒有明確用例」的屬性退回討論。
- 驗證真實使用。 從三個月資料抽樣，檢查儀表板、告警、日誌關聯與跨語言查詢是否得到相同結果，記錄缺失率與未知值。
- 控制成本與隱私。 測量新增屬性帶來的基數、儲存與查詢成本，禁止把使用者識別、原始內容或秘密寫入屬性；必要時使用雜湊或受控分類。
- 設計版本路徑。 對既有實驗慣例保留 development 命名空間；穩定化時提供版本選擇或 opt-in，雙寫期間比較新舊結果，再定義棄用日期。
- 設定門檻與回滾。 兩個試點服務連續兩個發布週期滿足相容測試、查詢正確率 99.9%、屬性缺失率低於 1%、基數增幅低於 20%，才提交穩定化；任一護欄越界就回到 opt-in。
替代方案包括先發布 beta、只穩定一組核心屬性、為不同訊號分開版本，或透過轉換處理器在收集端映射舊欄位。穩定化不應用來掩蓋尚未解決的取樣、權限或資料品質問題。
高品質示範回答
「我把 stable 視為相容性產品承諾。先盤點依賴該慣例的告警、報表、收集器與 SDK，稽核名稱、型別、單位、必要等級、列舉與隱私邊界。接著從三個月真實遙測中重放關鍵查詢，在兩個語言不同的服務上比較缺失率、未知值、基數與成本。只有連續兩個發布週期查詢正確率達 99.9%、缺失率低於 1%、基數增幅低於 20%，且已有穩定版本的棄用日期、雙寫與回滾方案，我才升級為 stable；若欄位含義仍有爭議，就保持 development 或 beta，寫清下一次評審的證據門檻。」
常見錯誤
- 錯誤表現： 用採用率或欄位數量直接證明穩定 → 失敗原因： 穩定級別是相容性承諾 → 修正方法： 增加跨 SDK、查詢與遷移測試。
- 錯誤表現： 把所有業務欄位都納入規範 → 失敗原因： 高基數與隱私風險會擴大 → 修正方法： 只保留有明確用例且成本可控的屬性。
- 錯誤表現： 立即替換舊欄位 → 失敗原因： 下游查詢會靜默失真 → 修正方法： 版本選擇、雙寫、對比與棄用日期齊備後再切換。
- 錯誤表現： 忽略未知與缺失值 → 失敗原因： 面板看似完整但結論不可靠 → 修正方法： 把資料品質指標列為穩定化門檻。
追問及應對
一個核心欄位需要改名，stable 還能保留嗎？
若改名改變下游查詢語意，應保留舊欄位並新增版本，提供映射與棄用週期；只有證明語意等價且遷移成本可控時，才考慮相容別名。
如何處理不同語言 SDK 的預設差異？
建立跨語言契約測試，用同一組輸入驗證欄位名、型別、單位與必要等級；預設行為未一致前不要擴大 stable 範圍。
基數增加但業務查詢更準確，是否接受？
把準確性收益與儲存、查詢延遲及成本上限一起評估；可先對高價值服務 opt-in，並設定取樣、聚合或降維方案。
什麼時候應停止穩定化？
當語意爭議未解決、缺失率或基數超過護欄、隱私審查失敗，或試點查詢無法重現時，應停止並回到 development/beta，記錄證據缺口。