Saat Perubahan Infrastruktur Bermasalah: Opsi Pemulihan dari Apply Ulang hingga Failover

Anda baru saja menjalankan terraform apply di infrastruktur produksi. Outputnya bersih. Tidak ada error. Lalu monitoring Anda memberi peringatan: pengguna tidak bisa terhubung ke database. Perubahan security group yang Anda lakukan secara tidak sengaja memblokir lapisan aplikasi.

Sekarang bagaimana?

Momen ini membedakan tim yang memiliki rencana pemulihan dari tim yang mulai panik mencari konfigurasi terakhir yang diketahui berfungsi. Perubahan infrastruktur bisa gagal dengan cara yang tidak bisa diatasi oleh rollback aplikasi biasa. Push konfigurasi yang buruk mungkin tidak merusak kode Anda, tetapi bisa merusak konektivitas, penyimpanan, atau kontrol akses. Pemulihan membutuhkan playbook-nya sendiri.

Mari kita bahas empat opsi pemulihan, dari yang paling sederhana hingga yang paling kompleks. Masing-masing cocok untuk situasi berbeda, dan masing-masing memiliki trade-off yang perlu Anda pahami sebelum Anda membutuhkannya.

Apply Ulang State Lama

Pendekatan yang paling langsung: kembalikan infrastruktur Anda ke konfigurasi sebelum perubahan.

Jika Anda menggunakan Terraform, ini berarti menjalankan terraform apply dengan file state atau konfigurasi sebelumnya. Konsep yang sama berlaku untuk Pulumi, CloudFormation, atau alat infrastructure-as-code lainnya. Anda memberi tahu sistem untuk mengembalikan definisi infrastruktur ke versi yang diketahui berfungsi.

Ini bekerja dengan baik ketika perubahan bersifat idempoten dan resource yang terlibat tidak menyimpan data kritis. Bayangkan aturan security group, variabel lingkungan pada instance komputasi, atau pengaturan load balancer. Resource ini bisa diubah bolak-balik tanpa efek samping.

Berikut adalah urutan perintah konkret untuk apply ulang state lama:

# 1. Verifikasi file state sebelumnya masih ada
ls -la terraform.tfstate.backup

# 2. Kembalikan state sebelumnya (menimpa state saat ini)
cp terraform.tfstate.backup terraform.tfstate

# 3. Pratinjau perubahan yang akan dilakukan Terraform untuk revert
terraform plan -state=terraform.tfstate

# 4. Apply state lama untuk mengembalikan infrastruktur
terraform apply -state=terraform.tfstate -auto-approve

Catatan: Selalu verifikasi bahwa file backup state valid sebelum melakukan apply. Jalankan terraform state list -state=terraform.tfstate.backup untuk memastikan file tersebut berisi resource yang diharapkan.

Kendalanya: Anda membutuhkan state lama yang masih ada. Jika tim Anda membersihkan file state lama atau jika penyedia infrastruktur telah melakukan garbage collection pada beberapa resource, Anda mungkin tidak memiliki apa pun untuk di-apply ulang. Selain itu, pendekatan ini kesulitan menangani resource stateful. Anda tidak bisa begitu saja apply ulang konfigurasi database lama dan berharap data kembali ke keadaan sebelumnya.

Apply ulang cepat, membutuhkan intervensi manual minimal, dan berfungsi untuk sebagian besar perubahan infrastruktur stateless. Tapi ini bukan solusi universal.

Pemulihan Snapshot

Ketika perubahan Anda menyentuh resource yang menyimpan data, apply ulang saja tidak cukup. Anda perlu memulihkan data itu sendiri.

Sebelum melakukan perubahan pada database, sistem file, atau resource stateful lainnya, ambil snapshot. Penyedia cloud menawarkan ini untuk volume, database, dan bucket penyimpanan. Snapshot menangkap keadaan resource pada titik waktu tertentu.

Jika perubahan gagal, Anda memulihkan dari snapshot tersebut. Database kembali ke keadaan sebelum perubahan. Sistem file kembali ke konten sebelumnya.

Pendekatan ini lebih berat daripada apply ulang. Memulihkan snapshot membutuhkan waktu. Selama waktu itu, resource mungkin tidak tersedia. Pengguna melihat error atau layanan yang menurun. Tapi untuk resource stateful, pemulihan snapshot seringkali satu-satunya opsi yang dapat diandalkan.

Ini bekerja paling baik ketika radius ledakan terbatas pada satu resource atau komponen. Jika Anda mengubah skema database dan itu merusak aplikasi, memulihkan snapshot database akan memperbaiki lapisan data. Aplikasi mungkin perlu di-restart, tetapi data kembali normal.

Kekurangan utamanya: Anda kehilangan data apa pun yang ditulis antara snapshot dan perubahan yang gagal. Jika aplikasi Anda terus-menerus menulis data, celah itu penting. Rencanakan waktu pengambilan snapshot Anda dengan tepat.

Rollback DNS

Terkadang pemulihan tercepat bukan tentang mengembalikan infrastruktur sama sekali. Ini tentang mengarahkan lalu lintas menjauh dari versi yang rusak.

Rollback DNS bekerja di tingkat pengaturan lalu lintas. Alih-alih mengembalikan perubahan infrastruktur, Anda mengarahkan lalu lintas kembali ke infrastruktur lama yang masih berjalan.

Bayangkan Anda men-deploy versi baru dari server aplikasi. Server itu sendiri baik-baik saja, tetapi perubahan konfigurasi merusak sesuatu. Server lama Anda masih berjalan dengan konfigurasi lama. Anda memperbarui catatan DNS atau konfigurasi load balancer untuk mengirim lalu lintas kembali ke server lama.

Ini cepat. Sangat cepat. Perubahan DNS menyebar dengan cepat di lingkungan yang terkontrol, dan pembaruan load balancer hampir instan. Anda tidak perlu membangun ulang atau memulihkan apa pun.

Tapi ada persyaratan kritis: infrastruktur lama harus masih ada. Jika proses deployment Anda menghancurkan resource lama saat membuat yang baru, rollback DNS bukanlah opsi. Strategi ini bekerja secara alami dengan deployment blue-green atau canary release, di mana versi lama dan baru berjalan berdampingan.

Rollback DNS juga tidak memperbaiki masalah yang mendasarinya. Infrastruktur yang rusak masih ada. Anda perlu menyelidiki dan memperbaikinya nanti. Tapi untuk mengembalikan pengguna online dengan cepat, ini sulit ditandingi.

Failover ke Lingkungan Standby

Ini adalah opsi pemulihan yang paling kompleks, dan juga yang paling dapat diandalkan untuk sistem kritis.

Anda memelihara lingkungan kedua yang mencerminkan pengaturan produksi Anda. Ini bisa berada di availability zone yang berbeda, region yang berbeda, atau bahkan penyedia cloud yang berbeda. Lingkungan standby menjalankan infrastruktur yang sama, versi aplikasi yang sama, dan memiliki data yang tersinkronisasi.

Ketika perubahan di produksi gagal dan dampaknya meluas, Anda melakukan failover. Semua lalu lintas dialihkan ke lingkungan standby. Pengguna tetap bekerja, dan Anda mendapatkan waktu untuk memperbaiki lingkungan produksi.

Failover melibatkan perubahan DNS, manajemen replikasi database, dan sinkronisasi data. Ini bukan sesuatu yang ingin Anda cari tahu saat insiden terjadi. Anda perlu menguji proses failover secara teratur, idealnya sebagai bagian dari operasi normal Anda.

Investasinya signifikan. Lingkungan standby membutuhkan biaya untuk dijalankan. Sinkronisasi data menambah kompleksitas. Anda membutuhkan orang yang memahami proses failover dan dapat menjalankannya di bawah tekanan.

Tapi untuk infrastruktur yang harus tetap berjalan, failover adalah opsi yang paling dapat diandalkan. Bank, sistem perawatan kesehatan, dan platform e-commerce skala besar menggunakan pendekatan ini karena biaya downtime jauh melebihi biaya memelihara lingkungan standby.

Memilih Opsi yang Tepat

Setiap opsi pemulihan cocok untuk skenario yang berbeda:

  • Apply ulang state lama: Perubahan stateless, perbaikan cepat, risiko data rendah
  • Pemulihan snapshot: Perubahan stateful, dampak resource tunggal, integritas data diperlukan
  • Rollback DNS: Lingkungan paralel, pemulihan cepat, infrastruktur lama masih ada
  • Failover: Sistem kritis, radius ledakan luas, kebutuhan uptime tinggi

Pilihan Anda tergantung pada tiga faktor: jenis perubahan yang Anda buat, potensi radius ledakan, dan seberapa cepat Anda perlu pulih.

Diagram alir berikut memetakan skenario kegagalan umum ke jalur pemulihan yang direkomendasikan:

flowchart TD A[Perubahan infrastruktur gagal] --> B{Tipe perubahan?} B -->|Stateless| C{State lama tersedia?} B -->|Stateful| D{Kehilangan data bisa diterima?} C -->|Ya| E[Apply ulang state lama] C -->|Tidak| F{Infra lama masih berjalan?} D -->|Tidak| G[Pemulihan snapshot] D -->|Ya| H[Apply ulang state lama] F -->|Ya| I[Rollback DNS] F -->|Tidak| J{Ada standby?} J -->|Ya| K[Failover ke standby] J -->|Tidak| L[Bangun ulang manual dari backup] E --> M[Verifikasi pemulihan] I --> M G --> M K --> M L --> M

Checklist Praktis Sebelum Perubahan Infrastruktur Berikutnya

Sebelum Anda menjalankan terraform apply berikutnya atau melakukan push perubahan konfigurasi, jalankan checklist ini:

  • Apakah saya tahu opsi pemulihan untuk perubahan ini?
  • Apakah file state lama dapat diakses dan valid?
  • Apakah saya sudah mengambil snapshot jika perubahan menyentuh resource stateful?
  • Apakah infrastruktur lama masih berjalan jika saya membutuhkan rollback DNS?
  • Apakah saya sudah menguji proses failover dalam sebulan terakhir?
  • Apakah tim tahu siapa yang mengeksekusi pemulihan dan bagaimana caranya?

Intisari Praktis

Pemulihan dari kegagalan infrastruktur bukan tentang memiliki satu strategi yang sempurna. Ini tentang mencocokkan opsi pemulihan dengan perubahan yang Anda buat. Perubahan security group tidak memerlukan failover penuh. Migrasi database mungkin membutuhkan snapshot. Deployment canary diuntungkan oleh rollback DNS.

Kenali opsi Anda sebelum Anda membutuhkannya. Waktu untuk memutuskan cara memulihkan adalah sebelum Anda melakukan perubahan, bukan setelah peringatan mulai berbunyi.