Jujur, Ivan sering menertawakan upaya sia-sia rekan-rekan dari departemen pemantauan. Mereka melakukan upaya besar untuk menerapkan metrik yang diperintahkan manajemen perusahaan kepada mereka. Mereka sangat sibuk sehingga mereka tidak ingin melakukan hal lain.
Dan kepemimpinan itu tidak cukup - itu terus-menerus memesan metrik lebih dan lebih, sangat cepat berhenti menggunakan apa yang dilakukan sebelumnya.
Baru-baru ini, semua orang baru saja membicarakan LeadTime - waktu pengiriman fitur bisnis. Metrik menunjukkan angka gila - 200 hari untuk mengirimkan satu tugas. Bagaimana semua orang mengerang, mengerang dan mengangkat tangan ke surga!
Setelah beberapa waktu, kebisingan perlahan-lahan menjadi tenang dan perintah datang dari manajemen untuk membuat metrik lain.
Ivan sangat jelas bahwa metrik baru juga akan mati dengan tenang di sudut gelap.
Memang, renung Ivan, mengetahui nomor itu sama sekali tidak memberitahu siapa pun. 200 hari atau 2 hari - tidak ada perbedaan, karena dengan angka tidak mungkin untuk menentukan alasan dan memahami apakah itu baik atau buruk.
Ini adalah perangkap metrik yang khas: tampaknya metrik baru akan memberi tahu esensi keberadaan dan menjelaskan beberapa rahasia rahasia. Semua orang berharap demikian, tetapi untuk beberapa alasan tidak ada yang terjadi. Ya, karena rahasianya tidak harus dicari dalam metrik!
Bagi Ivan, ini adalah tahap yang dilewati. Dia mengerti bahwa
metrik hanyalah penggaris kayu biasa untuk pengukuran, dan semua rahasia harus dicari di
objek yang terpengaruh , mis. dalam bentuk metrik ini.
Untuk toko online, objek pengaruhnya adalah pelanggannya, yang membawa uang, dan untuk DevOps, tim yang membuat dan meluncurkan distribusi menggunakan pipa.
Suatu ketika, setelah duduk di lobi dengan kursi yang nyaman, Ivan memutuskan untuk berpikir hati-hati tentang bagaimana ia ingin melihat metrik DevOps, dengan mempertimbangkan fakta bahwa tim adalah objek pengaruh.
Metrik DevOps Sasaran
Jelas bahwa setiap orang ingin mengurangi waktu pengiriman. 200 hari tentu saja tidak ada gunanya.
Tapi bagaimana, itu pertanyaannya?
Perusahaan ini memiliki ratusan tim, dan ribuan distribusi melewati saluran DevOps setiap hari. Waktu pengiriman nyata akan terlihat seperti distribusi. Setiap tim akan memiliki waktu dan karakteristiknya sendiri. Bagaimana Anda bisa menemukan setidaknya sesuatu di antara kekacauan ini?
Jawabannya muncul secara alami - Anda perlu menemukan tim bermasalah dan mencari tahu apa yang terjadi dengan mereka dan mengapa begitu lama, dan belajar bagaimana melakukan semuanya dengan cepat dengan tim "baik". Dan untuk ini, Anda perlu mengukur waktu yang dihabiskan oleh tim di masing-masing stan DevOps:
“Tujuan dari sistem akan menjadi pemilihan tim sesuai dengan waktu berlalunya stand, yaitu pada akhirnya, kita harus mendapatkan daftar tim dengan waktu yang dipilih, dan bukan angka.
Jika kita mengetahui berapa banyak waktu yang dihabiskan untuk total berdiri dan berapa banyak waktu yang dihabiskan untuk downtime di antara stand, kita dapat menemukan tim, memanggil mereka dan memahami alasannya secara lebih rinci dan menghilangkannya, ”pikir Ivan.
Cara menghitung waktu pengiriman untuk DevOps
Untuk menghitungnya, perlu untuk mempelajari proses DevOps dan esensinya.
Perusahaan menggunakan sejumlah sistem, dan informasi hanya dapat diperoleh dari mereka dan di tempat lain.
Semua tugas di perusahaan terdaftar di Jira. Ketika tugas diambil untuk bekerja, brunch dibuat untuk itu, dan setelah implementasi, komit dibuat untuk BitBucket dan Tarik Permintaan. Saat menerima PR (Tarik Permintaan), kit distribusi secara otomatis dibuat dan disimpan dalam repositori Nexus.
Selanjutnya, distribusi diluncurkan pada beberapa stand menggunakan Jenkins untuk memeriksa kebenaran pengujian rolling, otomatis dan manual:
Ivan melukis dari sistem mana informasi dapat diambil untuk menghitung waktu di tribun:
- Dari Nexus - Waktu pembuatan distribusi dan nama folder yang berisi kode perintah
- Dari Jenkins - Mulai waktu, durasi, dan hasil mengerjakan setiap pekerjaan, nama dudukan (dalam parameter pekerjaan), tahapan (langkah-langkah pekerjaan), tautan ke distribusi di Nexus.
- Ivan memutuskan untuk tidak memasukkan Jira dan BitBucket ke dalam pipa, karena mereka lebih terkait dengan fase pengembangan, dan tidak menggulung distribusi selesai di sekitar tribun.
Berdasarkan informasi yang tersedia, skema berikut dibuat:
Mengetahui berapa banyak distribusi waktu dibuat dan berapa banyak waktu yang dihabiskan untuk masing-masing, Anda dapat dengan mudah menghitung total biaya melalui seluruh pipa DevOps (siklus penuh).
Berikut adalah metrik DevOps dari Ivan sebagai hasilnya:
- Jumlah Distribusi yang Dibuat
- Bagian distribusi “masuk” ke dudukan dan “melewati” dudukan
- Waktu yang dihabiskan di stand (siklus berdiri)
- Siklus penuh (total waktu untuk semua tegakan)
- Durasi Pekerjaan
- Sederhana di antara tribun
- Sederhana antara peluncuran pekerjaan di satu stand
Di satu sisi, metrik sangat baik menandai pipa DevOps dalam hal waktu, di sisi lain, mereka dianggap sangat sederhana.
Puas dengan pekerjaan yang dilakukan dengan baik, Ivan membuat presentasi dan pergi untuk mempresentasikannya kepada manajemen.
Dia kembali cemberut dan dengan tangan ke bawah.
"Ini kegagalan, kawan," kolega ironis itu tersenyum.
Lanjutkan membaca artikel " Seberapa cepat hasil membantu Ivan ."