Belajar DevOps Engineer - Peran, Filosofi & Sejarah
DevOps bukan sekadar tools, melainkan budaya, praktik, dan filosofi yang lahir dari gerakan Agile pada 2009; di episode ini kalian memahami asal-usulnya, framework CALMS, dan DORA metrics sebagai tolak ukur kinerja tim software
#Pendahuluan
Setelah di episode 0 kita menyiapkan environment — Linux, Git, Docker, dan akun cloud — pada episode ini kita berhenti sejenak dari hands-on untuk memahami mengapa DevOps ada. Banyak yang mengira DevOps cukup dengan menginstall Jenkins dan menyebut diri DevOps Engineer. Kenyataannya, DevOps adalah jawaban atas masalah manusia dan organisasi yang jauh lebih tua daripada nama "DevOps" itu sendiri.
Mengapa penting memahami sejarah dan filosofinya? Karena tanpa ini, kalian hanya akan menjadi operator tools — bukan engineer. Ketika nanti tim kalian berdebat soal "harus pakai tool apa", pemahaman tentang mengapa dan untuk siapa akan menjaga keputusan tetap di jalur.
#Sejarah: dari Waterfall ke DevOps
#Era Waterfall: Tembok antara Dev dan Ops
Sebelum tahun 2000-an, software dikembangkan dengan model Waterfall: requirements → design → implement → test → deploy. Setiap fase selesai baru fase berikutnya dimulai. Rilis butuh waktu berbulan-bulan, dan ada tembok besar antara tim development (yang menulis kode) dan tim operations (yang menjalankannya di server). Keduanya punya target yang berseberangan: Dev mau perubahan cepat, Ops mau stabilitas mutlak.
#Gerakan Agile (2001): Mempercepat Sisi Kiri
Manifesto Agile (2001) memecah proses menjadi iterasi pendek dengan umpan balik cepat dari pelanggan. Masalahnya: Agile hanya mempercepat sisi pengembangan — sisi deployment tetap lambat. Hasilnya aneh: tim bisa menyelesaikan sprint dalam dua minggu, lalu menunggu dua bulan untuk rilis karena antrean operasional.
#Lahirnya DevOps (2009)
Titik baliknya adalah presentasi "10+ Deploys Per Day" oleh John Allspaw dan Paul Hammond (2009), dan pertemuan DevOpsDays pertama di Belgia pada tahun yang sama. Istilah DevOps dipopulerkan oleh Patrick Debois dari penggabungan Development dan Operations. Gagasannya sederhana namun revolusioner: hapus tembok antar tim, satukan tujuan, dan otomasi seluruh jalur dari kode ke produksi.
| Era | Ciri Utama | Frekuensi Rilis |
|---|---|---|
| Waterfall | Fase berurutan, Dev dan Ops terpisah | Bulanan sampai tahunan |
| Agile | Iterasi pendek, masih ada antrean ops | Mingguan sampai bulanan |
| DevOps (2009+) | Otomasi penuh, Dev dan Ops kolaboratif | Harian bahkan per-jam |
#Definisi DevOps
DevOps adalah budaya + praktik + tools yang menyatukan development dan operations untuk mengirim software lebih cepat, andal, dan berkelanjutan. Tiga kata kunci:
- Budaya: menghapus silo, berbagi tujuan, dan tanggung jawab bersama atas kualitas.
- Praktik: CI/CD, otomasi, IaC, monitoring, dan feedback loop yang cepat.
- Tools: Git, container, orchestrator, pipeline, observability — semua hanya pendukung dua poin di atas.
Important
Urutannya selalu orang → proses → tools, bukan sebaliknya. Membeli tools DevOps tanpa mengubah budaya hanyalah "DevOps theater": pipeline tetap ada, tapi tembok antar tim tidak hilang. Di episode 26 kita lihat bagaimana 2026 menuntut hal yang sama di level platform.
#Filosofi: Framework CALMS
Untuk menilai seberapa DevOps sebuah organisasi, gunakan akronim CALMS:
| Huruf | Kepanjangan | Arti Praktis |
|---|---|---|
| C | Culture | Kolaborasi dan trust antar tim, bukan saling lempar tanggung jawab |
| A | Automation | Mengotomasi pekerjaan berulang dan rawan error |
| L | Lean | Mengurangi waste, memperkecil batch, mempercepat flow |
| M | Measurement | Mengukur semuanya: lead time, frekuensi deploy, waktu recovery |
| S | Sharing | Berbagi knowledge, tool, dan tanggung jawab on-call |
CALMS bukan sekadar hafalan. Ia adalah checklist untuk mengevaluasi setiap keputusan: apakah praktik ini meningkatkan kolaborasi? Apakah mengurangi pekerjaan manual? Apakah bisa diukur?
#DORA Metrics: Mengukur DevOps
Pada 2014, DORA (DevOps Research and Assessment, kini bagian dari Google Cloud) memulai riset akumulasi data tentang apa yang membuat tim software "elite". Hasilnya empat metrik yang kini menjadi standar industri:
- Deployment Frequency — seberapa sering deploy ke produksi.
- Lead Time for Changes — waktu dari commit kode sampai jalan di produksi.
- Change Failure Rate — persentase deploy yang menyebabkan kegagalan.
- Mean Time to Restore (MTTR) — waktu yang dibutuhkan pulih dari insiden.
Temuan kunci DORA: tim elite deploy banyak kali per hari dengan lead time kurang dari satu hari, change failure rate rendah, dan recovery cepat. Yang menarik, tidak ada korelasi positif antara kecepatan dan instabilitas — tim cepat justru lebih stabil karena otomasi membuat perubahannya kecil dan bisa di-rollback. Kita akan memakai metrik ini lagi di episode 25 dan 26.
#Peran DevOps Engineer di Dunia Nyata
Sebagai DevOps Engineer, tanggung jawab kalian umumnya mencakup:
- Merancang dan memelihara pipeline CI/CD yang cepat dan dapat diandalkan.
- Mengelola infrastruktur sebagai kode (IaC) untuk environment yang konsisten.
- Menjaga observability agar setiap kegagalan bisa dideteksi dan dilacak.
- Mengotomasi provisioning, deployment, dan recovery.
- Menjadi jembatan antara developer, tim operasi, dan keamanan.
Jangan salah sangka: DevOps Engineer tetap menulis kode — hanya saja kodenya adalah pipeline, infrastruktur, dan alat bantu yang membuat developer lain produktif.
#Penutup
Pada episode 1 ini, kalian telah memahami bahwa DevOps adalah jawaban atas tembok antara development dan operations, bukan sekadar nama job title.
Inti yang harus dibawa pulang:
- DevOps lahir sekitar 2009 dari gerakan Agile dan ide deploy harian.
- DevOps = budaya + praktik + tools; urutannya selalu orang → proses → tools.
- CALMS adalah framework untuk mengevaluasi kedewasaan DevOps sebuah tim.
- DORA metrics (frekuensi deploy, lead time, change failure rate, MTTR) adalah standar pengukuran kinerja.
Di episode 2 selanjutnya kita akan membedah arsitektur dan siklus hidup DevOps — alur Plan → Code → Build → Test → Release → Deploy → Operate → Monitor, serta bagaimana komponen source control, CI/CD, environment, artifact registry, dan observability saling terhubung. Pastikan pemahaman filosofinya sudah kuat, karena praktik di episode-episode berikutnya berdiri di atasnya.