Evaluation Context dan Hooks OpenFeature: Bagaimana Cara Menjaga Batasan Flagging Tetap Jelas?

Pertanyaan dan ruang lingkup

Pewawancara mungkin bertanya: “Jelaskan bagaimana evaluation context, providers, dan hooks pada OpenFeature bekerja bersama, termasuk batasan kegagalan, tipe data, dan privasi.”

Sinyal yang dinilai adalah apakah Anda memahami OpenFeature sebagai API evaluasi aplikasi yang netral vendor (vendor-neutral), bukan sebagai konsol flag lengkap atau sistem otorisasi. Spesifikasi ini memisahkan flag key, nilai default, evaluation context, provider, dan evaluation details. Hooks dapat memvalidasi, memperkaya konteks, memancarkan telemetri, atau menangani error, tetapi hooks tidak boleh secara diam-diam mengubah semantik otorisasi bisnis.

Apa yang sedang diuji oleh pewawancara

• Apakah Anda membedakan pemanggil aplikasi (caller), provider, evaluation context, dan metadata flag.
• Apakah evaluasi bertipe dan nilai default membentuk perilaku kegagalan yang dapat diprediksi.
• Apakah Anda menggunakan konteks transaksi dan hooks alih-alih state global mutable yang digunakan bersama.
• Apakah Anda menangani timeout provider, ketidakcocokan tipe, flag yang hilang, dan data privasi.
• Apakah log evaluasi dan audit tetap terpisah dari otorisasi bisnis.

Pertanyaan klarifikasi

• Apakah flag tersebut mengontrol pengiriman bertahap (gradual delivery), penetapan eksperimen, atau otorisasi keamanan?
• Kolom konteks mana yang wajib diisi, dan mana yang harus tetap berada dalam proses atau di luar log?
• Apakah provider berupa memori lokal, layanan jarak jauh, file, atau komposisi provider?
• Apakah nilai default aman saat provider gagal, dan apakah kebijakannya fail-open atau fail-closed?
• Seberapa banyak detail evaluasi, versi aturan, dan error provider yang harus dicatat?

Jawaban 30 detik

Anda dapat mengatakan:

API aplikasi OpenFeature meminta nilai flag bertipe, evaluation context menyediakan data penargetan dan cakupan permintaan (request-scoped), provider mengevaluasi aturannya, dan hooks berjalan di sekitar siklus hidup untuk validasi, pengayaan konteks, atau telemetri. Pemanggil menyediakan nilai default yang aman; kegagalan provider, ketidakcocokan tipe, atau flag yang hilang mengembalikan detail yang dapat didiagnosis tanpa mengubah hook menjadi sistem otorisasi. Konteks hanya membawa kolom yang diperlukan dengan kontrol privasi. Eksperimen dan metrik rilis dapat mencatat versi aturan, tetapi tidak boleh mencatat data pribadi ke log.

Penalaran langkah demi langkah

Pisahkan tanggung jawab evaluasi

Pemanggil meminta nilai bertipe, provider menyelesaikan aturan, dan SDK menggabungkan hasilnya dengan nilai default, reason, variant, dan kode error:

application -> OpenFeature client -> provider -> flag result
                         |               |
                       hooks        evaluation details

Provider memiliki sumber aturan dan implementasi evaluasi. Jangan berasumsi bahwa setiap provider memiliki perilaku caching, jaringan, atau konsistensi yang sama; pemanggil tetap menentukan nilai default dan tindakan bisnis setelah kegagalan.

Rancang evaluation context

Konteks dapat mencakup targeting key, atribut pengguna atau organisasi, dan kolom yang dipropagasi oleh transaksi. Kirimkan hanya data yang diperlukan oleh aturan; lakukan hash, pangkas, atau hilangkan email, IP, dan pengidentifikasi perangkat. Propagasikan konteks transaksi bersama permintaan daripada menggunakan objek mutable yang dibagikan di seluruh permintaan.

Gunakan evaluasi bertipe dan detail evaluasi

Gunakan API yang sesuai untuk boolean, string, angka, dan nilai terstruktur, dengan nilai default bertipe sama. Evaluation details dapat membawa provider, reason, variant, kode error, dan metadata untuk diagnosis dan analisis eksperimen. Detail bukanlah vonis otorisasi; pemanggil harus membedakan antara "flag mati" dan "pengguna tidak diizinkan".

Tempatkan hooks dan kebijakan kegagalan

Hooks dapat memvalidasi nilai, menambahkan telemetri, mencatat error, atau memperkaya konteks pada tahap before, after, error, dan finally. Hooks harus idempoten, berlatensi rendah, dan aman terhadap privasi. Timeout provider jarak jauh atau error tipe menggunakan nilai default yang aman dan metrik degradasi. Fungsionalitas berisiko tinggi dapat menggunakan kebijakan fail-closed, tetapi jelaskan dampak terhadap pengguna dan pemulihannya.

Model jawaban berkualitas tinggi

Saya memperlakukan OpenFeature sebagai kontrak evaluasi aplikasi. Pemanggil menggunakan API bertipe dan menyediakan nilai default aman yang cocok tipenya; evaluation context hanya membawa targeting key dan atribut yang diperlukan oleh aturan. Provider mengambil dan mengevaluasi aturan dari sistem flag konkret, mengembalikan nilai, reason, variant, kode error, dan metadata. Hooks dapat memvalidasi, memperkaya konteks, dan memancarkan telemetri di sekitar siklus hidup, tetapi hooks tidak menggantikan otorisasi atau menulis ulang hasil secara diam-diam. Timeout provider, flag yang hilang, atau ketidakcocokan tipe mengikuti nilai default yang ditentukan dan memancarkan metrik error. Log mencatat targeting key yang dianonimkan, flag key, variant, dan versi aturan daripada email atau konteks permintaan lengkap. Pilih fail-open atau fail-closed untuk eksperimen rilis sesuai dengan risiko, lalu uji masa kedaluwarsa cache, pemulihan provider, dan rollback.

Kesalahan umum

• Menyebut OpenFeature sebagai konsol flag lengkap, distributor konfigurasi, atau layanan otorisasi.
• Membiarkan hook mengubah nilai tanpa mencatat alasan (reason), membuat hasil tidak dapat dijelaskan.
• Menggunakan nilai default dengan tipe yang salah atau memperlakukan flag yang hilang sebagai keberhasilan.
• Mengirimkan objek pengguna lengkap, email, atau IP ke dalam evaluation context tanpa minimalisasi data.
• Mencoba ulang provider yang gagal tanpa henti atau mengabaikan kebijakan fail-open/fail-closed yang eksplisit.
• Memperlakukan evaluation details sebagai keputusan izin akhir.

Pertanyaan lanjutan dan tanggapan

1. Bisakah targetingKey berupa alamat email?

Hanya jika aturan benar-benar membutuhkannya dan tinjauan privasi mengizinkannya. Pengidentifikasi pengguna atau organisasi yang stabil dan tidak dapat diubah kembali (irreversible) biasanya lebih aman. Log dan provider jarak jauh tetap memerlukan minimalisasi data dan batas retensi.

2. Apa yang harus terjadi jika provider mengembalikan error?

Pilih nilai default yang aman berdasarkan risiko, kembalikan kode error yang dapat didiagnosis, dan pancarkan metrik degradasi. Flag rilis berisiko rendah dapat secara konservatif tetap aktif, sedangkan fungsionalitas berisiko tinggi dapat dinonaktifkan atau memerlukan pemulihan manual. Bagian yang penting adalah memiliki kebijakan yang eksplisit dan dapat diuji.

3. Bisakah hooks mengimplementasikan audit?

Hooks dapat menjadi titik masuk telemetri untuk event evaluasi, tetapi audit juga memerlukan integritas independen, kontrol akses, dan retensi. Kegagalan hook tidak boleh memblokir setiap evaluasi kecuali jika persyaratan secara eksplisit menjadikan keberhasilan audit sebagai batasan mutlak (hard gate).