# Apa Itu Feature Flag? Panduan SRE untuk Deployment Aman

URL: https://upstreamapi.com/id/journal/apa-itu-feature-flag
Type: blog
Locale: id
Published: 2026-08-29
Updated: 2026-08-31

---

> Feature flag memisahkan deployment dari rilis -- fondasi arsitektur rollout progresif yang aman. Panduan SRE tentang empat tipe flag, SLO gate, kill switch, dan flag debt di skala enterprise.

## Apa Itu Feature Flag? Deployment dan Rilis Adalah Dua Peristiwa Berbeda

Apa itu feature flag? Ini adalah conditional check di dalam kode aplikasi yang mengontrol code path mana yang dieksekusi untuk pengguna, sesi, atau environment tertentu -- tanpa harus merilis build baru. Sebuah flag bernama `new_checkout_flow` yang bernilai `false` untuk 99% pengguna artinya kode itu sudah di-deploy dua minggu lalu. Anda belum menyalakannya saja. Kontrak yang ditegakkan feature flag sangat presisi: deployment dan rilis menjadi dua peristiwa terpisah. Untuk tim yang menjalankan continuous deployment di skala besar, kontrak ini adalah tulang punggung arsitektur delivery.

## Deployment Bukan Rilis: Perbedaan yang Dipelajari Setelah Insiden

Sebagian besar tim baru memahami perbedaan ini setelah rollout yang buruk. Sebuah fitur dikirim Selasa siang, sesuatu dalam request trace mulai berperilaku aneh Rabu pagi, dan saat investigasi dibuka selisihnya mencakup empat commit dan dua service boundary. Menetapkan kausalitas dalam skenario seperti itu memang sulit.

Feature flag memaksa presisi. Ketika kode di belakang flag di-merge dan di-deploy, ia diam di produksi. Anda memastikan deployment berhasil, mengamati metrik baseline selama beberapa jam atau hari, memverifikasi tidak ada degradasi. Lalu Anda mengaktifkan flag untuk 1% traffic. Kini Anda memiliki satu variabel yang dapat diatribusikan. Jika error rate naik di flagged path, Anda bukan sedang men-debug code diff. Anda sedang toggle config value.

Pemisahan ini bukan argumen tentang kecepatan. Ini argumen tentang blast radius. Rilis yang memengaruhi 1% sesi dan berjalan salah bisa dipulihkan dalam hitungan menit. Rilis yang memengaruhi 100% sesi dan berjalan salah adalah major incident.

Mekanismenya sendiri sederhana. Dalam TypeScript, evaluasi flag kurang lebih terlihat seperti ini:

`const showNewCheckoutFlow = flagClient.variation(
  'new_checkout_flow',
  { userKey: session.userId, custom: { plan: user.plan } },
  false // default jika flag service tidak bisa dijangkau
);

if (showNewCheckoutFlow) {
  return renderNewFlow(cart);
}
return renderLegacyFlow(cart);`Nilai default `false` bukan formalitas. Itu adalah perilaku yang diterima pengguna Anda jika layanan evaluasi flag mengalami network partition. Definisikan dengan sengaja, bukan secara kebetulan.

## Empat Tipe Flag yang Benar-Benar Penting di Produksi

Tidak semua feature flag melayani tujuan operasional yang sama. Memperlakukan semuanya identik di codebase dan tooling manajemen adalah jalan yang pasti menuju kebingungan saat insiden dan akumulasi flag debt.

**Release flags** mengatur fitur baru selama development dan rollout. Sifatnya sementara: dibuat saat pekerjaan dimulai di feature branch, dihapus begitu fitur mencapai 100% pengguna dan tim telah mengonfirmasi stabilitas. Release flag tanpa tanggal penghapusan dan tanpa pemilik yang ditunjuk akan menjadi furnitur permanen di codebase Anda.

**Experiment flags** menggerakkan A/B test dan eksperimen multivariat. Mereka terikat pada analytic cohort identifier dan lifecyclenya dibatasi oleh eksperimen. Ketika eksperimen selesai, flag ikut pergi. Kesalahan umum: mempertahankan varian pemenang di belakang flag tanpa batas waktu dengan alasan penghapusan "tidak mendesak." Dua tahun kemudian, experiment flag itu menjadi bagian dari critical path dan tidak ada yang ingat varian mana yang aktif.

**Ops flags** adalah kill switch dan circuit breaker. Berbeda dengan release flag, mereka dirancang sebagai infrastruktur permanen. Flag `disable_ml_recommendations` yang memungkinkan Anda melewati lapisan ML inference lambat saat SLO-nya terdegradasi adalah sesuatu yang ingin Anda miliki pukul 3 pagi tanpa perlu membaca dokumentasi. Flag ini harus dievaluasi secara lokal, memiliki fallback yang terdokumentasi dengan baik, dan diuji secara rutin dalam operasi normal -- bukan ditemukan saat tekanan tinggi.

**Permission flags** mengontrol akses berdasarkan user tier, account plan, atau beta cohort. Mereka berumur panjang berdasarkan desain. Risiko kebingungan: permission flag sering terlihat seperti release flag bagi pembaca yang tidak mengetahui sejarahnya. Konvensi penamaan yang jelas lebih penting di sini daripada di mana pun.

![Visualisasi rollout perangkat lunak progresif menampilkan routing traffic berbasis persentase dengan lingkaran node konsentris](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp)

## Rollout Persentase Tanpa SLO Gate Hanyalah Deployment yang Lambat

Di sinilah sebagian besar implementasi feature flag berhenti terlalu awal. Tim platform menyiapkan jadwal rollout: 1% Senin, 5% Selasa, 25% Rabu, 100% Jumat. Mereka mendokumentasikannya, membagikannya ke stakeholder, dan menyebutnya progressive delivery.

Tapi "progresif" tanpa kondisi validasi di setiap langkah adalah risiko yang ditunda, bukan risiko yang dikurangi. Dial persentase mengontrol eksposur. Ia tidak memvalidasi keamanan.

Yang membuat staged rollout bermakna secara operasional adalah SLO gate di antara setiap tahap. Sebelum maju dari 5% ke 25%, sesuatu harus menjawab: apakah error rate di flagged code path masih dalam SLO budget? Apakah latensi p99 terjaga dalam band yang sama dengan control group? Apakah error budget terbakar lebih cepat dari baseline?

Jika tidak ada pertanyaan itu yang diinstrumentasikan, jadwal rollout adalah timeline, bukan validation loop.

Setup yang terbukti di produksi: definisikan dua jendela evaluasi SLO. Jendela pendek (15 menit) menangkap kegagalan cepat -- database query yang buruk, schema mismatch, regresi di critical path. Jendela panjang (24 jam atau satu siklus traffic penuh) menangkap degradasi bertahap -- memory leak, tekanan cache, edge case dalam segmen traffic frekuensi rendah. Keduanya harus hijau sebelum ada kemajuan. Jika salah satu jendela dilanggar, hentikan rollout dan hubungi on-call.

Persentase adalah dial. Jendela SLO adalah gate. Keduanya diperlukan.

## Kill Switch: Rancang Sebelum Anda Membutuhkannya

Kill switch bukan fallback. Ini adalah keputusan desain kelas satu yang harus ada sebelum baris pertama kode fitur ditulis.

Kill switch yang dirancang saat tekanan tinggi adalah kill switch dengan asumsi yang belum diuji. Anda mengujinya untuk pertama kali selama insiden aktif, dalam sesi terminal yang dibuka dari notifikasi PagerDuty, dengan lima orang menonton Slack thread. Itulah momen terburuk untuk menyadari bahwa ops flag Anda menargetkan pengguna berdasarkan session ID dan layanan sesi Anda saat ini sedang terdegradasi.

![Dashboard monitoring SLO dengan grafik burn rate error budget dan indikator kill switch untuk kontrol rollout fitur](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp)

Tiga properti yang tidak bisa dinegosiasi untuk kill switch yang dimaksudkan untuk digunakan di produksi:

- 
**Evaluasi lokal di bawah 50ms**: pengecekan flag tidak boleh menjadi network call ke layanan evaluasi remote. Jika evaluasi bergantung pada layanan yang bisa terdegradasi, Anda memiliki circular dependency di jalur respons insiden.

- 
**Nilai fallback eksplisit**: apa yang dikembalikan flag ketika flag service tidak dapat dijangkau? Ini harus didokumentasikan, didefinisikan dalam kode, dan diuji. "Apapun default SDK" bukan jawaban.

- 
**Diuji di bawah kegagalan dependency**: kill switch harus menjadi bagian dari rotasi chaos engineering Anda. Validasi mereka terhadap skenario di mana auth terdegradasi, di mana flag service sendiri mati, dan di mana network latency ke evaluation endpoint melebihi 2 detik.

Tim yang mengeksekusi respons insiden dengan bersih adalah yang telah berlatih. Kill switch adalah bagian dari runbook. Buat membosankan.

## Flag Debt: Technical Debt yang Tidak Ada di Roadmap

Tim yang mengadopsi feature flag secara agresif sering mengakumulasi apa yang kadang disebut flag debt: flag yang telah menyelesaikan tujuannya tetapi tidak pernah dihapus. Fiturnya sudah dikirim, eksperimen sudah selesai, beta sudah berakhir. Flagnya bertahan.

Pada 50 flag, ini adalah gangguan kecil. Pada 500 flag di seluruh distributed system, ini adalah risiko operasional yang aktif. Setiap flag adalah code branch yang memerlukan pemeliharaan, pengujian, dan pemahaman selama investigasi insiden. Seorang developer yang mencoba memahami kegagalan pukul 2 pagi tidak ingin menelusuri 40 conditional branch untuk menemukan yang relevan.

Satu pola yang diamati di berbagai platform team: flag evaluation middleware muncul di lima frame stack teratas untuk latensi p99. Penyebab dalam kebanyakan kasus adalah stale flag dengan aturan targeting yang kompleks yang mengevaluasi lusinan kondisi per request, membawa beban keputusan yang dibuat dua tahun lalu yang tidak ada yang merasa nyaman untuk menghapus.

Solusinya bersifat organisasional daripada teknis. Setiap flag yang dibuat harus memiliki tiga atribut: pemilik, tipe (release, experiment, ops, permission), dan tanggal penghapusan yang diharapkan. Release flag harus dihapus dalam dua sprint setelah rollout penuh. Experiment flag harus dihapus ketika eksperimen selesai, bukan "ketika ada yang sempat." Inventaris flag harus dapat diaudit sesuai permintaan dan ditampilkan di engineering health dashboard.

## Granularitas Targeting: Dimensi yang Rusak di Skala Enterprise

Sebagian besar platform feature flag mendukung rollout berbasis persentase dan targeting atribut pengguna dasar. Kesenjangan yang muncul di skala enterprise adalah granularitas targeting: kemampuan untuk mengekspresikan aturan rollout yang cukup spesifik untuk berguna tanpa menjadi cukup kompleks untuk tidak dapat dikelola.

Hierarki targeting yang berguna untuk rollout produksi di level platform team:

- 
**Environment-level**: produksi, staging, preview. Gate pertama, bukan satu-satunya.

- 
**Infrastructure segment**: data center, availability zone, atau Kubernetes cluster. Berguna untuk mengisolasi blast radius geografis.

- 
**Account atau tenant**: untuk platform B2B SaaS, melakukan rollout per-account sering lebih aman daripada per-user-percentage, karena Anda dapat mengamati pola traffic satu akun penuh daripada sampel statistik.

- 
**User cohort**: beta user, internal user, power user berdasarkan activity tier.

- 
**Session attribute**: berguna untuk experiment flag, berbahaya untuk ops flag.

Platform yang mengimplementasikan ini dengan baik (LaunchDarkly dan Statsig paling sering dikutip oleh SRE team yang melakukan ini di skala besar) memungkinkan komposisi aturan yang kompleks tanpa memerlukan waktu engineering untuk memodifikasi logika targeting selama rollout aktif. Kemampuan self-service itulah yang membedakan antara jeda rollout 30 detik dan tiket ke platform team.

Platform yang mengimplementasikannya dengan buruk memaksa Anda memilih antara granularitas targeting dan kesederhanaan operasional. Trade-off itu akan muncul pukul 3 pagi.

## Apa yang Terus Ditemukan Post-Mortem

Setiap post-mortem untuk insiden produksi terkait fitur mengajukan pertanyaan yang sama. Apakah fitur di-gate di belakang flag? Apakah rolloutnya progresif? Apakah ada kondisi validasi di antara tahap? Apakah kill switch diuji sebelum insiden?

Jika keempat jawaban adalah ya, insiden adalah masalah kalibrasi: threshold yang terlalu longgar, aturan targeting dengan edge case, perilaku evaluasi SDK di bawah network partition yang tidak diperhitungkan. Ini dapat diselesaikan dengan perubahan konfigurasi dan pembaruan runbook.

Jika ada jawaban yang tidak, insiden adalah masalah arsitektur. Feature flag bukan kenyamanan debugging. Mereka adalah keputusan arsitektur deployment. Keputusan itu ada sebelum fitur dikirim, atau tidak ada sama sekali.

Pertanyaan yang layak dijawab sebelum rilis berikutnya: apa yang akan dikatakan post-mortem tentang rollout ini jika ada yang salah malam ini?

## FAQ

### Apa perbedaan antara deployment dan rilis dengan feature flag?

Deployment adalah tindakan menempatkan kode ke produksi. Rilis adalah tindakan mengaktifkannya untuk pengguna. Feature flag memisahkan keduanya: kode di-deploy dalam keadaan tidak aktif, lalu diaktifkan secara bertahap setelah deployment dikonfirmasi berhasil.

### Berapa banyak tipe feature flag yang ada dan apa bedanya?

Ada empat tipe utama: release flag (sementara, untuk rollout fitur baru), experiment flag (untuk A/B test dengan lifecycle dibatasi eksperimen), ops flag (kill switch permanen sebagai infrastruktur), dan permission flag (kontrol akses berdasarkan tier atau plan). Masing-masing memiliki lifecycle dan aturan pengelolaan yang berbeda.

### Mengapa rollout persentase saja tidak cukup untuk deployment yang aman?

Rollout persentase mengontrol eksposur, bukan keamanan. Tanpa SLO gate di setiap tahap -- yang memeriksa error rate, latensi p99, dan error budget burn -- rollout progresif hanyalah deployment yang diperlambat. Kondisi validasi di antara tahap adalah yang membuat rollout benar-benar progresif dan bermakna operasional.

### Apa saja properti yang harus dimiliki kill switch yang baik di produksi?

Tiga properti yang tidak bisa dinegosiasi: evaluasi lokal di bawah 50ms (tidak bergantung pada layanan eksternal yang bisa ikut terdegradasi), nilai fallback eksplisit yang terdokumentasi dan diuji dalam kode, dan validasi rutin dalam rotasi chaos engineering termasuk skenario kegagalan auth dan flag service itu sendiri.

### Apa itu flag debt dan kapan menjadi risiko operasional?

Flag debt adalah akumulasi flag yang telah menyelesaikan tujuannya tetapi tidak pernah dihapus. Pada 50 flag ini adalah gangguan kecil. Pada 500+ flag di distributed system, ini menjadi risiko operasional aktif: flag dengan targeting rules kompleks bisa muncul sebagai kontributor teratas latensi p99 karena mengevaluasi lusinan kondisi per request.

### Platform feature flag mana yang direkomendasikan untuk skala enterprise?

LaunchDarkly dan Statsig paling sering dikutip oleh SRE team yang melakukan rollout di skala enterprise. LaunchDarkly unggul dalam governance enterprise dan complex targeting, Statsig mengintegrasikan flag dengan product analytics. Keduanya memungkinkan komposisi aturan targeting yang kompleks tanpa perubahan kode selama rollout aktif.

### Bagaimana cara mengelola flag debt secara efektif di tim besar?

Setiap flag yang dibuat harus memiliki tiga atribut wajib: pemilik yang ditunjuk, tipe flag yang jelas (release/experiment/ops/permission), dan tanggal penghapusan yang diharapkan. Release flag dihapus dalam dua sprint setelah rollout penuh. Inventaris flag harus dapat diaudit sesuai permintaan dan divisualisasikan di engineering health dashboard.