Saat deployment baru menyebabkan error di produksi, tim biasanya berada di bawah tekanan untuk memulihkan layanan secepat mungkin. Dalam banyak kasus, rollback aman via feature flag adalah opsi tercepat karena perubahan perilaku aplikasi bisa dimatikan tanpa menunggu build, deploy ulang, atau restart seluruh stack.

Namun feature flag bukan tombol ajaib. Jika dipakai tanpa observability yang cukup, tanpa owner yang jelas, atau tanpa prosedur eksekusi yang aman, flag justru bisa memperburuk insiden. Artikel ini membahas cara menggunakan feature flag sebagai jalur rollback cepat pada backend atau web app, kapan memilihnya dibanding rollback versi aplikasi, dan bagaimana menjalankannya dengan disiplin operasional.

Apa yang dimaksud rollback via feature flag?

Rollback via feature flag berarti mematikan perilaku baru yang baru saja dirilis tanpa mengembalikan versi aplikasi ke build sebelumnya. Kode baru tetap ter-deploy, tetapi jalur eksekusinya dinonaktifkan berdasarkan konfigurasi runtime.

Pendekatan ini berguna jika perubahan berisiko sudah dibungkus oleh flag, misalnya:

  • Algoritme baru untuk pricing, ranking, atau rekomendasi
  • Endpoint API baru yang dipakai secara bertahap
  • Perubahan query atau pipeline background job
  • Perubahan UI yang memanggil backend baru
  • Integrasi ke layanan pihak ketiga yang dirilis bertahap

Kenapa ini bekerja? Karena akar masalah pada banyak insiden deploy bukan selalu artefak aplikasi secara keseluruhan, melainkan perubahan perilaku tertentu. Jika perilaku itu bisa dimatikan dengan cepat, blast radius dapat diperkecil sambil layanan utama tetap berjalan.

Gejala insiden setelah deploy yang perlu dikenali cepat

Setelah deployment, jangan hanya melihat status deploy sukses. Fokus pada gejala yang menunjukkan regresi operasional atau bisnis. Empat kelompok indikator yang paling relevan adalah error rate, latency, saturasi, dan business metric.

1. Error rate

  • Peningkatan HTTP 5xx atau gRPC error
  • Lonjakan exception di aplikasi
  • Retry ke database, cache, atau service downstream
  • Kegagalan job queue atau dead-letter queue yang meningkat

Error rate tinggi setelah flag diaktifkan sering menandakan cabang kode baru memanggil dependency yang belum siap, menangani null/timeout dengan buruk, atau menimbulkan load tambahan.

2. Latency

  • P95/P99 response time naik tajam
  • Waktu query database memanjang
  • Queue lag atau waktu proses job meningkat
  • Timeout ke service internal atau eksternal

Latency sering menjadi sinyal awal sebelum error benar-benar melonjak. Perubahan query, serialisasi payload, atau fan-out request ke banyak service dapat terlihat lebih dulu di sini.

3. Saturasi

  • CPU, memory, atau connection pool mendekati batas
  • Thread worker penuh atau event loop terhambat
  • Pool koneksi database habis
  • Cache miss meningkat dan membebani database

Saturasi penting karena beberapa deploy tidak gagal secara logika, tetapi menimbulkan konsumsi resource yang membuat layanan tidak stabil.

4. Business metric

  • Conversion rate turun
  • Pembayaran gagal meningkat
  • Checkout abandonment naik
  • Jumlah order, signup, atau request sukses menurun

Ini sering terlewat. Secara teknis semua endpoint bisa tampak sehat, tetapi perubahan baru bisa merusak hasil bisnis, misalnya diskon salah hitung, validasi terlalu ketat, atau alur checkout berubah.

Prinsip praktis: deploy dianggap bermasalah bukan hanya saat sistem error, tetapi juga saat metrik bisnis utama memburuk secara signifikan setelah perubahan diaktifkan.

Diagnosis singkat: pastikan masalahnya memang terkait deploy baru

Sebelum menekan tombol flag off, lakukan diagnosis singkat agar respons cepat tetap terarah.

  1. Pastikan korelasi waktu. Apakah lonjakan error/latency muncul segera setelah deploy atau setelah feature flag dinaikkan persentasenya?
  2. Bandingkan traffic yang terkena flag vs tidak. Jika hanya cohort tertentu yang terdampak, masalah kemungkinan ada pada fitur baru.
  3. Lihat log dan trace pada jalur baru. Cari exception, timeout, N+1 query, payload membesar, atau downstream call tambahan.
  4. Cek dependency. Jangan salah menyalahkan deploy jika sebenarnya database, cache, message broker, atau third-party sedang gangguan.
  5. Identifikasi blast radius. Apakah semua pengguna terdampak, hanya region tertentu, atau hanya endpoint tertentu?

Diagnosis ini tidak perlu panjang saat insiden aktif. Tujuannya adalah mengambil keputusan rollback yang benar dengan cepat, bukan menuntaskan root cause saat itu juga.

Kapan memakai feature flag, kapan rollback versi aplikasi?

Tidak semua insiden cocok ditangani dengan mematikan flag. Keputusan yang tepat bergantung pada lokasi perubahan dan seberapa aman kode lama untuk tetap berjalan.

Pilih rollback via feature flag jika:

  • Perubahan baru dibungkus rapi di belakang flag
  • Menonaktifkan flag mengembalikan jalur lama yang masih valid
  • Tidak ada perubahan skema database yang membuat jalur lama rusak
  • Masalah terlokalisasi pada fitur tertentu, bukan bootstrap aplikasi
  • Tim perlu memulihkan layanan dalam hitungan detik atau menit

Pilih rollback versi aplikasi jika:

  • Error terjadi saat startup, migration, atau inisialisasi sistem
  • Kode lama tidak lagi kompatibel dengan state/data terbaru
  • Perubahan tidak dibungkus dengan flag
  • Bug ada di jalur umum yang selalu dieksekusi, bukan fitur opsional
  • Feature flag service sendiri bermasalah atau tidak dapat dipercaya saat insiden

Pakai kombinasi keduanya jika perlu

Pada insiden nyata, langkah terbaik sering berupa urutan:

  1. Matikan feature flag untuk menghentikan kerusakan secepat mungkin
  2. Stabilkan metrik utama
  3. Putuskan apakah tetap perlu rollback versi aplikasi untuk mengurangi risiko residual

Pendekatan ini berguna jika kode baru masih memuat dependency berat, side effect tertentu, atau perubahan lain yang tetap aktif walau flag dimatikan.

Desain feature flag yang benar-benar bisa dipakai untuk rollback

Feature flag baru berguna sebagai jalur rollback jika dirancang sejak awal. Kesalahan umum adalah menambahkan flag hanya pada UI, sementara backend, job async, dan side effect lain tetap berjalan.

Prinsip desain penting

  • Flag harus membungkus perilaku, bukan hanya tampilan. Jika backend tetap menulis data baru walau UI dimatikan, rollback tidak benar-benar terjadi.
  • Sediakan jalur fallback yang diketahui sehat. Flag off harus mengarah ke implementasi lama yang memang masih dipelihara dan diuji.
  • Evaluasi flag sedekat mungkin dengan titik keputusan. Hindari menyalin hasil evaluasi ke banyak tempat tanpa kontrol konsistensi.
  • Pastikan default aman. Jika layanan flag gagal diakses, aplikasi sebaiknya kembali ke perilaku yang lebih aman.
  • Bedakan read path dan write path. Pada perubahan data, kadang Anda perlu mematikan write baru lebih dulu sebelum memulihkan read path.

Contoh pola implementasi backend

Contoh berikut menunjukkan endpoint checkout yang dapat beralih antara flow lama dan flow baru.

function handleCheckout(request, user) {
  const useNewCheckout = featureFlags.isEnabled('checkout_v2', {
    userId: user.id,
    region: user.region
  });

  if (!useNewCheckout) {
    return legacyCheckout(request, user);
  }

  return newCheckout(request, user);
}

Di atas, rollback bisa dilakukan dengan mematikan checkout_v2. Agar aman, legacyCheckout harus tetap berfungsi, dependency-nya masih tersedia, dan tidak bergantung pada state yang sudah diubah total oleh versi baru.

Contoh untuk side effect yang lebih berisiko

Pada fitur yang menulis ke sistem lain, lebih aman memisahkan flag untuk read dan write.

function updateCustomerProfile(profile) {
  savePrimary(profile);

  if (featureFlags.isEnabled('profile_sync_write')) {
    enqueueProfileSync(profile);
  }
}

Dengan pola ini, saat terjadi lonjakan error pada integrasi sinkronisasi, Anda bisa mematikan profile_sync_write tanpa menghentikan fungsi utama aplikasi.

Alur rilis yang aman: progressive rollout, bukan on/off sekaligus

Jika tujuan flag adalah rollback cepat, maka cara rilisnya juga harus mendukung deteksi dini. Progressive rollout membantu Anda membatasi dampak sebelum seluruh trafik terkena.

Urutan rilis yang umum

  1. Deploy kode dengan flag dalam kondisi off
  2. Verifikasi aplikasi sehat pada jalur lama
  3. Aktifkan untuk internal user atau cohort kecil
  4. Naikkan ke persentase rendah, misalnya sebagian kecil trafik
  5. Pantau error rate, latency, saturasi, dan business metric
  6. Naikkan bertahap hanya jika metrik tetap normal
  7. Siapkan prosedur flag off yang jelas jika indikator memburuk

Pola ini bekerja karena masalah sering baru terlihat pada skala tertentu. Misalnya query baru aman pada 1% trafik, tetapi pool koneksi mulai jenuh saat 20% atau 50% trafik memakai jalur baru.

Targeting yang membantu saat insiden

  • Per user atau account tertentu
  • Per region
  • Per tenant
  • Per endpoint atau use case
  • Per persentase trafik acak yang stabil

Targeting granular membantu rollback parsial. Jika hanya satu region terdampak, Anda tidak perlu mematikan fitur untuk semua pengguna.

Prosedur eksekusi rollback aman via feature flag

Saat insiden terjadi, tujuan utama adalah menghentikan dampak negatif secepat mungkin tanpa menimbulkan kerusakan tambahan. Berikut prosedur yang praktis.

Sebelum toggle: checklist cepat

  • Identifikasi nama flag yang tepat dan pastikan tidak tertukar dengan flag lain
  • Pastikan owner atau on-call memahami dampak saat flag dimatikan
  • Konfirmasi jalur fallback masih tersedia dan aman dipakai
  • Periksa apakah ada job, cache, atau proses async yang masih akan mengeksekusi perilaku baru
  • Pastikan observability dashboard untuk metrik utama sedang terbuka
  • Catat waktu dan alasan tindakan untuk audit dan postmortem

Langkah eksekusi

  1. Freeze rollout. Hentikan kenaikan persentase trafik atau perubahan konfigurasi lain.
  2. Matikan flag secara terkontrol. Jika perlu, turunkan bertahap pada skenario berisiko tinggi; jika dampaknya berat, matikan langsung.
  3. Amati propagation delay. Beberapa sistem flag tidak instan di semua instance karena cache atau polling interval.
  4. Pantau metrik pemulihan. Lihat error rate, latency, saturasi, queue lag, dan business metric dalam jendela waktu yang relevan.
  5. Pastikan tidak ada side effect tersisa. Misalnya job lama masih diproses, retry masih berjalan, atau data anomali terus dibuat.
  6. Komunikasikan status. Beri tahu tim incident channel bahwa rollback via flag telah dieksekusi beserta timestamp-nya.

Sesudah toggle: checklist verifikasi

  • Error rate kembali turun
  • Latency kembali mendekati baseline
  • Saturasi resource membaik
  • Business metric berhenti memburuk atau mulai pulih
  • Tidak ada lonjakan baru pada jalur fallback
  • Tidak ada alarm tambahan dari dependency lain

Jika metrik tidak membaik setelah propagation delay yang wajar, jangan berasumsi flag sudah gagal. Bisa jadi:

  • Masalahnya bukan pada fitur yang dimatikan
  • Ada lebih dari satu flag terkait
  • State berbahaya sudah terlanjur ditulis dan perlu mitigasi tambahan
  • Masalah berada pada deploy lain, migration, atau dependency eksternal

Pada titik ini, siapkan rollback versi aplikasi atau langkah mitigasi lain.

Observability minimum yang sebaiknya sudah ada sebelum mengandalkan feature flag

Feature flag untuk rollback hanya efektif jika Anda bisa melihat dampaknya dengan cepat. Minimal, siapkan dashboard dan alert yang bisa membedakan antara trafik yang terkena flag dan yang tidak.

Metrik yang perlu ada

  • Error rate per endpoint/flow
  • Latency P95/P99
  • Utilisasi resource: CPU, memory, connection pool, worker saturation
  • Queue health: backlog, retry, dead-letter
  • Business metric: order success, payment success, signup success, conversion

Dimensi yang berguna

  • Status flag atau cohort rollout
  • Versi aplikasi
  • Region atau availability zone
  • Tenant atau account tier
  • Endpoint atau job type

Tanpa dimensi ini, Anda mungkin melihat sistem memburuk tetapi tidak bisa membuktikan apakah penyebabnya rollout flag, deploy lain, atau perubahan trafik normal.

Kesalahan umum yang membuat rollback via flag gagal

1. Flag hanya mematikan UI, bukan backend

Pengguna mungkin tidak lagi melihat fitur, tetapi backend masih mengeksekusi write path, job, atau panggilan ke service baru.

2. Jalur fallback tidak diuji

Tim terlalu fokus pada jalur baru, sementara implementasi lama diam-diam rusak karena perubahan dependency, skema, atau kontrak API.

3. Flag terlalu banyak dan tidak jelas kepemilikannya

Saat insiden, engineer bingung flag mana yang mengontrol perilaku tertentu. Ini memperlambat respons dan meningkatkan risiko salah toggle.

4. Tidak ada audit log perubahan flag

Tanpa jejak siapa mengubah apa dan kapan, diagnosis menjadi kacau, terutama jika beberapa orang melakukan mitigasi bersamaan.

5. Flag dibiarkan permanen

Flag yang tidak pernah dibersihkan menambah kompleksitas, memperbanyak cabang kode, dan membuat perilaku sistem makin sulit dipahami.

6. Mengabaikan dampak data

Jika fitur baru menulis format data baru atau memicu side effect irreversible, mematikan flag saja belum tentu cukup untuk pulih.

Risiko pengelolaan feature flag yang buruk

Meski sangat berguna, feature flag membawa biaya teknis dan operasional.

  • Complexity debt: semakin banyak flag, semakin banyak kombinasi perilaku yang harus diuji
  • Configuration drift: antar environment atau region memiliki state flag berbeda tanpa dokumentasi jelas
  • Security/authorization risk: jika flag sensitif dapat diubah terlalu banyak orang, blast radius naik
  • Inconsistent behavior: cache flag atau propagation yang lambat membuat sebagian instance masih memakai state lama
  • Testing gap: tim hanya menguji flag on, padahal saat rollback justru jalur off yang kritikal

Karena itu, flag harus diperlakukan sebagai bagian dari sistem produksi, bukan sekadar sakelar sementara.

Praktik pencegahan setelah insiden: postmortem ringan yang berguna

Setelah layanan stabil, lakukan postmortem singkat yang berfokus pada perbaikan sistem, bukan menyalahkan individu. Tujuannya adalah memastikan rollback berikutnya lebih cepat dan lebih aman.

Pertanyaan yang layak dijawab

  • Kapan gejala pertama muncul, dan berapa lama sampai terdeteksi?
  • Apakah dashboard dan alert cukup cepat menunjukkan masalah?
  • Apakah flag yang benar mudah ditemukan dan dipahami?
  • Apakah propagation flag cukup cepat untuk kebutuhan insiden?
  • Apakah jalur fallback benar-benar aman dan teruji?
  • Apakah perlu rollback versi aplikasi juga?
  • Apakah ada kerusakan data atau side effect yang perlu dibersihkan?

Tindakan pencegahan yang sebaiknya diambil

  • Progressive rollout sebagai default, bukan full release langsung
  • Owner flag yang jelas: siapa yang membuat, siapa yang bertanggung jawab, dan tim mana yang on-call
  • Expiry date untuk setiap flag agar ada tenggat pembersihan
  • Audit log untuk setiap perubahan state dan targeting
  • Alerting yang dikaitkan dengan metrik teknis dan bisnis setelah rollout
  • Runbook insiden yang menyebut nama flag, dampak, dan langkah rollback
  • Pengujian jalur off secara berkala, bukan hanya saat insiden

Contoh runbook singkat untuk tim on-call

Insiden: lonjakan 5xx dan timeout setelah rollout checkout_v2

1. Verifikasi korelasi waktu deploy/rollout dengan lonjakan error.
2. Buka dashboard: error rate, P95 latency, DB connections, payment success rate.
3. Cek cohort yang terkena flag checkout_v2.
4. Jika dampak terkonfirmasi pada jalur baru, freeze rollout.
5. Set checkout_v2 = off untuk semua cohort terdampak.
6. Tunggu propagation dan pantau pemulihan selama beberapa menit.
7. Jika metrik tidak membaik, siapkan rollback versi aplikasi.
8. Catat timestamp, pelaksana, dan hasil observasi.
9. Setelah stabil, buat postmortem dan tiket cleanup flag/bugfix.

Penutup

Rollback aman via feature flag saat deploy gagal di produksi adalah teknik yang sangat efektif jika disiapkan dengan benar: fitur dibungkus rapi, fallback sehat, observability memadai, dan prosedur eksekusi jelas. Dalam banyak insiden, mematikan flag lebih cepat dan lebih aman daripada langsung rollback seluruh aplikasi.

Tetapi efektivitasnya bergantung pada disiplin engineering. Gunakan progressive rollout, tentukan owner flag, pasang expiry, simpan audit log, dan hubungkan rollout ke alert teknis serta business metric. Dengan begitu, feature flag bukan hanya alat rilis, tetapi juga mekanisme pengendalian risiko yang nyata saat produksi bermasalah.