プロンプトとコンテキスト
このプラットフォームシステムデザインの設問では、リポジトリ、デプロイシステム、人手による宣言から、コンポーネント、システム、ドメイン、API、所有者、および依存関係のエッジを保存します。これはディスカバリ、インシデント対応、ガバナンスに役立ちます。誰も信用しない、手動メンテナンスのCMDBに成り下がってはなりません。
面接官が評価するポイント
- 「サービスの所有者を見つける」という課題を、エンティティモデル、ソース信頼ポリシー、検索可能なエクスペリエンスへと落とし込めるか。
- 宣言的メタデータと自動スキャンの間における競合、有効期限切れ、削除を適切に処理できるか。
- 依存関係クエリ、権限の分離、テナント境界、鮮度SLOを説明できるか。
- メンテナンスコストと価値のバランスを取った段階的なプラットフォームのロールアウトを選択できるか。
確認すべき明確化のための質問
エンティティ数、1日の変更量、メタデータの遅延、クエリのピーク、組織または顧客の分離、依存関係が静的かランタイム観測か、誰が所有権を宣言できるかを確認します。リスクの高いインシデント対応での利用には、ソースレベル、古い（stale）マーカー、監査が必要です。開発者向けディレクトリであれば、より緩やかな鮮度から始めることができます。
30秒の回答フレームワーク
私は宣言的なエンティティグラフをモデル化します。コンポーネント、システム、ドメイン、API、チーム、関係性には安定した識別子を持たせます。リポジトリのカタログファイルが意図を提供し、デプロイおよびランタイムのシグナルがバージョンと観測されたエッジを追加し、コレクターがバージョン管理されたイベントを書き込みます。クエリサービスは、ソースと更新時刻を表示しながら、所有者、逆依存関係、検索機能を提供します。競合はサイレントな上書きではなく、対応可能なステータスとして扱われます。権限はエンティティとフィールドに適用され、古いエンティティは履歴として残しつつデフォルトの検索結果からは除外します。
ステップバイステップの詳細な回答
1. エンティティと関係性のモデル化
Backstageのエンティティモデルは有用なリファレンスです。コンポーネントはシステムに属し、システムはドメインに属し、APIはコンポーネントによって提供または消費され、チームがコンポーネントを所有します。すべてのエンティティに安定した名前、ネームスペース、バージョンキーを付与します。関係性のエッジには、ソース、検出時刻、信頼度を持たせます。インシデントのルーティングを自動化できるように、所有権は自由形式のテキストではなく、解決可能なチームプリンシパルを参照する必要があります。
2. キャパシティとSLOの設定
10,000のエンティティがあり、それぞれに20の関係性（約200,000のエッジ）があり、エンティティの変更が1日あたり5%（約500回のインポート）あると仮定します。イベントキューを経由して書き込み、所有者および隣接関係インデックスを備えたリードモデルを維持します。初期目標としては、数分以内のインポート可視化、検索のP95で300ミリ秒未満、3ホップの依存関係クエリを1秒以内とすることが考えられます。高リスクなビューではデータの経過時間も表示します。
3. 取り込みとソース優先順位の設計
リポジトリの宣言は意図と所有権を提供し、デプロイシステムは実際のバージョンと環境を提供し、ランタイムテレメトリは直近の呼び出しエッジを提供します。各インポートはソース、コミットバージョン、検証結果を保存し、冪等性キーを使用します。フィールドポリシーに従って競合をマージします。1つのランタイム観測によって宣言された所有権を書き換えることはできず、ランタイムエッジによって依存関係が存在しないことを証明することはできません。競合はキューに入れ、所有者に通知します。
4. 鮮度と削除のセマンティクスの定義
エンティティごとにlastSeenAt、宣言バージョン、有効期限ポリシーを保存します。ソースの更新が停止したエンティティにはstale（古い）マークを付けます。インシデントの再生用に履歴を保持しつつ、デフォルトの検索では非表示にするか順位を下げます。リポジトリの削除、サービスの廃止、エフェメラル環境には異なる状態が必要です。即座に削除すると履歴が失われ、まったく削除しないと検索結果が汚染されます。定期的なリコンサイラーが失敗したインポートを再試行し、孤立したエッジを削除します。
5. クエリ、権限、セキュリティパスの構築
名前、チーム、ドメイン、環境、タグ、所有者による検索をサポートします。グラフのトラバーサルがサービスに過負荷をかけないよう、依存関係の深さと結果数を制限します。エンティティとフィールドに組織スコープを付与し、機密性の高いリポジトリパス、内部エンドポイント、顧客テナントの詳細をフィールド単位でマスキング（redact）します。所有権の変更や拒否されたアクセスを監査します。ブラウザ上でデータを非表示にすることは認可ではありません。
6. 段階的なリリースと代替案の維持
ステージ1では、重要なサービスと所有者検索をカバーし、ソースと鮮度の要件を設定します。ステージ2では、依存関係グラフ、デプロイバージョン、インシデントルーティングを追加します。ステージ3では、自動化されたガバナンスを評価します。チームが宣言を維持しない場合は、全社的なカタログではなく、リポジトリテンプレートとCIチェックから開始します。AmazonのPMガイダンスでは、顧客の課題と能力の証拠が重視されます。検索の成功率、インシデント特定時間、メタデータの維持率によって導入の成果を証明する必要があります。
模範的な高品質の回答
私はカタログをスプレッドシートとしてではなく、ソースと鮮度を備えたエンティティグラフとして扱います。コンポーネント、システム、ドメイン、API、チーム、関係性は安定したキーを持ちます。リポジトリの宣言が意図を定義し、デプロイが環境バージョンを追加し、ランタイムシグナルが最近の依存関係を追加します。コレクターはイベント駆動で冪等性を持ち、コミットバージョンを保持します。リードモデルは所有者、逆依存関係、境界付きのグラフクエリを提供します。競合はキューに入れられ、古いエンティティは履歴として残るもののデフォルトの検索からは消え、権限は組織とフィールドごとに適用されます。対象を拡大する前に、重要なサービスにおいて検索成功率、インシデント特定時間、維持率を証明します。
よくある間違い
- 手動メンテナンスのCMDBを構築してしまう → すぐに陳腐化する → リポジトリの宣言と自動収集を事実情報として使用する。
- 所有者を文字列として保存してしまう → 通知やオフボーディングを検証できない → 解決可能なチームプリンシパルを参照する。
- 最新のソースですべてを上書きしてしまう → ランタイムのノイズがガバナンスの事実を書き換えてしまう → ソースに優先順位を付け、競合を保持する。
- 廃止されたサービスを削除してしまう → インシデントの再生で依存関係が失われる → ライフサイクル状態と履歴バージョンを使用する。
- 無制限の依存関係トラバーサルを行う → 1つのクエリがグラフ全体に拡大してしまう → 深さと結果を制限し、隣接関係インデックスを使用する。
フォローアップの質問と回答
宣言された所有権とデプロイデータが競合した場合はどうしますか？
それらを個別のソースを持つ属性として表現し、フィールドポリシーに従ってマージし、競合を表示します。管理された宣言が所有者フィールドを所有し、デプロイシステムが環境フィールドを所有します。双方に通知し、修正コミットを通じて解決します。
短期間のプレビュー環境はどのように処理しますか？
エンティティに環境と有効期限を付与します。プレビューのエントリにはデフォルトで低い重みを設定し、自動的にアーカイブされるようにします。本番環境がそれらに依存している場合、ランタイムエッジがアラートを発行できますが、所有権とテナント認可は引き続き適用されます。
インシデント中にカタログが利用できない場合はどうなりますか？
重要なサービスのエクスポート可能なスナップショットと直近の所有者キャッシュを保持し、そのデータの経過時間を表示します。インシデント対応ツールはスナップショットを読み取ることができますが、期限切れのスナップショットを最新の真実として提示してはなりません。
チームがカタログをリリース承認の関門（ゲート）として扱わないようにするにはどうしますか？
ディスカバリとインシデント対応から開始し、検索時間と特定時間を測定します。メタデータと権限が安定した後にのみガバナンスチェックを連携させます。チェックが失敗した場合は、すべてのリリースをブロックするのではなく、修正手順を提供する必要があります。