V každém netriviálním systému je selhání nevyhnutelné a k incidentům dochází. To, jak se s následky incidentů vypořádáme, rozhoduje o tom, zda nás budou stát jen peníze, nebo z nich něco získáme.

Slyšel jsem Johna Allspaw říkat citát o incidentech nebo výpadcích, který na ně dokonale sedí:

Incidenty jsou neplánované investice do přežití vaší společnosti.

Je po incidentu. Tuto „investici“ jste tedy provedli, vše je opět v provozu a nyní byste z ní měli získat co největší hodnotu. První částí tohoto procesu je provedení post mortem analýzy.

Skupina politiků debatuje při vyšetřování koronera

Klam hlavní příčiny

V mnoha organizacích se analýza po incidentu nazývá “zjištění hlavní příčiny” (anglicky root cause analysis) a v tom spočívá problém. Často vede k výsledku, že tam byla ta jedna věc, která se nepovedla, a kdyby se tato jedna věc povedla, k incidentu by nedošlo. To může být pravda, ale problém tohoto přístupu spočívá v tom, že obvykle existuje více než jen jeden faktor, který vedl k incidentu, a pokud se spokojíme s nalezením JEDINÉ hlavní příčiny, unikne nám celá řada potenciálních problémů.

Chápu touhu managementu incident zjednodušit, identifikovat příčinu, napravit ji a jít dál. Pokud však chceme získat maximální hodnotu za naše peníze, které jsme již na incident vynaložili, neměli bychom se s tím spokojit.

Cíl najít hlavní příčinu spolu s tendencí lidí hledat především vnější faktory způsobující incident často končí tím, že se za kořenovou příčinu považuje vadná hardwarová součástka nebo softwarová chyba v softwaru třetí strany. Tímto způsobem je možné někoho zvenčí obvinit, případně zažalovat a všichni mohou jít bez obav domů. A protože již máme nalezebnu tu jednu skutečnou hlavní příčinu, není třeba incident dále vyšetřovat.

Pokud se nám nepodaří najít externího dodavatele, který za to může, je další oblíbenou tendencí hledat někoho interního, kdo něco pokazil, a potrestat ho. To je ještě horší než hledání externí příčiny. Nejenže to obvykle nic neřeší, ale aktivně to brání tomu, aby se firma z tohoto incidentu a také z případných budoucích poučila. Stane-li se nalezení viníka a jeho potrestání normou, stane se hlavním zájmem všech zúčastněných při jakémkoli pozdějším incidentu “hlídaní si zad”, a nikoli úspěšné a rychlé řešení. A to je to poslední, co si v inženýrské organizaci nebo v jakékoli jiné organizaci přejete.

Pokud budeme ale postupovat jinak, můžeme mnohem lépe pochopit, jak věci skutečně fungují a selhávají. Vyžaduje to ale trochu více práce, času a nasazení.

Co znamená “bez obviňování”

Termín “postmortem bez obviňování” (anglicky blameless postmortem) není nový a rozhodně jsem s ním nepřišel já, ale přesto se často setkávám s tázavými pohledy, když mluvím o jeho provedení.

Znamená to, že lidi zprostíme viny za to, že něco zanedbali nebo udělali špatně? Že jim špatně odvedená práce projde? No, je to trochu složitější, ale jednoduchá odpověď zní: Tak trochu ano.

Cože? - Anarchie! Chaos!

Víte, byl jsem svědkem nesčetných incidentů. Některé malé, způsobující pětiminutový výpadek webových stránek. Některé velké, které vedly ke ztrátě několika měsíců e-mailů lidí ve středně velké organizaci. Nemohu vyloučit, že se to někde může stát, ale ještě jsem neviděl incident způsobený tím, že by někdo v organizaci chtěl úmyslně škodit nebo vědomě sabotovat firmu. Proto je třeba vždy předpokládat dobrý úmysl, pokud se neprokáže opak.

Být původcem incidentu je pro všechny nesmírně stresující. Různí lidé se s tímto stresem vyrovnávají různě. Někdo zezelená, někdo otupí, někdo začne žertovat. Snažte se nerozdávat rychlé soudy o úmyslech lidí na základě toho, jak se tváří během incidentu nebo krátce po něm.

Předpokládejte také, že lidé, kteří něco podělali, to většinou vědí dříve, než se to dozví ostatní. Už jen ten pocit je sám o sobě jakýmsi trestem, někdy velmi přísným, takže není třeba to hnát dál. Vlastně spíše naopak. Lidé někdy dávají vinu sami sobě, a to i v situaci, kdy jim selhání připravily vnější faktory a jejich čin byl tou pověstnou poslední kapkou. V takových případech potřebují spíše povzbuzení než jízlivé poznámky.

Post mortem bez obviňování znamená, že nehledáte viníka. Místo toho hledáte poznatky, proč a jak váš systém selhal a jak si v budoucnu počínat lépe. Jakmile se zbavíte obviňování, uvidíte, že se vám otevře zcela nový vhled. Lidé budou upřímněji popisovat, co a proč dělali, i když se to zpětně ukázalo jako špatné. A to přece chcete. Odstraněním obviňování odstraníte jejich motivaci zatajovat fakta nebo měnit příběh, který vyprávějí, aby zakryli důležité, ale nelichotivé skutečnosti.

Lidská chyba

Existuje ještě jeden pojem, se kterým se často setkáváme při analýzách po incidentu. Mýtická “lidská chyba”. Někdy slyšíte otázku: “Byla to chyba techniky nebo lidská chyba?“ Pokud nevíme nic lepšího, bývají myšlenky následující:

a) Pokud to bylo selhání zařízení, buď s tím nemůžeme nic dělat, nebo možná příští rok zařadit do rozpočtu lepší zařízení;

b) Pokud je to “lidská chyba”, zjistíme, kdo ji způsobil, a potrestáme ho, nebo mu alespoň řekneme, aby si “příště dával větší pozor”.

To je ovšem pro zvýšení celkové odolnosti proti případným budoucím selháním naprosto k ničemu.

Problém tohoto přístupu spočívá v tom, že pokud budete hledat dostatečně důkladně, vždy můžete analýzu ukončit lidskou chybou. I kdyby šlo o selhání zařízení, lze to považovat za lidskou chybu. Buď někdo udělal chybu při výrobě, nebo někdo špatně vybral konkrétní zařízení pro danou práci, nebo nebylo správně udržováno. Faktem ale zůstává, že tvrzení, že šlo o lidskou chybu, vám nedává vůbec nic, kromě toho, že máte koho obvinit. A to, jak jsme již zjistili, nehledáme.

Proto navrhuji, abyste během post mortem analýzy jednoduše odstranili ze svého slovníku výraz lidská chyba. Nikdy se nespokojte s tím, že někdo udělal chybu. Otevřete tím diskusi k tématům jako např.:

Praktický návod

Ještě když incident stále probíhá, se můžete začít připravovat na post mortem analýzu. Pokud jste manažerem, jste pro to ideální. Místo toho, abyste stáli svým lidem za zády a ptali se jich, zda už je to opravené, měli byste si dělat poznámky a vést si časovou osu. Zapisujte si, co lidé říkají. Zaznamenávejte si, co vidíte.

Po vyřešení incidentu nechte lidi trochu odpočinout, ale nečekejte déle než jeden nebo dva dny. Vyzvěte všechny, aby si mezitím zapsali osobní poznámky. Naplánujte post mortem schůzku. Pozvěte na ni všechny, kteří měli s incidentem něco společného, do stejné místnosti nebo na konferenční hovor. Vyberte jednu osobu, která bude “koronerem”, a pověřte ji vedením analýzy a vypracováním zprávy. To zabere nějaký čas (u komplikovaných událostí to může být i několik dní), proto se ujistěte, že koroner má na tuto činnost dostatek volných kapacit.

Hned na začátku nahlas řekněte, že půjde o postmortem bez obviňování, a vysvětlete, co to znamená. Poté nechte každého vyprávět svou verzi příběhu. Ujistěte se, že všichni dávají pozor. Pokud to párkrát uděláte, zjistíte, že mnoho lidí bude prezentovat vzájemně velmi odlišné příběhy. To znamená, že mají velmi odlišné mentální modely systému. To je nevyhnutelné v každém dostatečně složitém systému, ale provádění post mortem tímto způsobem pomáhá se sladěním mentálních modelů různých členů vašeho týmu. Může se zdát jako ztráta času, když vývojáři musí poslouchat správce sítě, jak ladili problém s fragmentací paketů, ale mějte na paměti, že jedním z hlavních výsledků post mortem je sdílení znalostí.

Nechte lidi popisovat:

Vše si zapište a sestavte podrobnou časovou osu akcí a rozhovorů. Přiložte všechny relevantní logy a obsah chatů. Ve skutečnosti může být zapotřebí více než jedno sezení nebo si může koroner domluvit další individuální schůzky se zúčastněnými osobami, pokud je zapotřebí více podrobností.

Při hledání příčin výpadku se nesnažte identifikovat pouze přímé příčiny, ale hledejte také přispívající faktory. Proč trvalo tak dlouho, než se na problém přišlo? Proč jeho řešení trvalo tak dlouho? Proč byl dopad výpadku tak velký? Proč to naše testy nezachytily? A tak dále.

Závěrečná zpráva by měla obsahovat alespoň následující části:

Poslední bod může být někdy ošemetný. Tato část bude zajímat především vaše vedení. “Co děláme, aby se to už neopakovalo?” Mělo by být v pořádku říci: “Zatím nevíme.” Ne všechno lze vyřešit okamžitě. I když se to může zdát divné, někdy může být odpovědí také “nic”. Může se stát, že samotná postmortem analýza je nápravnou akcí v případech, kdy zvyšujeme znalosti a vhled týmu. Nejčastěji však existuje něco, co lze udělat, aby se podobným incidentům v budoucnu zabránilo.

Záměrem tohoto článku není popsat všechna možná opatření, která můžete přijmout ke zvýšení odolnosti systému. Jen se ujistěte, že se neomezujete pouze na technická opatření. Nejčastěji totiž problém spočívá v postupech, komunikaci, školení a motivaci.

Přestože většina z nás nepracuje na systémech, kde jsou ohroženy lidské životy, je přínosné podívat se na odvětví, kde tomu tak je, a prostudovat si, jak se vypořádávají se selháním. Civilní letectví a stavební průmysl může být skvělým zdrojem inspirace. Kdyby reakcí letectví na letecké nehody způsobené “chybou pilota” bylo, že se pilotům řekne “příště buďte opatrnější, jinak …”, myslím, že by nikdo z nás už nechtěl létat.

Bezpečnost plodí bezpečnost

Doporučuji vám shlédnout tuto přednášku Simona Sinka na TEDu o tom, jak skvělí lídři vytvářejí pocit bezpečí. Stejné principy platí i post mortem analýzách. Pokud svým lidem dáte pocit bezpečí, kde mohou o incidentech mluvit otevřeně, bez obav z trestu, budou o nich mluvit. Pokud vytvoříte bezpečné prostředí pro učení se z chyb, k poučení dojde. Mnoho lidí se dokonce nadchne pro zlepšování bezpečnosti vašeho systému. A to je nakonec to, na čem by vám mělo skutečně záležet.

Tag: odolnost

Comments