Rast be, Ivan gelek caran bi hewildanên pûç ên hevkarên xwe yên ji beşa çavdêriyê dikeniya. Wan hewildanên mezin kirin ji bo pêkanîna metrîkên ku rêveberiya pargîdaniyê ferman da wan ku bigihîjin wan. Ew qas mijûl bûn ku nedixwestin kesek din tiştekî bike.
Lê ew ji rêveberiyê re ne bes bû - wan her gav metrîkên nû û bêtir ferman da, pir zû dev ji karanîna tiştê ku berê kiribû hişt.
Di demên dawî de, her kes li ser LeadTime diaxive - dema radestkirina taybetmendiyên karsaziyê. Metrîka jimareyek dîn nîşan da - 200 roj ji bo radestkirina yek peywirê. Çawa her kesî axîn û axîn û destên xwe ber bi ezmên ve bilind kirin!
Piştî demekê, deng hêdî hêdî mir û rêveberî fermanek wergirt ku metrîkek din biafirîne.
Ji Ivan re bi tevahî zelal bû ku metrika nû dê bi heman rengî bêdeng di quncikek tarî de bimire.
Bi rastî, Ivan difikirî, ku zanibe ku hejmar qet tiştek ji kesî re nabêje. 200 roj an 2 roj - ferq tune ye, ji ber ku ne gengaz e ku meriv sedemê bi hejmarê diyar bike û fêm bike ka ew baş e an xirab e.
Ev xefikek tîpîk a metrîkan e: wusa dixuye ku metrîkek nû dê cewhera hebûnê vebêje û hin razên veşartî rave bike. Her kes ji bo vê yekê pir hêvî dike, lê ji ber hin sedeman tiştek nabe. Erê, ji ber ku veşartî divê di metrîkan de neyê dîtin!
Ji bo Ivan, ev qonaxek derbas bû. Wî ev fêm kir ji bo pîvandinê, û hemî veşartî divê di nav de bêne lêgerîn , yanî ew e ku ev metrîk pêk tê.
Ji bo firotgehek serhêl, mebesta bandorê dê xerîdarên wê bin ku drav didin, û ji bo DevOps, ew ê tîmên ku bi karanîna lûleyek dabeşan çêdikin û derdixin.
Rojekê, Ivan di salonê de li ser kursiyek rehet rûnişt, Ivan biryar da ku bi baldarî bifikire ka ew çawa dixwaze metrîkên DevOps bibîne, li ber çavê xwe bigire ku mijara bandorê tîm in.
Armanca Metrîkên DevOps
Eşkere ye ku her kes dixwaze dema radestkirinê kêm bike. 200 roj, bê guman, ne baş e.
Lê çawa, pirs ev e?
Pargîdanî bi sedan tîmê kar dike, û bi hezaran belavok her roj di xeta boriyê ya DevOps re derbas dibin. Dema radestkirina rastîn dê wekî dabeşkirinê xuya bibe. Her tîm dê dem û taybetmendiyên xwe hebin. Hûn çawa dikarin di nav vê tevliheviyê de tiştek bibînin?
Bersiv bi xwezayî derket - pêdivî ye ku em tîmên pirsgirêkê bibînin û fêhm bikin ka çi bi wan re diqewime û çima ew ewqas dirêj digire, û ji tîmên "baş" fêr bibin ka meriv çawa her tiştî zû dike. Û ji bo kirina vê yekê, hûn hewce ne ku dema ku tîmê li her yek ji standên DevOps derbas kirine bipîvin:
“Armanca pergalê wê ew be ku tîmên li gorî dema ku ji stantan derbas dibin hilbijêrin, yanî. Wekî encamek, divê em navnîşek fermanan bi dema hilbijartî re bistînin, û ne hejmarek.
Ger em zanibin ka bi tevahî çiqas dem li standê hatiye xerckirin û çend dem ji bo rawestana di navbera stantan de hatiye xerckirin, em dikarin tîman bibînin, gazî wan bikin û sedeman bi hûrgulî fam bikin û wan ji holê rakin, "difikirî Ivan.
Meriv çawa ji bo DevOps Dema Radestkirinê Hesab dike
Ji bo hesabkirina wê, pêdivî bû ku meriv pêvajoya DevOps û cewhera wê veşêre.
Pargîdanî hejmarek sînorkirî pergalan bikar tîne, û agahdarî tenê ji wan û li ti cîhek din dikare were wergirtin.
Hemî karên di pargîdaniyê de li Jira hatine tomar kirin. Dema ku peywirek hate girtin, ji bo wê şaxek hate çêkirin, û piştî bicîhkirinê, ji BitBucket û Daxwaza Pull re peywirek hate çêkirin. Dema ku PR (Daxwaza vekişînê) hate pejirandin, belavkirinek bixweber hate afirandin û di depoya Nexus de hate hilanîn.
Dûv re, dabeşkirin li ser gelek stendan bi karanîna Jenkins ve hate şandin da ku rastbûna vekêşanê, ceribandina otomatîk û destan kontrol bike:
Ivan diyar kir ku ji kîjan pergalan çi agahdarî dikare were girtin da ku dema li standan were hesibandin:
- Ji Nexus - Dema çêkirina belavkirinê û navê peldanka ku koda fermanê tê de ye
- Ji Jenkins - Dema destpêkirinê, dem û encama her karî, navê standê (di pîvanên kar de), qonax (pêngavên kar), girêdana bi belavkirina li Nexus re.
- Ivan biryar da ku Jira û BitBucket nekeve nav boriyê, ji ber ... ew bêtir bi qonaxa pêşkeftinê ve girêdayî bûn, û ne bi belavkirina belavkirina qedandî li ser standan.
Li gorî agahiyên berdest ev diyagrama jêrîn hate xêzkirin:
Dizanin ka çiqas dem hewce dike ku belavkirinan biafirîne û çiqas dem li ser her yek ji wan tê xerc kirin, hûn dikarin bi hêsanî lêçûnên giştî yên derbasbûna tevahiya lûleya DevOps (çerxa tevahî) hesab bikin.
Li vir metrîkên DevOps hene ku Ivan bi dawî bû:
- Hejmara belavkirinên hatine çêkirin
- Parvekirina belavkirinên ku "hatin" standê û "derbas" stand
- Wextê ku li ser standê derbas bûye (çerxa standê)
- Demjimêra tevahî (dema tevahî ji bo hemî standan)
- Demjimêra kar
- Downtime di navbera standan de
- Demjimêra di navbera destpêkirina kar de li ser heman standê
Ji aliyek ve, metrîka lûleya DevOps di warê demê de pir baş diyar kir, ji hêla din ve, ew pir hêsan têne hesibandin.
Ji karê ku bi başî hatî kirin razî bû, Ivan pêşkêşiyek kir û çû ku wê pêşkêşî rêveberiyê bike.
Ew bi gemar û bi destên xwe vegerî.
"Ev fiyasko ye, bira," hevkarê îronîk keniya...
Di gotarê de bêtir bixwînin "".
Source: www.habr.com