Kriteria apa yang Anda gunakan untuk memutuskan antara rollback dan hotfix?

Question

Accepted Answer

Defaultnya adalah **rollback** — itu cara tercepat dan paling andal untuk memulihkan state yang diketahui baik. Pilih **hotfix** hanya ketika rollback mustahil atau lebih berbahaya daripada memperbaiki ke depan. Dalam incident yang aktif, prioritasnya adalah **hentikan pendarahan dulu**, diagnosis kemudian.

## Kriteria keputusan

- **Apakah rollback aman dan mungkin?** Jika versi sebelumnya diketahui baik dan tidak ada hal ireversibel yang terjadi, lakukan rollback. Ini jawaban yang biasa.
- **Apakah rilis buruk itu menciptakan state ireversibel?** Sebuah **migrasi database** atau korupsi data bisa membuat rollback lebih buruk daripada bug-nya. Jika Anda tidak bisa kembali dengan aman, Anda harus memperbaiki ke depan.
- **Apakah kita memahami perbaikannya?** Rollback tidak butuh diagnosis — itu kekuatannya. Sebuah hotfix yang tidak Anda pahami sepenuhnya bisa memperdalam incident; jangan pernah merilis tebakan ke produksi di bawah tekanan.
- **Waktu menuju state aman.** Pilih jalur mana pun yang mencapai stabilitas tercepat dengan risiko terkecil. Hotfix satu baris yang benar-benar dipahami bisa mengalahkan rollback yang rumit; perbaikan-ke-depan yang berisiko tidak pernah mengalahkan revert yang bersih.
- **Radius ledakan dan tingkat keparahan.** Outage total menuntut pemulihan secepat mungkin (biasanya rollback); degradasi minor mungkin memungkinkan hotfix yang hati-hati.

## Tabel keputusan cepat

| Situasi | Pilih |
| --- | --- |
| Versi sebelumnya diketahui baik, tanpa migrasi | Rollback |
| Migrasi DB ireversibel sudah dirilis | Hotfix / fix-forward |
| Penyebab tidak diketahui, dampak parah | Rollback (mengulur waktu) |
| One-liner sepele, benar-benar dipahami | Hotfix |
| Rollback itu sendiri berisiko/belum teruji | Hotfix |

## Trade-off dan jebakan

- **Rollback** aman tetapi hanya menangani gejalanya — Anda masih berutang perbaikan nyata dan sebuah postmortem.
- **Hotfix** mengatasi akar penyebab tetapi melewati jaring pengaman normal; bug dalam hotfix umum justru karena dibuat terburu-buru.
- **Jalur rollback yang belum teruji** adalah jebakan — jika Anda belum pernah melatihnya, ia bisa gagal saat Anda paling membutuhkannya. Latih rollback sebelum Anda membutuhkannya.
- Waspadai **debugging di produksi** di bawah tekanan; jika Anda lebih dari beberapa menit dari perbaikan yang meyakinkan, lakukan rollback dan selidiki dengan tenang.

## Mengapa ini penting

Keputusan ini terjadi pada momen terburuk yang mungkin — sistem down, waktu berjalan, semua orang menonton. Seorang Tech Lead dengan aturan yang jelas dan terlatih untuk itu memangkas MTTR secara drastis dan mencegah kesalahan klasik berupa mencoba bertindak pintar di tengah incident padahal revert yang membosankan ada tepat di depan mata. Pulihkan dulu, bertindak pintar belakangan.

Situasi	Pilih
Versi sebelumnya diketahui baik, tanpa migrasi	Rollback
Migrasi DB ireversibel sudah dirilis	Hotfix / fix-forward
Penyebab tidak diketahui, dampak parah	Rollback (mengulur waktu)
One-liner sepele, benar-benar dipahami	Hotfix
Rollback itu sendiri berisiko/belum teruji	Hotfix