Ketika Infrastruktur Anda Menyimpang dari Kode

Anda telah mendefinisikan seluruh infrastruktur di Terraform. Setiap security group, ukuran instance, dan parameter database ditulis dalam kode dan di-deploy melalui pipeline. Anda yakin bahwa apa yang ada di repositori cocok dengan yang berjalan di production. Lalu suatu hari, Anda menjalankan plan dan melihat perubahan yang tidak pernah Anda duga. Resource yang tidak Anda sentuh akan dimodifikasi. Ada perbedaan antara kode Anda dan kenyataan.

Perbedaan itu memiliki nama: drift.

Apa Arti Drift Sebenarnya

Drift adalah celah antara apa yang seharusnya ada menurut kode infrastruktur Anda dan apa yang benar-benar ada di cloud provider atau server. File Terraform atau Pulumi Anda mendefinisikan desired state. Resource yang berjalan di AWS, Google Cloud, atau Azure mewakili actual state. Ketika keduanya tidak cocok, Anda mengalami drift.

Kedengarannya sederhana, tetapi implikasinya dalam. Infrastructure as Code bekerja dengan asumsi kritis: bahwa kode Anda adalah satu-satunya sumber kebenaran untuk bagaimana semuanya harus dikonfigurasi. Asumsi itu hanya berlaku ketika setiap perubahan pada infrastruktur melewati pipeline Anda. Saat sesuatu berubah di luar pipeline itu, asumsi tersebut rusak.

Tiga Cara Drift Menyusup

Drift tidak muncul karena seseorang melakukan kesalahan. Drift muncul karena infrastruktur dikelola oleh orang sungguhan di bawah tekanan nyata.

Diagram di bawah menunjukkan bagaimana setiap jalur melewati pipeline IaC yang dimaksud dan menyebabkan drift.

flowchart TD A[Jalur yang Dimaksud: Pipeline IaC] --> B[Desired State dalam Kode] C[Perubahan Manual di Console] --> D[Modifikasi langsung] D --> E[Drift] F[Respon Insiden] --> G[Perubahan darurat] G --> E H[Tools Eksternal / Autoscaler] --> I[Perubahan otomatis di luar pipeline] I --> E B -.->|Tidak ada drift| J[Actual State Cocok dengan Kode] E --> K[Actual State != Kode]

Perubahan Manual

Seseorang login ke cloud console dan melakukan perubahan secara langsung. Mungkin mereka menambahkan aturan security group agar tim mereka bisa mengakses server dari IP kantor baru. Mungkin mereka mengubah ukuran instance karena ada demo yang akan datang dan mereka butuh kapasitas lebih. Perubahan itu memakan waktu tiga puluh detik di console. Memperbarui kode Terraform, membuat pull request, menunggu review, menjalankan pipeline — itu memakan waktu lebih lama. Jadi mereka melewatkannya.

Ini bukan kemalasan. Ini adalah respons rasional terhadap sistem yang membuat perubahan kecil menjadi mahal. Tetapi setiap perubahan langsung di console menciptakan celah antara kode dan kenyataan.

Respon Insiden

Ketika production down, tidak ada yang membuka pull request terlebih dahulu. Tim langsung masuk ke console atau CLI dan melakukan perubahan apa pun yang diperlukan untuk memulihkan layanan. Mereka menambah kapasitas instance. Mereka mengubah batas koneksi database. Mereka menonaktifkan feature flag melalui dashboard cloud.

Perubahan darurat ini benar secara operasional. Prioritasnya adalah memulihkan layanan, bukan menjaga kemurnian infrastruktur. Namun setelah insiden selesai, kode IaC jarang diperbarui untuk mencerminkan apa yang terjadi. Tim beralih ke kebakaran berikutnya, dan drift tetap ada.

Tools dan Proses Eksternal

Tidak semua drift berasal dari tindakan manusia. Autoscaler menambah dan menghapus instance berdasarkan beban. Tools keamanan menerapkan kebijakan melalui mekanisme terpisah. Sistem manajemen secret memutar kredensial secara otomatis. Tools manajemen konfigurasi memperbarui parameter di luar pipeline IaC Anda.

Ini adalah proses otomatis yang sah. Mereka menjaga infrastruktur Anda tetap berjalan dan aman. Tetapi mereka juga menciptakan celah antara apa yang didefinisikan oleh kode Terraform Anda dan apa yang sebenarnya berjalan.

Mengapa Drift Penting

Sedikit drift mungkin tidak menyebabkan masalah langsung. Aplikasi Anda tetap berjalan. Pengguna Anda tidak menyadari apa pun. Namun drift terakumulasi, dan akumulasi itu menciptakan risiko nyata.

Masalah paling langsung adalah kepercayaan. Ketika Anda menjalankan Terraform plan, Anda berharap hanya melihat perubahan yang Anda inginkan. Tetapi jika drift ada, plan menunjukkan modifikasi yang tidak terduga. Resource yang tidak Anda sentuh akan dikembalikan ke keadaan yang ditentukan kode. Aturan security yang ditambahkan seseorang secara manual? Itu akan dihapus pada apply berikutnya. Perubahan ukuran instance akibat insiden? Itu akan di-rollback.

Ini berbahaya karena Anda mungkin tidak tahu apa yang akan Anda rusak. Plan yang menunjukkan perubahan pada resource yang tidak Anda maksud untuk dimodifikasi seharusnya menghentikan Anda untuk melakukan apply. Namun dalam praktiknya, tim yang tertekan mungkin tetap menyetujui plan, dengan asumsi perubahannya tidak berbahaya. Kadang benar. Kadang tidak.

Masalah yang lebih dalam adalah bahwa drift membuat infrastruktur Anda tidak dapat diprediksi. Anda tidak bisa dengan percaya diri melakukan perubahan karena Anda tidak tahu apa keadaan sebenarnya saat ini. Setiap deployment menjadi perjudian. Apakah pipeline akan bekerja dengan benar? Apakah akan mengembalikan perubahan kritis yang dilakukan selama insiden? Apakah akan merusak sesuatu yang telah berjalan baik selama berbulan-bulan?

Drift Bukan Tanda Kegagalan

Penting untuk dipahami bahwa drift bukan bukti tim yang ceroboh. Ini adalah konsekuensi alami dari mengelola infrastruktur dengan banyak orang, prioritas yang bersaing, dan tekanan waktu yang bervariasi. Setiap tim yang menjalankan infrastruktur production mengalami drift. Perbedaan antara tim yang menangani dengan baik dan tim yang kesulitan bukanlah apakah drift ada. Tetapi apakah mereka tahu bahwa drift itu ada dan memiliki cara untuk mendeteksinya.

Tim yang mengabaikan drift pada akhirnya kehilangan kepercayaan pada seluruh pipeline deployment mereka. Mereka berhenti mempercayai plan. Mereka mulai membuat lebih banyak perubahan manual karena mereka tidak percaya pada otomatisasi. Infrastruktur menjadi kotak hitam yang tidak ingin disentuh siapa pun.

Tim yang mengakui drift membangun deteksi ke dalam alur kerja mereka. Mereka menjalankan pemeriksaan drift secara teratur. Mereka memiliki proses untuk merekonsiliasi kode dengan kenyataan. Mereka memperlakukan drift sebagai bagian normal dari manajemen infrastruktur, bukan kegagalan yang harus disembunyikan.

Daftar Periksa Deteksi Drift Praktis

Jika Anda mengelola infrastruktur dengan IaC, berikut adalah daftar periksa singkat untuk mulai menangani drift:

  • Jalankan plan terhadap lingkungan production setidaknya seminggu sekali, bahkan ketika Anda tidak melakukan deployment apa pun. Tinjau output untuk perubahan yang tidak terduga.
  • Siapkan deteksi drift otomatis. Sebagian besar tools IaC memiliki fitur atau integrasi yang dapat memperingatkan Anda ketika actual state berbeda dari desired state.
  • Setelah setiap insiden, jadwalkan waktu untuk memperbarui kode IaC Anda agar sesuai dengan perubahan darurat yang dilakukan.
  • Dokumentasikan tools dan proses eksternal mana yang memodifikasi infrastruktur di luar pipeline Anda. Ketahui perubahan apa yang terjadi secara otomatis dan mengapa.
  • Ketika Anda melihat drift dalam plan, selidiki sebelum melakukan apply. Pahami apa yang menyebabkan perbedaan dan apakah mengembalikannya aman.

Apa Selanjutnya

Drift tidak hanya menciptakan sakit kepala operasional. Drift membuat output dari tools perencanaan IaC Anda tidak dapat diandalkan. Ketika Anda menjalankan plan terhadap infrastruktur yang mengalami drift, hasilnya bisa menyesatkan. Anda mungkin melihat perubahan yang tampak aman tetapi sebenarnya mengembalikan konfigurasi kritis. Atau Anda mungkin melewatkan perubahan yang seharusnya dilakukan karena plan tidak menunjukkan apa yang Anda harapkan.

Bahaya sebenarnya adalah bahwa drift mengikis fondasi kepercayaan yang membuat Infrastructure as Code berharga. Tanpa kepercayaan pada pipeline Anda, Anda kehilangan keyakinan untuk membuat perubahan dengan cepat dan aman. Dan keyakinan itulah inti dari mengotomatiskan infrastruktur Anda.