You Build It, You Run It

[Hudba] 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

v první epizodě představíme heslo you Build It You Run it A proč si myslíme že je to užitečný pohled na provozování služeb A samozřejmě se také představíme Láďo my se známe už docela dlouho a Pracovali jsme spolu v apiary jak na to Vzpomínáš na dobu v apiary Já vzpomínám moc rád Já vlastně jsem do apiary přišel tak že jsem podepisoval smlouvu na vánočním večírku 2013 to bylo docela pěkný člověk podepisoval s britskou společností musel shánět svědka který je nezaujatý a neznámého ani jedna strana tak to byla taková zajímavá zkušenost na začátek a vlastně Začal jsem pracovat v lednu 2014 a první rok v API vlastně jsme byli skupina jenom inženýři vlastně plus grafici a Pracovali jsme na tom produktu každý vlastně dělal to samý střídali jsme se v on kolu Bylo nás tehdy na začátku toho roku 2014 nás bylo šest inženýrů a vlastně onkol člověk měl každej šestej den a každej šestej víkend ta doba byla hodně hektická inovovali jsme spoustu věcí jsme na produktu dělali a vlastně během dalšího roku jsme teprve přišli s

tým a když přerostl vlastně víc lidí se připojilo piar a my jsme začali budovat koncept Sar tehdy pro vlastně běh služeb který vlastně Lukáš linhard náš cto byl rok předem v roce 2014 na prvním s ronu v San Franciscu kde vlastně founder Sar Ben tror e ří měl kyotu a vysvětlil jak vlastně oni v Googlu už někde od roku 2003 to SR dělaj a jeho to zaujalo že bysme mohli využít jejich znalosti i v tak malým startupu jako jsme byli my v apiary A máš nějaký zkušenosti s tímhletím i jako z předchozích let no před apiary Já jsem pracoval v lmc vlastně což jsou i provozovatel služeb do dneška jobs.cz prace.cz kde vlastně jsme měli miliony návštěvníků na stránky už v tý době a vlastně já myslím že za seznamem to byla jedna z největších vlastně nejnavštěvovanějších stránek VČ v Český republice A tam už vlastně všechny ty koncepty pro provozování distribuovaných služeb My jsme uplatňovali vlastně 12 Factor jsem tehdy jako pojem úplně neznal ale vlastně všechny jeho zásady My už jsme tam měli zabudovaný v systému

ale byl to ještě ten klasickej vývojáři produkťák

až časem jsme se transformovali vlastně do více nějakýho agilního systému bylo to první tvoje setkání jakoby s tímhletím online světem nebo ještě i předtím něco tak předtím já já jsem dělal vlastně ještě na vysoký škole jsem dělal webmastera přes 10 let vlastně potom jsem pokračoval jako webmaster na ČVUT než jsem vlastně přešel do toho lmc takže já jsem nejdřív dělal jako klasickej webmaster děláte HTML že jo PHP nastoupilo já jsem byl hodně velkej fanda kolem roku 2005 na verzovací systémy jsem napsal knihu O tom o historii verzovacích systémů jak to vůbec vzniklo Proč je používáme a vlastně i když jsem nastupoval do lmc tak byl takovej vtipný že oni tehdy ještě používali cvs e concurrent version Control System kterej já jsem neměl moc v lásce a říkám mému budoucímu šéfovi Hele já k vám nejdu vy vy nemáte ani svn to to prostě to nechce a on říkal Vlastně když přijdeš tak první co můžeš udělat můžeš nás jí na na subversion Tak jsem nastoupil a do dvou měsíců jsme běželi na subversion takže a to samý jsem potom za dva roky

pozdějc udělal přechod svn do gitu v lmc takže to jsem tam za to byl zodpovědnej hodně No a co ty Vildo ty ty my jsme se potkali v apiary ale přece jenom tys dělal ve spoustě firem i předtím Jo jo tak pro mě apiary bylo taky super e já na to taky rád vzpomínám eh svým způsobem já v tom nějaký ným způsobem vlastně tak trochu pokračuju jakoby v v tý legální entitě která eh pohltila piar to znamená Oracle já teďko dělám e f oci Oracle Cloud infrastructure ale předtím já jsem předtím vystřídal spoustu různejch různejch míst A Eh vlastně já mám první zkušenost e s nějakým takovýmhle systémem Když jsem dělal v podstatě kasy pro eh Carefour kterej tady byl což eh byla Francouzská což je francouzský Tesco a to jsem e vlastně poprvé to jsem měl poprvé on Call vypadal tak že jsem měl eh šílenej Laptop těžký jako prase a k tomu jsem měl motorolu telefon kterej uměl kterej uměl modem aby jsem se mohl vzdáleně připojit a přesně se há tam něco zkoušet dělat prostě v těch eh v

těch pobočkách a měli jsme Run book vážil tak kilo a půl protože to bylo nějakých nevím kolik strašně moc stran vytištěného textu kterej měl teoreticky řešit problémy a to mi vydrželo docela dlouho e ale pak jsem já Jsem přešel a dělal jsem mapy v p softu a to bylo vlastně první místo kde jsem byl jakoby ve velkým vystavený internetu tím že jsme dělali portál mapy.cz a já jsem dělal navigaci která se ukázala strašně populární a já jsem tomu naprosto nevěřil všem když jsem viděl kamarády který to používali jsem říkal nedělej to já vím jak to funguje já jsem to dělal Je to strašný eh Každopádně tam to byl třeba vyloženě ten klasickej Split kdy já jsem vyvíjel a neměl jsem pří litost Já jsem neměl přístup tím systému vůbec Takže já jsem se třeba pak snažil odod debugovat nějaký chyby který bylo já jsem to nedokázal nasimulovat Já jsem strávil měsíc honěním nějakýho bugu a myslel jsem si tak možná jsem to opravil možná ne já jsem opravil 50 jinejch bugů tak možná to bude fungovat jo Hm

a což jako a vlastně eh pak jsem dělal na burze chvíli E pak jsem chvíli dělal Herry ale to není až tak možná pro mě bylo určující ta zkušenost z toho pofu a a z těch kas prostě kde to člověk viděl jako reálně jak jak moc velkou roli hraje to jestli člověk má tu zpětnou vazbu hned a nebo je tam nějakej prostředník a vlastně člověk neví co se děje já třeba jsem vlastně doit roval k tomuhle tomu SR devops you Build It You Run it konceptu e vlastně touhletou zkušeností že jako já jsem cejtil že to jako není dobrý ale nedokázal jsem to ještě v tý době ani pojmenovat jo já jsem byl rád že že to jako funguje ale eh vlastně tam tam to tam todleto uvažování mě začlo No u mě u mě Já to vidím že Přesně když jsem dělal v tom lmc tak my jsme hodně řešili to že člověk jako vývojář dostal nějaký zadání od produktu který vlastně bylo outdated protože oni to napsali půl roku předtím než to člověk implementoval a potom když

to člověk dostal do produkce tak tak vlastně ty Operations lidi vlastně nasazovali jenom balíčky My jsme měli velmi dobrej systém se nasazovalo pomocí RPM balíčků takže rollback fungoval velmi instantně pomocí SIM linků což bylo velmi mi dobrý řešení plus vlastně celá produkce byla Kašová na 15 minut takže jsme měli velmi eh dobrej vhled o tom jestli to v produkci nefunguje a když něco nefungovalo tak jsme byli schopn rollback nout velmi rychle ale zároveň kluci vlastně z Operations měli jediný oncol My jsme ho neměli A když se něco fakt dělo tak oni měli dost velký problémy když by potřebovali vstup od vývojářů jak nás vůbec zavolat a a podobně proto třeba releasy byly jako jednou za čtvrt roku že jo i když vlastně jsme byli schopn nasazovat každej den ale právě kvůli tomu že tam ta zpětná vazba byl byla pomalá na začátku tehdy a časem jsme to samozřejmě transformovali ale ten Operations se nikdy s tím developmentem nespojil až v apiary jsem zažil to že my jako vývojáři jsme kompletně zodpovědní od testování vývoje až po ten provoz a strašně mě to

uchvátilo protože prostě když je člověk aktivní vývojář a zajímá ho vlastně ten produkt i ty lidi co ho používají protože apiary bylo vývojáři vývojářům My jsme dělali produkt pro vývojáře že jo návrh API tak Eh tam strašně bylo vidět ten super pocit že člověk viděl nějakej problém co třeba když navrhoval vlastní apčko tak tak něco mu tam nefungovalo Já jsem byl třeba jeden z prvních uživatelů Ještě než jsem nastoupil do apiary a neustále jsem je bombardoval s nějakýma e problémama Který nikdo neměl jenom já protože jsem měl stovky repozitářů na githubu a oni tehdy neměli stránkování k když jste chtěli propojit apiary e s gid hubem a já jsem byl jeden z mála uživatelů kterýho to trápilo protože jsem neměl těch 20 30 repozitářů jako většina lidí ale třeba stovku a prostě jsem ten paging potřeboval a otravoval jsem je dost dlouho až vlastně tehdy ještě Jakub e nešetřil a Lukáš linhard pracovali sami na tom a já jsem byl za nima v kanceláři ještě v kanceláří bejvalý kebuli a tam oni seděli ještě sami dva tehdy a Honza Moravec dělal

myslím na dálku s nima a e oni jo chápeme tvůj problém prostě tady je to máme na to založenej BG a až někdy to opraví a trvalo asi rok než to opravil protože museli přijít potom další vývojáři a Jakub Koral který který se mnou potom pracoval ten byl asi zaměstnanec číslo tři nebo čtyři e jako vývojář a tak až ten to opravil prostě jo e nějakej rok e e pár měsíců předtím než já jsem vlastně vůbec nastoupil takže to bylo taky taková vtipná zkušenost z toho já teda ještě abych e tomu navázal nebo abysme postupně přišli k tomu tématu já mám pocit že jsme se aspoň trošku představili a určitě v dalších dílech se představíme víc až dojde na lámání chleba a budem se bavit o nějakých detailech ale co to třeba pro tebe jako eh to you BuildIt uranit znamená nebo co co ty nebo proč proč tobě To dává smysl už jsme to jako trochu naznačili ale možná teď jako si říct vyloženě jo A pro mě je to právě o tý zodpovědnosti a o tý kultuře v tý

firmě Jo a pokud nemáš tu kulturu you BuildIt juran Já to vidím spíš jako kulturní věc e že Ten vývojář je zodpovědnej za ten produkt i v tom běhu má ten on Call a zároveň má tu zpětnou vazbu k tomu produktu a to kolečko je vlastně uzavřený a velmi dobře definovaný samozřejmě spousta lidí navrhne že je to trochu problém že Ty vývojáři nemají ty znalosti nebo nechtějí se ty věci učit a to je taky v pořádku Určitě se najde mnoha segmentů ve vývoji kde kde tohle není potřeba ale zrovna u služeb typu třeba SAS a a pas kde kde máte hodně uživatelů a potřebujete to kolečko mít hodně uzavřený aby ta vazba byla rychlá e aby ten produkt byl spolehlivej tak si myslím že je to užitečný mít nemusí to bejt tak že úplně Každej je je vlastně třeba na tom oncu a podobně to závisí na velikosti firmy jak to potřebujete a podobně ale je dobrý když to tam je ta v tý kultuře a viděl jsem to jak to fungoval v API My jsme to

vlastně i akvizicí do orálu zjistili že tam to taky funguje a byli jsme to schopní dokonce učit týmy který to dřív orálu neměly a dávalo to smysl jak jim tak nám a když máte potom velkou firmu Kde je 6 000 vývojářů tak kdyby jme nebyli rozdělený na ty týmy a každý neměl tu zodpovědnost by se to velmi těžce organizovalo s tím růstem to já můžu potvrdit Já tam jsem furt ještě v tom v tom orlu a teď už je to možná organizace o 10 000 lidech A tenhleten princip tam jako furt funguje e i když občas jsou nějaký bouře a některý lidi s některý věci dělat nechtěj a tak dále což dovedu pochopit protože jsou Jou otravný eh na druhou stranu každej má tím pádem možnost podle mýho názoru eh to to změnit A opravit když ti to nevyhovuje jako já právě jsem zast jak pro mě třeba osobně je jako na tomhletom konceptu nejdůležitější to eh nebo nejpřínosnější ta zpětná vazba protože já když něco dělám a a ta zpětná vazba prochází Přes nějakej filtr jménem

Operations třeba nebo nebo ještě to nějaká složitě ší struktura není to jenom jeden člověk ale jsou tam další tři a jsou tam nějaký tikety a teď kolem toho těch toho tiketovací ten ten ta zpětná vazba ten třeba ta ta ta doba než člověk zjistí že je něco špatně je tak Obrovská že já už nevím co jsem dělal že jo To to to mám tuhletu zkušenost mám výbornou z burzy protože na burze vzhledem ke všem požadavkům Jak jak jako bezpečnostní a e dalším Eh tak já jsem nikdy neměl přístup do ničeho jenom vzdáleně připojení cou produkci to bylo jenom vybraný počet nějaký množství lidí a teď vlastně relase fungoval tak že se roval jednou nasazovalo se jednou za půl roku Jo A takže já jsem udělal Nějaký změny a šest sedm osm měsíců a pak jsem dostal zpátky zprávu že něco je špatně jo nebo většinou to bylo dřív ale protože tam zase na druhou stranu jsem masivně investoval do testování takže tam běžel ten systém v nějaký simulaci takže vlastně dostával ty reálný data a

vlastně se sledoval ten provoz ale byl to někdo úplně jinej a teď tam byly kolem toho ty tikety a bylo vidět jak strašně pomalej ten vývoj je jak já vlastně nemůžu flexibilně jít A jo teď jsem si uvědomil jo to je tenhleten problém už vím a opravím to a druhej den to je vyřešený ne trvalo to měsíc Třeba než se ten patch protlačil zpátky tak pro mě todleto je jako ta nejzásadnější věc a zároveň si myslím že ne pro každýho je tenhleten vlastně je druh e vývoje Jakože ne každej by je jako kovanej do tohodle toho světa protože ono je to z mýho pohledu je to velice náročný v tom že člověk se musí naučit nejenom vyvíjet ale musí najednou ještě rozumět spoustě dalších věcí který souvisej s tím provozem který jako št vývojář nemusím nikdy řešit přesně tak a já myslím že to je vlastně největší problém dneska že je spousta vývojářů co chtějí se specializovat že jo chtěj dělat třeba jenom ten frontend tak nemá cenu pro ně to dělat eh se specializovat

jak má deploy tu aplikaci jak má jí monitorovat a další věci ale přesně podle tý velikosti tý firmy můžou vznikat potom specializace naopak zase na tu observable bilu a na další Vidíme že teď třeba hodně populární jsou Platform týmy který vlastně řešej to že když ta firma už je hodně velká tak ta observable bility Platforma a podobný věci potřebuje specialisty ale to bylo vždycky byli tady Network inženýři systémoví inženýři to vůbec njak nekoresponduje s tím že potřebuješ aby ty vývojáři To uměli provozovat a já to vidím hodně s tím sre kterýmu Já jsem blízko že vlastně ty dáváš software inženýrům tu věc že oni pomocí softwaru řešej to škálování abys nemusel najmout Vlastně když poroste služba najmou další a další lidi do Operations Tak ty chceš nějakej supl lineární scaling to znamená Nepotřebuješ s desítkou služeb najmout 10 nových operátorů Stačí ti jeden A o tom to je řešit to automatizací a dneska do automatizace se investuje na všech úrovních vidíme to v testingu vidíme to v infrastruktuře vidíme to všude možně a to dává kompletně smysl ale co jsem

viděl třeba příklady ve firmách že oni rostou organicky že jo přibývají lidi snažej se hodně pracujou s různýma tipama jak organizovat tu práci a vidíme to my budeme mít vlastně firmy který používají Já nevím shapeup používají nějakej kanban používají různý způsoby řízení ale nic to neříká o tom jak oni tu věc provozujou jestli je tam ta kultura že každej tým má nějaký lidi který se starají o ten provoz nebo je tam jedna skupina nějakejch infrastructure inr který dělají provoz pro celou firmu nebo provozujou jenom kus tý infrastruktury a někdo nad tím třeba provozujou kubernetes a na tom celá firma běhá běhá ty věci a potom se může stát lehce najmete hodně lidí který třeba se fokusu jou na produkt na prodeje ale chybí vám třeba Engineering v inženýringu ta skupina která by rostla která se vám o ten provoz to stará a potom to e jak rostete a potřebujete třeba máte ty Enterprise zákazníky jako jsme viděli v orálu kde ta spolehlivost Bezpečnost je na prvním místě a už to není jenom o růstu toho produktu ale o

tý spolehlivosti doručit ten Performance doručit tu spolehlivost nějakou compliance a bezpečnost a tam potřebujete investovat masivně do toho aby ty backend inženýři rozuměli nejenom to jak to naprogramovat ale i jak to provozovat jak udělat dobře Rate limit jak tam mít dobře timeouty jak neutrácet moc peněz vlastně dneska z hlediska ekologie Vlastně kolik pálíme tý energie jo kolik spotřebám CO2 všechno se dá dneska monitorovat a musí se na to brát ohled No tos mi připomněl tímhletím že vlastně zajímavá zajímavá věc kterou jako vidím teď v OC kter je obrovská organizace že jo a je tam vlastně spousta různejch týmů který dělaj různý věci eh že eh na jednu stranu dává je tam je tam jasnej jako rozdíl eh Mezi mezi tím kdo dělá Operations a čemu jakoby rozumí a zároveň eh vývoj ale zrovna v tomhletom případě často je zmiňovaný jakoby klasickej jakoby civil inženýring to znamená stavební inženýrství a tydlety věci nebo nebo strojní inženýrství kde ve skutečnosti když se e ten systém designuje tak se musí designovat proto aby byl udržet aby se dal opravovat aby se dal aby se dal

upravovat opravovat rozvíjet dál což je něco co mám pocit že se vlastně vo tom moc vývojářů nepřemejšlí jako jak já to udělám tak abych mohl tuhletu věc kterou teď jsem tady nahodil mohl vyvíjet dál udržitelným způsobem tak aby to bylo aby to vlastně nefungovalo aby to furt fungovalo že jo a třeba dneska všichni na to používají kubernetes protože Jasně to spoustu věcí právě řeší eh ale pak že jo jsou jakoby feature flagy a tak dále já si zjišťuju že jsou jsou týmy který který nevědí že jsou feature flagy nebo vědí Ale nepoužívají je a já se jich zeptám jako proč a oni to je moc složitý jako on se to dělat nechce říkám jasně já to chápu že se nechce ale Eh je to jako Pracný ale zároveň to ten systém dělá bezpečnej že jo jako bezpečnej ve smyslu eh nejenom eh bezpečnej ve smyslu jako toho běhu kdy Já nemám nebudu mít výpadek Já nebudu z nerozbijou něco omylem e což je myslím ta největší Challenge v celý tomhletom jako you Build It You Run světě prostě

nebo ne jenom v tomhletom světě Myslel jsem tím A Pass a tak dále tam vlastně nejvíc nejtěžší je to nerozbít když na to někdo šahá Přesně tak vlastně většina incidentů dneska když se podíváte na cloudový služby je konfigurační problém není to to že by někdo něco špatně vyvinul jo i implementoval něco špatně protože to většinou je pokrytý testama a všechno ale strašně lehce se udělá konfigurační změna která se vám třeba omylem přenese z regionu do regionu a vy jste s tím nepočítali nebo se to testuje na regionu kterej nemá úplně stejnou konfiguraci jako ten jinej a podobné věci a ty se velmi špatně testujou a stále tam je problém že kdykoliv to může zbourat opravdu velkej ekosystém Já myslím že na tohle jsou nejlepší ty eh když se rozbije routing někomu někde někdo pne do routeru něco a že jo bgp to tam roznese a nic nefunguje že jo výpadek prase bgp a přesně a všechno je mrtvý Ano př to je ukázkovej příklad jako kde Něco co všichni znaj vlastně a všichni vědí že to je strašně rizikový

tak se to stejně přest to furt stává jako No protože se to vlastně netestuje že jo těžko testovat tydlety specifický věci Přesně tak a rollback e je někdy obzvlášť těžkej u u těch tle věcí na bázi DNS Já bych chtěl ještě pozvat všechny koho to zaujalo my budeme dělat takovou sessionu se spou s lidma takovou otevřenou diskuzi kde bude Vilda já Budou tam další hosté a budeme to mít v atacamě dáme link do popisku podcastu Pokud vás tahle problematika zajímá budeme rádi za zpětnou vazbu buďto nám můžete poslat email a nebo přijďte na na tu sšu živě eh 19 ledna link bude V popisku rozhodně doražte A Eh další díl uvidíme co bude protože e si myslím že zrovna tahleta diskuse možná bude to výživný e ta výživná věc která nám eh navrhne co bysme měli pokryt dál protože těch e témat je strašně moc A my uvidíme který budem rozpracovávat a Kterým směrem budeme chtít jít koho to zajímá kdo je ta cílová skupina A co by pro vás bylo to nejzajímavější tak díky moc a snad se

uvidíme 19 ledna tam Díky všem [Hudba]