Když nejede Seznam.cz, tak nejede český internet

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

you Build It You Run it znamená že někdo se stará aby služba běžela dobře 247 365 dní v roce To znamená že někdo je připravený zasáhnout v neděli ve 4 ráno o tom jak zavést takový režim co to obnáší A jak si to zorganizovat se budeme bavit v tomhle díle a Láďo možná než začnem Já bych chtěl nejprv všem poděkovat hlavně těm který nám dali jakoukoliv zpětnou vazbu spousta toho byla do nápadů a zároveň máme pozvánku kterou netradičně řekneme na začátku chtěli bysme všechny pozvat na 19 20 dubna na web Expo Budeme tam mít E panel vlastně za podobný co jsme měli v atacamě se zajímavými hosty a budeme diskutovat naše oblíbená témata kolem you Build It You Run it a pro všechny naše fanoušky máme 20% slevu na vstupenky kód najdete v popisu pisku podcastu Super tak doufám že se tam na webexu uvidíme a teď možná se dostaneme teda k tomu co jsme chtěli od začátku a to je eh vlastně jak zavést onc A ty jsi Láďo byl hlavním designérem co já vím

hlavním designérem vlastně tý zkušenosti toho on callu apiary a tak si říkám jestli bys to měl nějak nemohl nějak vykopnout e víš něk někdo kdo třeba vůbec neví vo co jde Co se to co to je co to je ten on Call a tak tak jenom v rychlosti popsat tak vlastně když jste já to budu brát třeba z manažerského pohledu člověk je třeba manažer má ten svůj tým většinou vývojářů a dostane za úkol zavést onkol Před touhle otázkou jsme teda v apiary nestáli protože tam byl onkol od začátku vlastně náš cto Lukáš linhard to zavedl úplně od začátku a v prvních letech byl chudák sám jedinej na tom oncu a postupně jak Rostl tým tak to přidával ale třeba v orálu když jsme byli tak vlastně spousta týmů naskakovala do oncu poprvý a já jsem učil spoustu manažerů vlastně jak na to a vy musíte když začnete přemejšlet o tom že bude on Call tak musíte myslet na několik věcí hlavní je ten váš tým Kde sedí jestli jste na jednom místě na světě nebo jste rozdělený na několik

Site jakoby USA Evropa Asie Kolik je časovej posun mezi něma to je velmi důležitý abyste vlastně byli schopný udělat takzvanou rotaci to znamená rotace jsou většinou per Side a vy určíte si nějakou dobu kdo jak v kdy budete vlastně střídat ty služby jo Třeba nám se osvědčilo to že my jsme používali mezi Amerikou a a Evropou a střídali jsme se v š večer ale může to bejt samozřejmě i ráno a různě eh těch eh způsobu kdy to střídat třeba když jsou jsou denní nebo nebo týdenní tak na to jsou různé názory Hele mě jenom napadlo jestli jsme trošku nepřeskočili a neřekli co to ten onkol Vlastně vůbec je jakože pro lidi který třeba vůbec nevědí co si pod tí maj představit tak Hlavní věc na tom onkol je že tady jsou jakoby dva dva typy onkol jeden eh kterej se dlouhodobě vlastně jmenuje nok je to Network Operation Center je to vlastně něco co u nás v Čechách třeba vidíte v elektrárnách v plynárnách a v podobných věcech že je tam vlastně nějaký ústředí tam seděj lidi 247 a

střídají se na službách koukají na budíky když se něco rozbije tak oni okamžitě jednají volají techniky spravujou vám elektřinu když vám vypadne posílají ty ty zásahový jednotky vlastně Mají to hasiči maj to eh má to policie to je takovej základ kterej existuje strašně dlouho a v v IT se tolik nepoužívá Mají ho opravdu obří firmy většinou telekomunikační a A nějaký další když jste menší firma tak vlastně vy chcete udělat něco podobnýho ale nechcete aby ty lidi tam seděli protože vy byste jim museli platit vlastně celou dobu co tam jsou i kdyby se vlastně nic nedělo takže vlastně ta onc varianta vývojářů jak my známe je o tom že oni mají u sebe nějaký zařízení říká se mu pager dřív to byl opravdický pager pokud si někdo pamatuje jak to vypadalo e dneska vlastně máte mobilní telefon s mobilní aplikací která vám vlastně když se stane nějakej problém přijde Alert tak vás vzbudí nejznámější aplikace na toho je page Duty která vlastně eh prorazila SP spoustu těch problémů který e s těmahle aplikacema které dřív existovali byly a dneska OBS geny další

máte grafa na onc eh datadog má vlastní aplikaci prostě těch aplikací typu pager je Celá řada Noo ve výsledku nejde nic o nic jinýho než nějak dát vidět že je někde nějakej problém že jo přesně a Důležitý je na tom aby se vlastně tam je Co je zajímavý na tom že máte nějakou kaskádu to znamená Ono vám to pošle email potom vám to pošle smsu potom vám to volá vy si můžete nastavit ty pravidla jak chcete aby to schopný lidi a aby to hlavně když to jednoho nevzbudí aby to eskalovalo na někoho dalšího případně dalšího aby tam byla nějaká Jasná nějaký jasnej ownership koho to má volat kdy a kdo je na za to zodpovědnej protože to je ten největší vlastně důvod proč ten onkol máte že máte danou osobu která je v ten okamžik zodpovědná za tu produkci A když se něco stane tak on je ten kdo jedná neznamená to že by on musel tu věc vyřešit On je tam aby jedn a úplně korektní jednání je i třeba eskalace vzbudit někoho kdo je odborník

na tu věc a fixne tu věc ale on je ten kdo to řídí on určuje Koho zbudí nebo to vyřeší když ví jak na to má na to třeba Run book a on je zodpovědný za to že se to bude řešit že má má ten ownership to je asi nejdůležitější vlastně u toho oncu je přesně daný Kdo je owner toho problému ten kdo bude vlastně s ní něco dělat jo jo já myslím že tam je důležitý si říct že pro to aby to člověk pochopil tak je to jako v podstatě takovej směj provoz na eh třeba doktoři tam mají tomu tomu říkají přísluš který to mají taky doktoři to mají taky že vlastně V případě nějakých problémů že by eskalovat k nim když dojde kapacita spousta věcí Tak vlastně je to tak že je někde nějaká někde nějakej seznam lidí který se nějakým způsobem rotují mají směny jako a když se bude něco dít voláme tobě eh zejtra to bude někdo jinej A Eh tím pádem tak z toho trošku možná vyplývá i jakože h když Kolik lidí je

vlastně jakoby potřeba No to je různý A ještě co bych zmínil Přesně jak jsi říkal ty přísluš by a tak vy musíte bejt do jistý míry v pohotovosti musíte být připravený technicky i mentálně a mít on Call je jako velkej zásah do soukromí jo spousta lidí to bagatelizuje ale z mý vlastní zkušenosti já vím že kamkoliv jsem jel na výlet k rodičům furt člověk měl u sebe počítač jo furt měl řešil připojení k internetu aby měl Kdyby se něco stalo a podobný věci jako je pravda že onkol se prostě z hospody dělá fakt blbě No obzlášť tam kde není signál že jo nebo Pamatuješ jak jsme byli v San Franciscu vytáhli nás na ten výlet a zjistíme že P kdo je kdo je kdo má onkol já kdo je kam to eskaluje to jsem já a manažer je tady taky takže když bude něco se dít tak se nikdo nedovolá No a ještě jsme měli jednoho člověka v Evropě kterej s náma nebyl tak jsme na něj spolehli že že u něj by to byl problém

protože jsme říkali No tam bude signál tam se nám aspoň dovolají že jo vždyť je to kolik to bylo 10 km od San Franciska nebo něco takovýho a nic že jo A nebyl tam ani signál telefonní na Tož data eh a Přesně jak jsi říkal eh ty ta práce je prostě důležitá ale zároveň má nějakej zásah do toho soukromí ten tým mů může bejt Já myslím že nejmenší rozumnej počet já udávám že je osm lidí jo na při kterým to dává SM ono to jde dělat v míň lidech ale prostě ty lidi potom nedělají nic jinýho a pokud ten onkol je ještě bolestivý to znamená opravdu toho máte hodně těch těch alertů a problémů v tý produkci Tak ty lidi brzo vyhoří a nemá to cenu ten Já považuju za ten počet osm na to silo na Site vlastně osm lidí na Site rozumnej počet aby měli vždycky jeden měsíc primární a druhej měsíc sekundární Rota Zažil jsem taky týmy Kde vůbec sekundární rotace nejsou a taky si nemyslím že je to úplně dobrý ale vzhledem k tomu jak ty lidi to

dělali dobře tak se tam nestával že by byl problém ale myslím si že vždycky by měla bejt jakoby možnost tam mít ten problém protože my jsme z vlastní zkušenosti xkrát zažili že člověk jel metrem dřív nebyl signál v metru nebo prostě mu selhal mobil prostě rozbil se jo nebo přesně jak jsme říkali teď že jsme byli na místě který jsme jako neplánovali že tam nebude signál netušili jsme to a to se vždycky může něco takovýho stát e a te ten člověk může mít úraz Třeba jo autonehodu nevíte prostě těch věcí se může stát milion vždycky je dobrý když je tam ten Backup mechanismus Já myslím že bas Faktor 1 není dobrej vůbec nikdy nikde to jenom tak jakože Tohleto je typickej příklad kde to fakt člověk nechce a mít jakoby vlastně nějakou eskalační nějakej mechanismus jak se to posune k někomu jinýmu kdyby jeden nemoh aby ho zastoupil je je docela dobrej eh Teď mě napadá ještě co třeba manažeři mají bejt taky manažeři v tom on kolu nebo to jenom č inženýrská záležitost nebo jak

by to mělo fungovat co myslíš tam ještě ještě bych k tomu řekl dvě věci tam ještě další výhoda toho zastoupení je v tom že když ty lidi na těch primárních sekundárních jsou parťáci tak oni si právě můžou strašně pomoct v tom aby ten onkol jim nezasahoval tolik do života že si můžou Navzájem To prohazovat když potřebujou k lékaři s dítětem někam podobný věci na to často lidi nemyslej ale je to obrovská pomoc A je mnohem snesitelnější ten onkol mít pokud ta parta funguje navzájem se kryjou pomáhaj si jako manažer Já si myslím že je strašně důležitý aby tam ty lidi manažeři byli toho týmu aby viděli tu bolest jo pokud ty manažeři jsou odstíněný od těch problémů toho onkol tak mají velmi špatný vnímání priorit pro ten tým obzvlášť z hlediska Operations ještě hůř pro ty který tím neprošli předtím a nemají ty zkušenosti jak to může bejt bolestivý Takže vždycky je dobrý Zaprvý tam tu eskalaci mít na ty manažery a ještě líp že tam vždy musí být executive eskalace protože Ten vývojář jsou věci který

nemůže rozhodovat jo Z hlediska právního bezpečnostního nebo velikosti toho dopadu protože se vám může stát že je nějaká chyba a máte jenom dvě špatný řešení jak to fixnout jednou bude stát třeba 10 milion dolarů druhý 5 milionů dolarů a opravdu není na tom vývojáři aby rozhodl co se stane to musí udělat Nějakej executive nějaký vice President CEO jo protože pro prostě to nepřísluší tomu vývojáři aby něco takovýho rozhodnul a vždycky nebo aspoň právník Třeba jo Můžou to bejt právní problémy přesně a podobný věci takže tam vždycky by měla bejt ta cesta na bezpečnost a na exek pvu nebo Legal aby vždycky tam bylo možný posvětit některý ty rozhodnutí protože to často nejsou potom už technický problémy máte řešení Ale máte dvě špatný řešení nemáte bezproblémový řešení a je potřeba vlastně vzít třeba v potaz ten Legal Protože i ta třeba dražší může bejt legálně lepší pro tu firmu než ta levnější varianta ten vyváří Ale z hlediska právního třeba dopady právní můžou bejt u toho levnějšího horší pro tu firmu než u toho dražšího já bych tady možná

zmínil moji zkušenost z německý burzy Kde právě třeba za nějaký výpadky a tak dále jsou pokuty a to člověk jako neví nedokáže spočítat v tu danou chvíli říct jako co bude větší Škoda jako když ten incident potrvá o 10 minut dýl nebo když to někomu zrovna konkrétnímu nepojede vůbec a všem ostatním Jo a tak dále T Je rozhodnutí který vlastně absolutně není technickýho rázu ani trochu ale jsou tady dvě dvě tř cesty jak to vyřešit a někdo kdo e je za to placenej tak musí udělat rozhodnutí přesně a opravdu Já myslím si obzvlášť třeba v americkejch firmách nechcete bejt vývojář kterej na kterýho to hoděj u nás naštěstí vás chrání nějakej pracovní právní systém ale to opravdu všude ve světě není důležitý je potom když se budeme bavit o tom jak ty směny budou dlouhý jo opravdu je velkej rozdíl i v tom dopadu třeba na ten co soukromej život Pokud máte ten onkol jenom v pracovní dobu nemáte Miho pracovní dobu Nemáte ho o víkendech tak je to jako snesitelný většinou bez problémů trochu

tam může bejt problém s tím že spousta lidí vlastně dělá na svejch běžných úkolech a ten onkol je tak trochu vedlejší a potom vidím často že práce jakoby vylepšování onkol a tak neprobíhají víceméně pardon ale to je Antip pattern to nedělejte No ale bohužel jako jsem to zažil jako xkrát a ní Není to dobrý právě my bysme vám to nedoporučili přesně tak ale bohužel je to dost často vidět z mé zkušenosti No a potom vlastně je důležitý jestli máte Teda pokud máte totiž jedn Site třeba když jsme měli jenom oncol tady v Praze tak ho Máte 24 hodin a teď ho můžete mít celej týden A nebo se střídáte po dni My jsme měli různý modely Měli jsme celý týden Měli jsme třeba přes týden že to byl denní a víkendy extra který potom Byli jednou za x počet lidí v tý rotaci třeba tak jednou za šest osm tejdnů 12 když bylo víc lidí už potom Tak tak to potom je snesitelný potom jsou právní nějaký aspekty a vlastně protože pokud to je v

pracovní dobu tak nedostanete ani korunu navíc pokud je to mimo pracovní dobu tak v Český republice vás platí za pohotovost plus samozřejmě máte příplatky za svátky za neděle a za práci v noci pokud dojde k incidentu tak je to plný přes čas a měli byste to vykazovat vlastně na bázi hodin vlastně a a bejt za to placený Já bych možná teda tady zasílal teďko zkušenost oci který je tak nějak všude a zároveň má ty týmy úplně všel jakým způsobem postavený takže my nemáme eh nemáme Že by všichni dělali úplně stejně protože máme týmy který mají vlastně ty jak ji říkal tři sajty některý něký maj dvě některý jenom jednu a jenom taková jako zkušenost toho je že v podstatě Člověk by měl plánovat tu dýlku těch služeb třeba jestli to jako týdenní nebo denní třeba na základě toho kolik mám lidí eh a jak jako jak náročný to vlastně jakoby třeba je protože když máte něco co v podstatě nikdy nikoho nebudí a v podstatě fungu je to jako výjimečná událost že se něco stane tak tak to mít

v šesti lidech jednou za jednou za jednou týdně J jako celej tejden je asi úplně v pohodě eh na druhou stranu jsou třeba zatížený služby třeba síťový a tak dále přesně e který vidím v oci kde vlastně že jo se proaktivně maká na těch věcech dřív než vůbec se něco stane že jo a tak tam třeba se střídají lidi po 12 hodinách jo protože vlastně já se soustředím Já vlastně mám furt co dělat protože já se soustředím na věci který zatím nic nezpůsobují žádnej výpadek Není žádnej problém ale proaktivně vím že tady budu muset něco udělat Tady se budu muset o něco postarat tak se to vlastně takhle dělá a je to třeba tím že ta služba je hodně náročná a je tam toho hodně tak je tam vlastně mnohem víc lidí a mnohem víc rotací a další jsou nejlepší je když máte to tak že dokážete pokryj 24 sed s tím že to je po 8i hodinách že jo to jo to ale vlastně jako říká Jasně Follow the Sun ale zase tam je overhead s těma

předáváním tam je předá první problém je předávání a druhej problém je musíte bejt ve správnejch časovej týmy ve správnejch časovej zónách což e nemám pocit že je úplně jednoduchý No potřebuješ Vietnam Singapur Evropu Ameriku No něco takovýho jo což ne každej si může dovolit spousta týmů e firem třeba my v Pure Storage nebo vyci mají Indii A ta bohužel neladí neladí časovým posunem s Evropou moc dobře No to jsou že jo nějaký 4 a pů hodiny 3 a pů nebo 3 a pů záleží jestli letní zimní čas zase to je další taková vychytávka která mě teď spálila eh jo nebo spálila Jasně překvapila nebo mě překvapilo že mě to zase překvapilo po tolika letech furt mě to překvapuje časovej posun že jo kterej jako ne všude na planetě je vždycky stejnej takže někomu se to mí dřív 14 dní ne Přesně tak takže eh že jo To co bylo to co bylo to co zůstalo furt v 9:00 ráno eh za pacifického času není ten stejnej čas tady tak to jenom tak jakože další legrácka Tak to jsou právě

problémy který vidíte další věc je potřeba právě závisí hodně na počtu lidí Taky třeba když potřebujete řešit dovolenou že jo a podobný věci je potřeba plánovat vlastně předávání těch služeb v rámci toho týmu Ať se kryjou dovolený nebo jakýkoliv vlastně třeba nemoce a podobný věci tak je důležitý mít nějaký dobrej systém na to jak vlastně s tím ne obchodovat ale prostě vyměnit si ty služby jednu za druhou My bysme tomu říkali onc Market říkali jsme tomu onc Market ale bylo zakázaný to prodávat že jo protože ale ovalo se samozřejmě No ale nenašli byl tam striktní můj můj a Alm zákaz na to aby se to prodávalo za peníze Což se nedělalo asi úplně za peníze Ale směňoval se za různé jiné věci tak Protože samozřejmě Jde o to aby v průměru všichni lidi měli přibližný počet hodin stej Jj na tom on kolu aby někdo prostě si nebral víc služeb aby měl víc peněz Protože to reálně třeba dělalo docela pěkný peníze v orálu Co si pamatuju to bylo třeba e jakoby že to kompenzovalo skoro to co strhl stát jako

lidem na daních tak vlastně to byla velmi pěkná částka toho Protože těch hodin tam bylo poměrně dost protože tam bylo málo lidí na tý rotaci No rozhodně to může je motivace a tomu je potřeba třeba zabránit protože člověk na tom onkol musí BT odpočatej že jo Měl by bejt jako schopnej rychle reagovat A to člověk kterej už má já nevím kolikátou šichtu takhle 247 už prostě není určitě a A vždycky je dobrý tam mít jako vlastně víc lidí abyste měli jejich různý pohledy na ten samej problém protože často e lidi co jsou hodně často na těch službách potom můžou střebák tunelový vidění ignorovat ty problémy a podobný věci na to třeba bylo skvělý že náš cto byl na oncu taky sice jako jednou za čas ale on to zase viděl jinýma očima a byl schopnej vyprodukovat tolik tiketů za jednu službu Že to vždycky nás příjemně posunulo prostě já bych ještě řekl že dokonce ale jako existuje i maximální počet lidí což nemusí bejt jako úplně zjevný ale důvod je ten že oncol je přece jenom něco Co

když člověk nedělá moc často tak vlastně z to jako vypadne začne si bejt nejistej nebude vědět vůbec jestli mu všechno funguje jak má a tak dále a a v podstatě je to taková aktivita při který by člověk měl pravidelně v podstatě vždycky všechno prozkoušet a všechno si vyzkoušet a udělat aby neztratil je to tak trochu je to Drill že jo jakoby čitě A Eh tak třeba Já si myslím že jako bejt na on callu Víc než jednou za dva měsíce je už jako v podstatě jsem po každý Nováček skoro protože už ztratím kontakt Jo určitě já já ten maximální počet jsem uváděl myslím že že kolem 15 lidí jo že potom už je dobrý to rozdělit na víc týmů prostě a mít to rozdělený v nějaký jiný granulit ale rozhodně není dobrý aby člověk byl třeba jednou za šest měsíců na on kolu to je pro něj kompletně jako kdyby začal znova mezitím se tolik věcí změní a podobný věci plus ještě co se nám hodně osvědčilo bylo že my jsme jsme měli speciální kanál kde

vlastně se trekoval ruční věci co se měnilo v produkci aby vlastně člověk co Eh Není na tom oncu moh lehce jít projít to a viděl co tam bylo jako za změny třeba od minulýho tejdne než měl onkol protože to jsou kolikrát drobnosti nic se nestane teď Ale je těžký bejt jakoby on Truck s těma protože toho se děje strašně moc v tý produkci a moc jsem to neviděl jinde jako udržování changelogu je rozhodně důležitý a člověk musí bejt vlastně připravenej na to že eh se někdy nějaká komponenta změnila a já musím vědět že se změnila a ne že přijít a najednou koukám jako puk Eh co to tady je tohleto jsem v životě neviděl Vůbec nevím co se děje eh To si myslím že je taky proces kterej na kterej si je třeba nezapomínat že vlastně ten tým kterej nese tu zodpovědnost za tu službu tak by měl zároveň Mít přehled o tom co novýho se jakoby stalo Co novýho může přijít aby eh to pak nebylo tak že vlastně já vždycky eskalují na někoho kdo to zrovna

dělal protože já vůbec nevím co to bylo a co se stalo a a co to znamená a tak dále což je říkám to nerad ale myslím si že to není úplně neobvyklý že vlastně se tam věci hážou do produkce a pak ten člověk co je na onkol je překvapenej co to tam je novýho a neviděl to a vůbec neví že to tam je a vlastně si neví moc co s tím No to je taky vlastně Antip když to vezmem protože ta mitigace by měla bejt na straně toho oncu bez ohledu na to co to je za službu jakkoliv on ji zná nebo nezná a je to důležitý hlavně z toho pohledu že tam běží nějakej čas vy máte vlastně nějakou availability kterou ta služba má a ten když se si to měříte pomocí slo Tak máte jenom nějaký čas pro ten váš error Budget jaky rychle potřebujete zareagovat a tak a vlastně každá eskalace vám to prodlužuje a je dobrý aby vlastně právě byl na to run book Byla tam ta mitigace toho problému potom už se můžou přizvat další lidi a

ta to vyšetřování může pokračovat ale to vyřešení toho toho problému je potřeba udělat rychle a to vám stejnak bude fungovat jenom do nějakých třech devítek a potom vlastně když se dostáváte nějakých 5 minut za rok tak už ani v silách není vlastně schopnost reagovat dostatečně rychle tak jenom jenom dostat informaci k mě že něco problém bude trvat minutu Pak mi bude trvat minutu než se přil lagující rok Takže si může dovolit jeden incident ročně Přesně tak a to je nereálný to se asi nestane že jo a přesně to je ten ten ten problém že někdy lidi jako přemýšlej dáme víc lidí na onkol A tohle ale ve skutečnosti Co je potom důležitý jak mít lepší ty onkol investovat do tý práce do tý automatizace do tý remediace těch problémů e preventivně sledovat právě aby lidi na onkol sledovali už ty příznaky a víceméně k incidentům nedocházelo a oni je vlastně předvídali a podíval Měli jste nástroje na to jak to jak to vlastně fixovat předem Už což velice často znamená z mojí zkušenosti aspoň že se musíš sáhnout třeba do

architektury cel do toho systému Protože ve skutečnosti najednou Já musím zvýšit eh vlastně redundanci přesně zvednout redundanci nebo něco tak nebo změnit někde nějaký zásadní jako architektonický parametr protože já když budu mít řekněme Single point of Fail v databázi a ona mi prostě vypadá na těch 5 minut tak já jsem skončil a už to nev Nemám žádnej žádnej způsob jak to zlepšit než změnit vlastně architekturu určitě tam jako obrovskej vlastně pokud má máte běžnej systém který má ty 3i Dev 3 A5 prostě tak jste to schopní dneska běžet v jednom regionu z několika availability zón a bez problémů vlastně s nějak dobře vycvičeným týmem ty čísla jste schopný dělat ale potom když budete mít něco kritického e nemusíte být zrovna Google nebo Facebook ale Dovedu si představit že třeba eh seznam v Český republice jeho Homepage prostě to lidi považujou za synonymu že běží internet tak tam třeba Chci pět devítek jo Nemyslím si že všechny služby Seznamu to potřebujou ale zrovna ta Homepage tam bych si to doved představit protože pro spoustu lidí internet znamená seznam.cz

v Český republice A tak tam bych si to doved představy tak přesně potom chcete že to chcete mít ve dvou datacentrech jako to seznam Dneska má e Chcete to mít prostě velkou dostupnost a musíte najmout vlastně pracovat na tom aby ty remedia když bude problém byly [Hudba] automatický Já myslím že supr e Díky moc lád za todleto eh dlouhý Intro do on callu Já myslím že tady naše naše díly tímhle naše pokrytí tohodle tématu dnešním dílem nekončí nicméně už nám utíká čas Takže já si to nechám asi zbytek na příště A máš ještě něco co bys chtěl dodat No já bych všem chtěl ještě jednou poděkovat Dostávám na meetupy Byl jsem naposledy třeba na cloud Native meetupu zpětnou vazbu od našich fanoušků moc za to Děkujeme a chtěl bych ještě připomenout budeme V popisku videa mít link na náš roundtable na webexu a bude najdete tam taky kód na slevu 20% na lístek Pokud ještě lístek nemáte Super díky moc mějte se hezky a zase za měsíc na