On-Call: Jak to udělat správně

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

z you Build It You Run it se dneska budeme i nadále bavit o té runit části a hlavně o tom jak poznáte že děláte oncol dobře udržitelně a že plní účel taky se podíváme na to Jaké nástroje vám mohou pomoci a bez kterých se fakt neobejdete Láďo než začneme podrobněji rozebírat onkol možná bychom měli říct jak taková směna vlastně vypadá a čím se člověk vlastně nejvíc na ní zabývá a ať ty co třeba ještě nemají tu zkušenost si dokážou vlastně udělat představu jak prostě každodenní on Call tak vlastně eh každej oncol začíná takzvaným handover vy přebíráte službu od někoho jinýho můžete i v různej čas My jsme třeba měli doporučený že jsme to dělali v 600 večer Pražského času aby to bylo v 9:00 ráno amerického času pro ty lidi z USA a v tom hanoveru vy si předáte to co se stalo za tu předchozí shiftu eh službu toho člověka a to co on má rozdělaný protože on může nějaký incident stále probíhat Něco se děje eh může běžet třeba nějaká konverzace s nějakým supportem třeba

řešíte Já nevím navýšení databáze něco podobnýho co je potřeba vaši pozornost a aby to nespadlo někam někam prostě e pod váš stůl a nikdo by se tomu nevěnoval takže to začíná ta služba potom musíte mít je dobrý na tom než vlastně začne ta služba si otestovat že máte všechno že jste schopný se přil lagovat do všech systémů že máte ty přístupy do těch do těch systémů bejvá na to nějaký checklist kter pomocí kterýho vlastně si ověříte že máte všechno potřebný k tomu často bejvá problém třeba tu faktorová autentizace Pokud byste se vám byl hardwarový klíč tak nemůžete vlastně onc dělat e a další věci takže to a samozřejmě musíte mít počítač musíte mít přístup k internetu a a a tak dále případně nové penky adapt schopnej se přil lagovat vlastně všude a mít přístup do všech produkčních systémů ke kterých byste teoreticky potřebovali přístup kdyby se věci nedařily jak mají přesně tak No a v rámci tý služby Pokud jste mimo pracovní dobu Tak jdete spát prostě nebo normálně prostě fungujete s rodinou večeři všechno a řešíte jenom když se vám ozve

pager takže to když jste v dobrý službě máte dobrej tým Tak se se vám to stane třeba maximálně jednou týdně ideálně ještě v pracovní dobu prostě a neřešíte takže to je v pohodě Potom ale když jste normálně v pracovní době tak řešíte ty jak jsme říkali ty věci proaktivně To znamená kouknete vlastně na tikety co vám tam spadaly mrknete na ty vlastně Low priority věci který vás nebudily protože je dost možný Pokud máte dobře nastavenej systém že tam k alertů došlo ale alerty vás nebudí nebyly to takzvaný page ale staly se z toho obyčejné obyčejné tikety ve vašem tiketovací systému a vy jste o tom abyste je vyřešili To je vlastně ten důležitej přístup když potom budeme mluvit o alerte že vy musíte když se snažíte vytvořit ten Alert tak byste měli dost dobře vědět jak to nebezpečí je důležitý jestli je potřeba vzbudit někoho ihned a nebo stačí počkat do pracovní doby a třeba doba vyřešení je 8 hodin nebo 12 hodin typický příklad kterej je ve všech příručkách najdete je dochází místo na

disku takže je potřeba vlastně umět spočítat nějakou lineárně extrapolaci a říct že to místo dojde za čtvrt hodiny potom Pju toho člověka a má to nějakou High prioritu místo dojde za dva týdny udělám tiket jenom jsem chtěl říct že to j mi připomněl typickej scénář kterej jsem viděl tolikrát že se že mě se chce možná spíš brečet než smát nebo nevím ale že ve 3:00 v noci přesně budí Alert 95 % místa na disku a přitom tempu sou přesným tempu toho jak dlouho to bude trvat tak by se došlo místo za tři neděle jo tak todle opravdu je něco co člověka neví jestli má se smát nebo brečet No a bohužel Jako přesně to máme smůlu že nám to vyjde teda na noc Američanům na den Většinou protože nevím přijde mi že všechny ale ty jsou nastavený na americkej Traffic nebo něco takovýho málokdy se to stane ale přesně to se stává on tam je důležitý vlastně vždycky ten počet těch alertů ten člověk e není schopnej mentálně a vlastně ani fyzicky e zvládat tých e enormní

množství a potom co se děje je že vlastně i když máte nějaký rozdělený těch alertů podle tý priority já ono se uvidíte všude třeba severity 1 2 3 4 5 a podobný věci ale já mám mnohem radši to rozložení jenom High priority budím člověka Low priority řeším v pracovní době Myslím si že právě to názvosloví když se říká page je to co budí člověka tiket je všechno ostatní je je správná a tam vlastně je potřeba ještě furt držet nějaký rozumnej počet protože pokud budete mít 100 tiketů za den tak se nikdy k těm Low priority nedostanete a budete rádi že zvládáte prostě ty nejdůležitější a Když uvidíte nějakej vlastně paging systém svýho týmu novýho vejdete tam a zí Víte že mají 100 page denně tak utečte radši jako já osobně Teda na základě zkušenosti bych řekl že co se pageová ní týče tak cokoliv víc než když budu hodně eh teď nevím jak to úplně říct hezky ale řekněme že budu hodně ochotnej toho hodně trpět tak si myslím že jako 10 15 je možná číslo o kterým se bavíme Ale

cokoliv na to už je jako na pováženou protože většinou page znamená znamená něco mě budí nepř mě ruší z práce kterou teď zrovna dělám a musím jít něco musím udělat to je nějakej kontext switch kterej musím udělat Musím se přihlásit teď nevím Musím se zorientovat rychle Je to člověkem někdy docela stresující záležitost a absolovat todleto e dejme tomu když budu mít směnou celej tejden absolvovat tohleto třeba 50krát za tejden eh jako já už teda nejsem úplně nejmladší ale ani ve 20 by mě to nebavilo Jak přesně tak jako já pro mě to byl vždycky ST stres Já já já jako dopad toho stresu na sobě jsem cejtil když člověk byl mladší tak mě to spíš jako jako povzbuzovalo a podobný věci ale teď jak je člověk starší tak přece jenom třeba dopady na ten spánek pro mě jsou důležitý Já jsem člověk kterej spí hodně a spí dost pravidelně Takže jakýkoliv rozhození toho toho spánkového cyklu nesu e špatně a proto vlastně vždycky jsem taky dbal na to aby ta kultura byla kolem toho rozumná protože přesně potom se stane že

když těch tiketů je moc tak ten onkol ta kvalita tý služby se není šance jí posunout jako dobrým směrem protože vy máte takovej malej buldozer který hrne jenom to nejdůležitější a nejste schopný vlastně přijít na ty příčiny a řešit vlastně ty věci v tom v tom kořenu V těch příčinách opravdovej že je nějaká systematický problém protože na změnu systematickou potřebujete aby na tom problému někdo soustavně pracoval po nějakou delší dobu a zároveň měl jakoby feedback z toho co v tý produkci je špatně a vlastně když utopíte v tý operativě v tom toju jak se říká fesi ty lidi na 100 % a ne ne nedáte jim nějakou přesnou definici Já jsem se vždycky snažil aby ten toil nikdy nepřekročil nějakých 40 % jejich práce tak se to prostě neposune A vždycky je potřeba dávat prioritu na ty věci co jako nejvíc přinášej toho toju do do tý práce a dělat opravdu věci který to posunou a opravdu to zlepše a je opravdu smutný když člověk zná některý týmy který toho měli hodně že jim Vlastně nikdo

dlouhodobě nepomoct a člověk se na ně podívá po roku po dvou a oni jsou tam kde byli před dvouma rokama jenom se tam měněj lidi protože ty lidi vyhoří a prostě nic dalšího se s tím nede dělá Já jsem možná jsem si říkal že bysme možná měli trošku nadefinovat eh asi trošku terminologii protože tady říkáme page říkáme incident říkáme eh Alert A může to budit dojem že to je možná to stejný Možná to není to stejný do toho přehazujeme tiket a tak dále já třeba eh mám pocit že třeba ale jako z mýho pohledu Alert je něco to je událost Alert je to stejný co page prostě to nějakým způsobem dává vědět že se že už je něco fakt špatně zároveň často se k tomu používaj e vlastně Alarmy Na metrikách a ten alarm to je signál že něco nějak že se stala nějaká událost na kterou pak můžem reagovat právě třeba page a nebo to není tak tak vysoký priority a a tím pádem to může bejt nějakej tiket A Eh Třeba já v oci

vlastně je jakoby je tam používáme tedy Je tu severity 1 2 3 4 5 je to tam jasně rozříznu jednička jednička je vlastně něco co se automaticky nikdy neudělá Jednička je tam od toho že to je jako situace která se dotýká mnoha týmů a vlastně to nastartován nějaký jiný procesy který běžně eh ten tým nemá a je to třeba něco Eh co co má jakoby řekněme obrovskej dopad nebo je to je přesně tak je to výpadek celýho regionu nebo nějakej takovej zásadní průšvih kde vlastně to vzbudí a automaticky to vzbudí a vlastně to natáhne i jakoby eh vlastně management jo ř řekněme jako ten někoho kdo může dělat tyhlety ty byznysový rozhodnutí a tak dále e zároveň pak třeba se ty nižší priority používají právě na to aby člověk si mohl rozložit co co je třeba událost jakoby čistě informační protože to je třeba z vývojového prostředí nebo není to řekněme tak tak důležitý a pak třeba jsou právě jakoby ta nižší priorita třeba trojka je vlastně něco co když to nebudu Když to budu dostatečně dlouho ignorovat

Tak mi to pak vybuchne a bude z toho dvojka a já můžu aktivně na tom teďko proaktivně zamakat v mý pracovní době opravit to hned Třeba identifikovat a tak dále nebo případně přijít na to jakýže je dlouhodobý řešení a tak dále takový různý věci abych se moh vlastně vyhnout tomu že mi to pak vzbudí za 2 hodiny za 4 hodiny prostě v noci No já to beru tak že ten Alert je přesně jak jsi říkal To je ten Trigger ale potom právě tam Musí dojít k tomu rozhodnutí jakou to má prioritu a podle tý priority se z toho stává ta page nebo Ticket Jo takhle já to mám v hlavě protože přesně je je důležitý prioritu určujeme podle prostředí podle toho dopadu Pokud jsme ho schopný nějak jako zkalkulovat a potom právě takzvaná timeless nebo jak rychle Je to potřeba vyřešit vlastně A to jak jsme mluvili o tom disku jestli je to potřeba řešit hned nebo ne Tím pádem když je tam ten čas tak spadne ta priorita tady třeba na seev 3 jak jak

uváděl Vilda a je to o tom že potom když mám oncol tak to řeším v pracovní dobu aby z toho ta sf2 nebyla protože přesně to tam ještě musí bejt implementovaný a to taky ne všichni mají ale třeba oci vím že to dobře má vyřešený že je tam ta eskalace když se to nevyřeší jako trojka tak se z toho stane někdy ta dvojka a někoho to vzbudí bez ohledu na to a zrovna ta eskalace na dvojku se děje myslím o půlnoci že jo takže to budí Takže záleží zrovna kde člověk je a tak dále no může může a nemusí budit No takže to je důležitý No potom celej ten incident proces Vlastně když dojde k tomu incidentu tak je jako nadlouho tam je spousta částí který dneska e nevyřešíme jsou tam potom nějaký postmortem nějaký procesy na hledání analýzy je tam něco o tom jak bysme se měli poučit vlastně z toho incidentu jak to promítnout přes třeba nějakej chaos Days do tréninku vlastně lidí na onkol jak vzdělávat lidi zpátky a tak na to

Uděláme nějakej samostatnej díl e 100% to je jako ve skutečnosti jedna z nejdůležitějších věcí eh nebo výstupů jeden z nejdůležitějších výstupů vlastně jakýhokoli incidentu je přesně ten ten feedback je to nejdůležitější co z toho chcete dělat a je tady skvělá konference v uvedeme v link pod video která se jmenuje Learning from incidents která má videa už na webu z letošního roku Doporučujeme shlédnout je tam spousta velmi zajímavejch e přednášek o různejch perspektivách třeba z jiných oborů e kde profesor Wood třeba krásně ukazuje aplikace které vlastně vyzkoumali v medicíně Jak se dají aplikovat na informační technologie jak problém tunelového vidění je napříč obor nejenom nejenom eh nejenom v medicíně a tohle z toho si můžeme vzít strašně moc pro to jak vylepšit svoje vlastní procesy Vildo a kolik vidíš že těch alertů je jako příliš Teď jsme se tom bavili o tom kolem tý 50 když buduju úplně novej tým a vlastně nemám tu tu zkušenost moc Kolik kolik to jak jak bys viděl jak by jak bysme měli nastavit jakoby eh jestli nás to má víc Budit nebo míň

budit jak bys to udělal na začátku když ještě jako nevíme úplně kolik toho je No tak na základě různých diskuzí s různejma lidma z různých míst všichni doit terovel k tomu že by jako za tejden těch page page jako ideálně člověk měl mýt jako třeba do pěti že to je takový zvládat jeden denně v průměru to vychází že to se dá eh když se to nenakupuji jsou situace kdy se to nakupí eh a to je potřeba mít pak třeba ošetřený právě eskalací a tahám další lidi a pomáhají mi víc a víc lidí Každopádně eh Jde o to aby vlastně člověk pokud možno si co nejmíň narušoval eh tu řekněme rekonvalescenci těch lidí abysme se nevyčerpávali na tom že prostě v noci hasíme požáry Takže bys byl hodně opatrnej s tím když třeba začnu tak všechny alerty bych dal seev 3 jako nějakou defaultní hodnotu a Opravdu bych se koukal jestli tady to je ten případ kdy ten člověk opravdu musí bejt e musíme ho vzbudit To znamená tady ten dám do se ne že všechno dám seev D a

potom jako uvidíme Já já jsem zastánci toho že jako vlastně si mám vymyslet já by jako moje Moje strategie vždycky byla já mám eh jeden alarm kterej mi říká jestli jsem nahoře nebo ne A tím začnou a ten budí protože když je dole todle tak je to AS asi dole a tím začnu a pak začnu vylepšovat tadyhle tu hodně hrubou e vlastně rozliš mám jedno rozlišení tak začnu přidávat další data pointy k tomu Jestli teda jo nebo ne e protože jinak se člověk se člověku snadno může stát že vlastně toho má jako hodně a začne mít všechny ty negativní začne se vlastně adaptovat tím negativním způsobem to znamená začnu mít něco co se nazývá Alert fí jo alerty tenhleten nic nedělá nevšímám si ho ale nic s ním už neudělám nevypnu ho nezruším ho prostě tam je co kdyby náhodou další takový mentální trik který vlastně My lidi máme je že to tam necháváme protože co kdyby náhodou se to hodilo No to je právě přesně ten špatnej způsob ty člověk chce začít s tím že vlastně

tam přidává když zjistí že to nefungovalo prostě když to fakt nešlo jinak aby aby si zachoval tu chladnou hlavu a naopak se snažil aktivně řešit aktivně řešit e když vlastně jako přes den když pracuje takže zároveň Třeba je pro mě nebo já to vnímám jako velkej problém je že když se vlastně když je někdo on Call tak a není aktivně nějakej jako velkej výpadek nemá to to Takže aktivně nepracuje že pracuje na něčem úplně jiným na nějaký fatře nebo čemkoli a nepracuje v podstatě na tom aby Buď to zlepšil ten kol proaktivně řešil problémy a tak dále To je třeba zase další věc kterou taky která je taky často vidět a je to samozřejmě jako balans jo já když se když nás bude když to bude fir firma o třech lidech o pěti lidech tak jako vlastně Asi jsme všichni onkol tak nějak furt a všichni děláme všechno furt když je nás 15 už bysme v tom měli mít nějak to mít nějak zorganizovaný A nějakým způsobem fungovat že jo a když je nás Prostě 1500 tak e ty procesy by měly

bejt náležitě tomu naškrábaný určitě eh Ještě jsme říkali že se dotkneme těch nástrojů e kolem toho oncu jaký ty vidíš zmiňovali jsme tady page Duty v minulým díle jako ten pageová ná nástroj uváděl jsem ty další vlastně jako je spun on Call a ještě od Atlasu vlastně e ten jo z Číny a No to je atlas nebo ne Já nevím kdo už to co má jak ale každopádně vždycky člověk potřebuje nějakej pageová mechanismus To znamená jak já dám vědět že to je jako fakt špatný a v ten moment by ideální bylo ale taky zároveň aby mi to nějak pomohlo v tom přijít na to co se děje To znamená Kam se mám podívat a tak dále ve skutečnosti to může jenom vytvořit nějakej tiket někde ale ať mi to dá ten link na ten tiket ať já rovnou se můžu podívat a rovnou to můžu začít nějakým způsobem řešit To si myslím že ve skutečnosti je jako todle nějakej mechanismus na vlastně spouštění tadyhle toho pageová to znamená Asi bych měl mít nějaký alarmy Jo a to znamená něco

používal k tomu No obsil přesně tak nějakou jako viditelnost do těch věcí Protože E jako už jsem hodněkrát viděl systémy kde vlastně jako někde nějaký metriky se lejou ale jako není tam žádnej alarm nikdo to jako nesleduje vlastně aktivně je to jakože co kdyby náhodou jak vidíš nástroje typu E typu incident IO nebo Roly který pomáhají vlastně dneska eh vlastně ten proces který máte nějak nastavenej třeba zorganizovat ve slek kanálu vlastně to jsou nástroje který vám vlastně z když nastane ten incident tak oni vám automaticky vytvoří kanál třeba ve sleeku pozvou tam všechny lidi který jsou interes ný v tom s leku shromažďují se tam všechny ty informace Když to vyřešíte automaticky to publikuje zprávy do jinejch kanálů aby třeba vedení mělo přehled umí to updatovat status page a na konci vám to vlastně udělá timeline se všema informacema v tom kanálu abyste měli vlastně jednodušší potom ten postmortem proces jako kdybych dneska začínal tak rozhodně jedno z toho použiju protože ono to pomáhá s tím že to vlastně kodifikuje celej ten proces Takže člověk pak nemusí ho vymejšlet

když třeba nemá tu zkuš š enost tak to co to co tam vlastně je Jako out of box je rozumnej způsob jak bych to dělal a když můžu tak proč ne samozřejmě je to mnohem složitější V momentě kdy to člověk nedělal nebo to dělal mizerně a chce se zlepšit Tak todl to nemusí bejt nezbytně nutně jako e ta správná cesta protože to samozřejmě zase integrační nástroj musím používat slek třeba nemám slek třeba používám něco jinýho začne se to komplikovat Každopádně mít něco co mi pomůže pomáhá s s prací s tím s tím incidentem abych já se nemusel teď jako pamatovat Prostě 50 kroků je jako fakt užitečný aby člověk věděl teď mám udělat todle První krok co musím je jako udělat nějakou mitigaci to znamená aby už vlastně ten dopad nějakej negativní dopad na zákazníky neexistoval to je první krok a pak vlastně najednou potřebuju Zdokumentovat všechno potom A to je třeba něco Kde jako nějakej nástroj je užitečnej a samozřejmě to potom umí řešit dobře třeba komunikaci jo vy musíte komunikovat s vaším supportem se

zákazníkama třeba přes status page nebo právě jak jsme mluvili minule o třeba o eskalaci na Legal tak můžete mít podmínkách někde ve smlouvách že informujete pokud je to třeba Security incident a je to sef 2 tak informujete zákazníky do x hodin a mají to někde ve smlouvě takže mít na to prostě potom že to vyrobí tiket někam kde se o to postarají třeba a podobný věci plus co já vidím jako největší přidanou hodnotu je že vám to shromáždí ty data na tu timeline a že to nemusíte dělat ručně je to potom hromada ruční práce když když děláte ten postmortem a tyhle nástroje vám pomůžou krásně to udělat 100% jako když když to nemůžete použít tak možná jenom jako koukněte jak to dělaj a prostě to zkopírujte jako a do toho svý do těch svejch systému to nějakým způsobem můžete dostat třeba eh jako eh Jira není jako Jira je hrozná ale na druhou stranu ty workflow se tam dají nastavit tak že si to tam člověk vlastně takovým nějakým způsobem může dát a a může z toho jako spoustu věcí vidět

určitě a třeba page Duty má vlastního nějakýho slack bota právě Jelly a Yo mají vlastního slack bota zdarma který vlastně tyhle věci umí dělat a dá se tyhle nástroje využít a když už máte potom ten nástroj jako page Duty Tak co je na tom zajímavýho je že vy dostanete spoustu metrik vlastně jste schopný a vlastně i ty nástroje třeba jako Rotel a tak vám pomáhají potom dobře stanovit metriky který vám můžou něco říct o tom jak vlastně v jakým stavu tu vaši produkci máte A když se na To koukáte jako manažer tak potom jsou metriky typu me time to detect která vám vlastně říká Jak rychle jste našli ten incident a tam je hodně dobře vidět třeba pokud vlastně došlo k tomu alertu automatickému a nebo ten incident třeba spustil support a ten ten incident ve skutečnosti se stal už třeba 48 hodin předtím a vy když to dohledáte a správně to zaznamenáte tak přesně to jsou ty díry který jsou mnohem důležitější protože já jsem kolikrát zažil že to vyřešení ten meantime to resolve je třeba 10 minut to se vyřeší

lehce když se na to přijde ale ten me time to detect byl třeba 40 hodin protože se to stalo v sobotu ráno a do pondělka dopoledne na to nikdo nepřišel hlavně jako nikdy nechcete aby váš zákazník vě viděl dřív než vy že je něco špatně jo to je jako epic fail za mě jo ale bohužel i to se děje protože když je to jenom na nějaký fiu tu skoro nikdo nepoužívá a podobně může se stát naprosto a každopádně Třeba tahleta metrika je fakt užitečná a ukazuje o tom jako vlastně jako jestli ten člověk Ten onkol dělá dobře To je jedna z nich eh Ty jsi zmínil tu meantime to resolve ta je taková jako e bych řekl že se na tom shodujeme že je celkem problematická protože ta říká jako když jsme to jako celý vyřešili Což ve skutečnosti možná není to nejdůležitější protože vyřešit incident ve skutečnosti to nejdůležitější na incidentu je e vlastně zbavit se jeho dopadu na zákazníky na vnější prostě zákazníky To znamená že já to můžu voix vat tím že udělám

rollback a je to dobrý a už to nikoho už to nikoho vlastně jako Nemá ten žádnej dopad to nám kryje me time to mitiga jasně to se dostáváme právě k tý meantime to mitiga která je zajímavá protože to je jak rychle já jsem byl schopnej eh vlastně ten e to je Já nevím jaký český slov dopady zrušit dopady nebo No mitigace prostě nevím jak to vlastně odstín dopady tak možná že to je hezký slovo To je možná ta nejdůležitější věc To je ve skutečnosti to první co člověk dělá že jo a to nejdůležitější Vlastě No a pak vlastně jestli to trvá vyřešit Jako kompletně jestli to trvá dva dny pět dní sedm dní To je taková jako nevím no nic moc zajímavýho No protože to můžete taky vyřešit dobře a špatně a rozdíl je právě to jestli tomu dáte půl hodiny nebo dva dny a a to je to důležitý a plus pozor na tu zkratku mttr protože to je meantime Tour resolve ale taky meantime to Recovery což je úplně jiná metrika a to je za jak dlouho

jste ze svého disaster Recovery schopný celou službu znova nastartovat třeba když dojde k výpadku celýho regionu Nebo úplně vám odejde hardware třeba a musíte vy provision vat novej hardware naopak tady to je velice důležitá a jedna z nejdůležitějších metrik co se co se eh tadyhle těch jako fakt černejch scénářů týče určitě a ta zrovna to me time to Recovery patří k metrikám o kterých budeme určitě uděláme nějaký díl ty se jmenujou for key Matrix patří mezi Dora Matrix a tam patří ještě právě deployment Frequency Patří tam Lead time to Changes a change failure Rate a to je to vám něco říká o vašem vlastně procesu nasazování a jak dobře to děláte No to to je to k je vlastně úplně všechny části toho proto to taky se o tom budem bavit protože to kraje jak tu Build it tak tu runit část kdy třeba vlastně nejčastějším nejčastějším případem Proč máte incident je protože jste něco deploy vy jste něco změnili Takže jako a samozřejmě člověk se snaží dostat do bodu kdy změna nerovná se jako

výpadek že jo žádnej ideálně což myslím že zatím neexistuje No a k těm oncol metrikám nám zbývá ta poslední a to je meantime bitv Fail kterou já moc rád nemám právě proto že z hlediska samotnýho oncu a vlastně těch Sasov služeb třeba to moc taky neříká to nemá žádnou taky si nemyslím že to má nějakou užitnou hodnotu to má užitnou hodnotu právě Třeba v těch jako řekně nějakejch hardwarových a tak dále a podobnejch případech kdy to opravdu člověku říká nějakou statistickou distribuci toho jak jak rychle může kdy může očekávat zase nějakej problém ale vlastně vlastně jako v případě takovejhle služeb to vlastně nedává žádnej smysl Takže třeba bys řekl že když budu mít vlastní datacentrum tak přesně sledovat Třeba nám to udávat Jak často nám odchází disky nebo nj takový přesně to mi pomáhá protože já můžu pak jako predikovat že jo jako jak rychle budu potřebovat třeba náhradu Kolik bych měl mít skladových zásob náhrad abych to dokázal udělat rychle a tak dále ale není to něco co by mě zrovna trápilo když běžím nějakej běžnej SAS tak já

myslím že eh tomuhle tématu Už to pomalu uzavřeme a budeme pokračovat potom v další epizodě já ještě zmíním e znova tu konferenci learn from incidents my uvedeme link na videa dole do popisku a doporučuju se podívat je tam spousta zajímavejch témat k pokrytí rozhodně taky doporučuju Viděl jsem zatím tak jako asi pět těch videí Mám je nalajnovaný i dalších 10 takže jako je tam toho materiálu hodně a s tím se s vámi teda loučíme díky moc a e zase někdy naslyšenou naslyšenou