Post mortem, feedback and root cause analysis

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

tenhle díl je o učení se z vlastních a i cizích chyb slova jako postmortem rudko analýza nebo Kapa proces si přidáme do slovníku a zvládneme tak tu nejtěžší část incidentu s grácií Láďo v tomhle díle navazujeme na předchozí díly o incidentech a tak možná nejlepší bude si trošku zopakovat životní cyklus incidentů Můžeš to ve stručnosti popsat co to je a a tak dále určitě to zopakujem pro posluchače že vlastně každej incident má nějaký start a konec My start je někdy Většinou ho neovlivníme že jo pokud ho nezpůsobíte třeba deployment a podobně potom je nějaká fáze detekce kdy ho zachytíte jak manuálně tak ho můžete zachytit automatickým monitoringem potom je ta mitigační část taková ta nejdůležitější odstraníte ty důsledky pro vlastní klienty potom je ten ten to vlastní vyřešení toho incidentu nějaká část kdy kdy opravdu ho vyřešíte to že třeba deploy nete tu správnou verzi a tak ale už dávno jste v tý části že to nemá vliv na ty vaše zákazníky No a potom je ta poslední část a to je o nějakým učení se

z toho a tý části my říkáme většinou postmortem obecně ale jsou i různé jiné názvy jak se tomu říká Vildo Vy jste to udělali v oci a tam na to byl konkrétně celý proces Jo jo eh ten Já už jsem zmiňoval v úvodu že to je proces který se jmenuje Kappa e což je vlastně zkratka z corrective Action preventa Action a je to podstatě obecnej proces kterej já myslím že přichází od hasičů nebo možná z nějaký výroby nevím je to fakt starý a s cílem je že vlastně jakýkoliv incident a teď v širším slova smyslu Ale v našem E V našem případě když se bavíme teda vo ových službách a tak tak e náš incident eh vlastně má mít nějakou jakoby korektivní akci ve smyslu Potřebuju to napravit v rychlosti jo To znamená jako mám to zpracování toho incidentu Jo začne mitigace tole tole se všechno udělá a pak nastoupí ten Kapa proces je to jako ok byl problém My jsme identifikovali AB jsme ho vyřešili nějakým způsobem ale teď jde o to takže možná jakoby ta tak corrective Action

neboli tak jako korektivní Akce je vlastně to to ta ta náprava by se dala říct někdy někdy ne je otázka co vlastně jakoby napravuje tu situaci ale pak je tam ten důležitej další krok a to je ta preventivní akce to znamená jako co jakou co jsme se z toho mohli naučit a rozšířit to tak abysme vlastně třeba zabránili ne tomuhle tomu konkrétnímu případu že nám došlo došlo na místo na rku na Na jednom serveru ale abysme to vyřešili tak že třeba si řeknem Ok tak my abysme zabránili vůbec všem těmhle těm případům tak na všech serverech budeme logy rotovat a budem mazat temp a já nevím co všechno a vymyslíme kolem tohodle toho celou celou Story která to zařídí a vlastně v oci tím že to je velký a bylo tam hodně lidí tak většinou to vypadalo tak že eh Kapa je auto byla autom aut icky tenhleten proces vlastně se začal automaticky u všech incidentů který byly který měly nějaký významný dopad na zákazníky a byli Jako na venek fakt vidět jo ty to měli vždycky všechny

automaticky Nikdo se o tom nebaví další kdy vlastně ten Kap proces začínal byl vykopnutý je třeba když to mělo dopad na ostatní a ostatní měli pocit že teda jako todleto by zasloužilo jako hlubší analýzu že to není jen tak takže vlastně kdokoli moh e začít Kapa proces na cokoli a kohokoli ve skutečnosti ani nemusel bejt vůbec s tím daným incidentem dotčený ten tým jenom má pocit Hele tole je fakt špatně to je se prostě dělá blbě a já chci vědět proč takže a Vildo a nezneužíval se toho nějak nebo spíš si slyš to tam bylo aby jako opravdu ten ownership napříč tým byl jako sdílený nebo tam všichni chápali že jako ta ten proces asi jako celkem náročnej Takže to nikdo nezkoušel jako využívat jen tak zbytečně jako oprus neříkám že se to nestalo jako věřím tomu že někde nějaká politika a nějaký hrůzy prostě korporátní byly ale ve ve ve většině případů to bylo jako já když to chci vědět tak já to jako vykopnu když nedostávám jakoby nějaký odpovědi který bych chtěl jo

eh nebo třeba e se to n tak jako většinou se to právě vlastně spouštělo tím standardním způsobem To znamená že byl nějakej výpadek kterej opravdu měl efekt jo ty ty ty externí vstupy byly málokdy ale bylo to třeba když se opakovaně něco dělo jakože my tady používáme nějakej nějakej downstream třeba ten Build a on jako se nám furt rozpadá a už nás to jako fakt nebaví Už nás to jako fakt otravuje oni to jako vždycky nějak opravili Něco něco něco ale jsou to furt jako ale vrací se to a vypadá to že to někoho neřeší nikdo jakoby do hloubky že tam je jako fundamentální problém a je potřeba ho možná ani ten tým který byl za to zodpovědný to možná nemohl vyřešit že to bylo jako hele na tole se musí vlastně jakoby přijít přistoupit jinak úplně jinak od jinou takže najednou jakože někdo jinej to musí začít řešit tak třeba na to se to používalo a v zásadě jako je to o tom že člověk musí udělat tu postmortem analýzu o který se určitě

budem bavit ještě mnohem víc jo která nebo já si myslím že jako já nevím já jsem vždycky přemejšlel nad tím jak je rozdí mezi postmortem a Rut analýzou a můj takovej překlad je postmortem se dělá u VŠ R jeden jeden z kroků toho postmortem přesně tak No jo takhle to jako jenom to A Eh a ta Takže ta analýze toho incidentu a teď tam ten proces vypadal teda tak že byl řízený jako Jirou samozřejmě jir tiketem protože to bylo poctivá korporace a a tam byly Prostě různý políčka který se musel vyplnit a jedna ze zásadních byla jako timeline neboli vlastně jako opravdu časovej soupis toho kdy se co stalo dělo že jo jak to začlo kdy to začlo kdy se to zdekoval kdy se povedlo to nějakým způsobem ta mitigace se povedla a dokončila e kdy se to roz roz to e vlastně roz řešilo pořádně a No u tý časový osy že jo všechny Všichni kdo byli vlastně přítomný tomu incidentu jestli se pageová další týmy je dobrý sebrat úplně vlastně všechno co jde A Eh Proto taky

jsme se bavili když jsme se bavili o incident rolích že třeba bejvá ta role scripe že to někdo vyloženě zapisuje Protože těch věcí co se děje je fakt hodně a dneska se spoustou těch věcí můžou pomoct nějaký automatizovaný nástroje ale je to potřeba potom shromáždit na jednom místě ideálně jak jak říkáš pro ten postmortem mít tiket a a protože z toho postmortem mu potom jakoby ty Action Items je potřeba zase trackovat že jo V běžnej chch nástrojích pro ty vývojáře a mít to všechno vlastně dohledatelný e mít tam nějaký deadliny na na ty na ty akce aby se to vyřešilo dostatečně brzo než třeba ten samej incident znova nastane to je krásná Idea tak by to jako v ideálu mělo fungovat ale zažil J mi to kdy jako eh byla Kapa třikrát na to stejný že jo a jo ale tak k tomu se možná dostaneme jak se s tím vlastně pak dál pracovat a jako jestli se člověk dokáže poučit nebo ne Mně ještě třeba jakoby na tom vlastně přišlo důležitý Krom toho krom tý časový

osy která je ono je to trošku taková detektivní práce jako jo A Eh vlastně ne vždycky to je tak že nejlepší detektiv je ten kterýho se to jako vyloženě týká i když to jako vlastně že jo e Takže jako zachytit tam všechny ty věci e Takže třeba právě v v oci byl bylo důležitý to že se vlastně ten kaa proces vykopnul teď ten tým kterej byl zodpovědnej za ten problém e to vlastně jako nějakým způsobem udělal tu časovou osu

eh ve stručnosti vlastně popsal takovej jako jak to říct jako manažerský manažerský summery jako co se stalo a pak inženýrský popis toho co se stalo kterej byl jako docela podrobneji opravdu jako dlouhej text To by třeba stránka textu která popis Takže my jsme udělali tuhletu změnu před třema měsícema a tak dále A teď celý jakoby příběh v podstatě toho incidentu od začátku do konce eh s těma s těma podstatnej věcma a co se hodně používalo byla metoda pro tu rudkou analýzu Já si myslím že rkos analýza je taková hodně ošemetná věc protože že by jako třeba incident měl jenom jeden jeden jednu jedinou příčinu proč se to stalo většinou nebývá Většinou to bejvá spíš vlastně jich tam se stalo hodně moc a celý se to vlastně sešlo jako souhra okolností mnoha okolností Já mám já mám systém na to abych zabránil tomudle tomu a tomudle tomu a tomudle tomu ale nemám systém kterej zabrání když všechny tři věci se lžou najednou že jo jo takže to je taková otázka Každopádně je to dobrý cvičení aby se člověk zamyslel aby třeba

člověk identifikoval to to to kde zhruba se to stalo a v o T se na to používala takzvaná metoda Five Wise to znamená pěti Proč onich by mělo bejt víc ale spíš o ta jako ta ta metoda se tak jmenuje No ta metoda se tak jmenuje a ta Idea tý metody je vlastně že se ptám jakoby vlastně do aleluja Proč proč todle Proč todle Proč tohle až se dohrabat nějakým fundamentálním problémů toho proč se to stalo Jo e a třeba identifikuju že selhalo pět těhletěch věcí najednou že to bylo souhra ohromná souhra náhod jakoby ne náhod ale jako událostí ale každopádně Five Wise je popsaný na Wikipedii a je to jako docela dobrá metoda která opravdu pomáhá člověku najít jako se pomáhá přemejšlet o tom problému když už má ten postmortem A když už má všechno všechny ty tu timeline a už to má pospojovaný a má pocit že všechno ví tak je dobrý si udělat teď to cvičení zeptat se Hele a proč se teda stalo tole a mám to zodpovězený mám tole zodpovězený a to je třeba něco kde ty

otázky je dobrý když ale někdo kdo u toho vlastně vůbec nebyl jo takže jo a je na tom jako framework vlastně nejenom těch metod je víc že jo než Five určitě No a já třeba mám rád hodně Five piece Mám rád potom ty sofistikovanější jako pdca a six Sigma který kombinujou vlastně to five s nějakýma dalšíma věcma jako jsou třeba x kaava diagramy a další věci ale vlastně všechny jsou troch trochu přesně Podobný jak jsi zmiňoval že jako předpokládají že prostě to není jedna příčina že je to několik vlastně příčin co co co se spojí aby k tomu došlo a je to vlastně moc pěkně třeba v tom Five piece je to vlastně jakoby Six piece problém a tam mají jakoby P factors tomu říkaj a to je nějakej jako presenting probl perp factors perpetu factors pred dispos factors protective factors present factors jo Takže všechny jako různý věci co k tomu přispěly že nemáme tuhle automatizaci nebo že zrovna jsme neměli štěstí ten ten den jo prostě všechno se do toho dá zachytit a nebo naopak Měli

štěstí že jo protože ale mohlo to bjt 10krát horší ale oni tam měli ještě Tuhle chybu a ta chyba zabránila Tom že se to jako rozpadlo ještě víc že jo přesně no no a nebo je tam nějakej Faktor že nějakej Network Engine někde udělal v typu A tím se to zhoršilo že jo podobný věci a dá se to rozpadnout já vím že mám takovou velkou vlastně jakoby e studii kde jsem koukal do těch metod jakoby jak to prezentovat lid protže ono je jakoby těžký každýho inženýra naučit tady tu Rus kod analýzu dělat dobře To si myslím že je jako největší problém že vlastně jako třeba ty Five Wi Mají tu výhodu že se dají docela dobře vysvětlit ale dělat to opravdu dobře není vůbec jednoduchý a mně se hrozně líbí přístup startupu který se jmenuje Jelly byly koupený teď Pag Duty takže e takže to asi bude horší už zase no no ale možná ty jejich toly se dostanou K větším množství lidí a jejich nástroj se právě soustřeďuje na tu incident analýzu a provede vás s

tímhle cyklem vlastně Jaký máte důkazy že se tohle stalo To je to taková hra na detektiva mi to trochu připomíná v tom jejich podání a Přesně jak jsi říkal že někdy je fakt dobrý když ten člověk umí dělat dobře toho detektiva a nemusí mít kontext toho toho a může to bejt jako ta velká pomoc dost často z naší zkušenosti to bylo že stačí když tam jsou seniornější lidi který trošku dvuj potom ten Rů kost analýzu ze s zkušenosti a uměj se dobře ptát víceméně stačí třeba i VP co byl dřív SR nebo někdo Ale umí dobře klást ty otázky a to může strašně posunout tu analýzu třeba ono vlastně My jli používali to five Wi proto protože to bylo hrozně jednoduchý vysvětlit každýmu jako Co je cílem cvičení a ta metoda je existujou jako výrazně sofistikovanější a s lepším lepší a s lepšíma výsledkama ale tole je jako tu esenci jako vysvětlí takže většin věšinou to bylo jako v pohodě a tam byla teda ještě jako vlastně další důležitá věc je a to je podle velikosti

Samozřejmě celý tý firmy a A koho se to týká Jak velký to je jo když to je prostě máte jednu apku A je vás 15 tak asi v pohodě pokavaď je to třeba něco většího Kde jako je víc komponent a víc lidí Eh tak třeba už se rozlišuje i jakoby Mezi mezi tím mezi nějakou takovou jako důležitostí těch eh těch incidentů jako ve smyslu jaký měl impakt a tak dále a třeba ty významnější eh e nebo v oci existuje proces jako ka review kdy vlastně ten tým už si myslí že má hotovo už jako že to je zpracovaný že to je dobře popsaný tam třeba byla ještě jako zajímavá věc kterou jsem neřek a která mi přišla vždycky užitečná a tu jsem čet většinu času a to je

eh lessons learned for others ve smyslu jako jaký jsou jako co se vlastn co si z toho můžou odnýst ostatní kterých se to jako vyloženě netýkalo jako snaha zobecnit to na úplně všechno a to bylo docela dobrý protože Eh tam pak přicházely vlastně jakoby třeba z toho vylejzá pak jako zajímavý zkušenosti který říkali Ok neměli bysme vůbec nikdo dělat takovouhle věc a vlastně se tím jakoby byla prevence velkých problémů e Každopádně vlastně to to review následovalo bylo vlastně pak na to se vlastně to bylo třeba každý tejden byly vlastně jako review a bylo jich několik úrovní a třeba byla na úrovni jakoby nějakýho VP kde vlastně ty seniorní inženýři přišli A řekli ale Ok tak se na to Pojďme podívat jo tole To dává smysl dává smysl Hele proč J tady něco něco a vlastně přišlo k tomu jakoby lidi který na tom který se toho neúčastnili a který měli zájem na tom aby to bylo jako dobře zpracovaný ten incident takže se právě ptali na všechny ty otázky který jako jsme O který jsme se bavili a snažili se

vlastně přijít udělat z toho ten kompletní obrázek a případně když to byly jako fakt významný incidenty tak šly klidně ještě vejš a pak byla vlastně globální C review Kde byl třeba jeden incident za tejden nebo něco takovýho kde se sešli jako vlastně opravdu mohl tam přijít kdokoli a začít do toho šťourat Jo a jako fakt to fungovalo dobře v tomhletom smyslu Tam je důležitý Samozřejmě že všichni mají zájem na tom aby se z toho něco naučili A to možná je totiž ta nejtěžší část jo určitě vlastně jakoby když člověk čte materiály a vůbec co třeba Sar všeobecně řešej Co by mělo bejt výstupem toho postmortem tak kromě těch samozřejmě Action Items prevence toho toho toho těch dalších podobnejch incidentů což je takovej ten základ to každej jakoby chtěl tak hodně vlastně firem se snaží udělat z toho nějakej výukový materiál když přijde novej inženýr vlastně aby si byl schopnej Přečíst o těch starších incidentech a získat nějaký knowhow z toho který třeba nemá a to je si myslím že jako takovej ultimátní cíl protože to je opravdu

hodně těžký udělat z toho něco co z čeho se může jakoby Nováček třeba učit a a přečíst si přesně jak jsi říkal o těch Lesson learns for others to je přesně přesně takovej ten kus kterej je strašně užitečnej aby se to dalo potom extrahovat a udělat z toho nějaký materiál který si člověk může přečíst Já jsem strašně rád že spousta firem opravdu je veřejně dobře se snaží napsat ty incidenty který měly dopad vlastně na nějakou širší oblast e já myslím z minulýho roku můžeme zmiňovat velký výpadek dat dogu a oni udělali velmi pěknou sérii článků kde vysvětlili jak to řešili co udělali co co udělali pro to aby se to nezopakoval a je to vlastně pro celý it Je to velmi dobrej způsob jakoby říct Hele a nemáme stejnej problém jo neměli bysme se na tohle taky podívat Vždyť e My My to děláme podobně Třeba jo A A tohle vždycky já oceňuju na těch firmách že jdou jako s tou kůží na trh a zveřejní to oni to taky samozřejmě dělají kvůli svý pověsti a kvůli svým

zákazníkům ale je je to dobrý že ta úroveň jak jsou někdy tyhle zpracovaný ty Veř veřejný postmortem se liší ale je důležitý je udělat včas ne neotálet a udělat je opravdu dobře To znamená fakt Do detailů rozdělit to na části pro lidi co spíš byznysový ale mít tam i tu technickou a opravdu jí třeba do detailu v tom co uděláme aby se to neopakovalo protože to je vždycky část třeba mě jako zákazníka nějaký tyhle firmy typu dat doog cloudflare aws jako zajímá nejvíc co oni dělají pro to aby aby se znova ten incident nestal já teda e musím říct že opravdu to je myslím si že ty incidenty a obzvlášť ta postmortem analýza je opravdu taková hodně Je to hodně podobný tomu kriminálnímu vyšetřování Kde je potřeba se sbírat důkazy co nejrychlejc a vlastně jako jako se sbírat ty ty všechny ty data opravdu jako pokud možno skoro i hned Poté co se to stalo aby všichni v to mají ještě v paměti aby se nevod logovali nevod rotovaly logy aby nezmizely tydlety různý jako stopy

prostě který jsou že to je potřeba nasbírat data hned A když se to neudělá tak prostě to je primárně na příležitost svým způsobem ještě J mi tou tím že jsi mluvil třeba o tom dat dogu a těch veřejných těch incidentech nebo postmortem já si myslím že třeba to je něco co vlastně ten náš jakoby Industry se bude muset ještě naučit dělat pořádně když se člověk podívá jak to jak to jak se tyhlety věci řešej třeba v leteckým eh v leteckým průmyslu a byznysu jak se to řeší jinde tak si myslím že my jsme ještě zdaleka nedostali tak nedospěli tak daleko abysme měli v podstatě jako kanonický učebnice co nemáš dělat takže všichni furt jako máme spoustu vidím furt dokola opakovaný stejný chyby Možná by si stačilo přečíst těch Já nevím 10 různejch postmortem a hned by člověk věděl že nemá dělat prostě dalších pět věcí Jo jo tady je velká snaha vlastně eh já pošlu link je existuje nějaká komunita kolem kolem těch incidentů kde se snažili vlastně mít veřejnou databázi těchhle incidentů a říká si to říkaj

tomu void Community A kde vlastně si můžete přečíst všechny E tyhle veřejný incidenty za docela dlouhou dobu e dáme link do popisku abyste abyste viděli A to je právě přesně jedna o takovou snahu dělat ten to centrální místo kde kde se o tom můžete přečíst podobně jako to mají třeba letci že jo který mají přesně standardizovaný formát šíří se to mezi všechny letecký organizace a je tam úplně jakoby Tip Top že když se stane letecká nehoda všichni k tomu přistupují stejně výstupy se dají sharovat a prostě to To nám trošku chybí ale jsou v tom nějaký jakoby snahy i i v IT a já já tam pošlu link na tu databázi kde si můžete Přečíst o mnoha mnoha incidentech když vás to bude zajímat to já si myslím že to je vynikající učební materiál i jako ve smyslu podívat se Ok tak jak vypadá dobře udělanej postmortem Jak vypadá dobře udělaný věci a třeba se tím inspirovat říct Ok tak takhle to budem dělat jo nebo to jsou ty informace který nás zajímaj e protože jedna část je ta

formální jo ta jakoby Ok si Sbírám timel něco tam jako vyrobím Ale pak jak jakoby vlastně co z toho vyvozuji eh A jak to jakoby sepíšu a jak se pokusím to pak předat dál je vlastně možná ta nejzásadnější a já třeba si myslím že ve skutečnosti celej tenhleten proces po incidentu je jako svým způsobem ta nejtěžší část toho celýho incidentu protože často to má dopady do jako organizační třeba a najednou je to o tom jakože Ok ale my tady máme tenhle problém A tenhle problém spočívá v tom že mám se tady prostě dva týmy mezi sebou nebavěj a jako řešení je oni se musí začí bavit že jo a teď to jako Ok ale tyhlety tyhlety manažeři se nemají rádi a já nevím Jo prostě se do toho začne zapojovat tady politika tady Todleto jo ega a tak a začne se to komplikovat takže já si myslím že jako Jasně velká třída z nich je taková přímočará dá se to odfláknout v podstatě se dá ten proces dělat a dělat ho jako a odfláknout ho určitě no obzvlášť tady ta

poslední část někdy se tam prostě jenom naflákat pár tiketů do jiry a tím je to vyřešený prostě hotovo A a to se dostáváme právě k tomu že si myslím že tam ta důležitá věc je ta návaznost Jo že vlastně celej ten proces má vést k tomu že se udě že se nějakým způsobem Rozhodnou nějaký akce že jo potom co s tím budeš dělat dál protože třeba ta ta nějaká jakoby když budu používat ten slovník toho kaa Tak ta korektivní akce je něco co uděláš jako rychle třeba OK tak já teďko rychle abysme to nezopakovali znova eh tlet ten kousek tak já tady teďko udělám jako zah Hard codu nějakou hodnotu do nějakýho ci systému a prostě mám nějakej test kterej říká že tohleto se nestane ale není to jako ta správná věc že jo to a to dlouhodobý řešení je to poctivý řešení je velice často to poctivý řešení trvá mnohem dýl a stá mnohem víc peněz a bude prostě mnohem složitější protože to znamená třeba OK tak my musíme přes dělat prostě Jinou strukturu databáze Protože naše quy jsou

moc dlouhý a existuje tady šance že todle A já nevím A jo a už to je prostě Ok jak to bu a půl roku a ta nedůslednost vlastně jakoby v tom v tom násled do udělání tý akce kterou jsme si řekli že to že uděláme jako která je to správný řešení tak pak vede k tomu že se že se ty incidenty vlastně třeba kupě dějou se furt dokola pak si lidi zvyknou říkaj jo to je furt ten stejnej problém a už prostě se to stane jako součá už je to taková součást všeho už se to s tím nestane nic jako už to nikdo s tím nepohne že to tam zůstane A já si pamatuju na tohleto úplně skvělou ukázku kdy za Za jistých okolností vlastně docházelo místo na risku Mhm úplně trapná věc a ale všichni si tak zvykli že už prostě roboticky vždycky když ten incident nastal tak šli eh On byl ten výpadek oni šli smazali tam nějakých pár souborů pár těch věcí a zase to nechali bejt že ono se to zase vlastně dalo do kupy a vůbec

nikomu to nevadilo už Hm přitom vlastně jo a jasně tak jako eh a vlastně jakoby ta správná akce by byla jako No my musíme vymyslet ten systém tak abysme to automaticky třeba mazali že jo což by znamenalo Jo budeme muset udělat tohle budeme muset udělat Jako byla by ta práce ale někdo vlastně už nechtěl už to prostě nikoho nezajímalo takhle to chodí už takhle to tady děláme to je takhle rok už určitě nejmíň Já jsem tady rok a půl a celou dobu to tak je Hm to je jako zoufalý že jo to je no a právě já si myslím že tohle je strašně důležitý e Podchytit protože přesně taková ta to je stejně jako s Alert Který nikdo neřeší že jo protože jako jo to už jsem viděl to to tady ret trinu e nebo přesně to počká prostě je to úplně ten samej problém vlastně sociální nějakej systémový v tý firmě a a vůbec to nesouvisí jakoby s tím konkrétním incidentem že jo je to víc prostě o tom jak jak kolik těch incidentů maj Jak

často se to řeší a hlavně si myslím že je to mnohem víc o tom jak je to manažersky vedený A jak ty priority v tý v těch týmech a v tý firmě fungujou mě já jsem si ještě uvědomil že ono jak je to ty jak jsi zmínil že to je jakoby vlastně takovej sociální problém jo tak třeba u těhletěch postmortem analýz je důležitý eh neukazovat prstem že někdo něco udělal špatně protože on asi jako měl dobrý důvod proč to dělá takhle a ty drtivá většina Myslím si že v podstatě všichni mají zájem na tom aby to dělali správně a tím pádem jakoby to to to to jakože tady někdo něco se přihlásil a udělal nějakou chybu je jako Jasně tak bylo to tenhle ten konkrétní jedinec ale je to vlastně jedno On kdyby tam byl někdo jinej Tak to udělá někdo jinej to je fuk ve skutečnosti Problém je v tom že třeba tenhleten přístup vůbec existuje neb přesně je to vždycky Já říkám že je to chyba procesu vždycky No je to nějaká systémová chyba je tam

systémová chyba která umožnila todleto a je to jako náhoda že to je zrovna tenhle člověk jo přesně tak jo ten Blam kultura u toho je fakt důležitá to jsme zapomněli zmínit protože to považujeme za samozřejmost ale je to přesně tak a a vlastně ještě kolem toho další věci Vy spoustu toho procesu teď se trošku dostanu k těm technikám protože přece jenom Už se blížíme ke konci že tam je spousta nástrojů který vám můžou pomoct e udělat vlastně celej ten postmortem jakoby rychleji praktičtěji a podobně najdete spoustu nástrojů typu Root le incident IO eh fyber Plane kterej má moc pěknej nástroj na sbírání a řešení incidentu eh přímo že přímo něco jako Jupiter notebook kde můžete pouštět ty dotazy sbírat ty data zároveň to potom použít pro ten postmortem v Rotel Třeba já jsem používal tu automatizaci toho procesu aby si ty lidi nemuseli pamatovat jakoby co mají všechno dělat tak automaticky nástroj jako je rotl nebo incident Ao založí slack kanál pozve všechny důležitý účastníky založí na to zoom Call jo kde máte nějakou e War místnost sbírá všechny ty

data co tam píšete můžete potom si otagovat ty obrázky ty screenshoty s těma měření s těma třeba s tí observable a podobně a umožní vám to celou tu tu timeline potom vyso jakoby vypublikovat třeba do Wiki nebo nebo do nějakýho dokumentu kde to potom zpracováváte a ušetří vám to takovou tu tu jakoby přepisovací nějakou otrockou práci dneska určitě Ai vám napíše Samary Když budete chtít a a podobný věci takže jak moc takovýmu s nemůžeš věřit ale to je jedno no ale tak jako já ne ne neříkám že že že by to nemělo projít nějakou lidskou korekcí ale že vám to Tyhle nástroje vám pomůžou jakoby to odstartovat že jo jako mít tam ty sekce předpřipravený furt to musí potom lidi projít musej musej mít ty otázky musej se ptát protože žádnej počítač vám nebude pokládat otázky že jo dneska jako vy se ho musíte ptát On je schopnej něco najít když to je ale vy musíte mít ty otázky a vy musíte mít ty podklady abyste dokázali když něco někdo tvrdí nějakou teorii že se to stalo proč a jak

tak by na to měl mít nějakej důkaz a to jak jsme se bavili že je to trochu ta detektivní práce protože často vidím a v mý minulosti jsem viděl že někdo jakoby je hodně nahlas v tomhle procesu ale vlastně jenom jakoby má pocit že se to tak stalo To není schopnej to dokázat a já Vždycky říkám No dobře tak to bereme to je nějaká teorie Pojďme se podívat jestli máme důkazy pro nebo proti Protože i když najdete proti důkaz tak je to taky dobře protože Můžete to vyloučit tuhle že jo A a takhle musíte přesně postupovat abysme došli k něčemu co dává smysl potom pro všechny a mít z toho tu akci Ještě jedna věc je důležitá a Přesně jak jsi říkal potom když je ta preventivní akce tak já doporučuju celý vlastně jak postmortem tak vlastně ty korektivní mít v jednom tiketovací systému aby vlastně se dobře trekoval že tady ten tiket patří k tomuhle incidentu a že to má mít nějakej deadline a že se to má dostat do nějakýho sprintu a že se to má vyřešit

aby to někde nezapadlo v nějakým Wordu v nějakým spreadsheetu jo kde kde to jednou za měsíc jednou za čtvrt roku někdo někdo třeba kontroluje a nebo vůbec se to nekontroluje to je ta nejhorší varianta když to vůbec nekontroluješ Nebo to to je v oci Tohleto je vyřešený tím že tam je automaticky ke všemu se musej dávat nějaký deadliny a tam je dashboard a ten se na ten se kouká každej tejden a samozřejmě je to klasicky jako máli se nějaká aktivita odehrát tak je potřeba jí trekovat měřit a honit lidi zodpovědný lidi aby to dotáhli do konce že jo to je e na tom stojí vlastně všechno určitě no jakoby bez měření a bez toho abyste ty lidi fakt donutili tak tak to asi nezvládnete Ale je pravda že když to potom funguje Lidi si na to zvyknou tak a těch incidentů nemáte hodně taky to taky pomáhá tak vlastně ty lidi si to berou za svý a potom ty korektivní akce fakt jako fungujou ty fixy jdou rychle lidi se snažej aby vlastně tou prevencí potom snižovali si

ten vlastní počet incidentů a když viděj že to kolečko funguje že třeba mají já nevím PT 10 incidentů měsíčně dobře se ty kapy dělaj klesá ty čísla klesají vlastně potom v důsledku toho že ta prevence se zlepšuje třeba že se to vychytává pokud celej ten proces i i vlastně provoz toho tý služby Tak my jsme viděli fapi že potom jsme měli jako incident jednou za uherskej rok víceméně a a bylo to úplně v pohodě vždycky No v momentě kdy to skončilo v Maintenance režimu tak tam žádnej incident nebyl jako měsíce přesně No protože prostě nebylo proč No muselo bejt nějaký fakt jako selhání na úrovni regionu nebo něco takovýho A to jsme stejnak jenom koukali Hele Díky já myslím že že jsme to docela popsali A kdybyste k tomu Měli nějaký otázky tak nám napište My rádi jako bysme to rozpracovali případně když nám napíšete na email tak My uděláme nějaký ještě pokračování tohodle Pokud vás to zajímá Jo jo díky Láďo díky všem že nás Posloucháte a zase brzo naslyšenou naslyšenou