DevOps lahir dari masalah lama: tim development ingin merilis secepat mungkin, tim operations ingin sistem tetap stabil, dan dua keinginan itu sering bertabrakan. DevOps adalah upaya menghapus dinding di antara keduanya, dengan cara membuat proses rilis begitu otomatis dan begitu terukur sehingga cepat dan stabil berhenti jadi pilihan yang saling meniadakan.
DevOps Bukan Sekadar Daftar Tools
Ini poin yang paling sering disalahpahami. Banyak orang mengira jadi DevOps Engineer berarti menghafal Docker, Kubernetes, dan Terraform. Padahal seseorang bisa fasih memakai ketiganya dan tetap menghasilkan sistem yang rapuh.
Inti pekerjaannya adalah memperpendek umpan balik. Berapa lama dari kode ditulis sampai jalan di production? Berapa lama sampai kita tahu ada yang rusak? Berapa lama untuk mengembalikannya? Tools hanyalah cara menjawab tiga pertanyaan itu.
Konsekuensinya, sebagian besar pekerjaan DevOps sebenarnya bersifat sosial: menyepakati standar, menulis dokumentasi yang dibaca orang, dan membuat jalur yang benar jadi jalur yang paling mudah ditempuh. Kemampuan menjelaskan dengan sabar sering lebih menentukan daripada kemampuan menulis YAML.
Fondasi yang Benar-benar Dipakai
Urutan di bawah ini disusun dari yang paling sering terpakai. Godaan terbesar pemula adalah melompat ke Kubernetes sebelum paham Linux, dan itu berakhir dengan bisa menyalin perintah tanpa tahu apa yang terjadi saat perintahnya gagal.
Linux. Ini fondasi yang tidak bisa dilewati. Bukan sekadar hafal perintah, tapi paham model prosesnya, izin file, bagaimana koneksi jaringan dibuat, dan bagaimana membaca log. Saat sesuatu rusak pukul dua pagi, yang menyelamatkan Anda adalah kemampuan membaca journalctl, ss, df, dan top, bukan dashboard.
Jaringan. DNS, HTTP, TLS, port, firewall, dan proxy. Porsi sangat besar dari masalah production sebenarnya adalah masalah jaringan yang menyamar jadi masalah aplikasi. Memahami apa yang terjadi antara mengetik alamat dan halaman muncul akan terbayar berkali-kali.
Git. Bukan cuma add, commit, push. Pahami branching, rebase, cara membaca riwayat, dan cara memulihkan keadaan saat ada yang salah.
Scripting. Bash untuk pekerjaan kecil yang menempel ke sistem, Python untuk yang lebih rumit. Patokan praktis: kalau skrip Bash Anda sudah melewati lima puluh baris dan mulai butuh struktur data, saatnya pindah ke Python.
Container. Docker dulu, sampai betul-betul paham perbedaan image dan container, cara kerja layer, dan cara data dipertahankan. Kubernetes menyusul setelahnya, dan hanya kalau memang ada kebutuhannya.
CI/CD. GitHub Actions atau GitLab CI adalah titik masuk yang paling mudah karena menempel langsung ke repository.
Infrastructure as Code. Terraform untuk menyediakan infrastruktur, Ansible untuk mengatur konfigurasi di dalamnya. Prinsipnya satu: keadaan server harus bisa dibaca dari berkas di repository, bukan dari ingatan seseorang.
Cloud. Pilih satu, pelajari sampai dalam. AWS punya pangsa pasar terbesar, tapi konsep antar penyedia sebagian besar bisa dipindahkan. Menguasai satu dengan baik jauh lebih berharga daripada mengenal tiga secara dangkal.
Observability. Prometheus untuk metrik, Grafana untuk visualisasi, dan satu tempat terpusat untuk log. Sistem yang tidak bisa diamati adalah sistem yang tidak bisa Anda perbaiki dengan percaya diri.
Urutan Belajar yang Masuk Akal
Alih-alih mengumpulkan sertifikat, bangun satu proyek dan perdalam bertahap. Alur berikut memaksa Anda menyentuh hampir semua hal di atas dengan urutan yang wajar:
- Sewa satu VPS termurah. Pasang Linux, kencangkan SSH, aktifkan firewall.
- Pasang aplikasi web sederhana secara manual. Rasakan repotnya.
- Pasang Nginx sebagai reverse proxy, tambahkan sertifikat TLS.
- Bungkus aplikasinya dengan Docker. Bandingkan dengan cara manual tadi.
- Tambahkan database dalam Compose, lengkap dengan volume dan healthcheck.
- Buat pipeline CI yang menjalankan test pada setiap dorongan.
- Lanjutkan pipeline itu sampai bisa deploy otomatis.
- Tambahkan pemantauan dan peringatan. Matikan aplikasinya dengan sengaja, pastikan Anda benar-benar diberi tahu.
- Tulis ulang penyediaan servernya dengan Terraform. Hancurkan seluruh infrastruktur, lalu bangun lagi dari nol.
Langkah kesembilan itu yang paling berharga. Kalau Anda bisa menghapus semuanya dan membangunnya kembali hanya dari kode di repository, Anda sudah memahami inti Infrastructure as Code.
Soal Sertifikasi
Sertifikasi cloud membantu melewati saringan HR dan memberi struktur belajar. Yang tidak bisa dilakukan sertifikasi adalah membuktikan Anda mampu menangani insiden.
Kalau harus memilih, ambil satu sertifikasi cloud tingkat dasar sebagai rangka belajar, lalu habiskan sisa waktu membangun sesuatu yang nyata. Dalam wawancara, cerita tentang bagaimana Anda pernah salah konfigurasi lalu memperbaikinya jauh lebih berbobot daripada daftar lencana.
Hal yang Sering Dilewatkan Pemula
Backup yang tidak pernah diuji. Backup yang belum pernah dipulihkan statusnya sama dengan tidak punya backup. Jadwalkan uji pemulihan.
Mengejar kerumitan terlalu dini. Kubernetes untuk satu aplikasi dengan dua ratus pengunjung per hari adalah beban perawatan tanpa imbalan. Pilih perkakas yang sepadan dengan masalahnya.
Mengabaikan biaya. Di cloud, arsitektur adalah keputusan finansial. Insinyur yang bisa memangkas tagihan bulanan separuh tanpa mengurangi keandalan akan selalu dicari.
Menyimpan secret di repository. Ini kesalahan klasik yang masih terjadi setiap hari. Pakai secret manager, dan pasang pemindai secret di CI sebagai jaring pengaman.
Otomatisasi tanpa pemahaman. Menyalin konfigurasi dari internet sampai berhasil jalan akan terasa produktif, sampai tiba hari ketika konfigurasi itu berhenti jalan dan Anda tidak tahu harus mulai dari mana.
Menyiapkan Diri untuk Wawancara
Pertanyaan yang paling sering muncul biasanya berbentuk skenario, bukan hafalan. Misalnya: sebuah situs tiba-tiba lambat, dari mana Anda mulai mencari? Atau: deploy terakhir merusak production, apa langkah pertama Anda?
Jawaban yang bagus menunjukkan cara berpikir yang runut. Sebutkan bagaimana Anda mempersempit kemungkinan, data apa yang Anda lihat lebih dulu, dan kapan Anda memutuskan untuk rollback alih-alih terus mencari penyebab. Untuk pertanyaan kedua, jawaban terbaik hampir selalu dimulai dengan memulihkan layanan dulu, baru menyelidiki setelahnya.
Siapkan juga satu cerita tentang kesalahan yang pernah Anda buat, beserta apa yang berubah setelahnya. Pewawancara yang berpengalaman mencari orang yang bisa jujur soal kegagalan, karena di bidang ini kegagalan pasti terjadi.