DevOps engineer
DevOps engineer menggarap jarak antara commit yang sudah di-merge dan perubahan yang berjalan aman di produksi â pipeline yang membawanya, strategi deployment yang membatasi kerusakan sebuah rilis buruk, dan sinyal yang memberi tahu apakah rilis itu berhasil. Disiplinnya sama banyak berurusan dengan cara sebuah tim menata tanggung jawab seperti halnya dengan tool yang dijalankannya. Berikut cakupan perannya, masalah delivery yang membenarkan keberadaannya, dan bagaimana ia mengubah cara sebuah tim merilis perubahan.
Apa yang dikerjakan seorang DevOps engineer?
DevOps engineer membangun dan memelihara otomatisasi yang membawa software dari commit seorang developer sampai berjalan di sistem produksi, berikut umpan balik yang memberi tahu tim apa yang terjadi sesudahnya. Pekerjaannya mencakup continuous integration, otomatisasi build dan rilis, infrastruktur yang dinyatakan sebagai kode, strategi deployment yang membatasi jangkauan dampak sebuah perubahan buruk, monitoring dan alerting, serta keterlibatan dalam incident response. Tujuan disiplin ini adalah membuat rilis menjadi kecil, sering, dapat dibatalkan, dan tidak dramatis â dan itu adalah perubahan pada cara sebuah tim bekerja, bukan hanya pada apa yang dijalankannya.
Namanya sendiri menimbulkan kerancuan, karena DevOps bermula sebagai argumen tentang struktur organisasi, bukan sebagai nama jabatan. Klaimnya adalah bahwa memisahkan orang yang menulis software dari orang yang menjalankannya menghasilkan kegagalan yang bisa ditebak: serah terima yang kehilangan konteks, insentif yang saling tarik ke arah berlawanan, dan proses rilis yang berubah menjadi negosiasi. Menambah orang dengan jabatan itu tidak menyelesaikan argumen tersebut. Yang ia lakukan, ketika berhasil, adalah memberi tim seseorang yang bidangnya adalah aliran perubahan itu sendiri.
Sebagian besar nilainya datang dari memperkecil ukuran rilis dan memperbanyak frekuensinya. Rilis besar menumpuk risiko yang tidak bisa diatribusikan â ketika ada yang rusak, puluhan perubahan menjadi tersangka. Perubahan kecil yang rilis dalam hitungan menit dan bisa ditarik dalam hitungan menit pula punya permukaan kegagalan yang sempit, dan kemampuan menariknya mengubah apa yang berani dicoba sebuah tim. Strategi deployment, verifikasi otomatis, dan jalur kembali yang sudah dilatih adalah mekanisme yang membuat pendekatan ini terbayar, bukan kenyamanan yang ditempelkan di atasnya.
Separuh kedua dari peran ini dimulai setelah deployment. Harus ada yang memutuskan apa yang diukur, apa yang layak membangunkan seseorang, dan apa yang terjadi ketika alert itu berbunyi pukul tiga pagi. Alerting yang berbunyi terus-menerus melatih orang untuk mengabaikannya; alerting yang tidak pernah berbunyi biasanya berarti tidak ada hal penting yang sedang diawasi. Menjaga keseimbangan itu adalah pekerjaan yang tidak menarik dan tak pernah selesai, jarang muncul di deskripsi jabatan, dan secara andal memisahkan engineer berpengalaman dari pendatang yang cakap.
Kapan tim membutuhkan kapabilitas ini
Otomatisasi delivery biasanya dibangun oleh siapa pun yang paling membutuhkannya, di sela-sela pekerjaan fitur. Berikut tanda-tanda bahwa susunan yang terbentuk begitu saja itu tidak lagi bertahan.
Merilis telah menjadi sebuah acara
Deployment dilakukan pada jendela waktu terjadwal, mengikuti dokumen berisi langkah manual, dan menuntut orang berjaga kalau-kalau ada yang salah. Biayanya bukan malam yang terpakai. Semuanya mengantre di belakang jendela berikutnya, sehingga batch membesar dan setiap rilis membawa lebih banyak risiko tak terlacak dibanding rilis sebelumnya.
Environment tidak lagi mirip satu sama lain
Produksi menumpuk perubahan yang dilakukan manual dan tidak pernah dicatat, staging dikonfigurasi dari ingatan, dan "di staging jalan kok" berhenti menenangkan. Mereproduksi masalah produksi lalu memakan waktu lebih lama daripada memperbaikinya, yang diam-diam melipatgandakan biaya setiap cacat.
Pelanggan menemukan kegagalan lebih dulu daripada instrumentasi
Tim mengetahui adanya gangguan dari tiket dukungan pelanggan. Entah sinyalnya memang tidak ada, atau sinyalnya ada tetapi tidak dipercaya siapa pun karena kanal alert-nya sudah cukup lama berisik hingga dibisukan. Dari luar keduanya tampak identik dan menuntut penanganan berbeda.
Pipeline berubah menjadi penghambat
Continuous integration berjalan cukup lama sehingga engineer menumpuk pekerjaannya agar tidak menunggu, dan sebagian kegagalannya flaky alih-alih nyata. Suite yang terus dijalankan ulang orang sampai lolos berhenti berfungsi sebagai gerbang: ia memakan waktu dan tidak memberi jaminan apa pun.
Gerbang manual bertambah lebih cepat daripada yang dipensiunkan
Setiap insiden menambahkan satu persetujuan, satu checklist, atau satu tanda tangan, dan tidak ada yang dihapus sesudahnya. Prosesnya memakan jam kerja nyata dan memberi jaminan yang sebagian besar seremonial, karena orang yang menandatangani tidak benar-benar bisa menilai apa yang mereka setujui.
Jumlah service yang dirilis melampaui cara merilisnya
Susunan yang cocok untuk satu aplikasi menjadi tak terkelola untuk lima belas, masing-masing dengan pipeline yang ditulis sedikit berbeda oleh orang berbeda. Biaya marginal menambah satu service naik sampai tim menghindari membuatnya, bahkan ketika memecahnya sebenarnya desain yang lebih baik.
Kapabilitas inti
Continuous integration
Menjaga branch bersama tetap dalam keadaan yang bisa dirilis kapan saja: umpan balik cepat pada setiap perubahan, suite yang dipercaya karena deterministik, dan waktu build yang cukup singkat sehingga orang berintegrasi beberapa kali sehari alih-alih menumpuk divergensi seminggu.
Otomatisasi rilis dan deployment
Deploy tanpa penjagaan yang bisa diulang dengan jalur kembali yang terdefinisi. Rilis rolling, blue-green, dan canary, paparan bertahap di balik feature flag, verifikasi otomatis setelah perubahan aktif, serta rollback yang pernah dilatih alih-alih sekadar diasumsikan ada.
Infrastructure as code
Menyatakan server, jaringan, cluster, dan konfigurasinya sebagai definisi dalam version control, sehingga perubahan bisa direview dan diatribusikan. Disiplinnya lebih sedikit soal tool daripada soal menolak melakukan perubahan manual tanpa catatan justru ketika cara itu lebih cepat.
Promosi artefak dan kesetaraan environment
Build sekali per commit yang siap rilis dan mempromosikan artefak yang sama persis ke tahap berikutnya, dengan segala yang memang sah berbeda disuplai saat runtime. Build ulang untuk environment berikutnya menghasilkan artefak yang berbeda, artinya apa pun yang sudah diverifikasi sebelumnya diverifikasi pada sesuatu yang lain.
Monitoring dan alerting
Menentukan apa yang diukur, menetapkan ambang yang mencerminkan dampak yang dirasakan pengguna alih-alih pemakaian sumber daya, dan menjaga jumlah alert cukup sedikit sehingga setiap panggilan layak ditindaklanjuti. Desain on-call â rotasi, eskalasi, serah terima â termasuk dalam pekerjaan ini, bukan menyusul sesudahnya.
Target keandalan dan error budget
Menyatakan keandalan sebagai sasaran eksplisit alih-alih harapan, dan memakai sisa anggarannya untuk memutuskan apakah perubahan berikutnya sebaiknya berupa fitur atau perbaikan. Ini mengubah perdebatan tentang kehati-hatian menjadi angka yang sama-sama terbaca oleh engineering dan produk.
Secret di jalur delivery
Menjaga kredensial tetap keluar dari repositori, image, dan log build; memberi pipeline kredensial berumur pendek dengan cakupan sempit alih-alih kunci berumur panjang; serta menjadikan rotasi sebagai rutinitas, bukan sesuatu yang pertama kali dicoba saat insiden berlangsung.
Integritas build dan supply chain
Dependensi yang dipatok versinya, provenance yang mencatat apa yang dibangun dan dari commit mana, pemindaian image, dan penandatanganan bila model ancamannya menuntut. Pipeline yang memegang izin luas termasuk sasaran paling berharga di sebuah organisasi dan kerap paling sedikit dijaga.
Incident response dan pembelajarannya
Menjalankan insiden dengan peran yang terdefinisi dan satu jalur komunikasi yang jelas, lalu mengadakan tinjauan tanpa saling menyalahkan yang menghasilkan perubahan spesifik dengan pemilik yang disebut namanya. Tinjauan yang menyimpulkan bahwa orang harus lebih hati-hati telah mencatat sebuah harapan, bukan menemukan sebuah sebab.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam DevOps engineering. Daftar ini menggambarkan lanskap disiplinnya secara umum sebagaimana dipraktikkan di pasar, bukan klaim tentang perangkat yang dikuasai engineer mana pun. Desain pipeline, strategi deployment, dan pertimbangan soal alerting berpindah antartool ini jauh lebih mudah daripada yang disiratkan nama-nama tool tersebut.
Continuous integration dan delivery
- GitHub Actions
- GitLab CI
- Jenkins
- CircleCI
- Argo CD
- Flux
Container dan orchestration
- Docker
- Kubernetes
- Helm
- Podman
- containerd
Infrastruktur dan konfigurasi
- Terraform
- Pulumi
- Ansible
- Packer
- Kustomize
Monitoring dan alerting
- Prometheus
- Grafana
- Alertmanager
- Datadog
- PagerDuty
Log dan trace
- OpenTelemetry
- Loki
- Elastic Stack
- Jaeger
- Sentry
Secret dan supply chain
- HashiCorp Vault
- SOPS
- Sigstore
- Trivy
- Dependabot
Scripting dan otomatisasi
- Bash
- Python
- Go
- Make
- jq
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah tim engineering menghasilkan pekerjaan secara stabil tetapi merilisnya lambat. Deploy dijadwalkan, sebagian manual, dan dilatih sebelumnya, sementara environment sudah cukup jauh menyimpang sehingga pengujian di staging tidak lagi memprediksi apa yang akan terjadi di produksi. Tim tahu apa yang perlu diubah dan tidak punya ruang untuk mengubahnya selagi roadmap terus berjalan.
- Pendekatan
- Tambahan kapasitas engineering beroperasi di dalam proses yang sudah dijalankan tim â model branching yang dipakai, konvensi review yang dipegang tim, kontrol perubahan yang dituntut bisnisnya, dan prioritas yang ditetapkan dalam perencanaannya sendiri. Pekerjaan pipeline dan deployment dikerjakan berdampingan dengan engineer yang nanti akan memeliharanya, bukan diserahterimakan di akhir.
- Yang ditambahkan ke tim
- Tim tetap memegang wewenang atas arsitektur dan kebijakan rilisnya sambil memperoleh ruang untuk mengerjakan pekerjaan delivery yang selama ini tertunda. Akan menjadi seperti apa prosesnya diputuskan oleh engineer yang akan mengoperasikannya.
Disiplin terkait
Pertanyaan yang sering diajukan
- Apa bedanya DevOps engineer dan platform engineer?
- DevOps engineer menggarap aliran perubahan â rute yang ditempuh sebuah commit menuju produksi dan umpan balik yang kembali darinya â biasanya di dalam atau berdampingan dengan tim delivery. Platform engineer membangun produk internal untuk engineer lain: sebuah permukaan swalayan, dengan jalur-jalur yang ditopang dengan baik, yang dipakai bagian lain organisasi tanpa perlu memahami apa yang ada di bawahnya. Pembedanya adalah audiens dan keluaran. Pekerjaan DevOps dinilai dari seberapa aman dan seberapa sering perubahan sampai ke pengguna; pekerjaan platform dinilai dari apakah engineer lain bisa memperoleh yang mereka butuhkan tanpa bertanya kepada siapa pun.
- Apa bedanya DevOps engineer dan cloud engineer?
- Bidang seorang cloud engineer adalah lapisan penyedia layanan: topologi account dan jaringan, identity dan izin, pemilihan managed service, penataan yang menjaga sistem tetap tersedia ketika sebuah region gagal, dan berapa biaya menjalankan seluruh estate-nya. Bidang seorang DevOps engineer adalah proses delivery yang berjalan di atas infrastruktur apa pun yang ada, cloud maupun bukan. Di organisasi kecil satu orang lazim mengerjakan keduanya; seiring estate membesar keduanya memisah, karena kedalaman soal penyedia dan kedalaman soal delivery tidak lagi muat nyaman dalam satu pekerjaan.
- Apakah DevOps sebuah peran atau sebuah budaya?
- Keduanya, dan ketegangannya nyata alih-alih sekadar soal istilah. Sebagaimana awalnya diargumentasikan, ia menggambarkan cara membagi tanggung jawab, dengan orang yang sama membangun sekaligus menjalankan software alih-alih ada tembok antara dua kelompok. Sebagai nama jabatan, ia biasanya berarti engineer yang mengkhususkan diri pada otomatisasi yang membuat tanggung jawab bersama itu praktis. Menambahkan jabatannya tanpa mengubah cara tanggung jawab dibagi cenderung membangun kembali tembok yang sama di tempat baru, dengan satu orang berdiri di seberangnya.
- Apa bedanya monitoring dan observability?
- Monitoring menjawab pertanyaan yang sudah diputuskan seseorang untuk ditanyakan lebih dulu: apakah antreannya membesar, apakah error rate melewati ambang, apakah disk-nya penuh. Observability adalah sifat sebuah sistem yang memungkinkan Anda mengajukan pertanyaan yang tidak diantisipasi siapa pun â biasanya lewat trace, event terstruktur, dan atribut berkardinalitas tinggi yang bisa diiris setelah kejadian. Monitoring memberi tahu ada yang salah. Observability adalah yang Anda butuhkan ketika penyebabnya adalah kombinasi kondisi yang tidak akan pernah dibuatkan dashboard oleh siapa pun, dan itu menggambarkan sebagian besar gangguan yang sulit.
- Apakah DevOps engineer sebaiknya ikut on-call?
- Biasanya iya, dan sebaiknya tidak sendirian. Engineer yang tidak pernah memegang pager kehilangan umpan balik yang menjaga alerting tetap jujur, dan lama-lama membangun sistem yang nyaman di-deploy dan menyiksa untuk dioperasikan. Engineer yang memegangnya seorang diri menjadi satu-satunya ingatan organisasi tentang cara segala sesuatu bekerja, dan itu risiko pemusatan yang tumbuh diam-diam. Susunan yang lebih sehat memasukkan orang-orang yang membangun sebuah service ke dalam rotasinya, dengan spesialis delivery ikut berbagi beban itu alih-alih menyerapnya untuk semua orang.
- Mengapa peran ini gagal ketika berubah menjadi antrean tiket?
- Karena pekerjaannya lalu dioptimalkan untuk menutup permintaan alih-alih menghilangkan alasan permintaan itu muncul. Orang yang memproses permintaan environment, permintaan akses, dan penyuntingan pipeline satu per satu tidak punya kapasitas untuk membuat satu pun di antaranya tidak lagi diperlukan, dan antreannya tumbuh lebih cepat daripada terurai. Organisasi yang memperoleh hasil dari disiplin ini memperlakukan permintaan berulang sebagai cacat desain, yang berarti memberi seseorang izin untuk berhenti membereskan antrean cukup lama untuk memperbaikinya.
- Bagaimana DevOps engineer bekerja dengan tim engineering yang sudah ada?
- Mereka bekerja di dalam proses delivery Anda â pipeline Anda, runbook Anda, manajemen perubahan Anda, dan rotasi on-call Anda â dengan engineer Anda yang menetapkan prioritas dan mengarahkan pekerjaannya sehari-hari. Keputusan produk, roadmap, arsitektur, dan standar engineering tetap milik Anda. Talent.ID adalah pemberi kerjanya: hubungan kerja, benefit karyawan, payroll, dan administrasi talenta berada pada kami, beserta hubungan karyawan yang berkelanjutan.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.