Migrasi Server Tanpa Downtime itu Mitos atau Bisa Dicapai?

Pukul dua pagi, terminal masih terbuka, satu tab menampilkan proses rsync yang jalan 40%, tab lain menampilkan dashboard uptime yang belum sempat merah tapi sudah bikin jantung deg-degan. Ini gambaran umum tiap kali ada rencana pindah VPS atau ganti provider hosting. Ada yang bilang migrasi tanpa downtime itu cuma mitos yang dipakai vendor buat jualan, ada juga yang bersikeras itu standar minimal yang harus dicapai siapa pun yang serius jadi admin server.

Kenyataannya ada di tengah. Downtime nol detik memang jarang tercapai kecuali infrastrukturnya sudah dirancang khusus untuk itu sejak awal, misalnya pakai load balancer dan replikasi database real-time. Tapi downtime yang kelihatan oleh pengguna, bukan cuma downtime di kertas laporan, itu bisa ditekan sampai nyaris tidak terasa kalau prosesnya disiapkan dengan benar. Bedanya cuma soal disiplin: file dan database dipindah lebih dulu, diverifikasi hasilnya identik dengan sumber, baru DNS atau pointing domain dialihkan paling terakhir.

Verifikasi ini bagian yang paling sering dilewatkan orang yang buru-buru. Banyak yang cuma copy folder lalu langsung pindah domain, padahal database bisa saja belum selesai sinkron atau ada file config yang ketinggalan. Proses migrasi yang benar itu memindahkan file aplikasi dan database sekaligus, lalu menjalankan pengecekan supaya hasil migrasi cocok persis dengan server lama sebelum server itu dimatikan. Kalau tahap verifikasi ini dilewati, risikonya bukan cuma downtime, tapi kehilangan data yang baru ketahuan seminggu kemudian saat pelanggan komplain transaksinya hilang.

Dua hal lain sering luput dari daftar checklist migrasi padahal sama pentingnya. Pertama, akses aman ke server baru selama proses pindahan berlangsung, apalagi kalau tim kerja remote dan tidak mau membuka port SSH ke publik begitu saja. Kedua, kebiasaan memantau server setelah migrasi selesai, bukan cuma pas hari-H tapi berminggu-minggu sesudahnya, karena beban kerja server baru kadang baru kelihatan bermasalah setelah trafik normal kembali.

Server yang baru pindah itu justru rawan luput dari pengawasan karena semua orang fokus ke proses migrasinya, lalu monitoring rutin lupa dipasang ulang di server baru. Padahal saat itulah CPU atau disk paling gampang penuh tanpa disadari, apalagi kalau resource server baru sedikit berbeda dari yang lama.

Kalau memang lagi merencanakan pindah hosting dalam waktu dekat, tiga hal ini sebaiknya disiapkan bareng, bukan satu-satu setelah masalah muncul. Migrasi website antar server menangani pemindahan file dan database sekaligus verifikasinya, Setup WireGuard VPN 1-command bikin akses ke server baru tetap aman tanpa buka port SSH ke publik, dan Monitoring server dengan alert Telegram memastikan begitu server baru online, ada yang mengawasi resource-nya sejak menit pertama. Kalau migrasi semacam ini sudah jadi rutinitas dan kamu ingin naik level ke arsitektur keamanan skala besar, Shift Left — DevSecOps Vol 2 membahas DevSecOps di skala besar sampai roadmap karir jadi arsitek keamanan.