プロンプトと適用範囲
中規模のエンジニアリングチーム向けの可観測性SaaSを担当しています。顧客はすでにOpenTelemetry設定ファイルを管理しており、宣言型YAMLをアップロードして収集、処理、エクスポートの設定を生成することを望んでいます。JSONスキーマ、YAML表現、およびパース/インスタンス化メカニズムは安定しています。インポート機能を提供するかどうかを判断し、最初のバージョンを設計してください。
面接官が見ているポイント
面接官は、「仕様が安定していること」と「プロダクトとして構築する価値があること」を切り分けられるか、またユーザー価値、設定の安全性、ベンダーロックイン、サポートコストを特定できるかをテストしています。優れた回答では、ターゲットユーザー、最小スコープ、拒否ルール、成功メトリクス、カナリア展開、そして明確な非目標（non-goals）を提示します。
最初に明確にすべき質問
- ターゲットユーザーはすでにCollectorを運用しているのか、それともYAMLを扱い始めたばかりなのか？
- インポートした設定はSaaS管理下のCollectorにデプロイされるのか、それとも顧客管理環境にエクスポートされるのか？
- ファイルに認証情報、ネットワークエンドポイント、プロセッサースクリプト、またはカスタムプラグインが含まれる可能性があるか？
- 最大の課題はオンボーディングなのか、移行の労力なのか、デバッグ時間なのか、それとも継続的な運用なのか？
30秒での回答
「仕様が安定しているからという理由だけでアップロード機能を構築するのではなく、まず顧客が既存の設定をマネージド環境に持ち込む必要があるかを検証します。初期バージョンでは制限されたスキーマのサブセットをサポートし、バージョン、権限、認証情報、リソースを検証した上で、エクスポートとロールバックが可能なレビュー可能なdiffを生成します。既存のCollectorユーザー向けにカナリアリリースを行い、インポート成功率、最初の有効なシグナル受信までの時間、24時間以内のロールバック、サポートチケット数、コストを測定します。価値が主に移行にある場合は、任意のYAMLを実行する前にバリデータとガイド付きフローを構築します。」
ステップごとの解決策
1. ユーザーの課題を定義する
マネージドCollectorへの移行を進めているプラットフォームチームにヒアリングを行い、「設定を作成できない」のか「既存の設定を移行できない」のかを切り分けます。設定サイズ、コンポーネントの種類、プライベートプラグイン、認証情報の取り扱い、リカバリデータを収集します。インポート機能の初期価値は、移行グループが有意義な時間を節約できる場合にのみ存在します。
2. 最小スコープを選択する
公式スキーマでカバーされているreceivers、processors、exporters、およびservice設定から開始し、バージョンとコンポーネントの明示的な許可リスト（allowlist）を設けます。未知のプラグイン、任意のスクリプト、埋め込まれた長期認証情報、サポートされていない拡張機能は拒否します。すべてを自動で成功させると約束するのではなく、複雑なファイルに対してはテンプレートや人手によるレビューを提供します。
3. セキュリティ境界を設定する
アップロードされたファイルは、パース中に外部ネットワークへの送信を行わない隔離された環境でパースします。認証情報はシークレットマネージャーへの参照によって紐付け、UI上ではマスキング（redact）し、アップロード者、承認者、有効化時刻を監査ログに記録します。インポートがデータ持ち出しや不正実行の経路にならないよう、設定生成前に権限、エンドポイント、リソース制限、データの保存場所（データレジデンシー）をチェックします。
4. プレビューを説明可能にする
YAMLを内部モデルに正規化し、コンポーネントの変更、サンプリング、マスキング、ルーティング、exportersを表示します。サポートされていないすべてのフィールドについて理由を説明し、生成された結果をダウンロードできるようにします。プレビューとデプロイでは同じパーサーバージョンを使用する必要があります。そうでない場合、プレビューは成功するのにデプロイが失敗するという事態が生じます。
5. 成功メトリクスを設定する
コアメトリクスは、インポート後に最初の有効なテレメトリシグナルを受信するまでの時間、初回成功率、および24時間以内のロールバック率です。ガードレールには、パース失敗、データ損失、サポートチケット数、エクスポートコスト、ポリシーによる拒否が含まれます。全体のインポート平均値に頼るのではなく、顧客の規模別にセグメント化します。
6. カナリアリリースとロールバック
すでに公式のCollector設定を使用している顧客を招待します。本番環境のバージョンを上書きせずにインポートを有効にし、承認後に新しいバージョンを作成します。デプロイ失敗時は前のバージョンを維持し、ワンクリックでのロールバックとエクスポートをサポートします。コンポーネントの種類追加やマネージド実行は、カナリアが安定した後にのみ追加します。
模範回答
安定した仕様をプロダクトの需要と同一視はしません。まず既存のCollectorユーザーが移行時に時間や定着率を失っているかを検証し、制限されたスキーマを中心にインポートのMVPを構築します。パースは隔離環境で行い、認証情報は埋め込まずに参照し、未知のプラグインやスクリプトは拒否します。正規化されたdiff、ポリシー拒否の理由、ダウンロード可能な出力を提示します。初期顧客は本番環境を上書きするのではなく新しいバージョンを作成します。最初のシグナル受信までの時間、初回成功率、24時間ロールバック率、チケット数、エクスポートコストを測定します。コンポーネントの拡充やマネージド実行は、十分な証拠が得られた後にのみ進めます。
よくある間違い
- 仕様が安定しているからとすべてをサポートする → サポートおよびセキュリティの範囲が爆発的に増大する → 許可リストから始める。
- 任意のプラグインやスクリプトを許可する → アップロードがコード実行の経路になる → パースを隔離し、未知の機能を拒否する。
- 本番環境を自動で上書きする → 1つの障害の影響範囲（blast radius）が大きくなる → バージョニング、diffのレビュー、ロールバック機能を提供する。
- インポート回数のみをカウントする → ユーザーの手元にデータが届いていない可能性がある → 最初の有効なシグナルとロールバック率を測定する。
- YAML内に認証情報を記述させる → 漏洩リスクが高まる → シークレット参照、マスキング、監査ログを使用する。
フォローアップ質問と回答
エンタープライズ企業からカスタムプラグインの要求があった場合はどうするか？
まず、そのプラグインがマネージドの境界内で安全に実行できるかを検証します。プライベートエージェントまたはエクスポートモードを提供しますが、1社の顧客のために共有実行パスへ任意のコード実行機能を追加することは避けます。
なぜ自動デプロイの前にエクスポート機能を構築するのか？
エクスポートは、より小さい障害半径でパース処理、diff、およびユーザー価値を検証できます。自動デプロイは権限、ネットワーク、リソース、ロールバックのリスクを伴うため、信頼性とガードレールが成熟した後に開放します。
スキーマのアップグレードはどのように処理すべきか？
スキーマバージョンを記録し、バージョンごとに検証を行い、移行ガイダンスを提供します。プレビューと互換性レポートとともに新しいバージョンをリリースし、サンプリングやエクスポートのセマンティクスを暗黙的に変更しないようにします。
どのような場合にこの機能の開発を中止すべきか？
ターゲットユーザーが引き続きGitOpsを好む場合、インポートがオンボーディング時間を短縮しない場合、またはセキュリティレビューとサポートコストが顧客維持の価値を上回る場合は、機能の拡張を中止します。代わりに検証機能、ドキュメント、またはエクスポートツールの強化に投資します。