Kepiye Ivan nindakake metrik DevOps. Obyek pengaruh

Seminggu wis liwati wiwit Ivan pisanan mikir babagan metrik DevOps lan nyadari yen kanthi bantuan kasebut perlu kanggo ngatur wektu pangiriman produk (Wektu-Kanggo-Pasar).

Malah ing akhir minggu, dheweke mikir babagan metrik: "Dadi yen aku ngukur wektu? Apa bakal menehi kula?

Pancen, apa sing bakal diwenehi kawruh babagan wektu? Ayo ngomong pangiriman njupuk 5 dina. Dadi, apa sabanjure? Apa apik utawa ala? Sanajan iki ala, mula sampeyan kudu nyuda wektu iki. Nanging carane?
Pikiran kasebut ngganggu dheweke, nanging ora ana solusi.

Ivan ngerti yen dheweke wis teka ing inti. Grafik metrik sing ora kaetung sadurunge wis suwe nggawe dheweke yakin manawa pendekatan standar ora bakal bisa digunakake, lan yen dheweke mung ngrancang (sanajan iku klompok), ora ana gunane.

Kepiye carane?…

Metrik kaya panguasa kayu biasa. Pangukuran sing ditindakake kanthi bantuan ora bakal menehi alesan, ngapa obyek sing diukur persis dawa sing dituduhake. Panguwasa mung bakal nuduhake ukurane, lan ora liya. Dheweke dudu watu filsuf, nanging mung papan kayu sing bisa diukur.

"Tikus baja tahan karat" saka penulis favorit Harry Harrison tansah ngandika: pikirane kudu tekan ngisor otak lan dumunung ing kono, supaya sawise nandhang sangsara kanggo sawetara dina tanpa kasil, Ivan mutusaké kanggo nindakake tugas liyane ...

Sawetara dina sabanjure, nalika maca artikel babagan toko online, Ivan dumadakan nyadari yen jumlah dhuwit sing ditampa dening toko online gumantung saka prilaku pengunjung situs. Iku padha, pengunjung / klien, sing menehi toko dhuwit lan sumber sawijining. Ing baris ngisor awis toko ditampa dipengaruhi dening owah-owahan ing prilaku customer, ora tindakan liya.

Ternyata kanggo ngganti nilai sing diukur kudu pengaruhe wong sing mbentuk nilai kasebut, yaiku. kanggo ngganti jumlah dhuwit saka toko online, iku perlu kanggo pengaruhe prilaku pelanggan toko iki, lan ngganti wektu pangiriman ing DevOps, iku perlu kanggo pengaruhe tim sing "nggawe" wektu iki, i.e. nggunakake DevOps ing karya.

Ivan nyadari yen metrik DevOps ora kudu diwakili dening grafik. Dheweke kudu makili awake dhewe alat telusuran Tim "pinunjul" sing mbentuk wektu pangiriman pungkasan.

Ora ana metrik sing bakal nuduhake alesan kenapa tim iki utawa tim kasebut butuh wektu suwe kanggo ngirim distribusi, pikir Ivan, amarga sejatine bisa uga ana yuta lan kreta cilik, lan bisa uga ora teknis, nanging organisasi. Sing. sing paling sampeyan ngarepake saka metrik yaiku nuduhake tim lan asile, banjur sampeyan isih kudu ngetutake tim kasebut kanthi sikil lan ngerteni apa sing salah karo dheweke.

Ing sisih liya, perusahaan Ivan duwe standar sing mbutuhake kabeh tim nyoba majelis ing sawetara bangku. Tim ora bisa pindhah menyang stand sabanjure nganti sing sadurunge rampung. Ternyata yen kita mbayangno proses DevOps minangka urutan ngliwati stand, banjur metrik kasebut bisa nuduhake wektu sing ditindakake tim ing stand kasebut. Ngerti posisi lan wektu tim, mula bisa ngobrol kanthi luwih spesifik babagan alasane.

Tanpa mangu-mangu, Ivan ngangkat telpon lan nelpon nomer wong sing wis ngerti babagan seluk beluk DevOps:

— Denis, matur nuwun, apa bisa ngerti manawa tim kasebut wis ngliwati posisi iki utawa iki?
- Mesthi. Jenkins kita mbuwang gendéra yen bangunan wis kasil diluncurake (lulus tes) ing bangku.
- Super. Apa gendéra?
- Iki minangka file teks biasa kaya "stand_OK" utawa "stand_FAIL", sing ujar manawa majelis lulus utawa gagal ngadeg. Nah, sampeyan ngerti, ta?
- Aku kira, ya. Apa ditulis ing folder sing padha ing gudang ing ngendi papan kasebut dumunung?
- Ya
- Apa mengkono yen Déwan ora pass bench test? Apa aku kudu nggawe bangunan anyar?
- Ya
- Inggih, ok, matur nuwun. Lan pitakonan liyane: apa aku ngerti kanthi bener yen aku bisa nggunakake tanggal nggawe gendéra minangka tanggal ngadeg?
- Pancen!
- Super!

Inspirasi, Ivan nutup telpon lan nyadari yen kabeh wis ana. Ngerti tanggal nggawe file mbangun lan tanggal nggawe gendéra, sampeyan bisa ngetung nganti detik sepira suwene tim ing saben stand lan ngerti papan sing paling akeh.

"Ngerteni endi paling akeh wektu, kita bakal nemtokake tim, goleki lan goleki masalah kasebut." Ivan mesem.

Kanggo sesuk, dheweke nemtokake tugas kanggo nggawe sketsa arsitektur sistem sing digambar.

Terus ...

Source: www.habr.com