Apa Itu Feature Flag? Jawaban SRE, Lengkap dengan Kode

Pukul 03:12 dan tingkat error checkout baru saja melewati 4 persen. Perubahan penyebabnya dikirim enam jam lalu. Tidak ada yang ingin me-revert seluruh rilis, karena rilis itu juga membawa dua perbaikan lain yang tidak berhubungan. Jadi, apa itu feature flag dalam situasi seperti ini? Feature flag adalah kondisi di dalam kode yang nilainya dibaca saat runtime dan menentukan apakah sebuah jalur kode dijalankan. Matikan flag itu, dan jalur baru berhenti dieksekusi, tanpa build dan tanpa deploy. Itu inti idenya. Sisanya adalah urusan operasi.

Apa sebenarnya feature flag (dan apa yang bukan)

Feature flag adalah titik keputusan. Di suatu tempat dalam kode ada if, dan nilai yang dibacanya berasal dari luar binary: layanan konfigurasi, baris di database, SDK vendor, atau environment variable yang bisa diubah tanpa restart.

const useNewPricing = await flags.isEnabled("new-pricing-engine", {
  userId: user.id,
  plan: user.plan,
  region: request.region,
});

return useNewPricing
  ? newPricingEngine.quote(cart)
  : legacyPricing.quote(cart);

Ada tiga konsekuensi dari potongan kode itu. Jalur lama masih harus ada dan masih harus berfungsi. Flag membutuhkan konteks (siapa yang meminta) jika Anda ingin sesuatu yang lebih pintar daripada sekadar nyala atau mati. Dan evaluasinya berada di jalur panas setiap request, jadi latensi dan mode kegagalannya sekarang menjadi tanggung jawab Anda.

Orang memakai "feature toggle" dan "feature flag" secara bergantian. Istilahnya tidak penting. Perilakunya yang penting: Anda memisahkan deploy kode dari rilis fitur. Kode masuk ke production dalam keadaan tersembunyi, dan seseorang atau sebuah sistem memutuskan nanti siapa yang akan melihatnya.

Empat jenis flag, dan mengapa mencampurnya merugikan

Sebagian besar masalah flag berasal dari memperlakukan semua flag sebagai satu hal yang sama. Taksonomi feature toggle dari Martin Fowler membaginya berdasarkan seberapa lama flag itu hidup dan seberapa dinamis keputusannya. Pembagian ini masih bertahan dalam praktik.

Release toggle bersifat sementara. Flag ini menyembunyikan pekerjaan yang belum selesai di balik flag agar Anda bisa menggabungkan kode ke trunk setiap hari. Menurut panduan Fowler, flag jenis ini jarang boleh bertahan lebih dari satu atau dua minggu. Keputusannya statis: setiap request untuk rilis tertentu mendapat jawaban yang sama.

Experiment toggle mengarahkan pengguna yang berbeda ke varian yang berbeda. Flag ini hidup cukup lama untuk mencapai signifikansi statistik, dari hitungan jam sampai beberapa minggu, dan tidak lebih lama dari itu. Keputusannya dibuat per request.

Ops toggle mengendalikan perilaku operasional: menonaktifkan fitur yang tidak kritis saat beban tinggi, berpindah ke dependensi fallback, atau mematikan query yang mahal. Sebagian kecil dari flag ini menjadi kill switch berumur panjang. Flag jenis ini harus bisa dibalik dalam hitungan detik, dan itu berarti tidak boleh bergantung pada sebuah rilis.

Permission toggle membatasi fitur berdasarkan paket langganan atau hak akses. Flag ini bisa hidup bertahun-tahun, dan keputusannya dibuat per pengguna pada setiap request.

Kesalahannya adalah memberi keempat jenis ini siklus hidup yang sama. Permission toggle membutuhkan pemilik dan jejak audit selamanya. Release toggle membutuhkan tanggal penghapusan sejak hari ia dibuat. Jika Anda tidak bisa mengetahui jenis sebuah flag hanya dari namanya, Anda juga tidak akan bisa mengetahui flag mana yang aman untuk dihapus.

Mengapa SRE peduli: flag sebagai kontrol blast radius

Bagi tim platform, properti yang paling menarik bukanlah A/B testing. Yang menarik adalah bahwa flag mengubah rilis dari sebuah peristiwa menjadi sebuah dial.

Tanpa flag, sebuah deploy memaparkan 100 persen trafik ke perubahan sekaligus. Satu-satunya revert adalah deploy lain, dan revert itu memakan waktu sepanjang pipeline Anda ditambah waktu yang dibutuhkan manusia untuk yakin. Dengan flag, Anda bisa memaparkan 1 persen pengguna, mengamati error rate dan p99, lalu naik ke 5, 25, 50. Blast radius adalah persentase yang Anda pilih, dan revert adalah perubahan konfigurasi yang menyebar dalam hitungan detik.

Hal ini mengubah mean time to recover Anda lebih dari kebanyakan investasi tooling. Pertanyaan post-mortem berhenti menjadi "mengapa rollback butuh 40 menit" dan berubah menjadi "mengapa perubahan ini tidak dipasang di balik flag".

Dial rollout punya satu kelemahan. Seseorang harus mengawasi sinyalnya dan memutar dial itu. Pada pukul 03:12, orang itu sudah lelah. Versi sistem flag yang berguna mengikat dial ke service level objective: jika error rate menghabiskan porsi budget tertentu, rollout berhenti dan revert terjadi tanpa manusia dalam lingkaran. Kebanyakan tim membangunnya sendiri dengan webhook dari alerting tool ke API flag. Butuh beberapa ratus baris kode, dan biayanya kembali pada malam pertama ia terpicu.

Tagihan yang datang: flag debt dan pelajaran Knight Capital

Secara teori, setiap flag yang Anda tambahkan melipatgandakan jumlah jalur melalui kode tersebut. Dalam praktik, Anda menguji beberapa kombinasi saja dan berharap sisanya aman. Fowler menyarankan untuk memperlakukan flag sebagai inventaris dengan biaya penyimpanan: tambahkan tugas penghapusan ke backlog saat flag dibuat, beri tanggal kedaluwarsa, dan di tim yang paling ketat, buat build gagal jika flag yang sudah kedaluwarsa masih ada di kode.

Versi paling mahal dari pelajaran ini adalah Knight Capital. Pada 1 Agustus 2012, deployment baru menggunakan ulang sebuah flag lama yang pernah mengendalikan fitur yang sudah pensiun. Satu server melewatkan deployment dan masih menjalankan kode lama. Dalam 45 menit pertama setelah pasar dibuka, router perusahaan mengirim lebih dari 4 juta order ke pasar, padahal hanya dibutuhkan untuk mengisi 212 order pelanggan, sebagaimana tercatat dalam perintah SEC terhadap Knight Capital. Artikel Fowler menyebut kerugian sekitar $460 juta sebagai peringatan tentang flag yang tidak dikelola.

Flag itu bukan satu-satunya kegagalan di sana. Deployment manual, tidak adanya kill switch, dan deteksi yang lambat ikut berkontribusi. Namun penggunaan ulang nama flag yang sudah mati adalah detail yang sebaiknya disimpan setiap tim platform di dinding mereka. Jangan pernah menggunakan ulang sebuah flag. Hapus yang lama, buat yang baru, dan jadikan penghapusan sebagai langkah kelas satu.

Bangun sendiri atau beli platform flag?

Sistem flag buatan sendiri biasanya dimulai dari file konfigurasi dan sebuah boolean. Itu cukup untuk beberapa release toggle pertama pada satu service. Itu berhenti cukup ketika Anda membutuhkan rollout persentase yang tetap konsisten per pengguna, aturan targeting berdasarkan segmen, log audit tentang siapa mengubah apa, dan perubahan flag yang sampai ke setiap instance dalam hitungan detik tanpa membanjiri penyimpanan konfigurasi.

Pada titik itu, Anda membandingkan platform dengan kriteria yang bisa diukur: latensi evaluasi SDK (evaluasi lokal dibandingkan panggilan jaringan), streaming dibandingkan polling untuk pembaruan, granularitas aturan targeting, dukungan multi-environment, dan bagaimana meteran harga tumbuh seiring trafik Anda.

Meteran harga berbeda lebih banyak daripada daftar fitur.

LaunchDarkly adalah implementasi acuan untuk kategori ini: targeting yang matang, guarded releases, dan permukaan integrasi yang dalam. Paket berbasis penggunaannya ditagih per service connection dan per seribu monthly active user di sisi klien, sehingga aplikasi konsumen dengan audiens anonim yang besar bisa melihat tagihan bergerak dengan cara yang tidak akan dialami tim yang hanya mengurus backend. Argumen positifnya nyata: jika Anda membutuhkan tata kelola dan audit dalam skala enterprise, LaunchDarkly sudah paling lama dimatangkan.

Statsig menggabungkan flag dengan eksperimentasi dan product analytics, dan menagih berdasarkan event. Itu cocok untuk tim yang memperlakukan flag terutama sebagai permukaan eksperimen. Jika kasus Anda sebagian besar adalah ops toggle dan kill switch, Anda membayar analytics yang mungkin tidak pernah Anda baca. Perlu dicatat juga bahwa vendor ini sudah berganti pemilik dua kali sejak September 2025, dan itu layak dicantumkan dalam tinjauan risiko vendor Anda.

Apa pun pilihannya, uji mode kegagalannya sebelum menandatangani kontrak. Blokir akses jaringan SDK di staging lalu periksa apa yang dilakukan aplikasi. SDK yang baik melayani nilai flag terakhir yang diketahui dari cache dan mencatat peringatan dengan lantang. SDK yang buruk justru memblokir jalur request.

Observabilitas adalah separuh dari sistem flag

Flag tanpa telemetri hanyalah tebakan. Setup minimum yang berguna melampirkan status flag ke setiap trace dan baris log untuk request tersebut, sehingga ketika lonjakan error muncul, Anda bisa mengelompokkannya berdasarkan varian flag dan melihat apakah jalur baru adalah penyebabnya.

Datadog dan platform all-in-one serupa membuat rincian per varian menjadi mudah begitu SDK Anda memberi tag pada span. Catatannya, penagihan per host dan per sinyal bertambah cepat ketika Anda menambahkan tag berkardinalitas tinggi seperti kunci flag ditambah varian ditambah segmen pengguna. Pilih dengan sengaja dimensi mana yang Anda beri tag.

Grafana adalah jalur yang lebih murah jika Anda sudah menjalankan Prometheus dan OpenTelemetry. Anda akan membangun sendiri dashboard yang sadar akan flag. Itu memakan waktu engineering, tetapi memberi kontrol penuh atas label yang Anda pancarkan. Untuk tim dengan 50 sampai 500 insinyur dan sebuah grup platform, trade-off itu sering kali tepat.

Runbook singkat untuk flag pertama Anda di production

Jika Anda memperkenalkan flag ke tim yang belum punya, buat rollout pertama tetap membosankan.

1. Pilih satu perubahan dengan metrik sukses yang jelas, misalnya error rate checkout atau latensi p99 satu endpoint.

2. Beri nama flag dengan jenis dan pemiliknya, misalnya release.checkout.new-tax-calc.owner-payments.

3. Tulis tiket penghapusan sekarang dan lampirkan tanggal kedaluwarsa paling lama dua minggu ke depan.

4. Rollout ke 1 persen, tahan selama satu siklus trafik penuh, lalu naikkan bertahap. Tentukan sebelumnya ambang batas untuk revert.

5. Jadikan revert sebagai satu perintah atau satu tombol, dan latih sekali di staging sebelum Anda membutuhkannya pada malam hari.

6. Setelah 100 persen bertahan beberapa hari, hapus flag dan jalur kode lama dalam perubahan yang sama.

Bagian yang tidak menarik adalah langkah 6. Tim yang melewatinya akhirnya memiliki ratusan flag, tidak ada yang tahu apa fungsi separuh dari flag itu, dan risiko seperti Knight Capital bersembunyi di dalam repository.

Seperti apa insiden terakhir Anda jika ada di balik flag?

Ambil insiden production terakhir yang ditulis tim Anda, lalu ajukan tiga pertanyaan. Apakah perubahan itu bisa dikirim dalam keadaan tersembunyi? Apakah satu orang bisa mematikannya dalam waktu kurang dari satu menit tanpa deploy? Apakah sebuah alert akan memberi tahu varian mana yang gagal?

Jika jawabannya tidak, tidak, dan tidak, Anda sudah punya kandidat flag pertama dan estimasi jujur pertama tentang berapa biaya revert hari ini. Post-mortem akan mengatakan apa yang harus dikatakannya. Pertanyaan yang lebih baik adalah seberapa banyak dampaknya bisa Anda kecilkan sebelum pager berbunyi.