Panduan latihan rollback: pulihkan rilis yang rusak dalam 5 menit

Mengapa rollback terasa menakutkan (dan mengapa latihan membantu)

Sebuah rilis bisa terlihat baik saat pengujian, lalu rusak dalam lima menit pertama lalu lintas nyata. Bagian menakutkan biasanya bukan bug-nya. Melainkan ketidakpastian: apa yang berubah, apa yang bisa dibatalkan dengan aman, dan apakah rollback akan membuatnya lebih buruk.

Segera setelah rilis, kegagalan sering sederhana dan terlihat jelas. Tombol baru bisa membuat halaman crash di mobile. Perubahan backend bisa mengembalikan bentuk data yang salah sehingga checkout gagal. Pengaturan kecil bisa merusak login, email, atau pembayaran. Bahkan saat perbaikannya mudah, tekanan meningkat karena pengguna mengamati dan setiap menit terasa mahal.

Kepanikan mulai ketika jalur rollback tidak jelas. Orang menanyakan hal yang sama pada waktu yang sama: Apakah kita punya snapshot? Versi mana yang terakhir baik? Jika kita rollback aplikasi, bagaimana dengan database? Siapa yang punya akses untuk melakukannya? Ketika jawaban-jawaban itu belum tertulis, tim membuang waktu berdebat alih-alih memulihkan layanan.

Tebakan saat insiden ada biayanya. Anda kehilangan waktu, pengguna kehilangan kepercayaan, dan perubahan tergesa-gesa bisa menyebabkan pemadaman kedua di atas yang pertama. Insinyur juga terseret ke terlalu banyak hal sekaligus: debugging, pemberitahuan, dan pengambilan keputusan.

Latihan mengganti suasana karena menggantikan ketidakpastian dengan memori otot. Latihan rollback yang baik bukan sekadar “bisakah kita revert kode.” Itu rutinitas yang bisa diulang: apa yang Anda snapshot, apa yang Anda pulihkan, apa yang Anda verifikasi, dan siapa yang boleh bertindak. Setelah beberapa latihan, rollback berhenti terasa seperti kegagalan dan mulai terasa seperti alat keselamatan.

Jika setup deployment Anda sudah mendukung snapshot dan restore (beberapa platform, termasuk Koder.ai, membangun ini ke dalam alur rilis), latihan jadi lebih mudah karena “kembali ke yang diketahui baik” adalah tindakan normal, bukan prosedur darurat. Bagaimanapun, tujuannya sama: saat saatnya tiba, tidak ada yang sedang mengimprovisasi.

Apa arti “pulihkan dalam 5 menit” sebenarnya

“Pulihkan dalam 5 menit” tidak berarti semuanya sempurna lagi. Itu berarti Anda bisa mengembalikan pengguna ke versi yang berfungsi dengan cepat, meskipun rilis baru masih rusak.

Layanan dulu, perbaikan nanti. Jika Anda bisa memulihkan layanan dengan cepat, Anda membeli waktu tenang untuk menemukan bug sebenarnya.

5 menit adalah untuk tindakan, bukan debat

Jam mulai ketika Anda sepakat: “Kita rollback sekarang.” Itu tidak termasuk diskusi panjang tentang apakah masalah mungkin pulih sendiri.

Tentukan trigger rollback lebih awal. Contoh: “Jika error checkout tetap di atas X% selama 3 menit setelah deploy, kita rollback.” Saat trigger tercapai, jalankan skrip.

Apa yang dihitung sebagai “dipulihkan”

“Dipulihkan” harus sekumpulan sinyal kecil yang memberi tahu Anda pengguna aman dan sistem stabil. Jaga agar tetap ketat dan mudah diperiksa:

• Aksi pengguna kunci berfungsi lagi (login, checkout, pencarian, atau satu hal yang harus dilakukan aplikasi Anda)
• Tingkat error kembali mendekati normal
• Latensi kembali ke rentang yang dapat diterima
• Tidak ada crash loop atau badai restart

Saat sinyal-sinyal itu tampak baik, hentikan timer 5 menit. Semuanya yang lain bisa menunggu.

Untuk menjaga latihan jujur, tandai secara eksplisit apa yang tidak Anda lakukan selama jalur 5 menit: debugging mendalam, perubahan kode atau rilis hotfix, dan apa pun yang berubah menjadi pekerjaan engineering.

Pilih pendekatan rollback yang bisa diulang oleh tim Anda

Rollback terasa cepat hanya ketika keputusan sebagian besar sudah dibuat sebelumnya. Pilih satu pendekatan yang bekerja untuk sebagian besar insiden, lalu latih sampai terasa membosankan.

Latihan Anda harus menjawab empat pertanyaan:

• Kita rollback atau hotfix?
• Ke apa kita rollback?
• Apa yang memicu rollback?
• Siapa yang berwenang berkata “lakukan”?

Rollback vs hotfix: pilih default

Rollback terbaik saat rilis baru secara aktif merugikan pengguna atau data, dan Anda sudah punya versi yang diketahui baik untuk dikembalikan. Hotfix lebih cocok bila dampaknya kecil, perubahan terisolasi, dan Anda yakin bisa menambal dengan aman.

Default sederhana bekerja baik: jika pengguna tidak bisa menyelesaikan tindakan utama (checkout, login, signup) atau tingkat error melonjak, rollback dulu dan perbaiki belakangan. Simpan hotfix untuk masalah yang mengganggu tapi tidak berbahaya.

Pilih target rollback

“Target” Anda harus sesuatu yang bisa dipilih cepat, tanpa debat. Sebagian besar tim menggunakan tiga target umum:

• Versi sebelumnya (rilis terakhir yang lulus pengecekan)
• Snapshot deployment yang dapat Anda restore
• Rollback hanya konfigurasi (feature flag atau pengaturan environment)

Jika Anda punya snapshot deployment yang andal, jadikan itu default karena paling bisa diulang saat di bawah tekanan. Simpan rollback konfigurasi sebagai jalur terpisah untuk kasus di mana kode baik tapi pengaturan salah.

Juga tentukan apa yang dihitung sebagai “previous good.” Itu harus rilis terbaru yang menyelesaikan pengecekan monitoring dan tidak memiliki insiden aktif, bukan “yang diingat orang.”

Definisikan trigger dan otoritas

Jangan menunggu rapat selama insiden. Tuliskan trigger yang memulai rollback dan patuhi itu. Trigger tipikal termasuk alur utama rusak lebih dari beberapa menit, error rate atau latensi melewati ambang yang disepakati, risiko data (tulisan salah, biaya ganda), dan setiap masalah keamanan atau privasi yang diperkenalkan oleh rilis.

Lalu tentukan siapa yang dapat menyetujui rollback. Pilih satu peran (incident lead atau on-call), plus cadangan. Semua orang lain bisa memberi saran, tapi mereka tidak bisa memblokir. Saat trigger tercapai dan pemutus berkata “rollback,” tim menjalankan langkah yang sama setiap waktu.

Apa yang harus disnapshot sebelum setiap rilis

Latihan rollback hanya bekerja jika Anda bisa kembali ke keadaan yang diketahui baik dengan cepat. Snapshot bukan sekadar “bagus untuk dimiliki.” Mereka bukti apa yang berjalan, apa yang berubah, dan cara kembali.

Lima hal yang harus ditangkap

Sebelum setiap rilis, pastikan Anda bisa mengambil item ini tanpa mencari di chat:

• Build aplikasi tepat yang Anda kirim: hash commit, nomor versi, dan artifact build (tag container, bundle, atau paket).
• Status database dan rencana migrasi: migrasi mana yang diterapkan, dan apakah bisa dibalik. Untuk perubahan berisiko, ambil backup atau snapshot yang bisa dipulihkan cepat.
• Konfigurasi saat deploy: feature flag, environment variable, endpoint pihak ketiga, dan apa yang berubah. Rahasia harus disimpan di sistem aman, tapi Anda tetap butuh catatan versi perubahan.
• Pengaturan infrastruktur dan routing: domain, sertifikat, aturan load balancer, dan saklar “ke mana trafik pergi”.
• Catatan rilis singkat: satu kalimat tentang apa yang berubah, dan satu kalimat tentang cara memverifikasi rollback berhasil.

Keamanan database adalah jebakan yang biasa. Rollback aplikasi cepat tidak membantu jika database kini mengharapkan skema baru. Untuk migrasi berisiko, rencanakan rilis dua langkah (tambah field dulu, mulai pakai nanti) sehingga rollback tetap mungkin.

Namai snapshot supaya bisa ditemukan dalam hitungan detik

Gunakan satu aturan penamaan di mana saja, dan buat bisa disortir:

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

Masukkan environment, timestamp, versi, dan commit. Jika alat Anda mendukung snapshot di UI, gunakan aturan penamaan yang sama di sana supaya siapa pun bisa menemukan titik restore yang tepat saat insiden.

Peran: siapa klik apa (dan siapa hanya menonton)

Latihan rollback lebih cepat dan tenang saat semua orang tahu tugasnya. Tujuannya bukan “semua orang terjun.” Melainkan satu orang membuat keputusan, satu orang melakukan aksi, satu orang mengonfirmasi berhasil, dan satu orang memberi info ke luar.

Untuk tim kecil dan menengah, peran ini bekerja baik (satu orang bisa memegang dua topi jika perlu, tapi hindari menggabungkan Deployer dan Verifier saat latihan):

• Incident lead (pengatur waktu dan pengambil keputusan): menyatakan target sukses dan memutuskan rollback.
• Deployer (pegang keyboard): mengeksekusi langkah rollback tepat seperti tertulis dan menerangkan apa yang dilakukan.
• Verifier (bukti bekerja): menjalankan pengecekan wajib dan memantau sinyal utama.
• Communicator (suara tunggal ke luar): memposting pembaruan singkat dan reguler kepada stakeholder dan support.

Izin menentukan apakah rencana ini nyata atau hanya dokumen bagus. Sebelum latihan, sepakati siapa yang boleh rollback produksi, dan bagaimana keadaan darurat bekerja.

Setup sederhana:

• Beri Deployer hak rollback selama rotasi on-call atau jendela latihan terjadwal.
• Biarkan Incident lead menyetujui aksi (bahkan jika mereka tidak punya tombol).
• Pastikan Verifier punya akses read-only ke dashboard dan log.
• Siapkan opsi break-glass (akses diaudit, berbatas waktu).
• Uji akses saat persiapan latihan, bukan selama timer 5 menit.

Jika Anda menggunakan platform yang mendukung snapshot dan rollback (termasuk Koder.ai), putuskan siapa yang bisa membuat snapshot, siapa yang bisa merestore, dan di mana aksi itu dicatat.

Langkah demi langkah: runbook latihan rollback

Latihan rollback paling baik ketika terasa seperti drill kebakaran: langkah sama, kata-kata sama, tempat yang sama untuk diklik. Tujuannya bukan kesempurnaan. Melainkan siapa pun yang on-call bisa mengembalikan versi terakhir yang diketahui baik dengan cepat, tanpa berdebat tentang opsi.

Sebelum mulai

Pilih satu trigger jelas dan ucapkan saat latihan dimulai. Contoh: “Checkout mengembalikan 500 lebih dari 1 menit” atau “Tingkat error 5x normal setelah deploy.” Mengucapkannya mencegah tim hanyut ke mode troubleshooting.

Simpan checklist persiapan singkat di samping runbook:

• Konfirmasi Anda bisa melihat sinyal kesehatan live (uptime, error rate, alur pengguna kunci)
• Konfirmasi identifier versi terakhir yang baik (tag, build, nama snapshot)
• Konfirmasi di mana rollback dieksekusi (CI/CD, konsol hosting, UI platform)
• Konfirmasi cara menjeda deploy baru
• Konfirmasi siapa yang merekam timestamp

Runbook 5 menit

1. Mulai timer. Satu orang menyatakan trigger dan keputusan: “Kita rollback sekarang.”

2. Bekukan perubahan. Jeda deploy baru dan hentikan edit non-esensial yang bisa mengubah sistem di tengah rollback.

3. Ambil snapshot kesempatan terakhir (jika aman dan cepat). Ini perlindungan jika Anda perlu merekonstruksi keadaan rusak nanti. Namai dengan jelas dan lanjutkan.

4. Jalankan aksi rollback persis seperti yang terdokumentasi. Jangan improvisasi. Baca prompt konfirmasi dengan lantang agar pencatat dapat menangkap apa yang terjadi.

5. Konfirmasi rollback selesai di satu tempat tepercaya. Gunakan satu layar dan satu sinyal setiap saat (tampilan riwayat deployment, label “current version”, atau indikator status yang jelas).

Segera setelah aksi, tangkap apa yang penting selagi masih segar:

• Waktu keputusan (trigger dinyatakan)
• Waktu mulai rollback (klik/perintah pertama)
• Waktu selesai rollback (versi sebelumnya aktif)
• Waktu verifikasi hijau pertama (cek kunci lulus)
• Kejutan apa pun (permission hilang, tombol tidak jelas, langkah lambat)

Jika rollback memakan waktu lebih dari 5 menit, jangan mencari alasan. Temukan langkah lambatnya, perbaiki runbook, dan jalankan latihan lagi.

Apa yang diverifikasi setelah rollback

Rollback hanya “berhasil” ketika pengguna merasakan berhasil. Anda tidak berusaha membuktikan versi lama terdeploy. Anda membuktikan layanan dapat digunakan lagi dan stabil.

Jaga verifikasi kecil dan bisa diulang. Jika daftarnya lebih dari lima, orang akan melewatkannya saat stres.

3–5 pengecekan wajib

Gunakan pengecekan yang bisa dijalankan cepat, dengan hasil jelas pass/fail:

• Pengguna bisa login (atau signup) dan mencapai layar utama tanpa error
• Transaksi inti berhasil (checkout, booking, submit form)
• Satu endpoint API kunci mengembalikan 200 dan respons terlihat normal
• Admin/support bisa melakukan satu aksi kritis (refund, cancel, update status)
• Satu alur tepi yang sering rusak (reset password, upload file, pencarian) masih berfungsi

Setelah pengecekan fungsional, lihat sekilas sinyal kesehatan sistem paling sederhana yang Anda percaya. Anda ingin melihat tingkat error turun kembali normal dan latensi berhenti melonjak dalam beberapa menit.

Juga konfirmasi bagian yang kurang terlihat sudah berjalan lagi. Job background harus memproses dan antrean harus mengosongkan, bukan menumpuk. Pemeriksaan database harus cepat dan membosankan: koneksi stabil, tidak ada lock pileup yang jelas, dan aplikasi bisa menulis.

Terakhir, uji dunia luar bila penting dan aman. Jika bisa dilakukan dengan aman, jalankan tes pembayaran, konfirmasi pengiriman email tidak bounce, dan pastikan webhook diterima (atau setidaknya tidak gagal).

Tentukan kata-kata “semua jelas”

Tulis satu kalimat siap pakai supaya tidak ada improvisasi:

“Rollback selesai. Alur inti diverifikasi (login + checkout). Tingkat error dan latensi kembali normal. Monitoring selama 30 menit. Update berikutnya jam 14:30.”

Contoh: rilis rusak dan pemulihan bersih dalam 5 menit

Jam 10:02 pada hari Selasa. Rilis baru keluar, dan dalam satu menit sebagian pengguna tidak bisa login. Beberapa mendapat “invalid session,” lainnya melihat spinner yang tak pernah hilang. Pendaftaran masih berfungsi, jadi masalah mudah terlewat awalnya.

Sinyal pertama biasanya bukan pemadaman dramatis. Itu lonjakan kecil: tiket support, penurunan login sukses, dan beberapa pesan marah dari pengguna nyata. On-call melihat alert “login success rate turun 18% dalam 5 menit,” dan support memposting: “3 pengguna tidak bisa login setelah update.”

Pemulihan 5 menit (bagaimana tampilannya)

Karena tim sudah melatih drill, mereka tidak lama berdebat. Mereka konfirmasi, putuskan, dan bertindak.

• 10:03: On-call mengonfirmasi dan menunjuk incident lead.
• 10:04: Keputusan rollback. Aturan: jika login rusak dan tidak ada perbaikan aman dalam 2 menit, rollback.
• 10:05: Deployer memicu rollback ke snapshot sebelumnya yang diketahui baik.
• 10:06: Trafik kembali ke versi sebelumnya. Tim mengetes ulang login di web dan mobile.
• 10:07: Incident lead memposting “Login dipulihkan, monitoring 10 menit” dan meminta support membalas pengguna yang terdampak.

Yang di-rollback: kode aplikasi dan konfigurasi untuk layanan web dan API. Yang tetap: database dan data pengguna.

Jika rilis menyertakan migrasi database, aturan drill sederhana: jangan rollback database dalam jalur 5 menit. Buat migrasi backward compatible, atau hentikan dan minta mata kedua sebelum deploy.

Apa yang dikomunikasikan (selama dan setelah)

Selama rollback, incident lead memposting pembaruan singkat tiap beberapa menit: apa yang pengguna lihat, aksi apa yang sedang berlangsung, dan kapan update berikutnya. Contoh: “Kita rollback rilis terakhir untuk memulihkan login. Update berikutnya dalam 2 menit.”

Setelah rollback, mereka menutup loop: “Login kembali normal. Tinjauan akar masalah sedang berlangsung. Kami akan bagikan penyebab dan perubahan untuk mencegah ulang.”

Kesalahan umum latihan rollback (dan perbaikan sederhana)

Latihan rollback harus terasa membosankan. Jika terasa stres, latihan mungkin mengekspos celah nyata: akses, snapshot hilang, atau langkah yang hanya ada di kepala seseorang.

Kesalahan yang membuang menit

• Anda latihan dengan akses yang diasumsikan, bukan izin nyata. Orang menemukan saat insiden bahwa mereka tidak bisa deploy, tidak bisa ubah config, atau tidak bisa buka dashboard. Perbaikan: jalankan drill dengan akun dan peran yang sama seperti saat insiden.

• Snapshot ada, tapi tidak lengkap atau sulit ditemukan. Tim snapshot aplikasi tapi lupa perubahan env, feature flag, atau routing. Atau nama snapshot tidak bermakna. Perbaikan: jadikan pembuatan snapshot langkah rilis dengan aturan penamaan dan verifikasi selama latihan bahwa snapshot terlihat dan bisa direstore cepat.

• Migrasi database membuat rollback tidak aman. Perubahan skema yang tidak kompatibel mengubah rollback cepat jadi masalah data. Perbaikan: utamakan migrasi aditif. Jika perubahan yang memecah tak terhindarkan, rencanakan perbaikan maju dan beri label rilis jelas: “rollback allowed: yes/no.”

• Anda menyatakan sukses sebelum memeriksa apa yang dirasakan pengguna. Aplikasi terdeploy, tapi login masih rusak atau job terjebak. Perbaikan: jaga verifikasi singkat tapi nyata, dan beri batas waktu.

• Drill terlalu kompleks untuk diulang. Terlalu banyak alat, terlalu banyak cek, terlalu banyak suara. Perbaikan: ringkas drill jadi satu halaman dan satu pemilik. Jika tidak bisa dilakukan dari satu runbook dan satu saluran komunikasi, itu tidak akan terjadi saat tekanan.

Latihan rollback yang baik adalah kebiasaan, bukan penampilan heroik. Jika Anda tidak bisa menyelesaikannya dengan tenang, kurangi langkah sampai bisa, lalu tambahkan hanya apa yang benar-benar mengurangi risiko.

Checklist cepat dan langkah selanjutnya

Latihan rollback paling baik saat semua orang mengikuti checklist satu halaman yang sama. Tempelkan di tempat tim Anda memang melihat.

Versi ringkas yang bisa dijalankan dalam kurang dari 10 menit (termasuk persiapan dan verifikasi):

• Sebelum rilis: konfirmasi titik rollback (snapshot/versi), catat perilaku “baik” yang diharapkan, tetapkan peran (deployer, verifier, comms).
• Trigger: nyatakan “rollback dimulai,” mulai timer, bekukan deploy baru.
• Aksi rollback: pulihkan rilis terakhir yang diketahui baik, rekam apa yang diklik dan urutannya.
• Verifikasi: jalankan 2–3 cek kritis (login, alur utama, satu integrasi atau pengecekan API), konfirmasi tingkat error turun.
• Tutup: nyatakan “layanan stabil,” tulis tiga catatan (apa yang berhasil, apa yang memperlambat, apa yang diubah), buka kembali deploy.

Jalankan drill cukup sering agar langkah terasa normal. Bulanan adalah default yang baik. Jika produk Anda berubah setiap hari, jalankan tiap dua minggu, tapi tetap fokus verifikasi pada jalur pengguna utama.

Setelah setiap latihan, perbarui runbook di hari yang sama selagi masih segar. Simpan bersama catatan rilis, dan tambahkan baris “last tested” bertanggal supaya tidak ada yang percaya pada prosedur yang kadaluwarsa.

Ukur hanya yang membantu Anda berkembang:

• Waktu-ke-rollback (dari deklarasi ke dipulihkan)
• Waktu-ke-verifikasi (dari dipulihkan ke stabil)
• Kejelasan peran (di mana orang ragu atau menggandakan kerja?)
• Info yang hilang (kredensial, izin, lokasi snapshot)

Jika tim Anda membangun di Koder.ai, perlakukan snapshot dan rollback sebagai bagian kebiasaan: beri nama snapshot konsisten, latih restore di antarmuka yang sama yang akan Anda gunakan saat on-call, dan sertakan pengecekan domain kustom dan integrasi cepat dalam langkah verifier. Menyebutkan ini di runbook menjaga latihan selaras dengan cara Anda sebenarnya mengirim.