Kill Switch: Matikan Fitur Bermasalah Tanpa Rollback

Anda baru saja membuka fitur baru untuk sepuluh persen pengguna. Lima menit kemudian, laporan error mulai berdatangan. Fitur tersebut merusak pemuatan halaman bagi sebagian pengguna, bahkan merusak data bagi yang lain. Setiap detik fitur itu menyala, semakin banyak pengguna yang terdampak. Insting Anda mungkin ingin melakukan rollback seluruh deployment, tapi itu butuh waktu: pipeline harus berjalan, image harus di-push, server harus restart. Sementara itu, pengguna masih terkena dampak kode yang rusak.

Di sinilah kill switch menjadi rem darurat Anda.

Apa yang Sebenarnya Dilakukan Kill Switch

Kill switch adalah mekanisme yang memungkinkan Anda mematikan fitur yang bermasalah tanpa harus mengembalikan seluruh aplikasi ke versi sebelumnya. Jika Anda menggunakan feature flag, kill switch hanyalah mengubah nilai flag dari true menjadi false. Saat flag itu berubah, aplikasi Anda langsung menjalankan jalur kode lama. Pengguna yang sebelumnya melihat fitur baru akan kembali ke antarmuka atau alur lama. Tanpa redeployment. Tanpa rollback. Tanpa menunggu pipeline selesai.

Perbedaan antara kill switch dan rollback sangat mendasar. Rollback mengembalikan seluruh aplikasi ke versi sebelumnya. Artinya, semua perubahan yang Anda rilis di versi terbaru akan dibatalkan, termasuk perbaikan bug untuk masalah lain dan peningkatan kecil yang berfungsi dengan baik. Rollback juga memakan waktu: pipeline harus berjalan, image container perlu dibangun ulang dan di-push, server perlu restart. Sebaliknya, kill switch hanya menonaktifkan satu fitur. Semua yang lain di aplikasi tetap berjalan pada versi terbaru.

Garis waktu di bawah menunjukkan seberapa cepat kill switch menghentikan dampak pada pengguna dibandingkan dengan rollback penuh.

Berikut adalah contoh minimal bagaimana flag kill switch membungkus sebuah fitur dalam JavaScript:

const featureFlags = {
  isEnabled(flagName) {
    // Di production, ini membaca dari remote config service
    return config[flagName] === true;
  }
};

function handleCheckout(userCart) {
  if (featureFlags.isEnabled('new-checkout')) {
    // Alur checkout baru dengan potensi bug
    return newCheckoutFlow(userCart);
  } else {
    // Alur checkout lama yang stabil
    return oldCheckoutFlow(userCart);
  }
}

Ketika flag berubah menjadi false, aplikasi langsung kembali ke jalur kode lama tanpa perlu redeployment.

flowchart TD subgraph Kill_Switch_Path A1[Fitur bermasalah] --> B1[Balik flag] --> C1[Kode lama berjalan langsung] --> D1[Pengguna tidak terdampak] end subgraph Rollback_Path A2[Fitur bermasalah] --> B2[Pipeline rebuild] --> C2[Redeploy] --> D2[Server restart] --> E2[Pengguna terdampak selama menit] end A1 -->|Waktu dihemat| D1 A2 -->|Waktu hilang| E2

Kapan Kill Switch Paling Efektif

Kill switch paling berguna untuk fitur yang baru dirilis dan belum terbukti stabil. Bayangkan alur checkout baru yang ternyata memiliki bug perhitungan biaya pengiriman. Dengan kill switch, Anda bisa menonaktifkan fitur checkout baru itu segera. Pengguna kembali ke halaman checkout lama. Tim Anda kemudian bisa memperbaiki bug tanpa terburu-buru, karena pengguna sudah tidak lagi terkena dampak masalah tersebut.

Pola ini cocok untuk:

  • Komponen UI baru yang mungkin rusak di bawah lalu lintas pengguna nyata
  • Fitur eksperimental yang mengubah logika bisnis inti
  • Integrasi pihak ketiga yang berperilaku berbeda di production dibandingkan di staging
  • Perubahan berisiko tinggi yang ingin Anda validasi dengan audiens kecil terlebih dahulu

Kuncinya adalah kill switch mengisolasi jalur kode yang bermasalah secara bersih. Saat flag mati, aplikasi harus berperilaku persis seperti sebelum fitur baru diperkenalkan.

Keterbatasan Kill Switch

Kill switch bukan solusi universal. Jika masalahnya bukan pada fitur baru itu sendiri, melainkan pada perubahan infrastruktur atau migrasi database, membalik flag tidak akan membantu. Misalnya, jika query database baru membebani production database Anda, menonaktifkan feature flag mungkin tidak cukup karena query sudah dieksekusi. Kerusakan sudah terjadi. Dalam kasus seperti ini, Anda memerlukan rollback atau perbaikan langsung ke infrastruktur.

Kill switch juga memerlukan desain kode yang cermat. Flag yang berfungsi sebagai kill switch harus memisahkan kode baru dari kode lama secara bersih. Jika fitur baru telah memodifikasi data di database, mematikan flag tidak secara otomatis mengembalikan data tersebut ke keadaan sebelumnya. Tim Anda perlu memikirkan efek samping ini sebelum memutuskan untuk mengandalkan kill switch.

Pertimbangkan fitur yang menulis ke tabel database baru. Saat Anda membalik kill switch, aplikasi berhenti menulis ke tabel itu, tetapi data yang sudah ditulis tetap ada di sana. Jika jalur kode lama tidak membaca dari tabel itu, data basi mungkin tidak menyebabkan masalah langsung. Tetapi jika jalur kode lama mengharapkan data dalam format atau lokasi yang berbeda, Anda bisa berakhir dengan inkonsistensi yang sulit diurai nantinya.

Menggabungkan Kill Switch dengan Circuit Breaker

Beberapa tim memasangkan kill switch dengan circuit breaker. Circuit breaker secara otomatis menonaktifkan fitur ketika tingkat error melebihi ambang batas yang ditentukan. Misalnya, jika tingkat error naik di atas lima persen dalam satu menit, circuit breaker mematikan fitur tanpa campur tangan manusia.

Kombinasi ini sangat berguna untuk fitur yang berjalan di luar jam kerja atau ketika tim Anda tidak sedang on call. Circuit breaker bertindak sebagai jaring pengaman otomatis, sementara kill switch memberi Anda kendali manual ketika Anda perlu bertindak lebih cepat daripada yang bisa dilakukan sistem otomatis.

Pola circuit breaker menambahkan lapisan lain: ia juga dapat mendeteksi kapan masalah yang mendasarinya telah teratasi dan secara bertahap memperkenalkan kembali lalu lintas ke fitur tersebut. Ini membuatnya lebih canggih daripada kill switch sederhana, tetapi juga lebih kompleks untuk diimplementasikan dan diuji.

Apa yang Terjadi Setelah Kill Switch Diaktifkan

Membalik kill switch adalah respons darurat, bukan solusi permanen. Setelah fitur dinonaktifkan, tim Anda perlu menemukan akar masalahnya. Fitur yang dimatikan tidak ditinggalkan begitu saja. Anda memperbaiki bug, menguji perbaikannya, lalu menyalakan flag kembali.

Jika Anda tidak menindaklanjuti, flag akan tertinggal di codebase Anda tanpa batas waktu. Flag mati menjadi utang teknis. Mereka mengotori kode, membingungkan pengembang di masa depan, dan meningkatkan risiko seseorang secara tidak sengaja mengaktifkan fitur yang rusak berbulan-bulan kemudian.

Daftar Periksa Praktis untuk Kill Switch

Sebelum Anda mengandalkan kill switch di production, jalankan daftar periksa ini:

  • Dapatkah flag memisahkan kode baru dari kode lama secara bersih tanpa efek samping?
  • Apakah menonaktifkan fitur meninggalkan data dalam keadaan konsisten?
  • Apakah toggle flag dapat diakses oleh tim on-call tanpa memerlukan deployment?
  • Sudahkah Anda menguji perilaku kill switch di lingkungan staging?
  • Apakah tim tahu siapa yang memiliki wewenang untuk membalik kill switch?
  • Apakah ada proses terdokumentasi untuk apa yang terjadi setelah kill switch diaktifkan?

Intisari Praktis

Kill switch memberi Anda kemampuan untuk menonaktifkan satu fitur dalam hitungan detik tanpa harus melakukan rollback seluruh aplikasi. Ini bukan pengganti rollback atau pengujian yang tepat, tetapi ini adalah mekanisme keamanan penting bagi tim mana pun yang merilis fitur secara bertahap. Desain feature flags Anda sehingga dapat berfungsi sebagai kill switch. Uji bahwa mereka benar-benar berfungsi. Dan ketika Anda membalik satu, perlakukan itu sebagai awal dari siklus perbaikan, bukan akhir dari pembicaraan.