Ohlédnutí za panelovou diskuzí v Ataccamě

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

19 ledna 2023 jsme pořádali panelovou diskuzi v atakami díky všem kdo jste dorazili hosty byli Roman pichlík s atakami Jirka Brunclík z product boardu Borek bernad z shoptetu a samozřejmě taky já s Láďou pro ty z vás kdo tam nemohli být v téhle epizodě shrneme to co tam zaznělo Láďo Tohle byla první z řady živých akcí které bychom rádi uspořádali a tak se tě zeptám na tvé dojmy Já bych chtěl také poděkovat vlastně všem co dorazili také a taka mě vůbec za ten prostor co nám vlastně věnovali že jsme to mohli vůbec uspořádat a bylo to velmi úspěšný na to že jsme vlastně byli poprvý tak jsme měli kolem 40 lidí a ten networking byl úžasnej e hosti byli byli skvělí A celá ta diskuse byla velmi příjemná My jsme to moc nenatahoval Bylo to na hodinku vlastně ta diskuze ale ten networking předem I i potom byl byl moc pěkný s lidma Je vidět že to téma je zajímají že mají různé náhledy na ten problém e buďto se s tím setkali nebo vůbec nikdy

nepotkali to téma a bylo to velmi příjemný Hodně se diskutovalo o tom jestli jubil to runit je ten správný způsob jak věci provozovat a proto jsme se rozhodli tomu věnovat taky celý další díl Nicméně nad dalším tématem které rezonovalo byly zkušený s nasazováním takového přístupu A co to obnáší Vildo Eh co co co tebe nejvíc zaujalo na tom na tomhle problému Vlastně když to chceme nasadit do firmy Nikdy jsme to předtím neprovozovali co s tím budeme dělat Já možná ještě se trošku navážu na tebe na ty dojmy eh za mě to bylo jako vlastně fantastický v tom že to nebyla klasická série přednášek což jsem velm velice ocenil že to bylo jako interaktivní eh s publikem kterýmu bych chtěl poděkovat za to že bylo aktivní a nebylo to jako že si tam povídají jenom eh ty čtyři lidi vepředu a jinak e když bych se teda dostal k tvý otázce tak zkušenosti s nasazováním co se tam zaznělo bylo eh třeba krásný příklad byl právě zmínil Roman pichlík s atakami o tom že Atakama na tenhleten

systém teprve přechází už na tom pracujou kolik to říkal šest měsíců nebo devět měsíců nebo něco takovýho eh už se opravdu chystají to udělat ale je to vlast vlastně vidět že to je ohromně Dlouhá příprava na to vůbec eh a je to vlastně vedení se rozhodlo před devt měsíci a ještě to furt není a ještě se na tom Furt pracuje k jako jak moc velká změna to vlastně je protože dochází k totálně jako změně kultury která tam je eh zaznělo tam vlastně že velkej problém nebo velkej problém ne ale záležitost která je potřebujou hrozně bylo ošetřit bylo to že vývojáři nebyli zvyklí na to e že nesou odpovědnost za produkci a tudíž že maj ně něco jako on Call A co to znamená Co to pro ně obnáší že musí k tomu bejt nějakej trénink musej vlastně e ošetřit taky nějakým způsobem třeba pracovněprávní vztahy protože najednou Jsou tam nějaký jako takzvaný přísluš by teď můžou bejt příplatky za to a teď co se a tak dále to spousta diskuzí kolem toho pak bylo zajímavý Ještě vlastně

product Board ten to vlastně dělá od začátku jo a je to tamka zmiňoval ale že tam třeba zase eh mají problém že to tam dělá jenom pár lidí od začátku a ty ostatní vůbec a a a taky se to snažej nějakým způsobem vlastně změnit A a a nasadit to jako doopravdy já když jsem tam mluvil za oci tak tam eh tomu nasazování jsem neměl moc co říct protože tam to je od začátku protože to v sobě nese tu kulturu toho Amazonu tím pádem to tam bylo od začátku Ale e takže nasazování do existujících struktur se zdá že jako je vlastně běh na dlouhou trať A člověk si musí dát pozor na to že musí vyřešit kompetence co se vlastně očekává od těch lidí co budou dělat přijít na to jako jakým způsobem je to třeba naučí Vypořádat se s tím že ne všichni budou ochotní pak je otázka jestli třeba by se tomu člověk neměl přizpůsobit eh hiring protože najednou já vlastně nenajím jenom obyčejný vývojáře e součástí toho celýho je budete on Call a teď

přemejšlím co tam ještě dál zaznělo jako tydlety věci Láďo ty si možná na něco vzpomeneš tak jestli k tomu můžeš něco dodat Já bych řekl že ještě tady to je důležitý že opravdu závisí firma od firmy a bylo to hodně vidět že jinak k tomu přistupuje Atakama Jinak se na to koukaj třeba v shoptetu kterej je menší a já z vlastní zkušenosti vím že já jsem učil spoustu manažerů vlastně zavádět třeba onc ve firmě kde jim to někdo dal jako příkaz a není to vůbec Jednoduchá věc obzvlášť Vlastně když to jde ze shora je potřeba vlastně nastavit kompetence Across vlastně celou organizaci změnit tu kulturu jak jsi říkal a vlastně ty změny nezavádět překotně Já myslím že dagis a taka mi tam velmi dobře vlastně řekl že oni na tom pracujou edukuj ty lidi protože často ten odpor který dostanete třeba od vývojářů od vývojářů tak je hlavně kvůli ta neznalost nezkušenost toho že to nikdy nedělali oni nikdy nebyli oncol A tenhle strach je potřeba rozpustit tím že jim dáte dostatečnej trénink opravdu je projdete tím celým

procesem jak ten onkol vypadá připravíte tréninky Já jsem hodně třeba pracoval právě na tréninkových scénářích v productboardu abysme vytvořili nějakej jakoby chaos testing nebo prostě prostředí kde jsme schopn simulovat ty onco a ty Game Day vlastně k tomu aby lidi než jdou na ten reálnej onc tak prošli game dayem kde si projdou ten incident celý všechny ty nástroje který MJ používat protože to máte page Duty na pageová ní nebo obsiny nebo nějakej jinej nástroj potom máte třeba něco na komunikaci kolem toho incidentu že se musí vytvořit Nějakej dedikovaný třeba slack kanál teď můžete nad tím mít další nástroj Root le incident IO jo Fire hydrant prostě těch je taky hafo který vám pomůžou s organizací tý komunikace teď je potřeba komunikovat vlastně ten problém vy jako v různých rolích jestli vedete řešení incidentu jestli jste člověk zodpovědnej za komunikaci kolem toho toho incidentu k zákazníkům k supportu Jo a všechny tyhle role potřebujou jinej trénink potom je tam potřeba vlastní řešení těch problémů to znamená mít nějakou sadu Run booku mít alerty napojený a všechno tohle chce

nějakou přípravu nějakej čas dobrej monitoring na kterej se lidi můžou spolehnout a opravdu to není věc kterou zavedete ze dne na den A myslím si že na tom jsme se tam všichni shodli a mně se moc líbil ten přístup atakami že jdou k tomu opatrně a opravdu mluvěj s těma lidma s těma vývojářem a nesnaží že se prostě jakoby tu direktivně tak přímo jako jsme to třeba zažili V orálu že tam lidi byli 20 let vývojáři a najednou Prostě za tři měsíce mají mít on Call a nikdo se ani manažer ani jich neptal teď v Americe nedostanou ani korunu navíc za to jo v Evropě aspoň aspoň máte za to nějakou kompenzaci finanční takže to byla třeba věc kterou jsme tam určitě diskutovali a určitě je to ještě velký jak jste velká firma a podobně tak takže to je prostě balík otázek který se tam rozebíraly vlastně ještě bych k tomu dodal E co mi přišlo nebo mně přišlo zajímavý vlastně to vidět z pohledu někoho kdo v tom žije už hrozně dlouho jako jak to vypadá u někoho kdo to jako

nedělal nikdy to bylo jako pro mě to bylo ohromně poučný protože já jsem si uvědomil že jsem se pohyboval většinu času v prostředí kde to takhle fungovalo Takže pro mě je to jakoby přirozený eh A sdílel jsem tam třeba to jakým způsobem to dělá oci kde eh když člověk nastoupí tak vlastně jakoby na úplně na začátku ještě ani nemá žádnej to součástí v podstatě onboardingu do firmy jsou vlastně cvičení který reálně člověk jako je n simulovaný n simulovaná vlastně jako zkušenost z oncu Kde je vyrobený falešný prostředí jakoby produkční kde se jako něco stane a člověk si vlastně ošahává stoje projede si to a může si to sám vyzkoušet několikrát aby trošku získal jako tu jistotu aspoň v tom používání těch nástrojů Hodně se tam pak bavil Bavili jsme se hodně o tom že že to vlastně vyžaduje Jako nejen změnu u vývojářů jako tam o tom se možná ještě pobavíme Ale i změnou totálně u firmy protože najednou z ničeho nic aby vůbec takovýhle věci fungovaly Tak musí existovat nějaký eskalační mechanismy a když já

zruším zruším vlastně jakoby oddělení který za to zodpovědný a přesunout to někam jinam tak najednou ten ty eskalační cesty tam furt musej bejt A bavili jsme se o tom že v Ataka je vlastně dagy je v současný chvíli jako k němu to bude eskalovat když budou problémy protože některý situace vyžadujou eh jak to říct jsou vlastně jakoby otázkou ne technickou ale byznysovou jako nebo Legal Legal že jo přesně nebo právní jako já mám situaci kdy já to můžu vyřešit prostě třema způsobama všechny tři varianty jsou fakt špatný Která z nich je nejmíň špatná musí rozhodnout někdo jiný protože za mě by bylo nejleší to vypnout celý popravit a pak znova pustit a to je nepřijatelná varianta že jo určitě typicky u Security problémů vlastně je potřebujete mít na telefonu vlastně právníky protože rozhodnout u nějakýho nebo standardní proces na to a potřebujete rozhodnutí nějakýho exekutiva na to Co máte udělat protože ta Škoda může bejt na v milionech dolarů a prostě to si žádnej vývojář prostě by neměl vzít na triko Od toho je tam prostě nějakej Šéf kterej To

rozhodne je jedno jestli dobře nebo špatně to je víceméně jedno ale je potřeba aby tam ty eskalační cesty byly a zároveň ještě eh jak jsme se bavili s tím zaváděním tak já jsem vždycky tlačil vlastně aby se do oncu připojovali i juniorní lidi A je to zase to že musíte mít třeba ty eh eskalační úrovně na úrovni těch zkušeností a já jsem prosazoval třeba v apiary že jsme měli vždycky ty juniorní lidi jenom na tom prvním levelu a na eskalační byl vždycky někdo zkušenější aby oni měli jistotu když nevědí tak je bezpečný eskalovat a tam jsou lidi který jim pomůžou a vždycky to tak bylo že jsou tam ty lidi aby jim pomohli dobře komunikované Není to že prostě oni to za ně budou dělat ale je to o tom že jsou tam aby pomohli aby pomohli když ten ČL člověk Třeba nemůže potřebuje si něco vyřídit vždycky tam byla ta spolupráce a myslím že to je vždycky důležitý aby ten tým i na tom oncu spolupracoval ať jsou to úrovně prostě zkušeností jak dlouho to děláte

Nebo až vlastně k tý exekutivě když jsou tam opravdu nějaký těžký rozhodnutí kdy je potřeba Prostě rada jak z hlediska třeba právního nebo prostě toho že to může bejt škoda za hrozný peníze a plus samozřejmě spousta incidentů vede k tomu že máte nějaký právní doložky s určitý zákazníkama a je potřeba je třeba informovat včas a podobně Já bych ještě k tomu tomu dodal My jsme tam vlastně v tý diskuzi narazili i na to že že kromě tle těch jakoby právních a tak dále záležitostí který vlastně vedou k tomu že třeba nějakým způsobem eskalovat a tak dále vytvořit to bezpečný prostředí vlastně pro ty pro ty lidi na tom on callu který protože jsou je to stresující tak vím že jsme se bavili i o tom že jako je to třeba je potřeba tý firmě zařídit i nějaký jako říct si pravidla Jak vlastně jako co je co je únosný A kdy už to přestane bejt únosný protože to je třeba Faktor na kterej se často zapomíná že e když má člověk jako když ho to třikrát čtyřikrát

za noc vzbudí druhej den nebude moc efektivní a další noc už když se bude znova opakovat Tak už vůbec to jako nebude moc co k čemu a je potřeba vlastně tady zavést spoustu dalších novejch procesů který který tam neexistovaly a myslet na todleto a není to není to vůbec jednoduchá záležitost asi ve velký organizaci to bude extrémně těžký Já věřím tomu že spousta malejch firem to dokáže snadno se adaptovat na todleto No ale zároveň třeba Přesně tohle pravidlo je popsaný v Sar booku od Googlu že když dostaneš dvě dvě page za sebou tak jsi střídaný na tom onkol a přesně protože když Máš pracovat dobře pos smem všechny ty věci a je to opravdu incident většího rozsahu tak nemůžeš mít prostě každej den jeden prostě to nejseš schopnej zpracovat z toho ty výstupy není eh potom ten ta správná zpětná vazba a to vyřešení e potom může trvat strašně dlouho nebo se některý ty míň důležitý věci nevyřeší vůbec to je svatá pravda to můžu potvrdit z vlastní zkušenosti že když je toho moc tak pak

se samozřejmě začne Začne zapomínat nebo vynechávat a už člověk jenom pak hasí požáry a dostává se třeba do těhletěch eh jako fakt situací který vlastně jsou ničemu moc nepomáhají protože člověk už jenom hasí požáry a situaci nedokáže zlepšit To jsou jakoby zkušenosti který si myslím že tady v dalších dílech určitě se o nich pobavíme ono vlastně ten on Call tam jako to byla taky velká část keda k jsme strávili mám pocit že víc než třeba půl hodiny byl ten onkol určitě no mně by přišlo zajímavý Možná Jako jestli dokážeš Shout jestli to vůbec jde teda jakoby vlastně shrnout co co to obnáší jako bejt on Call z pohledu prostě toho vývojáře Hm tak já už taky dlouho dlouho na tom onkol jsem vlastně Vedl jsem zavádění onkol vlastně v apiary v orálu ve spoustě tým tak nevím jestli jako ten můj pohled bude úplně relevantní protože to poprvý Když jsem byl onko tak to bylo trošku sparťanský e protože vlastně jsem se připojil do apiary a kluci mi řekli tady si nainstaluj page Duty a od zejtra

seš na oncu takže to není úplně nejlepší případ jak bys měl bejt on boardové do oncu ale za ty léta já jsem se snažil vždycky jako aby ten onboarding do toho byl nějak trošku jako lepší než jsem měl já E Neřekl bych že bych to dělal zrovna nejlíp protože já vím že že mý podřízený potom přev brali ten trénink ode mě protože můj trénink lidí na to že jim dám všechny ty informace trval 4 hodiny v kuse A já jsem takhle sypal všechny ty informace který potřebujou a tak to potom jsme to rozdělili na čtyři jednohodinový tréninky který vedla moje kolegyně Naďa protože většině lidí jako praskala hlava z mýho tréninku takže to radši radši jsme přesunuli na někoho schopnějšího a jako vývojář Tam je důležitý prostě znát ten systém a já to vidím že Hlavně pokud je člověk backendové programátor tak má nějakej vztah k tomu co to běží pokud ještě se zajímá o tu infrastrukturu aspoň latentně že běhá třeba vlastní nějaký VPS nějaký věci navíc že rozumí tomu Linuxu i když třeba vyvíjí na macu jak

jako já tak potom je má k tomu lepší přístup než třeba když házíte do onkol člověka kterej dneska dělá frontend všechno dělá jenom vlastně v javascriptu v browseru A nepotřebuje vlastně nic jinýho a nemá k tomu vůbec vztah jo nepoužívá Linux a nerozumí tomu tak je to velkej rozdíl pro ty lidi jak náročný To je ten trénink je může připravit když jste SR třeba v Googlu tak tam mají týdenní bootcamp kterej je zaměřenej na jenom na to prostě stře to jejich prostředí Mají tam nějakou fake službu rozdělíte si onkol jako týmy a máte živej trénink plus lekce prostě celej tejden onsite prostě na na místě kde na to mají vlastně univerzitu SR univerzitu přímo v Googlu vlastně která produkuje stovky sres každej rok který Google potřebuje ale je to jediná firma kde jsem slyšel že to tak systémově vlastně mají a není to jednoduchý vychovávat jak Sar nebo vývojáře který jsou potom schopní to dělat A Z hlediska toho vývojáře jak bych to viděl nejvíc Tam je důležitý se toho nebát podle mě důležitý je přistoupit k tomu s otevřenou myslí

Já myslím že většina jich když chtějí tak to bez problémů zvládnou protože prostě chytrý jsou dost to jako v tom v tom není problém akorát je to prostě stresující to je podle mě ta největší Challenge jak jedná kdo pod stresem je víceméně genetický A nejsem si jistej Na kolik se to dá naučit Samozřejmě nějakej částečně jo ale někdo prostě to zvládá špatně a má to velkej dopad na jeho zdraví a takový lidi prostě je potřeba vyřadit z toho on kolu myslet na jejich zdraví Protože někdo se opravdu může lehce vyhořet může může opravdu na tom bejt špatně nebejt vůbec nebýt schopen dělat ten onkol i když to je jinak třeba dobrej programátor i třeba rozumí tý infrastruktuře ale nezvládá ten stres a eh zároveň celej ten proces by měl bejt jakoby eh odolnej vůči inteligenci takovej jako e v tom smyslu že My tomu říkáme blbuvzdorný blbuvzdorný No přesně tak v tom smyslu že když děláte alerty tak by měl mít Run book ten Run book by měl být napsaný tak abyste to zvládli po

kocovině ve 2:00 ráno a pokud to tak není tak je něco špatně ještě vlastně zajímavá otázka k diskuzi se tam strhla taky o tom v jaký moment by měl inženýr vlastně jakoby nastoupit na ten onkol je to jako za měsíc co co nastoupil za tři měsíce za šest měsíců Jako kdy kde jakoby nějaká ta hranice potom tam proběhla docela živá diskuze mám pocit e závěr můj závěr byl nebo na základě zkušeností s oci závěr je že v momentě kdy ten člověk dokáže má dostatek těch základních dovedností který potřebuje což si myslím že jsou naprosto v dnešní době naprosto nutně eh základy jako nějaký administrace linuxového systému prostě těch pár základních příkazů mět si najít věci a tak dále e To si myslím že je první jakoby balík věcí který musíš zvládnout tak když ne tak by tam asi neměl jít protože si nebude schopnej poradit pořádně třeba teď Samozřejmě máme specifický obzvlášť dneska spousta lidí používá kubernetes takže najednou je to jako už se nikdo ne se sháčkujeme mašinu ale něco tak by měl zase bejt celkem

schopnej chápat aspoň v základu jako zase tom kubernetes jako děje aspoň tak aby dokázal říct jo jestli jako zjistit vlastně základní aspoň základní charakteristiky toho jak ten systém zrovna teď na tom je že jo no Tam je důležitý já vždycky vidím tu observable tuu pokud je tam nějaká dobře nastavená Tak ty lidi musej bejt opravdu familiérní s tím kde najdou logy kde najdou metriky jak se dostanou Právě přesně třeba k logům na tom kubernetes co ty logy říkaj a zachovat co nejvíc dat pro ty který potom třeba budou analyzovat ten incident eh často Já jsem třeba viděl že je potřeba dělat screenshoty z z Metric a z grafů protože si neuvědomujete když na to někdo bude koukat za měsíc tak to rozlišení to třeba sekundový 30 sekundový mizí s tím jak se to dlouho ukládá protože spousta těch systémů je dělaný že ukládá potom minutový pětiminutový průměry za delší dobu a tyhle věci je potřeba uložit k tomu incidentu a pokud možno dělat postmortem třeba hned druhej den ptát se lidí protože Každej člověk může mít na

ten samej incident jinej názor jinej pohled a pátrat se nějakýho Rot czu vlastně tý příčiny je strašně těžký a vlastně takový to detektivní myšlení Co je zatím co by mohla bejt příčina ne a je opravdu těžká disciplína je to nějakej jako myšlenkovej proces který musíte absolvovat a zároveň spousta lidí vydává nějakou kauzalitu za za nějaký jakoby důsledky za příčiny a nemají na to důkazy nebo domněnky vydávají za důkazy a tohle je potřeba odbourat z toho myšlení a opravdu mít hypotézu důkaz hypotéza důkaz Jo a je racionálně to j mi připomněl že si myslím že bysme měli mít díl o vědeckém debag vání určitě No protože opravdu to zkreslení mysli že si něco myslíme že to tak je že to tak počítač myslel je opravdu dost častý No obzvlášť dnešních komplexních systémech kde těch úrovní a částečně Je to jako jsme si to způsobili sami tím že jsme použili kubernetes třeba tak určitě Eh tak jsme si jako způsobili sami spoustu bolesti kterou teď budem muset absolvovat Každopádně já jsem ještě ještě vlastně si vzpomněl na

eh část diskuze byla vo vo vo monitoringu a hlavně jako z pohledu e zákazníka protože vlastně eh že jo ten velká tendence sledovat ten svůj konkrétní systém je velká tendence vlastně těch lidí který se tím zabývají soustředit se na ten kousek ve kterým jsou A ten zbytek Tak trochu ignorovat takže e byla tam diskuze o tom jak vlastně by měl probíhat e monitoring frontendu Protože i frontend jako i když je na CDN může nefungovat no může nefungovat jenom někomu protože ten někdo je zrovna na nějaký jiný části planety Kde to teď nefunguje a a takový tak e To si myslím že je taky velice zajímavý téma obzvlášť v případě když e má člověk Třeba jenom několik fakt velkejch zákazníků na kterých fakt záleží jako monitorovat třeba ty nějakým speciálním způsobem a netrápit se že že na pendu mi něco padá když to nemá žádnej efekt že jo přesně tak tam je takový klasický problém že máte hromadu metrik logu ale vlastně kdybyste udělali ten jakoby to rozpadnutí tak zjistíte že třeba některý errory vám choděj jenom od

výrazně velkých zákazníků a od nikoho jinýho ale vy to nevidíte A těch errorů je vlastně málo v tom globálním měřítku a přesně Tady ten problém kterej vole skutečnosti vás by stál hodně peněz Protože to jsou ty zákazníci co nejvíc platěj Oni mají tu službu vlastně třeba nejhorší jo protože ty střední a ty malý nemají problémy a jenom ty velký a když nemáte ten monitoring dobře udělaný A nejste schopný třeba tady to z toho zjistit že to padá jenom těm velkým zákazníkům že to je možná dělá s tím že mají moc velký moc velký množství dat ve vašem systému Tak je to opravdu problém a o tom se určitě pobavíme protože ten monitoring Dneska má aspekty co se týče cen nákladů na to máte množství služeb co používáte můžete dneska používat tracing můžete používat ebp spousta novejch technologií přichází do do monitoringu který zjednodušují i zkomplikují život e všem No a hlavně se tam dá odradit ranec peněz že jo jo určitě dyť firmy jako datadog a a další eh Mají svůj byznys model pevně v rukou

Si myslím přičemž přičemž vlastně člověk to potřebuje jenom když to nefunguje že jo jinak je to úplně zbytečný jen tak jako Každopádně já bych teda myslím že shrnutí jsme docela jako zvládli aspoň za mě shrnout aspoň trošku Co jsme co jsme tam probrali Já doufám že budou i další akce Ještě jednou bych chtěl poděkovat Všem zúčastněným za to že dorazili Vláďo ty J ještě chtěl někoho zase udělat malou pozvánku Jo jo já bych chtěl všechny pozvat na Go meetup 21 února v Pure Storage kde budeme s vildou mluvit o releasu go 21 můžete taky si pokecat s náma o podcastu a určitě pokud si budete chtít poslechnout celou tu akci Fat cně uvedeme link na záznam ze zoomu v popisu pod podcastu a taky tam dám link na na na meetup skupinu Go Pražského Go meetupu takže ještě jednou díky moc za poslech a zase brzo naslyšenou naslyšenou [Hudba]