Rencana Pemulihan untuk Perubahan Infrastruktur Berisiko Tinggi

Kamu akan melakukan perubahan yang berpotensi mengganggu produksi. Mungkin itu perombakan arsitektur jaringan, migrasi basis data, atau konfigurasi ulang security group yang menyentuh layanan kritis. Tim sudah meninjau rencana, menilai radius dampak, dan semua sepakat perubahan ini membawa risiko nyata.

Lalu?

Sebelum siapa pun menjalankan terraform apply atau menekan tombol deploy, kamu perlu rencana pemulihan. Bukan dokumen tebal yang hanya jadi pajangan. Tapi rencana praktis, spesifik, dan bisa dieksekusi untuk apa yang harus dilakukan jika terjadi kesalahan.

Mulai dengan Satu Pertanyaan

Seluruh rencana pemulihan dimulai dari satu pertanyaan: Jika perubahan ini gagal, apa yang perlu kita lakukan untuk mengembalikan semuanya ke kondisi aman?

Jawabannya tergantung pada apa yang kamu ubah dan seberapa jauh radius dampaknya. Perubahan konfigurasi sederhana pada satu security group mungkin punya jawaban pendek: terapkan ulang konfigurasi lama. Perubahan arsitektur jaringan atau migrasi basis data membutuhkan respons yang jauh lebih detail.

Jangan mempersulit. Rencana pemulihan harus proporsional dengan risikonya. Rencana lima baris sudah cukup untuk perubahan berisiko rendah. Runbook multi-langkah lebih cocok untuk sesuatu yang bisa menjatuhkan layanan inti.

Tiga Hal yang Harus Ada di Setiap Rencana Pemulihan

Rencana pemulihan yang berguna memiliki tiga komponen, dan semuanya harus eksplisit.

Langkah pemulihan yang konkret. "Kembalikan ke versi sebelumnya" bukanlah sebuah langkah. Tuliskan perintah persisnya, server tempat menjalankannya, parameter yang digunakan, dan cara memverifikasi bahwa pemulihan benar-benar berhasil. Jika seseorang harus SSH ke bastion host dan menjalankan perintah Terraform tertentu dengan file state tertentu, tuliskan itu. Jika mereka harus mengembalikan basis data dari snapshot, sertakan nama snapshot dan prosedur pemulihannya.

Berikut contoh konkret langkah pemulihan untuk perubahan security group di AWS:

# Recovery Plan: Revert Security Group Change
# Target: sg-12345678 (production web tier)

# Step 1: Revert security group rules
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# Step 2: Verify the rules are correct
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# Step 3: Confirm service is reachable
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

Siapa yang memutuskan untuk mengaktifkan pemulihan. Saat terjadi masalah, orang panik. Mereka mulai membuat keputusan sendiri. Ada yang ingin segera rollback. Ada yang ingin menyelidiki masalah lebih dulu. Kamu perlu satu orang atau peran yang punya wewenang untuk mengatakan "stop, kita lakukan pemulihan sekarang." Ini bukan proses demokrasi saat insiden. Sebutkan nama atau peran orang tersebut secara eksplisit dalam rencana.

Kapan rencana diaktifkan. Tidak semua kegagalan memicu pemulihan segera. Terkadang lebih baik membiarkan perubahan berjalan sementara tim menyelidiki. Tapi kamu perlu batasan yang jelas. Dua pendekatan umum yang berhasil:

  • Berbasis waktu: Jika sistem tidak stabil dalam 15 menit setelah perubahan diterapkan, mulai pemulihan.
  • Berbasis dampak: Jika tingkat error di atas 5 persen, atau jika pengguna melaporkan tidak bisa mengakses layanan, mulai pemulihan.

Tuliskan ambang batas ini. Jangan mengandalkan ingatan orang saat insiden terjadi.

Daftar Periksa Sebelum Menerapkan

Sebelum menerapkan perubahan berisiko tinggi, ada hal-hal yang harus sudah selesai dilakukan. Ini adalah daftar periksa pra-terapan, dan harus ada dalam rencana pemulihan.

Item umum meliputi:

  • Snapshot terbaru sudah diambil
  • File state infrastruktur sudah dicadangkan
  • Akses ke sistem pemulihan sudah dikonfirmasi
  • Anggota tim tahu peran mereka selama pemulihan
  • Saluran komunikasi untuk koordinasi insiden sudah dibuat

Daftar periksa ini ada karena kamu tidak bisa bersiap untuk pemulihan saat keadaan darurat. Jika kamu tidak mengambil snapshot sebelum perubahan, kamu tidak bisa memulihkan dari snapshot setelahnya. Jika kamu tidak mencadangkan file state, kamu tidak bisa rollback dengan percaya diri.

Diagram alir berikut menunjukkan alur lengkap dari tinjauan perubahan hingga pemeriksaan pra-terapan, penerapan, pemantauan, dan eksekusi pemulihan jika diperlukan.

flowchart TD A[Tinjau Perubahan] --> B[Pemeriksaan Pra-Terapan] B --> C[Terapkan Perubahan] C --> D[Pantau Sistem] D --> E{Sistem Stabil?} E -->|Ya| F[Perubahan Selesai] E -->|Tidak| G[Kaji Dampak] G --> H{Aktifkan Pemulihan?} H -->|Tidak| I[Lanjutkan Investigasi] H -->|Ya| J[Jalankan Perintah Pemulihan] J --> K[Verifikasi Pemulihan] K --> L[Sistem Pulih]

Daftar periksa pra-terapan juga berfungsi sebagai pemaksa. Ini membuat tim berhenti dan memastikan bahwa pemulihan benar-benar mungkin dilakukan sebelum membuat perubahan. Jika kamu tidak bisa mencentang semua item, jangan terapkan perubahan dulu.

Siapa yang Menyetujui Rencana Pemulihan

Untuk perubahan infrastruktur berisiko tinggi, rencana pemulihan perlu disetujui oleh seseorang yang memahami dampaknya dan memiliki wewenang untuk menerima risiko. Ini bisa berupa lead engineer, engineering manager, atau perwakilan dari tim yang akan terpengaruh oleh perubahan.

Jabatan tidak penting. Yang penting adalah pemberi persetujuan dapat mengevaluasi apakah rencana pemulihan sudah memadai atau masih ada celah. Mereka harus bisa mengajukan pertanyaan seperti "Apa yang terjadi jika rollback juga gagal?" atau "Bagaimana kita memverifikasi sistem sehat setelah pemulihan?"

Ini bukan stempel karet. Jika pemberi persetujuan tidak memahami rencana dengan cukup baik untuk menilainya, mereka tidak boleh menyetujuinya.

Simpan Rencana di Tempat yang Mudah Ditemukan

Rencana pemulihan tidak berguna jika tidak ada yang bisa menemukannya saat insiden. Jangan simpan di laptop pribadi. Jangan taruh di folder yang membutuhkan akses khusus. Jangan kubur di thread email panjang.

Letakkan rencana di lokasi bersama yang bisa diakses dengan cepat oleh semua pihak terkait. Wiki tim, drive bersama, atau bahkan sebagai file yang dilampirkan ke pull request yang berisi perubahan infrastruktur. Tujuannya adalah menghilangkan hambatan antara "terjadi kesalahan" dan "kami punya rencana di depan kami."

Daftar Periksa Praktis Singkat

Sebelum menerapkan perubahan infrastruktur berisiko tinggi, pastikan hal-hal berikut:

  • Langkah pemulihan ditulis dengan perintah dan parameter yang tepat
  • Satu orang tertentu ditunjuk untuk memutuskan kapan mengaktifkan pemulihan
  • Ambang batas waktu atau dampak untuk mengaktifkan pemulihan sudah ditentukan
  • Snapshot atau cadangan terbaru sudah dikonfirmasi tersedia
  • File state infrastruktur sudah dicadangkan
  • Semua anggota tim tahu peran mereka selama pemulihan
  • Rencana disimpan di lokasi yang dapat diakses semua pihak terkait
  • Seseorang yang berwenang telah meninjau dan menyetujui rencana

Ujian Sesungguhnya Terjadi Saat Eksekusi

Rencana pemulihan yang sudah disiapkan dan disetujui belum tentu sama dengan rencana pemulihan yang berhasil. Satu-satunya cara untuk tahu apakah rencana kamu kokoh adalah dengan mengujinya. Itu berarti menjalankan langkah pemulihan di lingkungan yang aman, memverifikasi bahwa perintah memberikan hasil yang diharapkan, dan memastikan tim bisa mengeksekusi rencana di bawah tekanan.

Tapi itu adalah topik untuk diskusi lain. Untuk saat ini, yang penting adalah memiliki rencana siap sebelum kamu menerapkan perubahan. Rencana pemulihan yang baik tidak menjamin semuanya berjalan mulus, tapi itu berarti kamu tidak akan membuat keputusan dalam kegelapan saat terjadi masalah.