Apa arti tombol rollback jika versi lama tidak lagi bisa membaca data yang baru ditulis? Mengembalikan executable dapat dilakukan dengan cepat, tetapi layanan tetap bermasalah ketika keadaan di sekitarnya sudah berubah.
Saya ingin menempatkan jalan pulang sebagai bagian dari desain deployment. Pembahasannya mencakup artefak rilis, konfigurasi, kompatibilitas data, dan keputusan pemulihan—dengan contoh aplikasi blog sederhana.
Peta singkat
Bagian | Yang perlu disiapkan sebelum rilis |
Artefak | Versi yang dapat dikenali dan dijalankan kembali. |
Konfigurasi | Pengaturan yang cocok dengan versi tujuan pemulihan. |
Data | Format dan skema yang tetap dapat dibaca selama transisi. |
Peluncuran | Ruang lingkup awal dan ukuran keberhasilan yang jelas. |
Pemulihan | Pilihan rollback atau perbaikan ke depan beserta batasnya. |
1. Kenali keadaan yang akan dikembalikan
Deployment mengubah sistem dari satu keadaan ke keadaan lain. AWS Builders’ Library menjelaskan bahwa dua versi yang masing-masing berfungsi belum tentu aman ketika dijalankan bersama atau saat transisi dibalik.
Untuk aplikasi blog, artinya mencatat identitas artefak, versi konfigurasi, status migrasi database, dan format pesan antrean. Catatan itu menjawab apa yang berubah dan ke keadaan mana sistem dapat dikembalikan.
Menyimpan nomor commit saja belum menjawab semua pertanyaan tersebut. Yang juga perlu diketahui: artefak yang benar-benar dijalankan, konfigurasi yang dipasangkan dengannya, serta perubahan data yang sudah terjadi.
Bab Release Engineering di buku Google SRE menekankan proses build dan rilis yang konsisten, otomatis, dan dapat diulang. Konsekuensinya, artefak lama yang sudah diverifikasi tetap disimpan selama masa pemulihan yang disepakati.
2. Uji versi lama terhadap data versi baru
Bayangkan versi pertama aplikasi menyimpan status artikel sebagai
draft atau published. Versi kedua menambahkan archived. Apabila versi pertama menolak nilai yang tidak dikenal, menjalankannya kembali setelah versi kedua menulis archived dapat menghasilkan kesalahan.Contoh ini memperlihatkan kompatibilitas dari dua arah: versi baru membaca data lama, dan versi tujuan rollback membaca data yang ditulis sesudah deployment.
AWS menjelaskan pendekatan dua tahap: siapkan pembaca agar mengenali format baru, baru aktifkan penulisan format tersebut. Sesudah penulisan baru aktif, batas rollback berubah; kembali ke versi sebelum tahap persiapan dapat menjadi tidak aman.
Untuk contoh blog tadi, tentukan versi minimum yang dapat membaca seluruh status yang sudah tersimpan. Batas itu dicatat sebagai bagian dari rilis, bukan diasumsikan selalu “satu versi sebelumnya”.
3. Pisahkan perubahan skema dari penghapusan data lama
Tulisan Stripe tentang online migration menjelaskan migrasi bertahap melalui penulisan ke penyimpanan lama dan baru, perpindahan pembacaan, perpindahan penulisan, lalu pembersihan data lama. Urutannya menjaga transisi tetap dapat diamati.
Misalnya, untuk mengganti kolom
cover_url menjadi storage_key, langkahnya:- Tambahkan struktur baru tanpa langsung menghapus yang lama.
- Rilis kode transisi yang menjaga keduanya sesuai kebutuhan.
- Isi data lama secara bertahap dan periksa hasilnya.
- Alihkan pembacaan setelah konsistensinya terbukti.
- Pertahankan jalur yang diperlukan selama jendela rollback.
- Hapus struktur lama lewat perubahan terpisah setelah batas pemulihannya disetujui.
Penulisan ganda membutuhkan penanganan kegagalan parsial dan perubahan bersamaan. Backfill juga perlu memastikan hasilnya tidak menimpa pembaruan yang lebih baru.
Uji juga kegagalan di tengah proses dan backfill yang dijalankan ulang. Jika dua representasi berbeda, perpindahan pembacaan ditunda sampai penyebabnya dipahami.
4. Batasi dampak awal dan ukur perilaku pengguna
Canary adalah deployment terbatas yang dievaluasi sebelum peluncuran diteruskan. The Site Reliability Workbook membahas perbandingan antara bagian yang menerima perubahan dan kelompok kontrol.
Untuk aplikasi blog, proses hidup saja tidak cukup menjadi kriteria lulus. Yang perlu diamati adalah keberhasilan membuka artikel, kegagalan penyimpanan, latency, dan kesalahan yang hanya muncul pada versi baru.
Rencana rilis perlu menentukan siapa yang menghentikan peluncuran dan bukti apa yang mendasarinya. Misalnya, kenaikan kegagalan membuka artikel menghentikan perluasan trafik sambil tim menilai jalur pemulihan.
Canary memperkecil paparan awal, tetapi tidak membatalkan perubahan data bersama. Jika kelompok canary menulis format baru ke database yang sama, versi kontrol tetap harus kompatibel.
5. Bedakan rollback, perbaikan ke depan, dan restore
Tiga tindakan ini menjawab masalah yang berbeda:
- Rollback aplikasi menjalankan kembali versi yang telah dipilih sebagai tujuan aman.
- Perbaikan ke depan merilis perubahan berikutnya untuk memperbaiki keadaan saat ini.
- Restore data mengembalikan data dari salinan atau mekanisme pemulihan yang tersedia.
Dalam contoh blog, kesalahan tampilan tanpa perubahan data mungkin dapat ditangani dengan rollback aplikasi. Sebaliknya, jika rilis salah menulis lokasi berkas, mengembalikan kode belum memperbaiki record yang sudah terdampak.
Record yang terdampak perlu dicatat, dan perbaikan datanya dinilai terpisah. Memulihkan seluruh database dari salinan sebelum rilis juga dapat menghilangkan pembaruan sah setelah salinan tersebut dibuat. Pertimbangannya berkaitan dengan titik pemulihan dan toleransi kehilangan data, sebagaimana dibahas dalam NIST SP 800-34 Rev. 1.
Keputusan pemulihan harus mempertimbangkan keadaan yang sudah terbentuk, termasuk pekerjaan antrean dan efek pada layanan luar.
6. Latih perjalanan maju dan kembali
AWS menyebut pengujian upgrade–downgrade untuk memeriksa keamanan transisi. Latihan ini dijalankan di lingkungan uji dengan data sintetis dan efek eksternal yang dikendalikan.
Urutan latihan untuk aplikasi blog ini adalah menjalankan versi lama, membuat data, melakukan upgrade, menulis data baru, lalu kembali ke versi rollback yang ditetapkan. Setelah itu, periksa apakah kedua kelompok data tetap dapat dibaca dan diperbarui.
Jika produksi memakai beberapa instance, latihan juga perlu mewakili masa ketika versi lama dan baru berjalan bersamaan. Daftar pemeriksaan mencakup worker antrean, konfigurasi, akses ke dependency, serta waktu sampai fungsi pengguna pulih.
Hasil latihan menjadi prosedur: artefak tujuan, langkah pelaksanaan, batas rollback, pemeriksaan hasil, dan penanganan bila rollback gagal. Prosedurnya harus bisa dipakai tanpa mengandalkan ingatan orang yang menulis perubahan.
Penutup
Mulailah dari satu perubahan kecil. Tentukan keadaan tujuan, pastikan kompatibilitas data, lalu latih upgrade dan rollback sebelum memperluas deployment.
Jalan pulang yang berguna punya batas yang jelas: kita tahu versi mana yang masih aman dijalankan, data apa yang telah berubah, dan kapan pemulihan membutuhkan tindakan selain mengembalikan kode.
