Incident handling — hope is not a strategy

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 dnešním díle se budeme zabývat tím černým scénářem kdy služba nefunguje jak má nebo nic jiného je špatně Co s tím jak to vyřešit rychle čistě a bez krve o tom že štěstí přeje připraveným a že ta hlavní otázka není jestli se to rozbije ale kdy a co budeme dělat pak Láďo než začneme řešit detaily nechceš trošku definovat to o čem se vlastně budem bavit dnešní díl je víceméně o incidentech a jak s nimi pracovat tak možná začít tradičním definováním si pojmu Co je to incident kategorie A tak podobně tak Probírali jsme to v předchozích dílech Můžete si je pustit samozřejmě ale to co je incident je vlastně cokoliv co vám naruší tu vaši funkci vašeho systému a těch příčin může být mnoho vlastně e to jsou nějaký kategorie incidentů v můžete mít výpadek infrastruktury klasika váš dodavatel e e cloudu má výpadek není to vaše vina vemete si popcorn a koukáte až to opravě jo to je jedna jedna taková varianta potom druhá část věc máte vy problém nějaký váš vývojář deploy nul nějakou změnu a změna

způsobila nějakej problém e uživatelé se nemohou přihlásit eh př zpomalila se databáze a celej systém je pomalej a a neodpovídá dostatečně rychle Mimochodem to je jedna z nejčastějších příčin incidentů je změna Jen tak mimochodem Jo a co je důležitý to o těch změnách jsou vlastně jako dva druhy těch změn jedny je změna toho softwaru a druhá je změna konfigurace když byste se podívali na největší výpadky vlastně třeba cloudových providerů za posledních let tak to většinou právě není softwarová změna Protože ta se dá velmi dobře otestovat ale naopak právě změny konfigurace kde Bohužel ještě ne všichni jsou schopný to testovat A někdy ten rozsah prostě Těch změn je takovej že ten Blast Radius vlastně ten zásah je někdy špatně předvídatelný a nebo opravdu můžete mít jako velkej problém kterej opravdu nikdo nepředvídal Třeba naposledy teď s dat dogem velmi úsměvný e když se jako dopátrá tý příčiny že vlastně automatický update jim restartoval vlastně všechny Nody napříč třema různýma provider a různýma region všechno ve stejnej čas který jim vlastně potom znemožnili nahodit ty ndy včas a

rychle zpátky tak prostě to by nikoho nenapadlo na tohle by se člověk měl připravit jsou varianty Který nikdo nevymyslí a stanou se No a právě to je vlastně k tomu motu který bysme chtěli vlastně říct kolem těch incidentů je Sar moto hope is not Strategy a je to o tom že vy musíte počítat že ty incidenty se stanou a pokud čím víc vlastně trénuje ten tým na tom jak se chovat při těch incidentech jak to řešit tak můžou být opravdu diametrální rozdíly v tom Jak rychle se ty věci vyřeší a opravdu to může být rozdíl vyřešíme to za čtv hodiny vyřešíme to za dva dny opravdu jenom tím že ten tým umí dobře spolu komunikovat a koordinovat a bylo vidět třeba naopak na tom dat dogu jak skvěle oni to mají zmáknutý protože oni měli opravdu stovky lidí stovky incident commandů vlastně zapojených A bylo vidět že to fakt do dvou dnů měli vyřešený eh bez dopadu na zákazníky obnovili všechny data a podobně což jako opravdu skvělá práce a opravdu byli připravený i na tak velký

výpadek na tole Já bych řekl že eh si myslím že všichni si musej přijmout variantu že ve skutečnosti eh incidenty mají bejt rutina to znamená Já nemám bejt jako v panice protože něco nefunguje Ne to je vlastně jako každodenní chleba že jo Takže tady máme proces tady máme nějakým způsobem nastavený pravidla a podle toho jedem jako nikdo nečeká nebo Bylo by blbý kdyby řekněme hasič pro hasiče požár byl jako něco neobvyklýho s čím jako budou v panice něco řešit že jo přesně tak a vlastně když s naší zkušenosti My jak jsme provozovali apiary kde vlastně ten tým nebyl velkej Bylo nás do 30 inženýrů tak každej byl tak často vlastně na tom onkol že byl byl s těma incidentem ob seznámený dostatečně věděl co dělat věděl kam to eskalovat a Nikdy jsme neměli jako větší problém vlastně to řešit Ale Vildo ty teď pracuješ v oci to je opravdu velká organizace a s velkým dopadem tak by možná bylo dobrý popsat jak se to řeší právě v tak v tolika lidech podobně jako třeba byl ten

datadog incident Ale vy jste ještě větší vlastně než dat dook a je pravda že některý incidenty se š ještě ještě ve více lidech Eh tak u nás ten u nás ten proces musí bejt velice striktní a musí v podstatě každ každej prochází školením který vypadá strašně otravně ale ve skutečnosti je neuvěřitelně užitečný a vlastně je tam jako dost striktní proces kterej všichni chtěj Takže nikdo vlastně se nesnaží to jako nějak obcházet protože ten moment se to vlastně totálně rozpadá a my tam máme vlastně celý to funguje tak že eh ty o to možná ještě úplně nemluvil ale vlastně incidenty většinou mají nějakou jako tak tak řík takzvanou jako se sity nebo jak moc hrozný to je a třeba v oci je severity 1 což je jakoby vlastně to nejhorší co se může dít tak to vlastně žádná jedna služba nikdy nemůže to není něco co se stane automaticky to se vždycky vyhlašuje v podstatě jakoby Poté co se teda ustanoví že to je fakt tak vážný že to je jednička a to pak samozřejmě automaticky vede k tomu že nějakým

způsobem jsou z ničeho nic když se řekne je to jednička tak to automaticky znamená že těhletěch 15 lidí i hned je vevnitř Jo a je tam vlastně nastavenej automatizovaný proces kterej znamená je to jednička takže my máme tým kterej se stará o komunikaci se se zákazníkama aby dával vědět co se děje ostatním automaticky ty Jou eh eh součástí ustanoví se vlastně Vyrobí se slack kanál ve kterým se všichni sejdou je tady Zoom My používáme Zoom tak je tam Zoom Bridge prostě do kterýho se všichni připojí eh Všichni jsou zaangažoval a automaticky vlastně je to všechno No přiřazený přiřazený a nikdo nepřemejšlí co teď jako Jasně Vyrobí se k tomu tiket kde se všechno tracku že jo každá změna Jo a máme tam vlastně nějaký Jsou tam nějaký role kolem toho Jo a vlastně celý to takhle probíhá To je ta velká věc ale vlastně největší drtivá většina incidentů který jsou že jo tak jsou větnou na úrovni nějaký služby třeba v jednom regionu někde něco není úplně ok ale vlastně to není jako žádnej velkej průšvih a tam to většinou probíhá

tak že ten tým který je zodpovědnej za tu službu tak dostane ten page že jo Ten má na to cca nějakých třeba 15 minut na to aby vlastně to začal jako s tím pracovat a většinou to je mnohem rychlejc že jo do 5 minut už ten člověk jako ví co se děje a snaží se to nějakým způsobem řešit a jsou tam právě třeba Jasně definovaný pravidla že v momentě kdy já vím že to má dopad na více než jako jednoho zákazníka tak ihned automaticky mám tlačítko prostě kter řeknu tady chci prostě komun chci mít mít udělat ten noc prostě vlastně Network Operation jakoby Center Call což je ten Bridge který na zoomu a automaticky se k tomu připojí člověk který pak bude se starat vo to vo tu komunikaci a případně já přijdu řeknu já potřebuju někoho potřebuju dalšího člověka z tohodle týmu a tam už někdo je kdo to zařídí a já už se nemusím zabejvat koho sehnat A Eh a jinak se vlastně spolu začne se na tom pracovat cílem Většinou tam je někdo

kdo se jmenuje incident command jak jest už vlastně vlastně už to asi běžná praxe tak se to tomu tak říká to je člověk kterej vlastně se stará vo ten tam je od koordinace a komunikace ten tam není od toho aby to řešil ve skutečnosti pak tam většinou je někdo kdo eh se stará vo o ten zápis aby si byly všechny poznámky aby se to Tomu se říká scripe eh to už se taky myslím ustanovilo úplně jasně kde ten člověk tam má vlastně jinou úlohu A to je zachycovat co se jaký jsou rozhodnutí co kdo kdy jako se vyšetřil nebo nevyšetřil a tak dále a pak jsou tam lidi který jsou takzvaný smes neboli subject meter Expert což jsou většinou ty lidi který to reálně řešej který reálně se logují koukaj do metrik a snaží se vymyslet co teda asi se děje a eh tyhlety se tam vlastně nějakým způsobem pak dohadují a takhle se vlastně pokračuje iteru se nad tím v momentě kdy třeba je to právě tak že vlastně ten výpadek se dosahuje najednou

se zjistí že to je výpadek mají má spousta služeb plácnu e vypadla jako půlka elektriky prostě prostě jo což má Což má efekt na všechny Tak v ten moment si řekne jo to je jednička takže to najednou jsou třeba je se dostane k tomu že že vysokej management si o tom ví a je do toho nějakým způsobem vtáhnutí automaticky To znamená že se že se třeba prodává status Co 10 15 20 minut jo a tak dále ale vlastně to je svým způsobem bude to znít divně ale je to tak trochu nuda jako cel cela to to zpracování toho je je tak trochu nuda Já tady zmáčknu tlačítko něco se stane já si tady dělám svoje tady každej má svůj nějakej jasnej úkol e nikdo neběhá Ne zoufal nekřičí prostě vlastně se v klidu to zpracovává jako poměrně nudná záležitost No ale to já si myslím že to je důležitý protože pokud by to vlastně jako nuda nebyla jak z hlediska procesního řízení Tak je něco špatně protože když se podíváme na hasiče záchranný složky v obecným složku

oni to procesně mají zvládnutý každý záchranáři přesně věděj že mají nějakej vstupní fanel kde rozdělují pacienty podle závažnosti potom je doktoři ošetřují a podobně a vlastně my musíme fungovat podobně a my jako it se snažíme teprve převzít tyhle postupy ze záchranných složek a vlastně v tom nejsme ještě tak moc dobrý Myslím si že oni jsou před náma o o desítky let co si myslím že třeba pomáhá v těch menších jo jako vy už máte vlastně někoho kdo s tím má zkušenosti Kdo navrhl ten proces vlastně vypiloval i ty nástroje kolem toho a aby to fungovalo efektivně a v tom dostatečným měřítku že jo protože opravdu když se zapojí u vás stovky týmů tak to není jednoduchý koordinovat i i vlastně ta cena za jenom za to že tam ty lidi všechny svolá když tam opravdu nejsou některý potřeba nebo jsou e tak to je velmi důležitý potom často je důležitý mít taky zkušenej ten manažment protože my se o tom budem bavit potom později třeba v

antiatlas práci těm těm inženýrům Pokud není dostatečně zkušenej nebo nebývali dřív na těch pozicích a nemají ty zkušenosti jak se k tomu má přistupovat a vlastně vstupují třeba do práce toho incident Commander jenom ze svý pozice že jsou nějaký VPS VP nebo prostě v management ale to do procesu incident managementu vůbec nepatří a naopak je lepší pokud třeba executive jsou informovaný nějakým kanálem ale nevstupují do toho Zoom callu Já bych se chtěl ještě vrátit k tomu dneska už jsou skvělý nástroje který pomáhají vlastně s tím co jsi popisoval a třeba dneska vlastně spousta lidí určitě slyšela pojem chat Ops a vlastně to že se používá ten slek a nástroje kolem toho který vlastně to co ji popsal že každej z ná ze školení a tak vlastně pomáhají výst tu agendu pro ty lidi co založí ten incident aby

nástrojů jeden kterej jsem chtěl zmínit je třeba od Jelly IO jejich slack aplikace page Duty má nějakou vlastní aplikaci která vám pomůže vlastně s tím zápisem incident IO nebo Root le jsou další firmy který vlastně se snažej pomoct vlastně svýma nástrojema v tom abyste si byli schopný vlastně kódem ZK modifikovat ten proces a zautomatizovat ho protože se může stát obzvlášť v těch menších firmách že ten incident není vůbec častá věc mů že se stát třeba jednou za tři měsíce jednou za měsíc a těch lidí v tom není moc obzvlášť na začátku když nemáte tolik zákazníků a podobně ale přesto chcete ty incidenty řešit nějak standardně chcete dobře komunikovat s těma pár zákazníkama abyste o ně nepřišli na začátku a zároveň potřebujete vyrůst nejenom jakoby byznysově ale i z hlediska vlastně Operations a do tý podoby potom až budete velká ent z organizace jako třeba oci abyste zvládali statisíce zákazníků a byli schopný doručit tu službu v tý kvalitě kterou kterou si říkáte Já právě si myslím že ve skutečnosti jako svým způsobem dělat to dobře je dneska snadný

nebo ne snadný a řekněme výrazně snažší protože já když se rozhodnu že teda takhle nějak dělám tak dejme tomu používám li page Duty tak si řeknu používám všechno pager Duty A oni vědí jako jak to vlastně ideálně má bejt a ten proces e stačí si to jenom přečíst a říct jo ok Děláme to takhle A vlastně pak už není člověk nemusí člověk moc přemejšlet nad tím jak jo jak to dělat ideálně protože ten proces minimálně nač jako takov ať to nenaroste na nějaký fakt jako řekněme tý Enterprise levelu tak tak je to vlastně relativně tak Stačej ty relativně jednoduchý nástroje k tomu jenom udržet to prostě nějak tu štábní kulturu a to je vlastně stačí Jo určitě tam potom spíš jde o to aby vlastně kulturně to sedlo do firmy aby ty lidi to považovali za dostatečně důležitý abysme se drželi vlastně toho Mota hope is not Strategy aby lidi trénovali aby opravdu to měli v ruce aby byli schopný vlastně si to prožít protože pro spoustu lidí Obzvlášť když jsou poprvé na on kolu vlastně oni

nevěděj do čeho jdou nevěděj co mají řešit a vlastně e je potřeba Je jim pomoct v tom že se udělají nějaký ty chaos Days nebo prostě cvičný incidenty na tom aby vlastně si to zažili Já vím že třeba Google v rámci jejich Sar školy vlastně nebo školení který trvá několik týdnů tak právě dostanou Pagi mají vlastní demo aplikaci kde je instruktoři v noci Pju Jou aby vlastně si zažili tuhle zkušenost na vlastní kůži na nějaký svý aplikaci kterou si sami tam eh dělaj aby vlastně a používají v všechny ty samý nástroje co potom budou používat až přejdou do těch reálnej týmů A to je jako super pro to to vyzkoušet to já si myslím že je fakt zásadní aby člověk kterej pak nějakým způsobem má řešit tady nějakej takovejhle jako výpadek třeba nebo něco aby věděl aby se najednou nezjišťoval jak ty věci jako fungujou jo že to chce jakoby opravdu vyzkoušet to A ne jako že jsem si to jednou zkusil a teď už jako fakt vím a vymyslím to ale eh aby to

bylo jako trošku zažitý My jsme se o tom bavili myslím minule že jo že že vlastně není dobrý když ten čě když ten oncol jako je málokdy protože to člověk z toho vypadne a tole je jeden z důvodů jako vlastně když ty nástroje používám pravidelně i když na na relativně Malý věci který nemají áj velkej dopad Tak když to pak bude Něco vážnýho tak vlastně já používám všechno furt stejně jenom OK Je to jako možná trochu víc stresu protože to je jako velkej výpadek a jako z pohledu nějak třeba byznysu je to jako hodně peněz a tak ale jako vlastně nebudu přemejšlet nad tím tady mám kliknout tole nebo teď se má udělat todleto jako to je to je situace Do který člověk nechce nechce vstat Přesně tak já si myslím že to je důležitý že vlastně ta procesní část potom by neměla bejt vůbec důležitá a opravdu je potřeba se soustředit na tu řešení na tu mitigaci toho incidentu ale zároveň Musí to bejt jako opatrný v tom že inženýři si rádi jakoby vejdou do

toho řešení a za zapomenou na ten čas a ona potom eh a to se nám i stalo taky že vlastně nikdo neřeší třeba tu komunikaci k těm zákazníkům ale zákazníci samozřejmě si u výpadku všimnou a začnou vám psát na support a když nemáte třeba dedikovaný lidi na supportu ze začátku a podobný věci tak je to jako velkej zmatek potom vás začnou bombardovat na Twitteru jo veřejně někde vlastně eh firmu osacovaci

může to bejt jako dost fiasko z hlediska nějakýho public relations a komunikace 100% jako v momentě jakože všichni to strašně řešej ale nikdo nedal vědět jo tak to vypadá řeší to vůbec u vás někdo jako my nic nevíme že jo tam ta komunikace Já si myslím že ve skutečnosti vlastně celý e celý zpracovávání incidentů je komunikace je naprosto totální klíč k tomu eh Ta technická složka Jasně máme lidi který to jako vymyslí to je dobrý ale eh dobře zvládnut incident znamená dobře odkomunikovat incident ve skutečnosti a to myslím tím odkomunikovat

tak dejme tomu k nějakýmu vedení firmy že jo který třeba pak budou muset se bavit se zákazníkama a vysvětlovat nebo s novinářem že jo no nebo i s novinářem že jo když už to bude hodně velký tak i jakoby uvnitř že jo k kdo to řídí prostě aby vlastně se dobře koordinovaly věci protže taky část jako problémů může bejt teď když je to malinký a je to 15 lidí tak si všichni všechno řeknou to je dobrý ale v momentě někdy třeba Je nás 100 a už tam máme nějak jako je tam nějaká struktura tak najednou já vlastně přímo nejsem dotčený ale možná bych měl bejt informovaný že se tohleto děje abych jako věděl co E co a jak případně moh si jím nějakým způsobem pomoct zároveň jako myslím že uděláme segment o

antiatlas A Eh ale vlastně a výstupem z toho incidentu je jasně nějakým způsobem už to Ne už nemáme ten problém ale eh zase je to vlastně jako Komunikace o tom jako co se stalo jak se to stalo eh aby vlastně pak z toho mohl zase fungovat ten nějakej postmortem A nějakým způsobem vlastně zpracovat ten incident jakoby jak ho zatáhnout zpátky do tý firmy No a tam je důležitá ještě jedna věc u těch postmortem tam je důležitá ta komunikace Pokud je to opravdu Jste velká firma třeba jako ten dat dook je potřeba dobře komunikovat ven ten postmortem proč co A hlavně třeba co mně trochu chybělo chybělo na tom od toho dat dogu a na jejich postmortem velmi dobře komunikovat co uděláme proto aby se to už víckrát nestalo Jo ono to je možná evidentní jakoby z toho jak oni si jak popisujou tu chybu že už to znova třeba nebude ale myslím si že třeba tady ten kus co My uděláme pro to A do kdy to bude připravený aby se to neopakovalo mě jako zákazníka jako uklidní nejvíc je

sice pěkný že že se dozvím proč se to stalo a tak toto je jako v pořádku a potom je strašně důležitý vlastně jak rychle ten dokument jste schopný vypublikovat poom Co se to stalo Čím dřív tím líp ale přitom musíte být fakt jako opatrný v tom že ten dokument musí bejt kompletní je blbý když ho musíte třeba třikrát jako znova přidávat tam kusy protože Zákazníci se furt PT na věci který tam nejsou a podobný věci to souhlasím že eh jako ten závěr pak je už důležitý se psat pořádně Každopádně to jako z toho tak trochu vyplývá a to si myslím že jsme vlastně nepokryli a měli bysme si říct jak vlastně řešit to když to trvá dlouho protože ne všechno je hned že jo to je jako Jasně my se bavíme li se o tom že já zrestartuje

e měl že jo nebo nějakej složitější výpadek může vést k tomu že to se bavíme jako o tom že to poběží že hodiny se to bude řešit Já vím co je za problém ale mě bude trvat dalších 12 hodin protože musím třeba vytáhnout databázovou eh datou zálohu a takovou takovoudle jako věc jo tak už najednou se bavíme o hodinách a No nebo dnech třeba s Atlas ani je jejich výpadek že jo co byl minulej rok vlastně atlas janni a tam to bylo hodně špatný vlastně protože oni e to pořadí vlastně toho jak vytahovali ty data a tak nebylo úplně ideální a vlastně místo aby se soustředili na ty nejdůležitější data pro pro ty klienty třeba věci s OBS geny a další tak to vytahovali čistě podle datumů nějak nebo něco takovýho a ta komunikace fakt nebyla dobrá a a myslím si že tam je jedna jako velká věc že tam může jít komunikace přímo těm zákazníkům a nikdo jsme to nemuseli vědět jakoby pravidelná já si pamatuju že my jsme měli třeba ve smlouvách s některýma zákazníkama přesný

pravidla Jaký je musíme informovat Za jak dlouho jak často a tak to obvykle bejvá takovéhle nějaké významnej zákazníků to tak bývá Ale to neznamená že to děláš taky veřejně Jo protože když vlastně jakoby není dopad na tu veřejnost je dopad na ty konkrétní zákazníky tak potom eh to taky není jako dobrý zas ti klesnou akcie No jasně jako Jako myslím si že tohleto celý je vlastně hrozně taky zajímavý Jako téma z pohledu nějakýho jako damage control V podstatě kdy najednou jako tak budu o tom mluvit nebo o tom nebudu mluvit eh protože že jo To může bejt jako no tak dotk se to velkýho zákazníka ale jenom jednoho ostatní vůbec v podstatě skoro tak mám to rozmazávat nemám to rozmazávat Al tak to to se nechává to je přesně ten důvod proč tam je ten Proč tam jsou zaangažoval tydlety složky v tom ale mě m třeba teda přijde ještě jakoby důležitý si říct že třeba eh jedna z věcí jako proč doufat jako není úplně správná strategie je že ten incident když bude potrvá dlouho Já musím mít

vymyšlený jak budou lidi střídat jo ten musej bejt rotace protože reálně pokavaď Já mám dejme tomu se soustředit a opravdu řešit zapekl tej problém komunikovat s 50 dalšíma různejma věcma nebo vzít tolik věcí v potaz tak já to nevydržím 8 hodin že jo Já jsem prostě nevím za D hodiny za 2 hodiny jsem už vyřízenej jako jo takže musím bejt vlastně vymyšlenej způsob jako rotace jakým způsobem budou měnit jakým způsobem se ty lidi budou měnit A jak ty Co budou přicházet se budou dostávat do toho aby věděli co všechno se už udělalo co jsme vyzkoušeli to jsme nevyzkoušeli abysme zase jako nešli a zkoušel už někdo dělat tohle a zkoušel už se ně podíval se někdo na tyhle metriky to pravděpodobně ano ale je dobrý toleo všechno vlastně mít zapsaný a proto e a mít proceduru na to jak já udělám střídačku určitě No já právě to mě nejvíc zaujalo vlastně na postmortem u toho dat dogu protože oni tam říkali ty čísla kolik set lidí inženýrů to řešilo kolik incident commandů to řešilo a

určitě to právě bylo o tom že oni to rotovali protože to vyřešení trvalo myslím že 24 hodin nebo něco takovýho a určitě chcete rotovat vlastně přes časový pásma Jo Maximálně 8 hodin a při tý práci Já bych rotoval třeba po č hodinách ty lidi obzvlášt jo možná i možná nejrychlejc jo jakože když si když si to vemu jakože třeba ten incident command na takle velký věci tak jako J jako tak já mám vlastně Treku strašně moc věcí a to je jako Pekelný soustředění a myslím si že reálně v takhle vysoce stresový situaci jo k Já musím zvládat tu komunikaci a bude tam určitě spousta lidí který do toho budou jako tak trošku házet nechtěně vidle protože budou mít sice dobrý úmysly ale budou házet vidle a všechno tohleto ukočírovat já si jako vím vím sám o sebe že po takovýhle akci jsem po dvou třech hodinách už jako fakt unavenej a po čtyrech by byl odepsanej takže už jsem úplně mimo jako a začnu dělat chyby že jo tam je ten problém že když jsou lidi unavený dělají chyby

Takže oni se musej střídat jako na hokeji prostě poměrně jako vlastně rychlejc než by si jeden myslel To není jakože 8 hodin to budu řešit No to nevydržím To určitě ne no dvě možná tři no Asi bysme se měli podívat jak to dělají ty záchranáři protože ty na to mají určitě proceduru tak já vím že v Pag když jsem si četl jak to třeba mají v pager Duty tak pager Duty má to že oni střídají po dvou hodinách v nejhorším případě po třech jako jo jo To dává smysl určitě No a problém je že potřebujete teda dostatek vytrénovaných lidí na tu pozici protože to je jak i ty dispečerovi nebo podobnou věc e Akorát že ty jsou v permanentním stresu celou dobu co jsou v práci tak tady Tady je to AD hok ale je potřeba ty lidi mít vytrénovaný a je opravdu velký rozdíl netrénovaný tým nebo trénovaný tým A může to být i takový extrémní rozdíl z mý zkušenosti že máte incident za jako čtvrt hodiny nebo taky za 4 hodiny jako vyřešeny a vlastně inženýrská práce byla

stejná jo rozdíl je jenom v tom že eh všichni vědí co mají dělat nebo nevědí co mají dělat A musí si to 50krát vysvětlovat eh takže já si myslím že jako jedna z věcí kter která je důležitá nepodcenit je mít vymyšleno jak já budu tyhlety věci řešit mít to na dostatečně natrénovaný aby nikdo nevymýšlel za běhu co bude dělat třeba jedna z eh jako tam je nejhorší nebo z mojí zkušenosti největší problém je s lidma který jako strašně moc chtěj pomoct a je to ten že Jou že ten ta cesta do pekla je fakt dlážděn Dlážděná těma dobrejma úmyslem všichni Raděj Jasně Sup ale kdo to udělá teď se to musí nějakým způsobem zachytit je tam ten proces kterej na kterej když se zapomíná tak je to vlastně 50 lidí běhá každej zkouší něco a vlastně jako se to třeba vůbec nikam nepos právě no a určitě potom Důležitý je dostatečně věnovat potom i vlastně Post incidentu a zpracování toho postmortem aby se ta zpětná vazba vlastně na týhle procesní úrovni co nefungovalo která ta komunikace který

týmy kde nám chyběj informace právě který jsme třeba nezapsali a a další věci vlastně jestli jsme nekomunikovali až moc Třeba někdo chtěl update každejch 5 minut a to nedává úplně smysl a tyhle věci je potřeba potom jakoby vylepšovat na tom procesu a pokud nám s tím můžou pomo nějaký nástroje tak je to super a je to těžký ale zároveň se bez toho nikdy neobejdete prostě no já možná jsme toho řekli hrozně moc já to možná shrnu jako v pár bodech co vlastně jako e jaká je ta správná strategie mít vymyšlený kdo co dělá Klidně to může bejt vlastně jeden člověk mít víc rolí bejt třeba v jeden moment jako scripe i incident Commander Protože ve skutečnosti jako je nás pár není potřeba větší ale jakoby vlastně bě si vědom těhletěch rolí vědět mít časomíru Já myslím že časomír A to jsme možná neřekli úplně dostatečně nahlas ale je potřeba tam mít časomíru a mít Právě si řečený jako hlídat si čas a říct dobře ty koukáš Do těch těch za 5 minut přijdu Zeptám se

tě nebo případně teď musíme Hel už jsme už uběhla půl hodina musíme dát update zákazníkům a tak dále a pak mít jasný jak eskalují kam a nebát se eskalovat nevím nehýbu se musím eskalovat a vědět a pak vlastně mít systém jak já to vlastně uzavřu a ukončím celou tuhletu akci Jo to znamená mít všechno zapsaný jaký jsou další kroky a určitě je důležitý Musíte si pamatovat že eh pan paměť lidská je je špatnej nosič takže vlastně veškerý ty věci co nefungovaly nebo něco když to nezapíšete tak vlastně se do nějakých 24 hodin lidem vykouří z hlavy a koukaj se na to jo My jsme to vyřešili bez problémů a i když tam ty Problémy byly a proto je taky třeba opravdu nutný aby ten když tam ten Skype je a všechno zapíše tak je to super dneska máte transcribe Můžete to nahrávat jo Můžete to zpracovat můžete mít roli vlast vlastně na který bude jakoby potom koukat na to jakoby že nebyl součástí toho incidentu bude koukat na ty informace jestli dávají smysl jestli něco nechybí a včas se ještě třeba těch

lidí doptá a tam je jako opravdu potom to zlato z toho abyste vytěžili z těch incidentů pro vylepšení tu zpětnou vazbu co potřebujete a já myslím že tím bysme to mohli uzavřít Taky si myslím a v dalším díle si trošku probereme takový ty Antip do kterých se rádo sklouzává A co to může způsobovat a čemu byste se měli vyhnout určitě Tak jo díky moc a brzo naslyšenou brzo naslyšenou Děkujeme moc že nás Posloucháte pokud s námi chcete zůstat v kontaktu najdete nás na mastodon iir mastodon cz dáváme tam tipy na zajímavé informace a budeme rádi za ty vaše Mějte se krásně a příště zase naslyšenou