DevOps Report a DORA metrics

vítejte u poslechu podcastu you Build It You runit Podcast o všem co potřebujete vědět když chcete provozovat globální internetovou službu tématem vás provázejí Láďa a Vilda

dnešní díl bude hlavně o tom jak dobře a rychle dostaneme změny do produkce jak poznáte že to děláte dobře A co měřit aby to tak zůstalo neboli když neměříš tak nevíš a neřešíš dřív než začneme tak bychom vás chtěli všechny pozvat na letos již třetí živou panelovou diskuzi tentokrát bude v rámci ponu který se koná 15 a 16 září v Praze budeme mluvit s Naďou jašíková je sá veteránka oci a s Karlem minaříkem který strávil skoro 10 let v elasticu Tak já zdravím všechny ještě jednou a dnešní dnešní téma je hlavně devops report a Dora metricky a možná Láďo Řekni teda začneme zase úvodem Co to je ten devops report tak devops report a vlastně i Dora metricky Všechno je navázaný na knihu accelerate která vyšla někde v roce 2018 a tam vlastně autoři eh kteří jí napsali nicool fors Jess Humble a a Jean Kim udělali takovou revoluci je to vlastně pokračování knížky Continuous delivery která je taky hodně známá a oni to rozpracovali s tím že to nepíšou jenom lidi z praxe ale přidalo se tam vlastně

ten podnět z akademický sfř sféry a oni vybudovali vlastně assessment fops assessment kterej běží každej rok a je to vlastně dotazník kterej jde napříč vlastně firmama po celým světě oni ten vzorek mají velmi pěknej kolem 33 000 lidí vidíte tu demografii v každém tom reportu Můžete se podívat z kolika zemí lidi přispěli v jakým věku kolik mají praxe a podobně a vlastně oni e zkoumají pomocí dotazníků každej rok to je ten devops report e jak se posunulo náš vlastně industrii standardy jak se nový věci etablují ve firmách jak se posouvají ty věci napříč znalostma adap jak se adaptují třeba cloudy hybridní cloudy a tyhle nový trendy napříč firmama protože jedna věc je když o tom Čtete vidíte to na konferencích a jiná věc je kdy to adoptuje nějaká už majorita firem a ty firmy se můžou hodně lišit v tom reportu Máte nějaký hodnocení od nějakých Elit po standardní firmy a můžete vlastně se porovnat udělat si ten assesment pro sebe porovnat se napříč tomu Já osobně si myslím že tam je e samozřejmě link na

ten report a zároveň i na ten takovej jako rychlej dotazník si můžete zjistit jak jste na tom jakoby vlastně v porovnání s ostatníma e Já si myslím že to je něco co by měl kaž v každý firmě každej tým by to měl vlastně dělat sám jo abysme aby protože z mojí zkušenosti sou C je to tak že a nejenom sou vlastně z velkejch z velkejch firem eh většinou je to tak že Eh tam ten rozdíl mezi těma tým různejma nebo divizemi a tak dále je obrovskej a vlastně jako to že u vás to běží skvěle takhle neznamená že ta celá firma vůbec takhle funguje jo To může bejt taky klidně totální výjimka a mně právě přijde zajímavý na tom přesně to dělat interně nejenom se porovnávat s Googlem a s Facebookem to to úplně smysl nedává ale právě když máte desítky nebo stovky týmů jako třeba oci tak ten vhled dovnitř když se jednotliví ty týmy samy evaluuje a potom se to na to někdo podívá jakoby z perspektivy toho manažmentu a tak tak zjistí opravdu ty

rozdíly někdy jsou tak velký že to prostě neč čekáte a spousta těch týmů potom je právě hodně v tom Operation v tom v tom toyu co jsme mluvili a vlastně dá se předejít spoustě problémů do budoucna Pokud vlastně něco takovýho děláte a Snažíte se prostě to zlepšovat jo protože nejde o to že byste někoho jako ty mají špatný výsledky s těma je to špatný ale jde o právě o to jako sledovat ty trendy zlepšovat ty vyrovnávat rozdíly mezi těm tým aby lidi mohli přecházet mezi těma tým nebyli frustrovaný z toho že přejdou do týmu kde to nefunguje a odešli z firmy a podobný věci jo co s tím mám bohatý zkušenosti kdy ty týmy jsou tak odlišný že lidi byť byly pracujou v podstatě jakoby v hodně podobným prostředí tak je to všechno tak jinak že že to je nepřenositelná zkušenost a to je třeba něco co si myslím že není úplně dobrý a tak teď jsme změnili ten devops report a teď ty metriky ty jsou možná zajímavý ty metriky to jako vlastně co se měří

abysme dokázali nějakým způsobem porovnávat ty týmy a jak už jsme řekli v úvodu Je to hodně o tom jak se změny dostávají do produkce a míň vo tom jak ta produkce jako taková běží to to to je spíš ten onc a tak dále To už jsme o tom jsme se docela pobavili v minulejch dílech tak Láďo možná Nahoď Nahoď metriky nebo Nahoď tak nějak jako co měříme tam my mluvíme o tom že je to performance dělíme to do dvou kategorií vlastně software delivery Performance to jsou takzvaný 4 ke Matrix vlastně první z nich je deployment Frequency Jak často organizace Je schopná doručovat releasy do produkce a koukáme se na celou organizaci jo Z hlediska Dora Matrix ne jednotlivý tým ne jednotlivec další ta důležitá metrika je Lead Time For Changes to znamená Jak dlouho vám trvá od Komit do produkce nebo můžete tak na to koukat od nějakýho tiketu vlastně jak dlouho se to dostane do produkce ale spíš se soustředíme na tu technickou znalost To znamená jak ten Continuous delivery proces u vás funguje jestli tam

jsou nějaký manuální stepy a to uvidíte to v tom čase tam bych dodal že že se nebavíme o tom jakle člověku trvá napsat ten kód a tak dále ale bavíme se o toho momentu kdy ten kdo na tom dělal vývojář má pocit že je hotovo a že je připravenej na toto vlastně jakoby nacpat do produkce Tak to nás zajímá tam je potom ještě důležitý e aspekty jestli Vlastně děláte třeba trunk base Development nebo používáte Pool requesty Třeba byla velká studie od Linear beal že právě třeba Pool requesty obzvlášť pokud jsou větší a tak tak třeba přes 50 % toho času vlastně čekají na něco a podobný věci a i v tom reportu najdete vlastně třeba posun k tomu trun bake developmentu aby se to urychlilo nebo jak dobře nastavit procesy kolem půl requestu aby stáli a podobný věci ten další důležitá metrika je change failure Rate a je to vlastně Kolik procent těch deploymentu který dojdou v produkci způsobí nějakej problém a to je hodně Klíčová metrika a ta poslední z těhle delivery Performance Metric je time to

Restore Service Jak dlouho trvá organizaci vlastně recover nout se z toho failu v tý produkci a já myslím že tyhlety čtyři nebo oni jsou čtyři Ale já osobně si třeba kdybych nedokázal měřit všechno najednou tak e za mě change F Rate je úplně zásadní protože v podstatě když dělám změnu a skoro pokaždý to rozbiju tak mám tak něco fakt špatně jo Tam si myslím že že eh vlastně jako v ideálním případě je to jako pod 20 % vlastně v reportu si můžete přečíst nějaký čísla e Vildo Podívej se kolik tam vlastně mají ty elitní týmy ty tam mají od N do 15 % Přesně tak to jsou jakože po 20 % by člověk tohleto chtěl mít dole aby aby vlastně si to nerozbíjí tím že dělá změnu i když jako zkušenost oci je že změna je drt v drtí většině příčina problémů jo Takže když na to nešahám Tak všechno funguje většinou jo kolik maj ty Low Performance týmy Ty se bavíš až 60 % No to je jakože Skoro skoro pokaždý to je jako jdu deploy vat

a jem v nervu protože to pravděpodobně rozbiju No a potom Právě přesně v těhlech týmech taky ty deployment frekvence jsou třeba taky jednou za půl roku prá právě to kvůli tomu strachu že každej druhej deploy se rozbije že jo tam bych ještě dodal zase další zkušenost že Čím větší změny Diplo jete tím větší je pravděpodobnost že to že to rozbijete jo tam není jako je jedno jestli to frekvence je šest měsíců nebo ne ale kolik toho tam vlastně dodáváte čiž jako samozřejmě tam ta proxy s tím časem je že jo ale jako kdyby to teoreticky byl jeden Simple comit jednou za šest měsíců tak asi v pohodě Ale málokdo má jeden Simple comit za šest měsíců většinou se tam naakumuluje strašný kvanta věcí který vůbec nikdo netuší jak Inter reagujou spolu dokovat se to nenahodí že jo a pak se to rozpadá A to je právě vidět i korelace na těch ostatních metrikách když se podíváte do reportu že jo Tak u těch Low Performance týmu ta deployment Frequency je víc než měsíc je víc než měsíc Přesně tak kdež

to u těch Elit je to Daily že jo několikrát ještě denně třeba tak taky trošku záleží na škále upřímně protože eh jsou jsou služby třeba který jsou jako velkokapacitní velký na na na mnoha mnoha regionech a tam jako několikrát denně to v podstatě není realistický vůbec stíhat ale eh ne Nevím o nikom kdo by to dělal méně často než třeba jednou za 14 dní jo i v největší škále co já znám jo což se bavíme třeba 40 regionů prostě A jsou to jako desítky tisíc mašin tak stejně to jednou za 14 dní stíhají a myslím si že to jako všude mít to všude že jak a musíš musíš opečovat všechny ty mašiny přesně Takže jakoby tam tam vlastně jako je potřeba eh Myslím si že snažit se dejova rychle menší kousky co nejčastějc to reálně jde a najít si tu svojí pozici je jako důležitá věc eh jako prevenci právě těch výpadků a druhá metrika kterou já bych vybral jako druhou nejdůležitější z těch čtyř je právě time to Restore To znamená jak rychle já když

se to teda rozbije jsem schopnej to vrátit do hry jo Tam myslím si že existujou v podstatě dva tábory jeden je rollback a druhej je žádnej rollback vždycky Rollover je otázka teď E jako asi možná filozofická Ale za mě z mojí zkušenosti dobře udělanej rollback je možná to nejlepší Obzvlášť když je to třeba distribuovaný tým kde nejsou ty lidi který to dělali nejsou ty co to deploy a tak dále tak asi jako Hele já jdu zpátky prostě mělo by to fungovat Eh je asi správnej způsob a hlavně Pokud se ten rollback testuje před tím nasazením Tak máte docela jistotu že to bude fungovat přesně tam jako je samozřejmě jako rollback kterej netestují je znamená že rollback nemám že jo Vůbec netuším co bude že jo to je jako klasicky e když to nedělám tak to tak nemůžu spoléhat na to že to bude fungovat To je jasná věc No a tohle jsou ty čtyři klíčový metriky ale to najdete všude jako for key Matrix ale ve skutečnosti Dora Matrix má pátou metriku která patří k Operation Performance a to

je reliabilita ta byla přidaná v roce 2021 protože vlastně je vidět ten Trend že od nějaký availability se přechází k ty rel reliability na ty slo na tom protože potřebujete vědět jestli ty vaše frekven ty změny v produkci jaký mají dopad na zákazníky a je to klíčový abyste vlastně deploy rychle ale ten bylo to spolehlivý a ty zákazníci na tom netrpěli protože byznys Prostě potřebuje tu spolehlivost Já myslím že tam je důležitý říct že to je že to je právě ta spolehlivost ta reliability a ne availability protože já můžu mít relativně vysokou availability ale vlastně ten systém jako moc spolehlivej není protože on celkově na to mám jako s tím to je krásně vidět v oci Kde je jako hodně různejch týmů a hodně různě zatížených s různou zkušeností a s různejma přístup je vidět že eh OC jako takový má třeba eh Vlastně když používáte takhle celou platformu tak se to sčítá z těch všech všech pod jako dalších malejch e týmu a tak dále a tam se Třeba ukáže že vlastně jako availability je celkem dobrá ale

reliability jako nic moc nebo horší protože já na to abych udělal nějakej Task kterej já potřebuju jako zákazník udělat tak já potřebuju použít dvě služby a eh ta jedna funguje vždycky a ta druhá občas vypadne Takže já vlastně třeba skončím u toho že mně se jako třeba 20 % mejch požadavků vlastně jako rozbije a jako vlastně to nefunguje funguješ zdánlivě a nebo seš v nějakým specifickým regionu kde jsou větší potíže než je průměr třeba že jo přesně tak takže jako reliability je je rozhodně něco co by lidi mělo možná zajímat víc než jenom banální availability když availability je samozřejmě důležitá věc a tím začnem že jo vždycky je to nahoře jako aspoň plus to zdánlivě funguje je první metrika kterou by člověk měl mít určitě ale ale právě ta spolehlivost je pro ty zákazníky důležitý a je vlastně z hlediska tý organizace se potřebujete vlastně ty metriky navázat i na nějaký organizační To znamená jak celkově funguje Performance v organizaci jestli docích profitabilní cílů to znamená vydělává ta ta služba kterou běháte jo protože Bez toho to nejde ten je to furt

byznys jo neděláme to jako pro charitu že jo To je pravda že asi jako na druhou stranu to si myslím že trápí hlavně hlavně řekněme CEO a tak No a vlastně teď si řeknete jak jakoby to měřit je tady spousta nějakých nástrojů e jak chcete měřit vlastně tyhle metriky hodně závisí na tom v jakým prostředí se pohybujete jestli používáte kubernetes nebo ne je tam je moc pěkná studie od od Googlu já jí

nalinka jejich Big query a tak sbírat ty for key Matrix a o tom jak si to vizualizovat pokud máte data Science Team Tak ty jsou velmi schopný vám sbírat tyhle věci a ideálně když sypete jak ty Operations věci deployment věci byznysový do jedný datový platformy a potom máte přístup ke všem datům eh S tímhle já mám moc dobrou zkušenost z productboardu kde opravdu tahle datová Platforma fungovala Úžasně a všechny ty data se daly dobře korelovat a a visibilita vlastně těch dat pro všechny ve firmě byla úžasná a a opravdu to dělají skvěle já možná jako když si když se na to podívám jakoby z pohledu řekněme nějaký hodně řekněme fakt menší menší firmy jako malý řekněme malý firmy kde se bavíme o tom že tam je pár lidí nebo to tak vlastně Většina z těhletěch bude používat pravděpodobně Buď to github nebo gitlab nebo něco takovýho a to už ty spoustu těch metrik emituje Jo a aspoň třeba z toho ci že člověk je schopnej zjistit třeba todleto a pak když používá nějakej deployment jako

Argo do kubernetes nebo tak tak to už zase Taky dává ty metriky aspoň aspoň některý ty metriky takže Eh tam bych doporučil jako pokud možno vlastně přejít na nějakej co nejvíc nějakej celkem běžně používanej tool protože spousta z nich už dneska ty metriky alespoň nějaký rovnou dává a člověk už pak nemusí Zas tak toho moc vymejšlet Já můžu doporučit pokud používáte kubernetes máte Argo Flux jakýkoliv gits vlastně nástroj tak je projekt který se jmenuje Captain kterej vlastně vám umožní obalit váš deployment proces nějakýma Prama a pos Hama a automaticky emituje metricky v Open telemetry formátu který si strčíte do svý observable systému což je dneska standardní a lehce vlastně získáte ty ty základní čtyři metriky myslím že není moc nad tím přemejšlet AY jste velký tak asi máte dost lidí na to abyste měli data Science Team a měli dostatek Jira tiketu na to aby se to do šesti měsíců zvládlo udělat jo určitě eh tyhle věci kolem měření jsou důležitý a zároveň musíte dávat potom pozor jak zacházíte s těma metrik protože jsem viděl od

nějakejch projekťák a tak že e tím začali potom těm vývojářům jak mávat před očima Jak já říkám a a pozor na to že vývojáři vždycky dokážou optimalizovat na jakoukoliv metriku to lidi Optimal lidi obecně optimalizují na metriku Takže když po mě chcete abych měl hodně hodně e něčeho tak toho hodně budu mít a vůbec nedosáhnu toho co jste chtěli jo to je jako samozřejmě všechno všechny měření jsou nebezpečný v tom že se na to člověk může nebo celá organizace se na to pak adaptuje A ve výsledku všichni mají perfektní krásný výsledky ale na konci to vůbec není to co to má bejt tady bych e Myslím si že používá metriky jako bitch je to co čemu se člověk vlastně chce vyhnout a chce to spíš mít jako e informační charakter jako Hele tady se nějakým způsobem něco zhoršilo tak se pojďme podívat e kde nastal ten problém než jako bičovat lidi za to že něco je špatně hodně firmy se zaklínají vlastně Developer třeba Experience a Developer efficiency což se velmi těžce měří a právě tyhle data vám můžou pomoct třeba

pokud máte platformní tým ve firmě a Snažíte se ty optimalizovat procesy jako je Continuous delivery Continuous deployment Tohle jsou skvělý podklady pro ně na co se třeba zaměřit ale rozhodně pozor na tu optimalizaci Já třeba mám rád hodně gits přístup Pracuju s fluxem s Argo CD a vy byste si řekli že já mám všechno v repozitáři vlastně Každý comit deploy je tam trackovatelný takže já nepotřebuju žádnej další nástroj na to ale jak vyčtete vlastně jak dlouho třeba ten deploy e trval z toho repozitáře to jde velmi špatně nebo jak často tady ta komponenta konkrétní jde do kterýho regionu nebo Mělo to nějaký dopad na nějakýho zákazníka třeba tenhle deploy To jsou věci který vám klasicky třeba git Ops jenom záznam v repozitáři neřekne a na to je potřeba právě to rozšířit o nějaký nástroj jako je ten Captain a mít to jak jako součástí tý observable a zároveň vy potřebujete mít právě tu reliability Takže pokud máte slo sledujete ty Tracy a používáte a propojíte vlastně ty dam metricky s těma produkčním metrik Tak máte opravdu pěknej vhled do toho jak se

vám celej ten systém choval Já myslím že třeba zrovna ta change failure Rate a ten time to restor vlastně ta ta ta ta vyloženě operační Jak jsem rychle schopnej co to dá dohromady zpátky jsou něco co Eh z GTH hops rozhodně člověk Nepozná že jo to je první věc druhá věc je že jsou to zrovna z mýho pohledu jako ty fakt důležitý Takže tam asi bude potřeba jako nějakým způsobem Já nevím jestli to ten Captain vlastně jako dokáže udělat tak aby to vyhovovalo každýmu to asi člověk si to musí trošku eh poupravit ale tole je něco do čeho se rozhodně vyplatí investovat určitě A já si myslím že tam je ještě potom důležitý když zahrnete vlastně do toho nějaký projekťáky vlastně vůbec jakoby projektový řízení Myslete jestli používáte scram nebo jeru a podobný věci tak potom spoustu najdete třeba příspěvku na internetu od Linear B který mají produkt podobnej jaře vlastně který mluvěj o damet trikách v tom smyslu že Pojďme trasovat vlastně celý Pool requesty abysme zjistili Ne comit ale vlastně celou furu kdy se jakoby dostane

do produkce a zároveň třeba kolik toho Vlastě vlastně není naplánovaný a dostane se do tý produkce a vlastně není na to žádnej tiket a oni mají takovou pěknou fičur která se mi tam líbila že vlastně když Pool request nemá Ticket tak oni to automaticky uměj vytvořit aby vlastně třeba pro tomu projekťáky a tak už viděl měl náhled do toho že lidi ve skutečnosti naplánují něco do sprintu udělaj ale třeba jako ten počet bodů je stejnej On vidí ta velocita z hlediska sramu je moc pěkná ale oni půlku těch věcí co naplánují neudělají a přihodí se jim tam něco protože jsou nějaký problémy prostě a oni musej měnit obsah sprintu což se nemá dělat ale jako něco je donutí třeba a nebo další věci a získat tu visibilitu jako ve větších celách jakoby co se týče celý fiury nebo jakoby kusy Road map není vůbec jednoduchý to j docela dobře připomněl ty sprinty to jsme zmiňovali jak to nemáme moc rádi a myslím si že tady právě je krásně vidět že ty sprinty příliš nefungujou v tomhletom prostředí

proto protože velice často člověk musí ten tým musí nějakým způsobem reagovat na nějaký podměty zvenku že něco ne Nějaký výpadek objeví se Bak objeví se novej zákazník který to používá novým způsobem zátěž a tak dále a todle vlastně velice často nikdo nikdy nějak netrek to se prostě rychle opraví ale vlastně o tom není záznam není to měřený A tím pádem jako ten tým může vypadat že třeba je hrozně pomalej přitom oni v reálu Ty vývojáři jsou fakt z přetížený a v podstatě makají do plnejch a na vch to vypadá že se nic neděje Jo to jenom k tomu že pokavaď to člověk neměří tak o tom fakt neví a většinou to ani neřeší A Eh dochází k tomu že se vlastně neřešej pak problémy který vlastně v reálu existujou a Takže já třeba si myslím že zrovna ten přístup dělám fix existuje k tomu tiket kterej zachytí tu práci aby nezmizela a aby to bylo vidět přesně vlastně i z hlediska třeba Sar jakoby trackovat toil to znamená tu extra práci je těžký je to náročný ale

je to potřeba dělat protože vy opravdu potřebujete mít kapacitu na to se s tím vypořádat a dlouhodobě plánovat věci abyste to odbourali A proč něco nefunguje dlouhodobě je o tom že vlastně ten toil jakoby převálcuje ty týmy a oni opravdu potom jsou zoufalí ty lidi odcházej měněj se a vlastně pokud by to často třeba ty manažeři nebo ty projekťáci viděli tak oni jsou schopný třeba s tím něco dělat ale vlastně oni o tom neví často nebo to ví ten jejich manažer ale ten nadřízený už se to nikdy nedozví a podobný věci na tole jsem viděl krás jasnej Slide eh v nějakým to teď nevzpomenu si kde kde bylo Pohled pohled jakoby manažmentu jako řekněme toho vyššího manažmentu ne teď toho jako Team le a tak dále ale řekněme nějaký jako VP level a tak dále Kde byl jako představa většiny lidí je že tam je že tam Letí orel kterej vidí každej detail v reálu tam e možná Letí orel ale jsou tam všude mraky a on vidí jenom takový špičky kopců a jinak neví

co se děje Jo a to se v reál to takhle to v reálu vypadá a proto vlastně e třeba zrovna tadyhle ty metriky jsou něco co může se propagovat dobře nahoru aby všichni viděli aby byla ta aby ta byla viditelnost byla co největší i pro i pro to vyšší vedení protože někdy se stává že přímej [Hudba] management třeba upřímně stojí za prd To mám s tím zkušenost kdy manažer vlastně jako se staral hlavně o sebe aby on vypadal dobře nikdy za NC nemoh všechno bylo jako z jeho pohledu perfektní a jenom vývojáři a tlačil to vlastně jakoby na vývojáři ty problémy a nebylo jak to pořádně ukázat vlastně eh ukázat to vlastně k vyššímu vedení tak jenom eh proč to možná měřit a s tím bych se možná rozloučil e My bude tam bude h tentokrát ty bude hodně odkazů a hodně čtení dalšího Takže já vám mockrát děkuju a zase někdy neslyšené a Láďo ty ještě možná zopakuješ zase pozvánku ne určitě ta naše živá Akce bude na ponu od 15 16 září běží pajon v Praze letos už tam

bude po třetí příležitost si s náma popovídat Pokud máte dotazy budete je moct položit případně nás můžete odchytit na ponu my tam určitě budeme a po kdybyste to nechtěli na Pon A náhodou jeli na ne konferenci J Open Space 6 až 8 října tak tam budeme taky Tak jo díky moc a brzo naslyšenou brzo naslyšenou Díky že jste si poslechli tento díl podcastu Pokud se vám Podcast líbil budeme rádi když o tom někomu řeknete nebo nasdílíte třeba na sociálních sítích sledujte nás na mastonu nebo na linkedinu aby vám neušla žádná [Hudba]