Sejujurnya, Ivan kerap menertawakan upaya sia-sia rekan-rekannya di bagian monitoring. Mereka melakukan upaya besar untuk menerapkan metrik yang diperintahkan manajemen perusahaan untuk mereka capai. Mereka begitu sibuk sehingga mereka tidak ingin orang lain melakukan apa pun.
Tapi itu tidak cukup bagi manajemen - mereka terus-menerus memesan lebih banyak metrik baru, dengan cepat berhenti menggunakan apa yang telah dilakukan sebelumnya.
Akhir-akhir ini, semua orang membicarakan tentang LeadTime - waktu untuk menghadirkan fitur bisnis. Metriknya menunjukkan angka yang luar biasa - 200 hari untuk menyelesaikan satu tugas. Betapa semua orang berteriak dan mengangkat tangan mereka ke langit!
Setelah beberapa waktu, kebisingan secara bertahap mereda dan manajemen menerima perintah untuk membuat metrik lain.
Sangat jelas bagi Ivan bahwa metrik baru akan mati secara diam-diam di sudut gelap.
Memang benar, pikir Ivan, mengetahui nomor tersebut sama sekali tidak memberi tahu siapa pun. 200 hari atau 2 hari - tidak ada perbedaan, karena tidak mungkin menentukan alasannya berdasarkan angka dan memahami apakah itu baik atau buruk.
Ini adalah jebakan khas metrik: tampaknya metrik baru akan mengungkapkan esensi keberadaan dan menjelaskan beberapa rahasia rahasia. Semua orang sangat berharap untuk ini, tapi entah kenapa tidak terjadi apa-apa. Ya, karena rahasianya tidak boleh ditemukan dalam metrik!
Bagi Ivan, ini adalah tahapan yang telah dilewati. Dia mengerti itu untuk pengukuran, dan semua rahasia harus dicari , yaitu. adalah metrik ini terbentuk.
Untuk toko online, objek pengaruhnya adalah klien yang menghasilkan uang, dan untuk DevOps, tim yang membuat dan meluncurkan distribusi menggunakan saluran pipa.
Suatu hari, sambil duduk di kursi yang nyaman di aula, Ivan memutuskan untuk memikirkan dengan cermat bagaimana dia ingin melihat metrik DevOps, dengan mempertimbangkan fakta bahwa objek pengaruhnya adalah tim.
Tujuan Metrik DevOps
Jelas bahwa semua orang ingin mengurangi waktu pengiriman. 200 hari tentu saja tidak baik.
Tapi bagaimana caranya, itulah pertanyaannya?
Perusahaan ini mempekerjakan ratusan tim, dan ribuan distribusi melalui jalur DevOps setiap hari. Waktu pengiriman sebenarnya akan muncul sebagai distribusi. Setiap tim akan memiliki waktu dan karakteristiknya masing-masing. Bagaimana Anda bisa menemukan sesuatu dalam kekacauan ini?
Jawabannya muncul secara alami - kita perlu menemukan tim yang bermasalah dan mencari tahu apa yang terjadi dengan mereka dan mengapa hal ini memakan waktu begitu lama, dan belajar dari tim yang “baik” bagaimana melakukan segala sesuatunya dengan cepat. Dan untuk melakukan ini, Anda perlu mengukur waktu yang dihabiskan oleh tim di setiap stand DevOps:
“Tujuan dari sistem ini adalah untuk memilih tim berdasarkan waktu mereka melewati tribun, yaitu. Hasilnya, kita akan mendapatkan daftar perintah dengan waktu yang dipilih, dan bukan angka.
Jika kita mengetahui berapa total waktu yang dihabiskan di stand dan berapa banyak waktu yang dihabiskan untuk downtime antar stand, kita dapat menemukan tim, memanggil mereka dan memahami alasannya lebih detail dan menghilangkannya, ”pikir Ivan.
Cara Menghitung Waktu Pengiriman untuk DevOps
Untuk menghitungnya, perlu mempelajari proses DevOps dan esensinya.
Perusahaan menggunakan sistem dalam jumlah terbatas, dan informasi hanya dapat diperoleh dari sistem tersebut dan tidak dapat diperoleh dari tempat lain.
Semua tugas di perusahaan didaftarkan di Jira. Saat tugas diambil, cabang dibuat untuk tugas tersebut, dan setelah implementasi, penerapan dilakukan pada BitBucket dan Pull Request. Ketika PR (Pull Request) diterima, distribusi secara otomatis dibuat dan disimpan dalam repositori Nexus.
Selanjutnya, distribusi diluncurkan di beberapa stand menggunakan Jenkins untuk memeriksa kebenaran peluncuran, pengujian otomatis dan manual:
Ivan menjelaskan dari sistem mana informasi apa yang dapat diambil untuk menghitung waktu di tribun:
- Dari Nexus – Waktu pembuatan distribusi dan nama folder yang berisi kode perintah
- Dari Jenkins – Waktu mulai, durasi dan hasil setiap pekerjaan, nama stand (dalam parameter pekerjaan), tahapan (langkah pekerjaan), tautan ke distribusi di Nexus.
- Ivan memutuskan untuk tidak memasukkan Jira dan BitBucket ke dalam pipeline, karena... mereka lebih terkait dengan tahap pengembangan, dan bukan pada peluncuran distribusi yang sudah jadi di stand.
Berdasarkan informasi yang tersedia, diagram berikut dibuat:
Mengetahui berapa lama waktu yang dibutuhkan untuk membuat distribusi dan berapa banyak waktu yang dihabiskan untuk masing-masing distribusi, Anda dapat dengan mudah menghitung total biaya untuk menjalankan seluruh pipeline DevOps (siklus penuh).
Berikut adalah metrik DevOps yang diperoleh Ivan:
- Jumlah distribusi yang dibuat
- Pangsa distribusi yang “datang” ke stand dan “melewati” stand
- Waktu yang dihabiskan di stand (siklus stand)
- Siklus penuh (total waktu untuk semua stand)
- Durasi pekerjaan
- Waktu henti antar stand
- Waktu henti antar peluncuran pekerjaan di stand yang sama
Di satu sisi, metrik tersebut mengkarakterisasi pipeline DevOps dengan sangat baik dalam hal waktu, di sisi lain, metrik tersebut dianggap sangat sederhana.
Puas dengan pekerjaan yang dilakukan dengan baik, Ivan melakukan presentasi dan pergi untuk mempresentasikannya kepada manajemen.
Dia kembali dengan murung dan dengan tangan ke bawah.
“Ini kegagalan, kawan,” rekan ironis itu tersenyum...
Baca selengkapnya di artikel “'.
Sumber: www.habr.com