Menguji Perubahan Infrastruktur Tanpa Mengganggu Produksi
Seorang pengembang melakukan perubahan kecil pada aturan firewall. "Hanya penyesuaian konfigurasi kecil," pikirnya. Beberapa menit kemudian, tidak ada yang bisa mengakses aplikasi. Pengguna mulai melaporkan error. Tim panik mencari tahu apa yang terjadi.
Skenario ini lebih sering terjadi daripada yang diakui sebagian besar tim. Perubahan infrastruktur menyimpan risiko tersembunyi. Kesalahan konfigurasi database dapat merusak data. Perubahan kebijakan jaringan dapat mengisolasi seluruh layanan. Dan tidak seperti kode aplikasi, masalah infrastruktur sering kali berdampak pada semuanya sekaligus.
Pertanyaan yang perlu dijawab setiap tim: di mana Anda menguji perubahan infrastruktur sebelum mencapai produksi?
Masalah Lingkungan untuk Infrastruktur
Ketika tim mengelola server secara manual, jawabannya biasanya tidak jelas. Beberapa memiliki server pengujian. Yang lain mengubah produksi secara langsung karena "hanya perubahan konfigurasi kecil." Perubahan kecil pada infrastruktur jarang berdampak kecil.
Aplikasi memiliki jawaban alami untuk masalah ini: lingkungan staging. Anda menguji fitur baru di staging, memverifikasi bahwa itu berfungsi, lalu deploy ke produksi. Infrastruktur membutuhkan pendekatan yang sama, tetapi dengan sedikit perbedaan.
Anda tidak selalu bisa menyalin infrastruktur secara persis. Memutar server, jaringan, dan database duplikat membutuhkan biaya nyata. Lingkungan staging yang mencerminkan pengaturan produksi dengan puluhan server, load balancer, dan klaster database dapat melipatgandakan tagihan infrastruktur Anda. Tantangannya adalah menemukan keseimbangan antara pengujian menyeluruh dan pengelolaan biaya.
Prinsip Inti: Isolasi Sebelum Menguji
Setiap perubahan infrastruktur harus melalui lingkungan terisolasi sebelum menyentuh produksi. Isolasi di sini bersifat ketat: lingkungan staging tidak boleh berbagi sumber daya apa pun dengan produksi. Tidak ada database bersama. Tidak ada jaringan bersama. Tidak ada akses ke data pengguna nyata.
Jika staging dan produksi Anda masih berbagi server atau berada di VPC yang sama, itu bukan isolasi. Kesalahan di staging dapat merambat ke produksi. Database staging yang salah konfigurasi dapat menimpa data produksi. Aturan jaringan bersama dapat mengekspos layanan staging ke lalu lintas produksi.
Isolasi saja tidak cukup. Lingkungan staging harus mereplikasi konfigurasi produksi semirip mungkin. Jika produksi menjalankan tiga server di belakang load balancer, staging harus memiliki pengaturan yang sama. Jika produksi menggunakan versi database tertentu, staging harus cocok.
Tujuannya bukan membuat staging sekuat produksi. Tujuannya adalah menangkap masalah yang hanya muncul dengan konfigurasi tertentu. Kueri database yang berfungsi baik di instance staging kecil mungkin timeout di produksi saat dibebani. Aturan jaringan yang lolos di pengaturan sederhana mungkin memblokir lalu lintas yang sah di topologi nyata.
Lapisan Lingkungan Praktis
Sebagian besar tim akhirnya memiliki beberapa lapisan lingkungan infrastruktur. Setiap lapisan memiliki tujuan berbeda dan trade-off berbeda antara biaya dan ketepatan.
Lingkungan development untuk pengembang menguji perubahan kecil. Ini dapat menggunakan sumber daya minimal dan konfigurasi yang disederhanakan. Satu server kecil alih-alih klaster. Database lokal alih-alih pengaturan replikasi. Persyaratan utamanya adalah isolasi dari staging dan produksi. Lingkungan development tidak boleh menyentuh sumber daya produksi, bahkan secara tidak sengaja.
Lingkungan staging untuk pengujian terintegrasi. Ini harus mencerminkan konfigurasi produksi semirip mungkin, meskipun skalanya lebih kecil. Versi sistem operasi yang sama. Versi runtime yang sama. Topologi jaringan yang sama. Perbedaannya biasanya pada kapasitas: lebih sedikit server, instance lebih kecil, penyimpanan lebih sedikit. Tetapi pola konfigurasi harus cocok.
Lingkungan produksi menjalankan layanan yang sebenarnya. Perubahan mencapai sini hanya setelah berhasil melewati development dan staging.
Diagram di bawah menunjukkan bagaimana perubahan mengalir melalui setiap lapisan lingkungan, dengan gerbang validasi mencegah perubahan yang belum terverifikasi mencapai produksi.
Perangkap Konfigurasi
Satu detail yang sering menjebak banyak tim: konfigurasi khusus lingkungan. Kata sandi database, kunci API, dan alamat server jelas berbeda antar lingkungan. Tetapi konfigurasi lainnya harus tetap konsisten.
Versi sistem operasi harus sama di semua lingkungan. Versi runtime harus cocok. Aturan logging harus identik. Ketika ini berbeda antar lingkungan, Anda menciptakan celah di mana masalah dapat bersembunyi. Bug yang hanya muncul di versi OS tertentu mungkin tidak pernah muncul di staging jika staging menggunakan versi berbeda.
Solusinya adalah memisahkan konfigurasi berdasarkan jenis. Nilai khusus lingkungan masuk ke file terpisah per lingkungan. Konfigurasi umum ditulis sekali dan diterapkan di mana-mana. Ketika Anda meningkatkan versi sistem operasi, Anda mengubahnya di satu tempat, bukan tiga file berbeda.
Bagaimana CI/CD Mengelola Lingkungan Infrastruktur
Pipeline untuk perubahan infrastruktur mengikuti urutan yang jelas:
- Tinjau perubahan melalui code review atau alat perencanaan
- Terapkan perubahan ke staging secara otomatis
- Jalankan tes untuk memverifikasi sumber daya dibuat dengan benar
- Validasi bahwa sumber daya yang ada tidak rusak
- Terapkan perubahan yang sama ke produksi
Setiap langkah terjadi melalui alat infrastructure-as-code yang sama. Rencana Terraform yang sama, playbook Ansible yang sama, program Pulumi yang sama dijalankan terhadap staging terlebih dahulu. Jika lolos, maka dijalankan terhadap produksi.
Proses ini memastikan setiap perubahan infrastruktur melalui lingkungan yang mencerminkan produksi sebelum memengaruhi pengguna nyata. Pipeline menegakkan disiplin yang sering dilewati oleh proses manual.
Daftar Periksa Praktis untuk Lingkungan Infrastruktur
- Staging berada di VPC atau akun terpisah dari produksi
- Staging tidak memiliki akses ke database atau penyimpanan produksi
- Staging menggunakan versi OS dan runtime yang sama dengan produksi
- Konfigurasi umum didefinisikan sekali dan dibagikan antar lingkungan
- Nilai khusus lingkungan diisolasi dalam file terpisah
- Pipeline menerapkan perubahan ke staging terlebih dahulu, lalu produksi
- Tes dijalankan setelah penerapan staging untuk memverifikasi kebenaran
Apa Selanjutnya
Menguji perubahan infrastruktur di lingkungan terisolasi menangkap sebagian besar masalah sebelum mencapai produksi. Tetapi tidak menangkap semuanya. Perubahan yang berfungsi sempurna di staging mungkin masih menyebabkan masalah ketika diterapkan ke produksi dalam skala besar atau di bawah pola lalu lintas nyata.
Di sinilah kebijakan dan tata kelola berperan. Langkah selanjutnya adalah mendefinisikan aturan tentang perubahan apa yang diizinkan, siapa yang dapat menyetujuinya, dan kondisi apa yang harus dipenuhi sebelum deployment produksi. Tapi itu adalah topik untuk artikel lain.
Untuk saat ini, kesimpulan konkretnya adalah ini: jika perubahan infrastruktur Anda langsung menuju produksi tanpa melalui lingkungan staging terisolasi, Anda hanya berjarak satu penyesuaian konfigurasi kecil dari gangguan produksi. Siapkan lingkungan terlebih dahulu. Biarkan pipeline menegakkan disiplin. Pengguna Anda akan berterima kasih.