(Time-To-Market).
I o víkendech přemýšlel o metrikách: "A co z toho, že změřím čas? Co mi to přinese?"
Odpovídá to otázce: Co přinese znalost času? Řekněme, že dodání trvá 5 dní. A co dál? Je to dobré nebo špatné? I kdyby to bylo špatné, musíme nějak zkrátit tento čas. Ale jak?
Tyto myšlenky mu nedaly spát, ale řešení nepřicházelo.
Ivan chápal, že se dostal k jádru problému. Bezpočet grafů metrik, které viděl předtím, ho dávno přesvědčil, že standardní přístup nebude fungovat, a že když jen vytvoří graf (), nebude to mít žádný smysl.
Co teď?…
Metrika je jako obyčejný dřevěný pravítko. Měření provedená s jeho pomocí neřeknou příčinu, proč proč by měřený objekt měl mít právě tu délku, kterou ukázalo. Pravítko pouze ukáže jeho velikost, a nic víc. Není to filosofický kámen, ale jen dřevěná deska, kterou měříme.
"Nerezová krysa" jeho oblíbeného spisovatele Harryho Harrisona vždy říkala: myšlenka musí dosáhnout dna mozku a tam si odpočinout, proto po několika dnech neúspěšného trápení se Ivan rozhodl zaměřit na jiný úkol…
Po pár dnech, když četl článek o internetových obchodech, Ivan najednou pochopil, že výše peněz, které internetový obchod získává, závisí na chování návštěvníků webu. Právě oni, návštěvníci/klienti, předávají obchodům své peníze a jsou jejich zdrojem. Na konečnou částku peněz, které obchod získá, mají vliv změny v chování klientů, a ne nic jiného.
Z toho vyšlo, že pro změnu měřené veličiny je třeba ovlivnit ty, kteří tuto hodnotu vytvářejí, tj. pro změnu množství peněz internetového obchodu je třeba ovlivnit chování klientů tohoto obchodu, a pro změnu doby dodání v DevOps je třeba ovlivnit týmy, které tuto dobu "vytvářejí", tj. využívají DevOps ve své práci.
Ivan pochopil, že metriky DevOps by rozhodně neměly představovat pouze grafy. Měly by představovat nástroj pro hledání "vynikajících" týmů, které formují konečný čas dodání.
Žádná metrika nikdy neukáže příčinu, proč nějaký tým dlouho dodával distribuci, pomyslel si Ivan, neboť ve skutečnosti může být důvodů milion a malé vozíky, a ty mohou být zcela ne-technické, ale organizační. Tedy maximálně, co lze od metrik očekávat – to je ukazatel týmů a jejich výsledků, a poté se stejně bude muset jít k těmto týmům osobně a zjistit, co se u nich stalo.
Na druhou stranu, v Ivanově společnosti existoval standard, který vyžadoval, aby všechny týmy testovaly verze na několika stánkách. Tým nemohl přejít na další stránku, dokud neprošel předchozí. Vyplývá, že pokud bychom proces DevOps představili jako sekvenci procházení stánkami, metriky by mohly ukazovat čas, který týmy strávily na těchto stánkách. Znalostí stánku a času týmu by bylo možné konkrétněji mluvit s ním o příčinách.
Ivan se dlouho nerozmýšlel, zvedl telefon a zavolal někoho, kdo se dobře vyznal v nitrech DevOps:
— Denisi, prosím tě, dá se nějak zjistit, že tým prošel tím či oním stánkem?
— Samozřejmě. Náš Jenkins vyhodí vlajku, pokud verze úspěšně prošla (byla testována) na stánku.
— Super. A co je to vlastně ta vlajka?
— To je obyčejný textový soubor typu „stand_OK“ nebo „stand_FAIL“, který říká, že verze prošla nebo neprošla stánkem. Chápav jsi, co tím myslím?
— V principu ano. Píše se do téže složky v úložišti, kde je verze?
— Ano.
— A co se stane, když verze neprojde stánkem? Bude třeba udělat novou verzi?
— Ano.
— No ok, díky. A ještě otázka: Chápu správně, že jako datum průchodu stánkem mohu použít datum vytvoření vlajky?
— Absolutně!
— Super!
Nadšený Ivan položil sluchátko a uvědomil si, že všechno dává smysl. S vědomím data vytvoření souboru verze a dat vytvoření vlajek bylo možné přesně na sekundu spočítat, kolik času týmy tráví na každém stánku a pochopit, kde tráví nejvíce času.
„Pochopením toho, kde jde nejvíce času, přesně najdeme týmy, půjdeme k nim a prozkoumáme problém.“ Ivan se usmál.
Na následující den si stanovil úkol načrtnout architekturu vyvstávajícího systému.
Pokračování příště…
Zdroj: habr.com
