Metrik DORA adalah empat pengukuran utama yang membantu para pemimpin tim untuk memahami efektivitas praktik kerja DevOps mereka. Grup DevOps Research and Assessment (DORA) mengembangkan metrik setelah enam tahun melakukan penelitian terhadap keberhasilan adopsi DevOps.
Mengukur data adalah cara terbaik untuk mengukur pengaruh DevOps terhadap organisasi Anda. Berfokus pada aspek yang diidentifikasi oleh DORA dapat membuka peluang untuk mengoptimalkan proses Anda dan meningkatkan efisiensi. Dalam artikel ini, kami akan menjelaskan bagaimana masing-masing dari empat metrik berkontribusi terhadap kesuksesan DevOps.
Deployment Frequency
Frekuensi penerapan mengukur seberapa sering Anda mengirimkan kode baru ke lingkungan produksi Anda. Karena tujuan utama DevOps adalah untuk memberikan kode yang berfungsi secara lebih efisien, frekuensi penerapan adalah titik awal yang baik saat Anda mengevaluasi keberhasilan.
Anda dapat mengumpulkan data ini hanya dengan menganalisis berapa kali kode baru telah diterapkan selama periode waktu tertentu. Anda kemudian dapat mencari peluang untuk meningkatkan tingkat rilis Anda, tanpa mengorbankan pagar pengaman yang mempertahankan standar kualitas. Menggunakan pengiriman berkelanjutan untuk menerapkan kode secara otomatis saat Anda menggabungkannya adalah salah satu cara Anda dapat mempercepat alur kerja Anda.
Frekuensi penerapan yang ideal bergantung pada jenis sistem yang Anda bangun. Meskipun sekarang sudah umum untuk aplikasi web dikirimkan beberapa kali sehari, irama ini tidak cocok untuk pengembang game yang memproduksi build multi-gigabyte.
Dalam beberapa situasi, mengakui perbedaan ini dengan memikirkan frekuensi penerapan sedikit berbeda. Anda dapat mendekatinya sebagai frekuensi yang dapat digunakan untuk menerapkan kode, jika Anda ingin memotong rilis baru pada titik waktu tertentu. Ini bisa menjadi cara yang lebih efektif untuk mengukur throughput ketika pengiriman berkelanjutan yang sebenarnya tidak layak untuk proyek Anda.
Change Lead Time
A lead time perubahan adalah interval antara revisi kode yang dilakukan dan komitmen yang memasuki lingkungan produksi. Metrik ini mengungkapkan penundaan yang terjadi selama peninjauan kode dan iterasi, setelah pengembang menyelesaikan sprint.
asli Mengukur nilai ini sangatlah mudah. Anda perlu menemukan waktu saat pengembang menandatangani perubahan, lalu waktu saat kode dikirimkan ke pengguna. Waktu tunggu adalah jumlah jam dan menit antara dua nilai.
Sebagai contoh, pertimbangkan perubahan sederhana untuk mengirim email peringatan keamanan setelah pengguna masuk. Pengembang menyelesaikan tugas pada pukul 11 pagi dan melakukan pekerjaan mereka ke repositori sumber. Pada pukul 12 siang, seorang pengulas membaca kode dan meneruskannya ke QA. Pada pukul 14:00, penguji tim QA telah melihat ada kesalahan ketik pada salinan email. Pengembang melakukan perbaikan pada jam 3 sore dan QA menggabungkan perubahan terakhir ke dalam produksi pada jam 4 sore. Lead time dari perubahan ini adalah 5 jam.
Lead time digunakan untuk mengungkap ketidakefisienan saat pekerjaan berpindah antar item. Meskipun standar sangat bervariasi menurut industri dan organisasi, waktu tunggu rata-rata yang tinggi dapat menjadi indikasi gesekan internal dan alur kerja yang kurang dipertimbangkan. Waktu tunggu yang diperpanjang juga dapat disebabkan oleh pengembang berkinerja buruk yang menghasilkan pekerjaan berkualitas rendah sebagai iterasi pertama mereka pada suatu tugas.
Beberapa organisasi menggunakan pengukuran yang berbeda untuk waktu tunggu. Banyak yang memilih waktu yang berlalu antara pengembang memulai fitur dan kode akhir memasuki produksi. Orang lain mungkin melihat ke belakang lebih jauh dan menggunakan waktu saat perubahan diminta – oleh pelanggan, klien, atau manajer produk – sebagai titik awal.
Metode ini dapat menghasilkan informasi yang lebih berguna secara luas di dalam bisnis, di luar tim teknik. Interpretasi DORA menggunakan stempel waktu komit memiliki satu keuntungan besar: data ditangkap secara otomatis oleh alat kontrol sumber Anda, sehingga pengembang tidak perlu mencatat waktu mulai secara manual untuk setiap tugas baru. produksi yang menyebabkan suatu kejadian. Insiden adalah bug atau perilaku tak terduga yang menyebabkan pemadaman atau gangguan pada pelanggan. Pengembang dan operator perlu meluangkan waktu untuk menyelesaikan masalah.
Anda dapat menghitung tingkat kegagalan perubahan dengan membagi jumlah penerapan yang Anda buat dengan jumlah yang menyebabkan kesalahan. Nilai terakhir biasanya diperoleh dengan melabeli laporan bug di perangkat lunak manajemen proyek Anda dengan penerapan yang memperkenalkannya.
Menyebutkan insiden secara akurat dengan perubahan yang menyebabkannya terkadang bisa rumit, terutama jika Anda memiliki frekuensi penerapan yang tinggi, tetapi dalam banyak kasus itu mungkin bagi pengembang dan tim triase untuk menentukan pemicu yang paling mungkin. Tantangan lain dapat menyepakati apa yang merupakan kegagalan: haruskah bug kecil meningkatkan tingkat kegagalan Anda, atau apakah Anda hanya tertarik pada pemadaman besar? Kedua jenis masalah tersebut memengaruhi cara pelanggan memandang layanan Anda sehingga akan berguna untuk mempertahankan beberapa nilai yang berbeda untuk metrik ini, masing-masing melihat kelas masalah yang berbeda.
Anda harus selalu bertujuan untuk mendorong tingkat kegagalan perubahan serendah mungkin. Menggunakan pengujian otomatis, analisis statis, dan integrasi berkelanjutan dapat membantu mencegah kode yang rusak keluar ke produksi. Lindungi proses Anda dengan alat dan metode kerja baru untuk secara bertahap mengurangi tingkat kegagalan dari waktu ke waktu.
Waktu untuk Memulihkan Layanan
Sayangnya kegagalan tidak dapat dihilangkan sama sekali. Akhirnya Anda akan mengalami masalah yang menyebabkan rasa sakit bagi pelanggan Anda. Metrik DORA keempat, Time to Restore Service, menganalisis seberapa efektif Anda dapat merespons peristiwa ini.
Serupa dengan mengubah waktu tunggu, durasi yang diukur dapat bervariasi antar organisasi. Beberapa tim akan menggunakan waktu di mana bug dikerahkan, yang lain akan pergi dari laporan pelanggan pertama, dan beberapa mungkin mengambil waktu di mana tim respons insiden di-page. Titik pemicu mana pun yang Anda adopsi, Anda harus menggunakannya secara konsisten dan terus mengukur hingga insiden ditandai sebagai terselesaikan.
Waktu pemulihan rata-rata yang tinggi merupakan sinyal bahwa proses respons insiden Anda perlu disesuaikan. Respons yang efektif bergantung pada orang yang tepat yang tersedia untuk mengidentifikasi kesalahan, mengembangkan patch, dan berkomunikasi dengan pelanggan yang terpengaruh. Anda dapat mengurangi waktu pemulihan dengan mengembangkan prosedur respons yang disepakati, menjaga agar informasi penting dapat diakses secara terpusat di organisasi Anda, dan memperkenalkan pemantauan otomatis untuk memperingatkan Anda tentang masalah segera setelah masalah itu terjadi.
Mengoptimalkan metrik ini sering diabaikan karena terlalu banyak tim yang menganggap masalah utama pemadaman tidak akan pernah terjadi. Anda mungkin juga memiliki titik data yang relatif sedikit untuk digunakan jika layanan Anda umumnya stabil. Menjalankan latihan respons insiden menggunakan teknik seperti pengujian chaos dapat memberikan data yang lebih bermakna yang mewakili waktu pemulihan Anda saat ini.
Keempat metrik DORA memberikan data kepada pemimpin tim DevOps yang mengungkap peluang peningkatan. Secara teratur mengukur dan menganalisis Frekuensi Penerapan, Mengubah Waktu Proses, Mengubah Tingkat Kegagalan, dan Waktu untuk Memulihkan Layanan membantu Anda memahami kinerja Anda dan membuat keputusan yang tepat tentang cara meningkatkannya.
DORA metrik dapat dihitung secara manual menggunakan informasi dalam sistem manajemen proyek Anda . Ada juga alat seperti Empat Kunci Google Cloud yang akan menghasilkannya secara otomatis dari informasi komit. Beberapa alat ekosistem seperti GitLab mulai menyertakan dukungan terintegrasi juga.
Implementasi DevOps terbaik akan memfasilitasi perubahan cepat dan penerapan reguler yang sangat jarang menimbulkan kesalahan baru. Setiap kemunduran yang terjadi akan ditangani dengan segera, meminimalkan waktu henti sehingga pelanggan memiliki kesan terbaik tentang layanan Anda. Melacak tren DORA dari waktu ke waktu memungkinkan Anda memeriksa apakah Anda mencapai cita-cita ini, memberi Anda peluang terbaik untuk kesuksesan DevOps.
Itulah berita seputar
Apa itu Metrik DORA dan Bagaimana Menginformasikan Kesuksesan DevOps?, semoga bermanfaat.
Disadur dari HowToGeek.com.
