Ketika Infrastruktur adalah Produk: Tata Kelola IaC dan Deteksi Drift

Bayangkan Anda bertanggung jawab atas ratusan atau ribuan server yang tersebar di berbagai penyedia cloud dan region. Perusahaan Anda mungkin adalah penyedia layanan cloud, platform e-commerce besar, atau perusahaan teknologi dengan infrastruktur yang diterapkan di Singapura, Frankfurt, dan Virginia secara bersamaan.

Dalam lingkungan seperti ini, infrastruktur bukan sekadar tempat aplikasi berjalan. Infrastruktur adalah produknya. Setiap perubahan konfigurasi—menambahkan aturan firewall, mengubah ukuran instance database, menyesuaikan parameter load balancer—dapat memengaruhi puluhan layanan sekaligus. Satu konfigurasi yang salah tidak hanya merusak satu aplikasi. Ia merusak ratusan layanan yang bergantung pada infrastruktur bersama tersebut.

Ini adalah dunia yang berbeda dari sekadar men-deploy satu aplikasi web. Taruhannya lebih tinggi, radius ledakannya lebih luas, dan margin kesalahan hampir nol.

Masalah Konsistensi yang Mengarah ke IaC

Ketika infrastruktur dikelola secara manual melalui sesi SSH atau dashboard cloud, inkonsistensi akan cepat muncul. Lingkungan staging Anda memiliki aturan firewall yang sedikit berbeda dari production. Setup production Anda di Asia berbeda dengan Eropa. Tidak ada yang bisa mengatakan dengan yakin konfigurasi apa yang sebenarnya berjalan saat ini.

Inilah saatnya tim beralih ke Infrastructure as Code (IaC). Anda menulis semua konfigurasi infrastruktur sebagai kode, menyimpannya di Git, dan menerapkannya secara otomatis melalui pipeline. Terraform, Pulumi, AWS CDK, atau CloudFormation menjadi alat utama Anda. Setiap server, aturan jaringan, dan bucket penyimpanan didefinisikan dalam version control.

Namun, menulis konfigurasi sebagai kode hanyalah langkah pertama. Setelah infrastruktur Anda hidup dalam kode, muncul pertanyaan baru: "Bagaimana cara memastikan setiap perubahan mengikuti kebijakan kami sebelum mencapai production?"

Tata Kelola IaC: Kebijakan Otomatis, Bukan Birokrasi

Tata kelola (governance) terdengar seperti kata yang memperlambat segalanya. Dalam praktiknya, tata kelola IaC justru sebaliknya. Ini adalah pagar pembatas otomatis yang memeriksa setiap perubahan sebelum masuk ke production, tanpa perlu manusia membaca setiap baris konfigurasi.

Begini cara kerjanya dalam praktik. Tim keamanan Anda memutuskan bahwa semua bucket penyimpanan harus dienkripsi. Tim kepatuhan (compliance) mewajibkan semua instance database menggunakan tipe instance tertentu. Tim jaringan Anda mensyaratkan bahwa tidak ada aturan firewall yang membuka port 22 atau 3306 ke internet publik.

Diagram berikut mengilustrasikan pipeline tata kelola otomatis dari commit kode hingga deployment dan deteksi drift:

flowchart TD A[Commit Kode IaC] --> B[Jalankan Pemeriksaan Kebijakan] B --> C{Kebijakan Lolos?} C -->|Ya| D[Deploy ke Infrastruktur] C -->|Tidak| E[Blokir Perubahan & Notifikasi] E --> A D --> F[Pantau Drift] F --> G{Drift Terdeteksi?} G -->|Tidak| H[Infrastruktur Stabil] G -->|Ya| I[Alert Tim] I --> J[Perbaiki Otomatis?] J -->|Ya| K[Sinkronkan ke State Kode] J -->|Tidak| L[Review Manual] K --> F L --> M[Update Kode atau Terima Drift] M --> A

Aturan-aturan ini ditulis sebagai kebijakan otomatis yang berjalan di dalam pipeline CI/CD Anda. Ketika seseorang mengirimkan pull request yang mengubah kode infrastruktur, pipeline tidak langsung menerapkan perubahan tersebut. Pipeline pertama-tama memeriksa setiap resource terhadap kebijakan Anda. Jika perubahan melanggar kebijakan, pipeline gagal. Perubahan tidak pernah mencapai production.

Sebagai contoh, berikut adalah aturan Open Policy Agent (OPA) sederhana yang menerapkan standar tagging, mewajibkan setiap resource memiliki tag cost-center:

package terraform

# Tolak resource apa pun yang tidak memiliki tag 'cost-center'
violation[msg] {
  resource := input.resource_changes[_]
  resource.type in ["aws_s3_bucket", "aws_instance", "aws_db_instance"]
  not resource.change.after.tags.cost-center
  msg := sprintf("%v %v tidak memiliki tag wajib 'cost-center'", [resource.type, resource.address])
}

Ketika kebijakan ini berjalan di pipeline CI/CD Anda, setiap perubahan resource yang tidak memiliki tag yang diperlukan akan menyebabkan pipeline gagal, mencegah infrastruktur yang salah konfigurasi untuk mencapai production.

Ini bukan tentang menambahkan gerbang persetujuan demi kendali semata. Ini tentang menangkap masalah sebelum menjadi insiden. Bucket penyimpanan yang salah konfigurasi sehingga dapat dibaca publik tidak akan menjadi kebocoran data. Instance database yang terlalu kecil tidak akan menyebabkan gangguan performa. Kebijakan menangkapnya di pipeline, dan tim memperbaikinya sebelum sempat berjalan.

Drift: Ketika Realitas Menyimpang dari Kode

IaC memberi Anda satu sumber kebenaran (single source of truth) untuk infrastruktur Anda. Namun kebenaran itu hanya berlaku jika apa yang sebenarnya berjalan sesuai dengan apa yang ada di kode Anda. Dalam praktiknya, keselarasan ini sering kali rusak.

Drift terjadi ketika konfigurasi infrastruktur di dunia nyata berbeda dari yang didefinisikan dalam kode IaC Anda. Seseorang login ke dashboard cloud saat insiden dan mengubah aturan security group secara manual. Seorang anggota tim menambahkan listener load balancer langsung melalui konsol karena dibutuhkan segera. Proses otomatis dari tim lain memodifikasi resource tanpa melalui pipeline Anda.

Drift berbahaya karena membuat IaC Anda tidak dapat dipercaya. Jika kode Anda mengatakan server memiliki konfigurasi A, tetapi kenyataannya memiliki konfigurasi B, maka pemulihan, penskalaan, atau pembuatan lingkungan baru akan menghasilkan hasil yang tidak terduga. Anda tidak dapat membangun ulang infrastruktur dari kode jika kode tidak sesuai dengan kenyataan.

Deteksi drift memecahkan masalah ini dengan secara periodik membandingkan keadaan infrastruktur aktual Anda dengan kode. Pipeline menjalankan perintah yang sama yang digunakan untuk menerapkan infrastruktur, tetapi dalam mode "plan" atau "preview". Ia tidak mengubah apa pun. Ia hanya membandingkan. Ketika menemukan perbedaan, ia melaporkannya.

Beberapa tim melangkah lebih jauh. Ketika drift terdeteksi, pipeline dapat secara otomatis menyelaraskan infrastruktur kembali ke keadaan yang didefinisikan kode. Yang lain lebih memilih untuk memberi tahu tim yang bertanggung jawab dan membiarkan mereka memutuskan apakah akan memperbarui kode atau menerima drift sebagai sesuatu yang disengaja.

Menangani Perubahan Berisiko Tinggi

Beberapa perubahan infrastruktur membawa risiko lebih besar dari yang lain. Mengubah konfigurasi database production, memodifikasi aturan firewall yang memengaruhi lalu lintas utama, atau mengubah load balancer yang melayani jutaan permintaan—semua ini memerlukan perhatian ekstra.

Untuk perubahan ini, Anda memerlukan lebih dari sekadar kebijakan otomatis. Anda memerlukan proses persetujuan terintegrasi yang terjadi di dalam pipeline, bukan di luarnya. Alur kerjanya terlihat seperti ini:

  1. Seorang pengembang membuat pull request dengan perubahan infrastruktur.
  2. Kebijakan otomatis berjalan dan memeriksa pelanggaran.
  3. Jika kebijakan lolos, pipeline memberi tahu reviewer yang relevan—mungkin DBA untuk perubahan database, atau network engineer untuk perubahan firewall.
  4. Reviewer menyetujui atau meminta perubahan langsung di pull request.
  5. Hanya setelah semua persetujuan terpenuhi, perubahan diterapkan.

Poin utamanya adalah bahwa persetujuan tidak berarti memperlambat. Ini berarti melibatkan orang yang tepat untuk meninjau perubahan yang tepat pada waktu yang tepat, dengan semua konteks tersedia di pipeline. Tidak perlu mengejar orang di chat. Tidak ada persetujuan di menit-menit terakhir sebelum jendela rilis ditutup.

Daftar Periksa Praktis untuk Tata Kelola IaC

  • Tulis kebijakan otomatis untuk setiap aturan keamanan dan kepatuhan yang berlaku untuk infrastruktur Anda
  • Jalankan pemeriksaan kebijakan di pipeline Anda sebelum perubahan infrastruktur apa pun diterapkan
  • Siapkan deteksi drift untuk berjalan secara terjadwal (harian atau mingguan tergantung toleransi risiko Anda)
  • Putuskan apakah akan memperbaiki drift secara otomatis atau memberi tahu tim
  • Tentukan perubahan mana yang memerlukan persetujuan tambahan dan siapa yang menjadi penyetuju
  • Jadikan persetujuan sebagai bagian dari pipeline, bukan proses terpisah di luarnya

Kesimpulan

Ketika infrastruktur adalah produk Anda, konsistensi dan kendali bukanlah opsional. IaC memberi Anda fondasi, tetapi tata kelola dan deteksi drift mengubah fondasi itu menjadi sesuatu yang dapat Anda percaya. Kebijakan otomatis menangkap masalah sebelum mencapai production. Deteksi drift memberi tahu Anda ketika realitas telah menyimpang dari kode Anda. Dan persetujuan terintegrasi memastikan bahwa perubahan berisiko tinggi mendapatkan perhatian yang tepat tanpa menjadi hambatan.

Tujuannya bukan untuk memperlambat perubahan infrastruktur. Tujuannya adalah membuatnya cukup aman sehingga Anda dapat bergerak cepat tanpa rasa takut.