Pengujian diterapkan pada infrastruktur

Sudah sekitar sepuluh tahun sejak dunia operasi… banyak berubah. Dengan munculnya Infrastruktur sebagai Kode, kami telah mengadopsi praktik-praktik pengembangan, seperti membuat versi kode kami, melakukan peninjauan, mengotomatiskan penerapan, menyiapkan saluran CI/CD… Infrastruktur yang kami kenal saat ini lebih bersifat industrial dan lebih kolaboratif.

Namun saat baru-baru ini bekerja dengan pengembang pada proyek klien, saya menyadari. Kita masih kehilangan satu elemen penting. Di antara para pengembang, ada tes. Baik kesatuan, integrasi atau end-to-end, mereka adalah bagian dari kehidupan sehari-hari mereka. Anda tidak dapat membayangkan mengirimkan fitur baru tanpa rangkaian pengujian untuk memastikan tidak ada yang rusak.

Jadi mengapa kita tidak melakukan hal yang sama di pihak Ops? Mengapa praktik pengujian tidak mengikuti jalur yang sama seperti pembuatan versi atau otomatisasi? Apakah ini budaya, karena kita tidak pernah belajar melakukan hal sebaliknya? Apakah ini terlalu mahal, karena pengujian infrastruktur sering kali memerlukan penerapannya? Atau apakah kita meyakinkan diri sendiri bahwa “jika diterapkan, itu karena berhasil”?

Pertanyaan ini menarik perhatian saya dan saya yakin inilah saatnya untuk menjawabnya. Karena jika kita benar-benar ingin “mengembalikan praktik-praktik baik mulai dari pembangunan hingga infrastruktur”, kita harus melakukan yang terbaik, belajar juga, dan mengujinya.

Menguji di dunia dev, jelas?

Dalam dunia pengembangan perangkat lunak, pengujian bukanlah suatu pilihan. Setiap developer tahu bahwa menulis kode tanpa tes seperti melompat keluar dari pesawat tanpa parasut (sedikit metafora tapi saya tidak punya apa-apa lagi saat ini haha). Pengujian memungkinkan untuk mendeteksi kesalahan dengan cepat, memvalidasi perilaku yang diharapkan, dan yang terpenting menghindari regresi ketika fungsi baru ditambahkan atau setelah pemfaktoran ulang.

Umumnya ada beberapa tingkat pengujian.

Ada pengujian unit, yang memeriksa fungsionalitas atau aturan bisnis yang terisolasi.

Tes integrasi, yang memvalidasi bahwa blok bangunan bisnis berfungsi baik dengan infrastruktur.

Pengujian end-to-end (E2E), yang menyimulasikan skenario lengkap dari sudut pandang pengguna, dari awal hingga akhir.

Piramida tes ini sudah menjadi standar. Di banyak tim, bahkan diintegrasikan langsung ke dalam rantai pengiriman berkelanjutan (CI/CD). Komit secara otomatis memicu pelaksanaan pengujian: jika salah satu pengujian gagal, kode tidak dapat dikirimkan (biasanya).

Dengan semua ini, pengembang mendapatkan keuntungan dari umpan balik yang sangat singkat. Mereka dengan cepat mengetahui jika suatu perubahan merusak sesuatu. Dan menurut saya hal ini memungkinkan mereka untuk bergerak maju lebih cepat, lebih percaya diri, dan mencoba pendekatan ketika ragu. Semua yang Anda perlukan untuk memaksimalkan keberhasilan suatu proyek.

Namun di sisi lain, refleks ini masih jauh dari tercapai… dan di sinilah kontrasnya menjadi menarik.

Mengapa tes di sisi Ops hilang?

Jika kita melihat dari sisi Ops, praktik pengujian masih jauh dari kata sistematis (atau bahkan tidak ada). Tidak seperti pengembang, kami tidak tumbuh dengan praktik ini. Beberapa alasan dapat menjelaskan perbedaan ini.

Pertama, ada kisah budaya, meskipun sangat bervariasi dari satu perusahaan ke perusahaan lainnya. Beberapa tim telah lama menerapkan ketahanan, kinerja, uji beban, dll., sering kali ditulis oleh arsitek dan dilaksanakan oleh Ops. Namun di sebagian besar lingkungan yang saya temui, praktik ini tetap merupakan pengecualian dan bukan aturan. Saya mendapat kesan bahwa secara historis, peran Ops terutama berfokus pada ketersediaan dan stabilitas sistem. Kami melakukan konfigurasi, kami memantau, kami melakukan intervensi jika terjadi insiden. Gagasan “menguji secara sistematis” apa yang kami terapkan tidak bersifat umum, bertentangan dengan apa yang kami temukan di sisi pengembangan.

Kemudian, saya melihat kendala teknis dan ekonomi. Menguji aplikasi “hanya” membutuhkan waktu, CPU, dan memori. Menguji infrastruktur jauh lebih sulit. Anda harus menerapkan komponen nyata (jaringan, mesin virtual, database, penyeimbang beban, dll.), oleh karena itu bayar tagihan terkait. Ini mewakili waktu dan uang.

Tapi bukan itu saja, sepanjang proyek yang bisa saya kerjakan, saya perhatikan juga ada ilusi kepercayaan diri. Kami berkata pada diri sendiri, jika penerapannya berhasil, itu karena infrastrukturnya bagus. Namun pada kenyataannya, “berhasil diterapkan” tidak berarti sistem tersebut memenuhi harapan fungsional kami atau aman. Berapa kali kita menemukan dalam produksi bahwa port dibiarkan terbuka, aturan IAM memberikan terlalu banyak izin, atau layanan tidak merespons titik akhir yang benar?

Dan yang terakhir adalah kurangnya kesadaran. Dalam pelatihan dan budaya Ops, gagasan pengujian otomatis hampir tidak pernah dibahas. Kita belajar menulis Bash, Terraform, atau Ansible, tetapi jarang bertanya pada diri sendiri “bagaimana saya bisa yakin bahwa saya tidak akan melakukan regresi pada perubahan selanjutnya pada kode saya?”

Pengujian sering kali dilihat sebagai “hal” yang diperuntukkan bagi pengembang. Dan justru visi inilah yang harus diubah.

Ubah paradigma?

Jika kita benar-benar ingin memprofesionalkan dan menjadikan praktik infrastruktur kita lebih andal, inilah saatnya untuk mengintegrasikan pengujian ke dalam Operasi harian kita.

Tanpa pengujian, kesalahan konfigurasi atau aturan keamanan yang buruk sering kali hanya ditemukan di produksi, terkadang dalam keadaan darurat. Sedangkan dengan pengujian otomatis, kami dapat mendeteksi masalah ini jauh lebih awal, misalnya saat diterapkan ke lingkungan yang bersifat sementara.

Saat ini kita harus melihat infrastruktur sebagai komponen aplikasi. Ini terus berkembang, baik dengan memperbarui modul Terraform, menambahkan sumber daya, mengubah versi penyedia, dll. Setiap modifikasi mengandung risiko. Pengujian otomatis berfungsi sebagai perlindungan. Mereka akan memastikan bahwa apa yang berhasil kemarin masih berhasil hari ini.

Selain itu, arsitektur menjadi semakin besar, semakin kompleks, tim Operasi tidak mampu lagi “menguji dengan tangan”. Beban kognitifnya terlalu besar. Mengotomatiskan pengujian tidak hanya menjadi praktik yang baik, namun juga suatu keharusan untuk memastikan keandalan infrastruktur.

Di luar aspek teknis semata, mengadopsi pengujian di sisi Operasi juga berarti memfasilitasi kolaborasi dengan pengembang. Kami berbagi praktik yang sama, kami mengintegrasikan pengujian kami ke dalam CI/CD dan kami memperkuat budaya DevOps.

Komentar penguji l’infra ?

Anda mungkin berpikir bahwa pengujian infrastruktur itu rumit. Namun, sudah ada alat dan pendekatan yang dapat memberikan ketelitian. Idenya bukanlah untuk menguji semuanya sekaligus, namun untuk mengadopsi pendekatan progresif, dimulai dari dasar kemudian berlanjut ke pengujian yang lebih lanjut.

Bagi saya, cara termudah untuk menyiapkannya adalah dengan menggunakan alat seperti validasi Terraform, tflint, kube-linter, atau ansible-lint. Mereka memungkinkan Anda memeriksa sintaksis, konsistensi, dan kepatuhan terhadap praktik terbaik tanpa perlu menerapkan apa pun. Pengujian ini cepat, murah, dan sudah sangat efektif dalam menghindari kesalahan ketik, sumber daya yang buruk, bidang yang hilang, dll. Namun kami melihatnya secara teratur, dan kurang lebih sudah diadopsi.

Oke, langkah kedua, uji bata infra kita secara terpisah. Untuk melakukan ini, blok pengujian terraform memungkinkan Anda menerapkan modul atau tumpukan yang dikurangi, lalu memeriksa perilakunya. Misalnya, kami akan dapat memastikan bahwa bucket S3 dibuat dengan kebijakan enkripsi yang benar, atau bahwa grup keamanan tidak membuka port yang tidak diperlukan. Kami juga dapat melengkapi pendekatan ini dengan SAST (misalnya Checkov, tfsec, atau SonarQube) untuk mendeteksi kerentanan keamanan secara langsung dalam kode dan tanpa penerapan. Dari perspektif tata kelola, kita juga dapat berbicara tentang alat Kebijakan sebagai Kode seperti OPA atau Kyverno yang memungkinkan verifikasi otomatis bahwa infrastruktur mematuhi aturan yang ditentukan oleh organisasi.

Langkah ketiga dan terakhir, uji infrastruktur secara keseluruhan. Kami menerapkan lingkungan sementara lalu meluncurkan serangkaian pengujian yang memvalidasi perilaku yang diharapkan. hal ini dapat dilakukan untuk memeriksa apakah penyeimbang beban merespons pada port 443 dengan sertifikat yang valid, untuk menguji apakah database hanya dapat diakses dari jaringan internal… Dan lebih jauh lagi, beberapa tim juga menggunakan praktik chaos engineering untuk memastikan bahwa infrastruktur tetap tangguh dalam menghadapi simulasi kegagalan atau degradasi.

Perubahan budaya yang nyata terjadi ketika pengujian ini secara langsung ditentukan dalam “definisi selesai” dan diintegrasikan ke dalam jalur penerapan. Setiap penggabungan pada cabang “dilindungi” (misalnya) atau setiap rilis baru memicu:

1. Le linting
2. Menyebarkan lingkungan fana
3. Menjalankan tes unit dan E2E
4. Penghancuran lingkungan + verifikasi bahwa sumber daya telah hancur total

Pengujian menjadi otomatis dan sistematis, sama seperti pengujian aplikasi.

Tantangan yang harus diatasi?

Membangun budaya pengujian di dunia infrastruktur adalah hal yang penting, namun Anda pasti tahu apa yang mereka katakan, “lebih mudah diucapkan daripada dilakukan”. Saya telah mengidentifikasi beberapa hal yang mungkin memperlambat penerapannya.

Menyebarkan aplikasi pengujian relatif ringan (dari apa yang saya lihat di berbagai proyek). Menyebarkan infrastruktur pengujian bisa memakan biaya yang besar, hal ini memerlukan penyesuaian lingkungan sementara yang tepat dan memikirkan penghancuran otomatis infrastruktur tersebut di akhir pengujian untuk menghindari kejutan yang tidak menyenangkan pada tagihan di akhir bulan (jika diterapkan di cloud, di lokasi kita mungkin mengalami masalah dengan sumber daya yang tersedia).

Untuk meluncurkan rangkaian pengujian E2E pada infrastruktur, Anda harus mengatur penerapan, pelaksanaan pengujian, validasi hasil, dan kemudian penghancuran. Semua ini harus sesuai dengan jalur pipa yang sudah ada, yang terkadang memerlukan cukup banyak rekayasa.

Banyak orang Ops yang belum melihat pengujian sebagai bagian integral dari pekerjaan mereka (saya duluan, tapi saya mencoba untuk berubah, saya janji!). Dari apa yang saya lihat dalam beberapa tahun terakhir, budayanya masih sangat “penyebaran dan eksploitasi”, dan kurang “validasi”. Hal ini memerlukan kerja akulturasi, pelatihan dan pendidikan untuk meyakinkan bahwa investasi tersebut menguntungkan.

Banyak tim telah memiliki infrastruktur yang besar, terkadang bahkan heterogen, dengan warisan yang sulit untuk diotomatisasi. Memperkenalkan tes pada archi seperti itu mungkin tampak sulit. Solusinya adalah melakukan secara bertahap, dimulai dengan batu bata baru, kemudian memperluas ke batu bata yang sudah ada seiring berjalannya waktu.

Kesimpulan

Tidak menguji berarti menerima untuk menemukan masalah dalam produksi. Dan terkadang kesakitan. Sebaliknya, pengujian berarti memberi diri Anda sarana untuk mengurangi putaran umpan balik, mencegah regresi, dan menghadapi setiap perubahan dengan percaya diri.

Jadi harus mulai dari mana? Tidak perlu mengincar kesempurnaan sejak awal (mentalitas Kaizen seperti yang dikatakan seorang YouTuber terkenal). Mulailah dengan menyiapkan linting jika Anda belum melakukannya. Tambahkan beberapa pengujian unit pada modul Terraform Anda misalnya dan integrasikan skenario end-to-end secara bertahap ke dalam pipeline Anda.
Pertanyaan lain yang perlu ditanyakan adalah, “Seberapa penting aplikasi atau layanan tersebut?” Kebutuhan pengujian tidak akan sama bergantung pada apakah Anda menerapkan lingkungan dev atau prod. Mendefinisikan SLI (Indikator Tingkat Layanan) dan SLO (Tujuan Tingkat Layanan) membantu membingkai tingkat pengujian yang diharapkan. Semakin penting suatu layanan, semakin kuat cakupan dan ketelitian pengujiannya.