Meningkatkan kinerja Engineering sebagai bagian dari proses DevOps dapat berdampak luas pada seluruh bisnis. Merampingkan siklus hidup pengembangan dan menghilangkan hambatan akan berfungsi untuk mempercepat kinerja bisnis secara keseluruhan — pada akhirnya meningkatkan laba. Dan jika Anda berpikir, sebagai seorang insinyur DevOps, bahwa Anda tidak perlu peduli dengan kinerja bisnis, Anda salah.
Menurut DevOps Research and Assessment (DORA), tim DevOps berkinerja tinggi secara konsisten mengungguli pesaing mereka dalam empat bidang utama:
- Frekuensi penerapan: Istilah ini mengacu pada seberapa sering teknisi Anda dapat menerapkan kode. Meningkatkan kinerja sejalan dengan penerapan beberapa kali per hari sesuai keinginan.
- Lead time: Lead time adalah berapa lama waktu yang Anda butuhkan untuk mulai dari melakukan kode baru hingga menjalankan kode tersebut di lingkungan produksi. Performa tertinggi, menurut DevOps Research and
- Assessment DORA, memiliki lead time di bawah satu jam, sedangkan performer rata-rata membutuhkan waktu hingga satu bulan.
- MTTR (Mean Time to Recover): MTTR mengacu pada berapa lama waktu yang Anda butuhkan untuk memulihkan layanan setelah terjadi insiden atau pemadaman. Idealnya, Anda ingin membidik di bawah satu jam. Pemadaman membutuhkan uang yang serius, terutama bila berdampak pada pusat laba aplikasi. Pemadaman lama menghancurkan kepercayaan, menurunkan moral, dan menyiratkan tantangan organisasi tambahan.
- Perubahan kegagalan: Istilah ini mengacu pada tingkat di mana perubahan pada sistem Anda berdampak negatif pada kinerja. Meskipun Anda tidak akan pernah mencapai tingkat kegagalan perubahan nol persen, Anda benar-benar dapat mendekati nol dengan meningkatkan pengujian otomatis dan mengandalkan pipeline penerapan dengan pemeriksaan dan gerbang integrasi berkelanjutan — yang semuanya memastikan kualitas.
Menghilangkan kesempurnaan sebagai ukuran keberhasilan DevOps
DevOps mengandalkan mantra “Selesai lebih baik dari sempurna.” Tampaknya menjadi salah satu kutipan yang mustahil untuk dikaitkan, tetapi kata-katanya tetap berbicara kebenaran. Mencoba untuk mencapai kesempurnaan adalah musuh efektivitas dan produktivitas.
Sebagian besar insinyur, termasuk mereka dari berbagai DevOps, menderita beberapa versi kelumpuhan analisis — penderitaan mental yang membatasi produktivitas Anda dalam upaya untuk menganalisis pekerjaan Anda secara berlebihan dan menghindari potensi kecelakaan.
Melatih ketidaksempurnaan ke dalam pekerjaan Anda mengharuskan Anda untuk merangkul kemungkinan kegagalan dan refactoring yang tak terhindarkan. Membuat loop umpan balik di sekitar pelanggan dan mengulang kembali ke berbagai tahap pipeline adalah penyewa utama DevOps. Di DevOps, Anda menghubungkan ujungnya untuk menekuk garis menjadi lingkaran.
Saat Anda berpikir berulang dan melingkar, mengeluarkan kode yang tidak sempurna tampaknya jauh lebih menakutkan karena kode tersebut tidak diukir menjadi batu. Alih-alih, dalam keadaan sementara para insinyur DevOps sering meningkatkan saat Anda mengumpulkan lebih banyak data dan umpan balik.
Merancang tim kecil untuk DevOps
Anda mungkin pernah mendengar tentang tim “dua pizza” Amazon. Konsep ini secara luas berbicara tentang pentingnya tim berukuran kecil. Sekarang, jumlah pasti orang yang membentuk tim dua pizza bervariasi sesuai dengan selera Anda.
Sebaiknya pertahankan tim di bawah 12 orang. Ketika sebuah kelompok mendekati 9, 10, atau 11 orang, coba bagi menjadi dua. Sweet spot untuk ukuran grup adalah sekitar 4–6 orang. Jumlah pasti Anda dapat bervariasi tergantung pada orang yang terlibat, tetapi intinya adalah ini: Ketika kelompok menjadi terlalu besar, komunikasi menjadi sulit, klik terbentuk, dan kerja tim terganggu.
Inilah satu tujuan bonus lainnya saat membentuk tim DevOps: angka genap. Merupakan ide bagus untuk memberi orang “teman” di tempat kerja — seseorang yang bisa mereka percayai di atas segalanya. Dalam kelompok bernomor genap, setiap orang memiliki teman dan tidak ada yang tertinggal. Anda dapat memasangkan secara merata dan cenderung bekerja dengan baik. Membentuk kelompok bernomor genap tidak selalu dapat dicapai karena jumlah personel, tetapi itu adalah sesuatu yang perlu diingat.
Melacak pekerjaan DevOps Anda
Jika Anda dapat mengatasi biaya kecil untuk mencatat apa yang Anda lakukan setiap hari, hasilnya akan memberi Anda nilai luar biasa. Memiliki data nyata tentang bagaimana Anda menggunakan waktu membantu Anda melacak kemanjuran Anda dan tim Anda. Seperti kata Peter Drucker yang terkenal, “Jika Anda tidak dapat mengukurnya, Anda tidak dapat meningkatkannya.”
Berapa hari Anda meninggalkan pekerjaan dengan perasaan tidak melakukan apa-apa? Anda baru saja mengadakan rapat demi rapat atau interupsi acak sepanjang hari. Kamu tidak sendiri. Banyak pekerja memiliki masalah yang sama. Mungkin sulit untuk melacak kemajuan Anda dan karenanya produktivitas Anda. Perbedaan antara perasaan kemanjuran kita dan kenyataan kemanjuran kita adalah wilayah berbahaya bagi tim DevOps mana pun.
Coba gunakan pena dan kertas daripada alat otomatis untuk ini. Ya, Anda dapat menggunakan perangkat lunak untuk melacak bagaimana Anda menggunakan waktu di komputer Anda. Ini dapat memberi tahu Anda ketika Anda sedang membaca email, ketika Anda malas, dan ketika Anda sedang coding, tetapi tidak memiliki nuansa dan sering meleset atau salah mengkategorikan sebagian besar waktu.
Setelah Anda memiliki gagasan tentang apa yang Anda lakukan dan kapan, Anda dapat mulai mengidentifikasi aktivitas mana yang termasuk dalam kuadran mana dari Matriks Keputusan Eisenhower. Pekerjaan sibuk apa yang Anda lakukan secara rutin yang tidak memberikan nilai bagi Anda atau organisasi?
Mengurangi gesekan dalam proyek DevOps
Salah satu hal terbaik yang dapat dilakukan manajer untuk tim Engineering DevOps adalah membiarkan mereka sendiri. Pekerjakan insinyur yang ingin tahu yang mampu memecahkan masalah secara mandiri dan biarkan mereka melakukan pekerjaan mereka. Semakin Anda dapat mengurangi gesekan yang memperlambat pekerjaan Engineering mereka, semakin efektif tim Anda.
Mengurangi gesekan termasuk gesekan yang ada di antara tim — terutama operasi dan pengembangan. Jangan lupakan spesialis seperti keamanan juga.
Menyelaraskan tujuan dan insentif meningkatkan kecepatan. Jika semua orang fokus untuk mencapai hal yang sama, mereka dapat bergabung bersama sebagai sebuah tim dan bergerak secara metodis menuju tujuan tersebut.
Memanusiakan peringatan untuk kesuksesan DevOps
Setiap tim Engineering memiliki peringatan tentang tindakan atau peristiwa yang tidak penting. Memiliki semua peringatan itu membuat para insinyur tidak peka terhadap peringatan yang benar-benar penting. Banyak insinyur telah dikondisikan untuk mengabaikan peringatan email karena pesan yang meluap-luap.
Kelelahan waspada merugikan banyak organisasi Engineering dan menimbulkan biaya tinggi. Jika Anda kebanjiran setiap hari, memilih yang penting dari lautan yang tidak penting tidak mungkin. Anda bahkan bisa mengatakan bahwa pesan-pesan ini mendesak tetapi tidak penting. . . .
Menerapkan apa yang telah Anda pelajari tentang iterasi cepat, evaluasi ulang ambang peringatan Anda secara teratur untuk memastikan jumlah cakupan yang sesuai tanpa terlalu banyak kesalahan positif. Mengidentifikasi lansiran mana yang tidak perlu membutuhkan waktu dan kerja keras. Dan itu mungkin akan sedikit menakutkan, bukan? Menghapus peringatan atau meningkatkan ambang selalu disertai dengan sedikit risiko.
Bagaimana jika peringatan itu benar-benar penting? Jika ya, Anda akan mengetahuinya. Ingat, Anda tidak boleh takut gagal dalam organisasi DevOps. Anda harus menerimanya sehingga Anda dapat mendorong maju dan terus meningkat. Jika Anda membiarkan rasa takut memandu keputusan Anda, Anda mandek — sebagai seorang insinyur dan sebagai sebuah organisasi.