Mengapa Anda Harus Merencanakan Perubahan Infrastruktur Sebelum Menerapkannya

Anda sedang meninjau sebuah pull request yang mengubah satu baris di file konfigurasi firewall. Perubahan tersebut membuka port 443 untuk lalu lintas publik. Sederhana, bukan?

Namun, satu baris itu bisa memiliki konsekuensi yang tidak Anda duga. Mungkin ada aturan lain yang bertentangan dengannya. Mungkin port tersebut sengaja ditutup karena alasan keamanan enam bulan lalu, dan tidak ada yang ingat alasannya. Mungkin membukanya akan memutus koneksi database yang selama ini dirutekan melalui port yang berbeda. Anda tidak akan tahu semua ini sampai setelah perubahan diterapkan dan sesuatu berhenti berfungsi.

Inilah situasi yang dirancang untuk dicegah oleh workflow plan-review-apply.

Masalah dengan Penerapan Langsung

Ketika Anda menerapkan perubahan infrastruktur secara langsung, Anda bekerja secara buta. Anda mungkin memiliki kode di depan Anda, tetapi kode saja tidak menunjukkan apa yang sebenarnya akan terjadi ketika kode tersebut dijalankan di lingkungan live Anda. Keadaan infrastruktur Anda yang sebenarnya bisa berbeda dari apa yang diasumsikan oleh kode Anda. Mungkin seseorang telah melakukan perubahan manual minggu lalu. Deployment sebelumnya mungkin meninggalkan sesuatu dalam keadaan yang tidak terduga. Kode Anda mengatakan "tambahkan aturan ini," tetapi sistem mungkin mengartikannya sebagai "ganti semua aturan yang ada dengan yang ini."

Penerapan langsung mengubah setiap perubahan menjadi sebuah perjudian. Anda hanya tahu apakah Anda kalah ketika semuanya rusak.

Bagaimana Plan-Review-Apply Bekerja

Workflow ini memiliki tiga tahap, dan masing-masing memiliki tujuan spesifik.

Diagram di bawah mengilustrasikan alurnya:

flowchart TD A[Start: Code Change] --> B[Plan: Generate Diff] B --> C[Review: Human Checks Plan] C -->|Approved| D[Apply: Execute Changes] C -->|Rejected| B D --> E[End]

Plan menghasilkan perbandingan detail antara keadaan infrastruktur Anda saat ini dan keadaan yang ingin dibuat oleh kode Anda. Ini menunjukkan dengan tepat apa yang akan ditambahkan, dimodifikasi, atau dihapus. Ini bukan ringkasan atau tebakan. Ini adalah diff infrastruktur yang presisi dan dihasilkan oleh mesin.

Review adalah tempat manusia memeriksa rencana tersebut. Anda memeriksa kejutan. Anda memverifikasi bahwa rencana tersebut sesuai dengan maksud perubahan. Anda menangkap hal-hal seperti "penghapusan grup keamanan ini akan mempengaruhi server produksi" sebelum seseorang menekan tombol apply.

Apply mengeksekusi perubahan yang telah direncanakan. Karena rencana sudah diverifikasi, langkah apply memiliki risiko hasil yang tidak terduga yang jauh lebih rendah. Anda tidak lagi menebak-nebak. Anda mengeksekusi serangkaian perubahan yang sudah diketahui.

Seperti Apa Bentuk Rencana Sebenarnya

Sebuah rencana bukanlah deskripsi yang samar. Ini adalah daftar operasi yang konkret. Sebagai contoh, sebuah rencana mungkin menunjukkan:

  • Menambahkan aturan grup keamanan baru untuk port 443
  • Memodifikasi listener load balancer yang ada untuk menggunakan sertifikat baru
  • Menghapus grup subnet database yang sudah tidak direferensikan

Setiap operasi menyertakan pengidentifikasi sumber daya, nilai saat ini, dan nilai baru. Tingkat detail ini memungkinkan Anda melihat masalah sebelum terjadi. Anda mungkin melihat bahwa rencana tersebut ingin menghapus sumber daya yang Anda kira tidak digunakan, atau memodifikasi pengaturan yang bergantung pada tim lain.

Menjadikan Rencana sebagai Persyaratan Mutlak

Tim yang paling efektif memperlakukan rencana sebagai langkah yang tidak dapat dinegosiasikan. Pipeline mereka dikonfigurasi untuk berhenti jika tidak ada rencana yang dibuat, atau jika rencana tersebut belum ditinjau dan disetujui. Ini adalah padanan infrastruktur dari mewajibkan code review sebelum menggabungkan pull request. Anda tidak akan menggabungkan kode yang belum ditinjau ke produksi. Mengapa Anda menerapkan perubahan infrastruktur yang belum ditinjau?

Guardrail ini mencegah pola kegagalan yang paling umum: seseorang membuat perubahan kecil, menganggapnya aman, dan menerapkannya tanpa memeriksa. Pipeline memaksa mereka untuk membuat rencana terlebih dahulu, yang seringkali mengungkapkan sesuatu yang tidak mereka duga.

Rencana sebagai Jejak Audit

Rencana memiliki tujuan kedua yang menjadi kritis ketika terjadi kesalahan. Setiap rencana dapat disimpan sebagai artefak di pipeline Anda. Ini menciptakan catatan historis dari setiap perubahan infrastruktur: apa yang berubah, kapan berubah, dan siapa yang menyetujuinya.

Ketika insiden produksi terjadi, catatan itu sangat berharga. Alih-alih bertanya-tanya untuk mencari tahu siapa yang mengubah apa, Anda melihat artefak rencana. Anda dapat melihat diff persis yang diterapkan tepat sebelum masalah dimulai. Ini mengubah investigasi insiden dari tebak-tebakan menjadi analisis berbasis bukti.

Tanpa rencana yang disimpan, Anda hanya memiliki log manual, pesan chat, dan ingatan. Tidak satu pun dari itu yang dapat diandalkan ketika Anda mencoba men-debug pemadaman produksi pada jam 2 pagi.

Menangani Perubahan yang Bersamaan

Tim yang bekerja pada infrastruktur yang sama menghadapi tantangan lain: perubahan yang saling bertentangan. Dua orang memodifikasi file konfigurasi jaringan pada waktu yang sama. Kedua perubahan terlihat baik secara terpisah. Namun ketika digabungkan, mereka menciptakan konflik yang dapat memutus konektivitas.

Langkah rencana menangkap ini. Ketika orang kedua membuat rencana, itu akan menunjukkan konflik sebelum perubahan apa pun diterapkan. Tim dapat menyelesaikan konflik dalam kode, bukan di produksi. Ini jauh lebih aman daripada menerapkan kedua perubahan dan berharap keduanya tidak berinteraksi secara buruk.

Apa yang Tidak Dipecahkan oleh Rencana

Plan-review-apply sangat kuat, tetapi memiliki keterbatasan. Ini hanya dapat membandingkan apa yang dikatakan kode Anda dengan apa yang dilaporkan infrastruktur Anda saat ini. Jika seseorang melakukan perubahan manual di luar pipeline Anda, rencana mungkin tidak menangkap setiap ketidakkonsistenan. Jika penyedia infrastruktur Anda memiliki bug atau perilaku yang tidak terduga, rencana mungkin menunjukkan sesuatu yang berbeda dari apa yang sebenarnya dieksekusi.

Kasus-kasus tepi ini tidak membatalkan workflow. Itu hanya berarti Anda memerlukan praktik tambahan di sampingnya, seperti deteksi drift dan rekonsiliasi rutin antara kode Anda dan infrastruktur live Anda.

Daftar Periksa Praktis

Sebelum Anda menerapkan plan-review-apply di pipeline Anda, pertimbangkan poin-poin ini:

  • Hasilkan rencana secara otomatis setelah setiap pull request yang digabungkan, bukan hanya berdasarkan permintaan
  • Simpan setiap rencana sebagai artefak pipeline dengan stempel waktu dan metadata persetujuan
  • Blokir apply jika tidak ada rencana atau jika rencana belum ditinjau
  • Tinjau rencana untuk kejutan sebelum menyetujui, bukan hanya untuk kebenaran
  • Gunakan rencana selama investigasi insiden sebagai sumber kebenaran pertama Anda untuk perubahan terbaru

Ide Inti

Plan-review-apply mengubah perubahan infrastruktur dari perjudian buta menjadi operasi yang terhitung dan terverifikasi. Rencana menunjukkan apa yang akan terjadi sebelum terjadi. Review menangkap masalah sebelum mencapai produksi. Apply mengeksekusi hanya apa yang telah diverifikasi. Workflow ini tidak menghilangkan semua risiko, tetapi menghilangkan risiko menerapkan perubahan tanpa mengetahui dampak penuhnya.

Jika tim Anda masih menerapkan perubahan infrastruktur secara langsung, mulailah dengan satu aturan sederhana: buat rencana terlebih dahulu, bacalah, dan baru kemudian putuskan apakah akan menerapkannya. Kebiasaan tunggal itu akan mencegah lebih banyak masalah produksi daripada kebanyakan alat monitoring.