Kiel Ivan faris DevOps-metrikojn. Objekto de influo

Semajno pasis de kiam Ivan unue pensis pri DevOps-metrikoj kaj rimarkis, ke per ilia helpo necesas administri produktotempon. (Tempo-Al-Merkato).

Eĉ en semajnfinoj, li pensis pri metriko: "Kio do se mi mezuros tempon? Kion ĝi donos al mi?

Efektive, kion donos scio pri tempo? Ni diru, ke livero daŭras 5 tagojn. Do, kio sekvas? Ĉu ĝi estas bona aŭ malbona? Eĉ se ĉi tio estas malbona, tiam vi devas iel redukti ĉi tiun tempon. Sed kiel?
Tiuj ĉi pensoj hantis lin, sed neniu solvo venis.

Ivano komprenis, ke li venis al la esenco mem. La sennombraj grafikaĵoj de metrikoj, kiujn li antaŭe vidis, antaŭ longe konvinkis lin, ke la norma aliro ne funkcios, kaj ke se li simple grafikus (eĉ se temas pri kohorto), ĝi ne utilos.

Kiel esti?…

Metriko estas kiel ordinara ligna regulo. Mezuradoj faritaj kun ĝia helpo ne diros la kialon, kial la mezurita objekto estas ĝuste la longo, kiun ŝi montris. La reganto simple montros ĝian grandecon, kaj nenion pli. Ŝi ne estas la filozofa ŝtono, sed simple ligna tabulo per kiu oni mezuru.

La "neoksidebla ŝtala rato" de sia plej ŝatata verkisto Harry Harrison ĉiam diris: penso devas atingi la fundon de la cerbo kaj kuŝi tie, do post suferado dum kelkaj tagoj senutile, Ivan decidis preni alian taskon...

Kelkajn tagojn poste, legante artikolon pri interretaj vendejoj, Ivan subite rimarkis, ke la monsumo, kiun ricevas reta vendejo, dependas de kiel kondutas la vizitantoj de la retejo. Estas ili, vizitantoj/klientoj, kiuj donas al la vendejo sian monon kaj estas ĝia fonto. La fundo de mono kiun butiko ricevas estas influita de ŝanĝoj en klienta konduto, ne io alia.

Montriĝis, ke por ŝanĝi la mezuran valoron necesis influi tiujn, kiuj formas ĉi tiun valoron, t.e. por ŝanĝi la monsumon de reta vendejo, estis necese influi la konduton de la klientoj de ĉi tiu vendejo, kaj por ŝanĝi la livertempon en DevOps, necesis influi la teamojn, kiuj "kreas" ĉi-foje, t.e. uzu DevOps en sia laboro.

Ivan rimarkis, ke DevOps-metrikoj tute ne devus esti reprezentitaj per grafikaĵoj. Ili devas reprezenti sin mem serĉilo "elstaraj" teamoj kiuj formas la finan livertempon.

Neniu metriko iam montros la kialon, kial tiu aŭ alia teamo daŭris longan tempon por liveri distribuon, Ivan pensis, ĉar efektive povus esti miliono kaj malgranda ĉaro, kaj ili povas esti ne teknikaj, sed organizaj. Tiuj. plej vi povas atendi akiri de metriko estas montri teamojn kaj iliajn rezultojn, kaj tiam vi ankoraŭ devas sekvi ĉi tiujn teamojn per viaj piedoj kaj ekscii kio estas malbona kun ili.

Aliflanke, la firmao de Ivan havis normon, kiu postulis ĉiujn teamojn testi kunigojn sur pluraj benkoj. La teamo ne povis moviĝi al la venonta stando ĝis la antaŭa estis kompletigita. Rezultis, ke se ni imagas la DevOps-procezon kiel sekvencon de trapasado de standoj, tiam la metrikoj povus montri la tempon pasigitan de teamoj sur ĉi tiuj standoj. Konante la standon kaj tempon de la teamo, eblis paroli kun ili pli specife pri la kialoj.

Senhezite, Ivan prenis la telefonon kaj markis la numeron de persono, kiu bone konas la enojn de DevOps:

— Denis, bonvolu diri al mi, ĉu eblas iel kompreni, ke la teamo preterpasis tiun aŭ alian standon?
- Certe. Nia Jenkins forĵetas la flagon se la konstruo sukcese ruliĝis (pasis la teston) sur la benko.
- Bonega. Kio estas flago?
- Ĉi tio estas regula tekstdosiero kiel "stand_OK" aŭ "stand_FAIL", kiu diras, ke la asembleo trapasis aŭ malsukcesis la teston. Nu, vi komprenas, ĉu ne?
- Mi supozas, ke jes. Ĉu ĝi estas skribita en la sama dosierujo en la deponejo kie la asembleo situas?
- Jes
— Kio okazas se la asembleo ne pasas la testbenkon? Ĉu mi devos fari novan konstruon?
- Jes
- Nu, bone, dankon. Kaj alia demando: ĉu mi ĝuste komprenas, ke mi povas uzi la daton de kreado de la flago kiel la daton de la stando?
- Absolute!
- Bonega!

Inspirite, Ivano pendigis kaj rimarkis, ke ĉio enfalis. Konante la daton de kreado de la konstrudosiero kaj la daton de kreado de la flagoj, eblis kalkuli ĝis la dua kiom da tempo la teamoj pasigas sur ĉiu stando kaj kompreni kie ili pasigas la plej grandan tempon.

"Komprenante kie la plej multe da tempo estas pasigita, ni indikos teamojn, iros al ili kaj enfosos la problemon." Ivano ridetis.

Por morgaŭ, li fiksis al si la taskon skizi la arkitekturon de la desegnita sistemo.

Daŭrigota…

fonto: www.habr.com

Aldoni komenton