Sejujure, Ivan kerep ngguyu karo upaya sing ora ana gunane kanca-kanca saka departemen pemantauan. Dheweke nggawe upaya gedhe kanggo ngetrapake metrik sing diprentahake dening manajemen perusahaan. Wong-wong kuwi sibuk banget nganti ora gelem wong liya nglakoni apa-apa.
Nanging ora cukup kanggo manajemen - dheweke terus-terusan mrentahake metrik anyar, kanthi cepet mandheg nggunakake apa sing wis ditindakake sadurunge.
Akhir-akhir iki, kabeh wong wis ngomong babagan LeadTime - wektu kanggo pangiriman fitur bisnis. Metrik kasebut nuduhake nomer edan - 200 dina kanggo ngirim siji tugas. Carane kabeh wong oohed lan aahed lan ngangkat tangane menyang langit!
Sawise sawetara wektu, swara kasebut alon-alon mudhun lan manajemen nampa pesenan kanggo nggawe metrik liyane.
Ivan wis jelas yen metrik anyar bakal mati kanthi tenang ing pojok peteng.
Pancen, pikir Ivan, ngerti nomer kasebut ora ngandhani sapa wae. 200 dina utawa 2 dina - ora ana bedane, amarga ora bisa nemtokake alesan kanthi nomer lan ngerti apa sing apik utawa ala.
Iki minangka jebakan metrik sing khas: misale jek metrik anyar bakal nyritakake inti saka eksistensi lan nerangake sawetara rahasia rahasia. Saben uwong ngarep-arep banget kanggo iki, nanging sakperangan alesan ora ana kedadeyan. Ya, amarga rahasia kasebut ora bisa ditemokake ing metrik!
Kanggo Ivan, iki minangka tahap sing wis dilewati. Dheweke ngerti kanggo pangukuran, lan kabeh rahasia kudu digoleki , i.e. iku metrik iki kawangun.
Kanggo toko online, obyek pengaruhe yaiku para klien sing nggawa dhuwit, lan kanggo DevOps, bakal dadi tim sing nggawe lan ngluncurake distribusi nggunakake pipa.
Sawijining dina, lungguh ing kursi sing nyaman ing aula, Ivan mutusake kanggo mikir kanthi ati-ati babagan carane dheweke pengin ndeleng metrik DevOps, kanthi nganggep kasunyatan manawa obyek pengaruh yaiku tim.
Tujuan Metrik DevOps
Cetha yen kabeh wong pengin nyuda wektu pangiriman. 200 dina, mesthi, ora apik.
Nanging kepiye, pitakonan kasebut?
Perusahaan kasebut makaryakke atusan tim, lan ewu distribusi ngliwati pipa DevOps saben dina. Wektu pangiriman nyata bakal katon minangka distribusi. Saben tim bakal duwe wektu lan ciri dhewe. Kepiye sampeyan bisa nemokake apa wae ing antarane kekacoan iki?
Jawaban kasebut muncul kanthi alami - kita kudu nemokake tim masalah lan ngerteni apa sing kedadeyan karo dheweke lan kenapa suwene suwe, lan sinau saka tim "apik" carane nindakake kabeh kanthi cepet. Lan kanggo nindakake iki, sampeyan kudu ngukur wektu sing ditindakake dening tim ing saben stand DevOps:
"Tujuan sistem kasebut yaiku kanggo milih tim adhedhasar wektu sing dilewati, yaiku. AkibatΓ©, kita kudu entuk dhaptar perintah kanthi wektu sing dipilih, dudu nomer.
Yen kita ngerteni sepira suwene wektu sing dientekake ing stand lan sepira suwene wektu istirahat ing antarane stand, kita bisa nemokake tim kasebut, nelpon lan ngerti sebabe kanthi luwih rinci lan ngilangi, "pikir Ivan.
Cara Ngitung Wektu Pangiriman kanggo DevOps
Kanggo ngetung, sampeyan kudu nyelidiki proses DevOps lan intine.
Perusahaan nggunakake sawetara sistem sing winates, lan informasi mung bisa dipikolehi saka wong-wong mau lan ora ana ing papan liya.
Kabeh tugas ing perusahaan didaftar ing Jira. Nalika tugas ditindakake, cabang digawe kanggo kasebut, lan sawise implementasine, komitmen digawe kanggo BitBucket lan Pull Request. Nalika PR (Pull Request) ditampa, distribusi digawe kanthi otomatis lan disimpen ing repositori Nexus.
Sabanjure, distribusi kasebut diluncurake ing sawetara stand nggunakake Jenkins kanggo mriksa kabeneran rollout, tes otomatis lan manual:
Ivan diterangake saka sistem apa informasi sing bisa dijupuk kanggo ngetung wektu ing stands:
- Saka Nexus - Wektu nggawe distribusi lan jeneng folder sing ngemot kode perintah
- Saka Jenkins - Wektu wiwitan, durasi lan asil saben proyek, jeneng ngadeg (ing paramèter proyek), tahapan (langkah kerja), pranala menyang distribusi ing Nexus.
- Ivan mutusake ora kalebu Jira lan BitBucket ing pipa, amarga ... padha luwih related kanggo tataran pembangunan, lan ora kanggo Rolling metu distribusi rampung ing stands.
Adhedhasar informasi sing kasedhiya, diagram ing ngisor iki digambar:
Ngerti suwene wektu kanggo nggawe distribusi lan sepira suwene wektu kanggo saben wong, sampeyan bisa kanthi gampang ngetung biaya total kanggo ngliwati kabeh pipa DevOps (siklus lengkap).
Mangkene metrik DevOps sing ditindakake Ivan:
- Jumlah distribusi digawe
- Nuduhake distribusi sing "teka" menyang stand lan "lulus" stand
- Wektu sing ditindakake ing stand (siklus stand)
- Siklus lengkap (total wektu kanggo kabeh stand)
- Durasi kerja
- Downtime antarane stands
- Downtime antarane mbukak proyek ing ngadeg padha
Ing tangan siji, metrik kasebut nduweni ciri pipa DevOps kanthi apik babagan wektu, ing sisih liya, dianggep gampang banget.
Puas karo tugas sing ditindakake kanthi apik, Ivan nggawe presentasi lan menehi presentasi menyang manajemen.
Dheweke bali surem lan karo tangan mudhun.
"Iki pancen gagal, bro," rekan sing ironis kasebut mesem ...
Waca liyane ing artikel "".
Source: www.habr.com