(Čas nakupovat).
I o víkendech přemýšlel o metrikách: „A co když budu měřit čas? co mi to dá?
Co vlastně dá znalost času? Řekněme, že doručení trvá 5 dní. Takže, co bude dál? Je to dobré nebo špatné? I když je to špatné, musíte tento čas nějak zkrátit. Ale jak?
Tyto myšlenky ho pronásledovaly, ale žádné řešení nepřicházelo.
Ivan pochopil, že došel k samotné podstatě. Nesčetné grafy metrik, které předtím viděl, ho již dávno přesvědčily, že standardní přístup nebude fungovat a že pokud jednoduše vykreslí (), nebude to k ničemu.
Jak být?…
Metrika je jako obyčejné dřevěné pravítko. Měření provedená s jeho pomocí neřeknou důvod, proč měřený předmět je přesně na délku, kterou ukázala. Pravítko prostě ukáže svou velikost a nic víc. Není to kámen mudrců, ale prostě dřevěná deska, se kterou se měří.
„Nerezová krysa“ jeho oblíbeného spisovatele Harryho Harrisona vždy říkala: myšlenka se musí dostat až na dno mozku a tam ležet, takže poté, co se Ivan několik dní marně trápil, rozhodl se přijmout jiný úkol...
O pár dní později si Ivan při čtení článku o internetových obchodech najednou uvědomil, že množství peněz, které internetový obchod obdrží, závisí na tom, jak se návštěvníci webu chovají. Právě oni, návštěvníci/klienti, dávají obchodu své peníze a jsou jeho zdrojem. Konečný výsledek v hotovosti, který obchod obdrží, je ovlivněn změnami v chování zákazníků, nikoli ničím jiným.
Ukázalo se, že pro změnu naměřené hodnoty bylo nutné ovlivnit ty, kteří tuto hodnotu tvoří, tzn. pro změnu množství peněz internetového obchodu bylo nutné ovlivnit chování zákazníků tohoto obchodu a pro změnu dodací lhůty v DevOps bylo nutné ovlivnit týmy, které tuto dobu „vytvářejí“, tzn. používat ve své práci DevOps.
Ivan si uvědomil, že metriky DevOps by vůbec neměly být reprezentovány grafy. Musí reprezentovat sami sebe vyhledávací nástroj „vynikající“ týmy, které utvářejí konečnou dodací lhůtu.
Žádná metrika nikdy neukáže důvod, proč tomu či onomu týmu trvalo dodání distribuce tak dlouho, pomyslel si Ivan, protože ve skutečnosti jich může být milion a malý vozík, a ty nemusí být dost technické, ale organizační. Tito. maximum, co můžete od metrik očekávat, je ukázat týmy a jejich výsledky, a pak stále musíte tyto týmy sledovat nohama a zjišťovat, co je s nimi špatně.
Na druhou stranu Ivanova společnost měla standard, který vyžadoval, aby všechny týmy testovaly sestavy na několika lavicích. Tým se nemohl přesunout na další stanoviště, dokud nebyl dokončen předchozí. Ukázalo se, že pokud si proces DevOps představíme jako sekvenci procházení tribun, pak by metriky mohly ukázat čas strávený týmy na těchto tribunách. Díky znalosti postoje a času týmu bylo možné s nimi konkrétněji mluvit o důvodech.
Ivan bez váhání zvedl telefon a vytočil číslo člověka, který se dobře vyzná ve všech detailech DevOps:
— Denisi, prosím, řekni mi, je možné nějak pochopit, že tým prošel tím či oním stánkem?
- Rozhodně. Náš Jenkins odhodí vlajku, pokud se sestava úspěšně rozjela (prošla testem) na lavičce.
- Výborně. Co je to vlajka?
- Toto je běžný textový soubor jako „stand_OK“ nebo „stand_FAIL“, který říká, že sestava prošla nebo selhala ve stojanu. No, rozumíš, ne?
- Hádám že ano. Zapisuje se do stejné složky v úložišti, kde se nachází sestavení?
- Ano
— Co se stane, když sestava neprojde zkušební stolicí? Budu muset udělat novou stavbu?
- To jo
- Dobře, děkuji. A ještě dotaz: rozumím tomu správně, že jako datum stánku mohu použít datum vytvoření vlajky?
- Absolutně!
- Výborně!
Inspirován Ivan zavěsil a uvědomil si, že všechno zapadlo na své místo. Díky znalosti data vytvoření souboru sestavení a data vytvoření vlajek bylo možné s přesností na vteřinu vypočítat, kolik času týmy stráví na každém stanovišti, a pochopit, kde tráví nejvíce času.
"Pochopíme-li, kde se tráví nejvíce času, určíme týmy, půjdeme k nim a prozkoumáme problém." Ivan se usmál.
Na zítřek si dal za úkol načrtnout architekturu rýsovaného systému.
Chcete-li se pokračovat ...
Zdroj: www.habr.com