プロンプトとスコープ
面接官は次のように質問する場合があります。「障害、型、プライバシーの境界を含め、OpenFeatureの評価コンテキスト、プロバイダー、フックがどのように連携するかを説明してください。」
ここでの評価ポイントは、OpenFeatureを完全なフラグ管理コンソールや認可システムとしてではなく、ベンダーニュートラルなアプリケーション評価APIとして理解しているかどうかです。仕様では、フラグキー、デフォルト値、評価コンテキスト、プロバイダー、評価詳細が明確に分離されています。フックは検証、コンテキストの拡張、テレメトリの出力、エラー処理を行えますが、ビジネスの認可セマンティクスを暗黙的に変更するべきではありません。
面接官がテストしていること
- アプリケーション呼び出し元、プロバイダー、評価コンテキスト、フラグメタデータを区別できているか。
- 型付き評価とデフォルト値によって予測可能な障害動作が形成されているか。
- 共有されたミュータブルなグローバル状態の代わりにトランザクションコンテキストやフックを使用しているか。
- プロバイダーのタイムアウト、型の不一致、フラグの欠落、プライバシーデータを適切に処理しているか。
- 評価ログと監査がビジネス認可から分離された状態を維持しているか。
明確化のための質問
- そのフラグは段階的リリース、実験の割り当て、セキュリティ認可のどれを制御していますか？
- どのコンテキストフィールドが必須で、どれをインプロセス内にとどめる、またはログから除外する必要がありますか？
- プロバイダーはローカルメモリ、リモートサービス、ファイル、またはプロバイダーのコンポジションですか？
- プロバイダー障害時のデフォルト値は安全ですか？また、ポリシーはフェイルオープンですか、フェイルクローズですか？
- 評価詳細、ルールバージョン、プロバイダーエラーはどの程度記録する必要がありますか？
30秒の回答
次のように答えることができます。
OpenFeatureのアプリケーションAPIは型付きフラグ値を要求し、評価コンテキストがターゲティングおよびリクエストスコープのデータを提供し、プロバイダーがそのルールを評価し、フックが検証、コンテキスト拡張、またはテレメトリのためにライフサイクルの前後で実行されます。呼び出し元は安全なデフォルト値を提供します。プロバイダーの障害、型の不一致、またはフラグの欠落が発生した場合は、フックを認可システムに変えることなく診断可能な詳細情報を返します。コンテキストにはプライバシー制御を施した上で必要なフィールドのみを含めます。実験やリリースメトリクスはルールバージョンを記録できますが、個人データをログ出力すべきではありません。
ステップごとの論理展開
評価の責務を分離する
呼び出し元が型付きの値を要求し、プロバイダーがルールを解決し、SDKが結果をデフォルト値、理由（reason）、バリアント、エラーコードと結合します。
application -> OpenFeature client -> provider -> flag result
| |
hooks evaluation detailsプロバイダーはルールソースと評価の実装を所有します。すべてのプロバイダーが同じキャッシュ、ネットワーク、または整合性の動作を持つと想定してはなりません。呼び出し元が依然として障害後のデフォルト値とビジネスアクションを定義します。
評価コンテキストを設計する
コンテキストには、targeting key、ユーザーや組織の属性、トランザクションによって伝播されるフィールドを含めることができます。ルールに必要なデータのみを送信し、メールアドレス、IPアドレス、デバイス識別子はハッシュ化、トリミング、または省略します。リクエスト間で共有されるミュータブルなオブジェクトを使用するのではなく、トランザクションコンテキストをリクエストとともに伝播させます。
型付き評価と評価詳細を使用する
ブール値、文字列、数値、構造化された値に対して適切なAPIを使用し、同じ型のデフォルト値を設定します。評価詳細には、診断や実験分析のためにプロバイダー、理由、バリアント、エラーコード、メタデータを保持できます。詳細は認可の判定結果ではありません。呼び出し元は「フラグがオフである」ことと「ユーザーが許可されていない」ことを区別する必要があります。
フックと障害ポリシーを配置する
フックは、before、after、error、finallyの各ステージで値の検証、テレメトリの追加、エラーの記録、コンテキストの拡張を行うことができます。フックは冪等であり、低レイテンシで、プライバシーに対して安全でなければなりません。リモートプロバイダーのタイムアウトや型エラーが発生した場合は、安全なデフォルト値とデグラデーションメトリクスを使用します。高リスクな機能はフェイルクローズにする場合がありますが、ユーザーへの影響と復旧手順を明確に説明します。
模範的な高クオリティの回答
私はOpenFeatureをアプリケーションの評価契約として扱います。呼び出し元は型付きAPIを使用し、型が一致する安全なデフォルト値を提供します。評価コンテキストには、ルールで必要なtargeting keyと属性のみを含めます。プロバイダーは具体的なフラグシステムからルールを取得して評価し、値、理由、バリアント、エラーコード、メタデータを返します。フックはライフサイクルの前後で検証、コンテキスト拡張、テレメトリの出力を行えますが、認可を置き換えたり、結果を暗黙的に書き換えたりはしません。プロバイダーのタイムアウト、フラグの欠落、または型の不一致が発生した場合は、定義されたデフォルト値に従い、エラーメトリクスを出力します。ログには、メールアドレスや完全なリクエストコンテキストではなく、匿名化されたtargeting key、フラグキー、バリアント、ルールバージョンを記録します。リスクに応じてリリースの実験をフェイルオープンにするかフェイルクローズにするかを選択し、キャッシュの有効期限切れ、プロバイダーの復旧、ロールバックを検証します。
よくある間違い
- OpenFeatureを完全なフラグ管理コンソール、構成配信ツール、または認可サービスと呼ぶこと。
- フックが理由を記録せずに値を変更できるようにし、結果の原因を不明瞭にすること。
- 間違った型のデフォルト値を使用したり、フラグの欠落を成功として扱ったりすること。
- 最小化を行わずに完全なユーザーオブジェクト、メールアドレス、IPアドレスを評価コンテキストに送信すること。
- 失敗したプロバイダーに対して無限にリトライを行ったり、明示的なフェイルオープン／フェイルクローズポリシーを省略したりすること。
- 評価詳細を最終的なパーミッション判定として扱うこと。
フォローアップの質問と回答
1. targetingKeyにメールアドレスを使用できますか？
ルールが真にそれを必要とし、プライバシーレビューで許可されている場合に限られます。通常は、安定的で不可逆なユーザーまたは組織の識別子を使用する方が安全です。ログやリモートプロバイダーでも、依然としてデータの最小化と保持期間の制限が必要です。
2. プロバイダーがエラーを返した場合はどうすべきですか？
リスクに応じて安全なデフォルト値を選択し、診断可能なエラーコードを返し、デグラデーションメトリクスを出力します。低リスクなリリースフラグは保守的に有効のままにしておくこともできますが、高リスクな機能はクローズするか手動復旧を必要とする場合があります。重要なのは、明示的でテスト可能なポリシーを持つことです。
3. フックで監査を実装できますか？
評価イベントのテレメトリエントリポイントとして機能させることは可能ですが、監査には独立した整合性、アクセス制御、保持管理も必要です。要件として監査の成功が必須ゲート（ハードゲート）と明記されていない限り、フックの失敗によってすべての評価をブロックすべきではありません。