Ketika Perubahan Infrastruktur Merusak Produksi: Pemulihan dari Bencana IaC

Anda sudah melakukan semuanya dengan benar. Rencana Terraform telah ditinjau oleh dua engineer senior. Perubahan tersebut lolos pemeriksaan kebijakan di pipeline Anda. Berjalan mulus di staging selama tiga hari. Kemudian Anda menerapkannya ke produksi, dan dalam waktu sepuluh menit, pengguna mulai melaporkan error.

Inilah realitas perubahan infrastruktur. Tidak peduli seberapa teliti proses tinjauan Anda, beberapa masalah hanya muncul di bawah lalu lintas nyata. Dependensi yang tidak Anda lihat. Perbedaan konfigurasi antara staging dan produksi yang entah bagaimana lolos. Interaksi halus antara perubahan Anda dan sumber daya yang sudah ada yang tidak diantisipasi siapa pun.

Ketika ini terjadi, tim Anda membutuhkan satu hal di atas segalanya: kemampuan untuk kembali ke kondisi baik yang diketahui, dengan cepat. Ini adalah rollback infrastruktur, dan cara kerjanya berbeda dengan rollback kode aplikasi.

Mengapa Rollback Infrastruktur Berbeda

Rollback aplikasi biasanya berarti menyebarkan versi kode sebelumnya. Server, jaringan, skema database—semuanya tetap sama. Anda hanya menukar biner atau image container.

Rollback infrastruktur tidak sesederhana itu. Infrastruktur mencakup server, load balancer, aturan jaringan, instance database, volume penyimpanan, dan puluhan sumber daya lain yang saling bergantung. Mengembalikan satu sumber daya ke versi lama tanpa mempertimbangkan yang lain bisa memperburuk keadaan, bukan memperbaikinya.

Bayangkan Anda mengubah aturan security group dan juga memperbarui konfigurasi load balancer. Jika Anda hanya melakukan rollback pada security group, load balancer mungkin sekarang mengarah ke instance yang diblokir oleh security group lama. Upaya pemulihan Anda justru menciptakan gangguan baru.

Kunci rollback infrastruktur yang aman bergantung pada dua hal: manajemen state dan versioning konfigurasi.

Manajemen State: Ketahui Apa yang Anda Miliki

Alat Infrastructure as Code seperti Terraform, Pulumi, atau OpenTofu menyimpan file state. File ini mencatat setiap sumber daya yang dikelola alat, konfigurasi saat ini, dan bagaimana sumber daya saling terkait. Tanpa state yang akurat, alat tidak dapat mengetahui apa yang ada, apalagi cara mengubahnya.

File state adalah aset kritis. Mereka perlu disimpan dengan aman, dikontrol aksesnya, dan diberi versi setiap kali perubahan terjadi. Jika Anda kehilangan file state, Anda kehilangan kemampuan untuk mengelola infrastruktur tersebut melalui IaC. Anda kembali ke pemulihan manual, menebak sumber daya apa yang ada dan bagaimana mereka terhubung.

Praktik terbaik adalah menyimpan state secara remote—di penyimpanan cloud, layanan backend, atau alat manajemen state khusus. File state lokal di laptop pengembang adalah bencana yang menunggu untuk terjadi. Pipeline harus selalu menggunakan sumber state yang sama dan otoritatif.

Versioning Konfigurasi: Ketahui Apa yang Anda Miliki Sebelumnya

Kode aplikasi mendapatkan tag versi. Konfigurasi infrastruktur membutuhkan perlakuan yang sama. Setiap perubahan pada template IaC, modul, dan file variabel harus dikomit ke version control dengan penanda yang jelas.

Ketika tim Anda memutuskan untuk melakukan rollback, mereka tidak perlu menebak konfigurasi mana yang terakhir berfungsi. Mereka harus bisa menunjuk ke commit atau tag tertentu dan berkata, "Yang itu." Pipeline kemudian menerapkan versi tersebut menggunakan file state yang sesuai dengan titik waktu itu.

Ini terdengar jelas, tetapi banyak tim memperlakukan konfigurasi infrastruktur sebagai "cukup deploy yang terbaru" tanpa menandai rilis. Ketika sesuatu rusak, mereka bergegas mencari commit terakhir yang diketahui baik, berharap tidak ada yang mendorong perubahan setengah jadi di antaranya.

Merencanakan Rollback Sebelum Anda Menerapkan

Waktu terbaik untuk merencanakan rollback adalah sebelum Anda menerapkan perubahan. Di pipeline Anda, simpan salinan state saat ini sebelum menjalankan langkah apply. Jika perubahan menyebabkan masalah, pipeline dapat segera menjalankan apply dengan state yang disimpan. Tidak perlu mencari-cari, tidak perlu menebak, tidak perlu langkah manual.

Rollback yang direncanakan sebelumnya ini dapat diotomatisasi. Setelah apply selesai, jalankan health check. Jika health check gagal, picu rollback secara otomatis. Tim Anda mendapat notifikasi, tetapi pemulihan sudah dimulai.

Misalnya, jika perubahan pada satu sumber daya seperti instance EC2 menyebabkan masalah, Anda dapat menargetkan sumber daya tersebut secara spesifik:

# Simpan state saat ini sebelum menerapkan perubahan apa pun
terraform state pull > state-backup-$(date +%Y%m%d-%H%M%S).json

# Terapkan konfigurasi sebelumnya hanya untuk sumber daya yang bermasalah
terraform apply -auto-approve -target=aws_instance.web

# Verifikasi rollback dengan health check
terraform output instance_health

Tidak semua perubahan infrastruktur dapat di-rollback dengan bersih. Menghapus volume database, mengubah skema jaringan yang bergantung pada sumber daya lain, atau memodifikasi layanan bersama—tindakan ini mungkin tidak meninggalkan jalur kembali yang bersih. Untuk perubahan seperti ini, Anda memerlukan strategi tambahan.

Ketika Rollback Tidak Cukup

Beberapa perubahan infrastruktur bersifat destruktif secara alami. Jika perubahan Anda menghapus volume database, melakukan rollback konfigurasi IaC tidak akan mengembalikan data. Volume tersebut hilang. File konfigurasi mengatakan seharusnya ada, tetapi sumber daya aktual sudah tidak ada lagi di penyedia cloud Anda.

Diagram alir berikut mengilustrasikan proses pengambilan keputusan ketika perubahan merusak produksi:

flowchart TD A[Perubahan merusak produksi] --> B{Dapatkah perubahan<br/>di-rollback dengan bersih?} B -->|Ya| C[Pulihkan state sebelumnya<br/>dari file state yang disimpan] B -->|Tidak| D{Apakah snapshot<br/>diambil sebelum perubahan?} D -->|Ya| E[Pulihkan dari snapshot<br/>lalu terapkan konfigurasi lama] D -->|Tidak| F{Apakah lingkungan lama<br/>masih berjalan?} F -->|Ya| G[Alihkan traffic kembali<br/>ke lingkungan lama] F -->|Tidak| H[Provision sumber daya baru<br/>dari konfigurasi baik terakhir] C --> I[Jalankan health check] E --> I G --> I H --> I I --> J{Apakah health check<br/>berhasil?} J -->|Ya| K[Pemulihan selesai] J -->|Tidak| L[Eskalasi ke<br/>engineer on-call]

Untuk kasus-kasus ini, Anda memerlukan strategi pemulihan yang melampaui rollback:

  • Ambil snapshot sebelum melakukan perubahan destruktif. Snapshot database yang diambil tepat sebelum migrasi skema memberi Anda titik fallback.
  • Gunakan deployment blue-green atau canary untuk infrastruktur. Pertahankan lingkungan lama tetap berjalan sampai Anda yakin lingkungan baru berfungsi.
  • Provision infrastruktur secara paralel daripada memodifikasi di tempat. Buat sumber daya baru di samping yang lama, lalu alihkan traffic saat siap.

Strategi ini menambah biaya dan kompleksitas, tetapi lebih murah daripada gangguan berkepanjangan.

Uji Rollback Anda

Rencana rollback yang belum pernah diuji bukanlah rencana. Itu hanya harapan.

Lakukan latihan rollback di lingkungan staging Anda. Terapkan perubahan, lalu picu rollback secara sengaja. Ukur berapa lama waktu yang dibutuhkan. Periksa apakah file state dipulihkan dengan benar. Verifikasi bahwa semua sumber daya kembali ke konfigurasi sebelumnya. Konfirmasi bahwa aplikasi berfungsi dengan benar setelah rollback.

Lakukan ini secara teratur. Setiap beberapa bulan, atau setiap kali pengaturan infrastruktur Anda berubah secara signifikan. Tujuannya bukan hanya untuk memverifikasi mekanisme berfungsi, tetapi untuk membangun kepercayaan diri tim Anda. Ketika produksi rusak pada jam 2 pagi, Anda ingin tim Anda tahu persis apa yang harus dilakukan, bukan membaca dokumentasi untuk pertama kalinya.

Setelah Rollback: Belajar dan Dokumentasikan

Setelah rollback selesai dan produksi stabil, pekerjaan sesungguhnya dimulai. Cari tahu apa yang salah. Apakah dependensi yang hilang? Penyimpangan konfigurasi antar lingkungan? Kondisi race dalam urutan apply?

Dokumentasikan insiden tersebut. Perubahan apa yang diterapkan? Apa yang rusak? Bagaimana terdeteksi? Berapa lama rollback berlangsung? Apa yang bisa membuatnya lebih cepat? Dokumentasi ini menjadi dasar untuk meningkatkan pipeline, pengujian, dan prosedur rollback Anda.

Daftar Periksa Praktis untuk Kesiapan Rollback Infrastruktur

  • File state disimpan secara remote dengan kontrol akses dan versioning
  • Setiap perubahan infrastruktur diberi tag versi di version control
  • Pipeline menyimpan state saat ini sebelum menerapkan perubahan
  • Health check otomatis berjalan setelah setiap apply
  • Rollback terpicu secara otomatis saat health check gagal
  • Perubahan destruktif memiliki strategi snapshot atau deployment paralel
  • Rollback diuji di staging setidaknya sekali per kuartal
  • Dokumentasi insiden dibuat dan ditinjau setelah setiap rollback

Intisari Konkret

Rollback infrastruktur bukanlah fitur yang ditambahkan kemudian. Ini adalah keputusan desain yang Anda buat dari awal. Rencanakan manajemen state Anda. Beri versi pada konfigurasi Anda. Otomatiskan jalur rollback. Uji sampai membosankan. Ketika produksi rusak, tim Anda seharusnya tidak mencari cara untuk pulih. Mereka harus menjalankan prosedur yang telah mereka lakukan puluhan kali sebelumnya, tahu persis berapa lama waktu yang dibutuhkan dan apa hasilnya.