設問とコンテキスト
あなたは、SDK、コレクター、ダッシュボード、アラートで使用される言語横断的な可観測性（オブザーバビリティ）コントラクトを保守しています。チームは下流の利用者が依存できるように規則を開発段階から安定版へと移行したいと考えていますが、プラットフォームチームは未解決の意味定義、二重書き込み、および高カーディナリティによるコストを懸念しています。3か月分の実際のテレメトリデータと2つのパイロットサービスが利用可能であると仮定します。
面接官が見ているポイント
面接官は、あなたが「安定（stable）」をドキュメントの網羅性ではなく、互換性の保証（コミットメント）として説明できるかを評価しています。優れた回答では、名前、型、単位、必須レベル（requirement levels）、enum、プライバシーの境界を検証し、導入状況、クエリの正確性、カーディナリティ、移行コストを測定した上で、非互換な変更に対する移行パスを確保します。
最初に確認すべき明確化のための質問
- すでにこれらのフィールドに依存している下流のアラート、請求レポート、またはコンプライアンスレポートはどれですか？依存関係が多いほど、より高い安定性基準が求められます。
- どのシグナルと言語が対象ですか？デフォルト値はすべてのSDK間で一致している必要があります。
- 高カーディナリティな値、機密データ、または曖昧なenumは存在しますか？安定化の前にこれらを解決してください。
- 互換性はどのくらいの期間維持する必要がありますか？既存のコレクターでは、バージョン選択やオプトイン方式の移行が必要になる場合があります。
- 成功の定義は、導入率ですか、再利用可能なクエリですか、それともカスタムフィールドの削減ですか？目標によってパイロットの評価指標が変わります。
30秒回答フレームワーク
「フィールドの数が十分にあるという理由だけで規則を昇格させることはしません。セマンティクス、型、単位、必須レベル、enum、プライバシー、およびSDK間の挙動を監査し、実際のダウンストリームクエリを検証します。パイロットサービスが安定版を使用し、互換性テストに合格し、カーディナリティとコストがガードレール内に収まり、移行および非推奨（deprecation）のパスが明確になって初めて昇格させます。そうでなければ、開発版またはalpha版にとどめ、次の決定ゲートを記録します。」
ステップごとの詳細な回答
- 保証内容を定義する。 OpenTelemetryの規則には、development、alpha、beta、release candidate、stableの各レベルが使用されます。stableは、下流の利用者が互換性の保証を信頼できることを意味します。
- セマンティクスを監査する。 名前、値の型、単位、必須レベル、enum、およびサンプルの整合性を確認します。有用そうに見えてもユースケースが不明確な属性は、再度議論に戻します。
- 実際の使用状況を検証する。 3か月分のデータをサンプリングし、ダッシュボード、アラート、ログの関連付け、および言語横断クエリをリプレイします。欠落した値や未知の値を記録します。
- コストとプライバシーを制御する。 新しい属性によるカーディナリティ、ストレージ、およびクエリコストを測定します。属性にユーザー識別子、生コンテンツ、またはシークレットを含めてはなりません。必要に応じてハッシュ化や制御されたカテゴリを使用します。
- バージョニングを設計する。 実験的な規則は開発用の名前空間に保持します。安定化の過程では、バージョン選択またはオプトインを提供し、二重書き込み中に新旧の結果を比較し、非推奨となる日付を公開します。
- ゲートとロールバックを設定する。 2つのパイロットサービスが互換性テストを満たし、2つのリリースサイクルにわたってクエリの正確性が99.9%以上、欠落率が1%未満、カーディナリティの増加が20%未満を維持した後にのみ昇格させます。違反があった場合はオプトインに戻します。
代替案としては、最初にbeta版をリリースする、コア属性セットのみを安定化する、シグナルごとに個別にバージョニングする、コレクターの変換で古いフィールドをマッピングする、などが挙げられます。安定化によって、サンプリング、認可、またはデータ品質に関する未解決の問題を隠蔽してはなりません。
模範回答
「私は安定版（stable）を互換性に関するプロダクトのコミットメントとして扱います。まず、規則に依存するアラート、レポート、コレクター、SDKを洗い出し、名前、型、単位、必須レベル、enum、プライバシーを監査します。3か月分の実際のテレメトリに対して重要なクエリをリプレイし、異なる言語の2つのサービス間で欠落値、未知の値、カーディナリティ、コストを比較します。安定版としてマークする前に、クエリの正確性99.9%、欠落率1%未満、2リリースサイクルにわたるカーディナリティ増加20%未満に加え、非推奨期日、二重書き込み計画、ロールバックパスを要求します。意味定義にまだ議論の余地がある場合は、developmentまたはbetaにとどめ、次回のレビューに必要な証拠を明示します。」
よくある間違い
- 間違い: 導入実績やフィールド数を安定性の証明として使用する → 失敗する理由: 安定性とは互換性の保証であるため → 対策: SDK横断テスト、クエリテスト、移行テストを追加する。
- 間違い: あらゆるビジネスフィールドを規則に含める → 失敗する理由: カーディナリティとプライバシーリスクが急速に増大するため → 対策: 明確なユースケースと制限されたコストを持つ属性のみを保持する。
- 間違い: 古いフィールドを即座に置き換える → 失敗する理由: 下流のクエリの意味が知らぬ間に変化する可能性があるため → 対策: バージョン選択、二重書き込み、比較、および非推奨期間を提供する。
- 間違い: 未知の値や欠落値を無視する → 失敗する理由: ダッシュボードが完全に見えても、得られる結論が信頼できなくなるため → 対策: データ品質を安定化の判定ゲートとする。
フォローアップの質問と回答
安定版の規則で名前が変更されたコアフィールドを維持できますか？
名前の変更によって下流のクエリのセマンティクスが変わる場合は、古いフィールドを維持し、バージョンを追加し、マッピングを公開して非推奨期間を設定します。互換性エイリアンは、意味的な同等性と移行コストが実証された場合にのみ検討してください。
SDKごとのデフォルト値の違いはどのように処理しますか？
同じ入力を使用して言語横断のコントラクトテストを構築し、フィールド名、型、単位、必須レベルを検証します。デフォルト値が一致しない間は、安定版のスコープを拡大しないでください。
カーディナリティは上昇するものの、ビジネスクエリの精度が向上する場合はどうしますか？
精度の向上を、ストレージ、クエリレイテンシ、およびコストの上限と合わせて総合的に評価します。価値の高いサービスから段階的にオプトインし、サンプリング、集約、または次元削減を追加します。
安定化を中止すべきタイミングはいつですか？
セマンティクスの対立が残っている場合、欠落率やカーディナリティがガードレールを超えた場合、プライバシーレビューに不合格となった場合、またはパイロットクエリが再現できない場合は、中止して開発版またはbeta版に戻します。不足している証拠の内容を記録してください。