V týdnu jsme všichni jistě alespoň na pár minut upnuli svůj zrak ke Štrasburku. Nikoliv kvůli nějakému politickému rozhodnutí nebo kvůli sportovnímu zápasu, ale kvůli obyčejnému požáru budovy na břehu Rýna. Ve středu brzy ráno propukl požár v datacentru společnosti OVHCloud, který kompletně zničil jednu budovu, poškodil druhou a celou lokalitu vyřadil na několik dní až týdnu z provozu. Nebudu se pouštět do spekulací, co požár způsobilo, proč měl tak drastické následky a co mohlo OVH udělat lépe. Podívám se ale co naopak my, admini a zákazníci providerů, můžeme udělat abychom zabránili likvidaci své firmy.

Všichni už jsme asi zažili SMSku nebo automatický hovor z monitoringu, že něco nefunguje. Že je našemu milovanému projektu auvajs a žádá si naší pozornost. A nemusí to být jenom kvůli požáru, vyřadit systémy může prasklé potrubí v budově, administrátorská chyba na síti v Indii nebo neodborný zásah policie – pamětníci si jistě vzpomenou na rok 2007 a kauzu s názvem NBUSR123. Scénář je ale vždy stejný – najednou, bez jakéhokoliv varování, všechno zhasne a monitoring se rozsvítí rudě. Nic nefunguje.

A co teď? Můžete buď nadávat, stěžovat si a panikařit nebo aktivovat svoje disaster recovery plány. Scénáře, které jste v době klidu sepsali pro případ, že se něco hodně, hodně pokazí. Dokumenty, o kterých jste doufali, že je nikdy nebudete muset číst.

Disaster recovery plán – co to je, jak to má vypadat, kdo to má sepsat

Ve zkratce – DR plány jsou dokumenty, které jasně popisují, jak dostat technologii a projekt zpět do funkčního stavu. Mají mnoho podob a pokrývají spoustu možných scénářů. Mohou to být jednoduché seznamy krizových přístupů ale mohou to být i komplexní scénáře, které zahrnují úkony napříč několika odděleními ve firmě. Vždy by ale měly obsahovat co je potřeba udělat, kdo to má udělat a jak to má udělat. Kde jsou dostupné zálohy, v jakém pořadí je potřeba nahazovat služby a obnovovat data. Vhodné je zahrnout i přihlašovací údaje na krizové účty, ať je máte po ruce. Cílem DR plánů je vždy minimalizovat obchodní dopad katastrofy a co nejrychleji postavit projekt zpátky na nohy. Musí být napsány jasně a stručně, protože když už podle nich budete postupovat, určitě to nebude v klidu a pohodě.

Je běžné, že DR plány mají přesah do jiných oddělení. Kromě technického zvládnutí problému je potřeba udržovat kontakt se zákazníky případně zajistit podklady pro právní oddělení. Proto je potřeba při sepisování DR plánů přibrat na pomoc zástupce jiných oddělení, konzultovat jednotlivé kroky s nimi a mít jistotu, že postupy dávají všem smysl a nezapomněli jste na nějaký netechnický dopad.

Při jejich tvorbě můžeme vycházet z principu letectví. Když dojde k problému v letadle, platí postup “Aviate, Navigate, Communicate”, tedy udrž letadlo ve vzduchu, zjisti kde jsi a kam můžeš a až pak se otravuj s komunikací. V IT toto lze využít také: Nejprve se snažte zachránit co jde (minimalizovat přímé dopady, klidně odstavením systémů), dostat systém do dostatečně stabilní podoby a až pak komunikovat ven. Pokud máte více adminů, lze proces paralelizovat a je to i vhodné. Není nic horšího, když admina “otravují” spousty hovorů a dotazů z obchodu a customer supportu, co mají říct klientům.

Krok 1: Aviate

Když letadlo spadne na zem, je konec. Přišli jsme o letadlo, o posádku, o náklad, o pasažéry. Proto je potřeba jej udržet ve vzduchu. A stejně tak v IT – pokud přijdeme o jednu službu, je potřeba minimalizovat kaskádové dopady na další i za cenu jejich odstávky.  Když příjdeme postupně o všechna data a systémy, firma končí. Krátkodobá odstávka projektu je výrazně menší zlo než dlouhodobá obnova dat. Typickým příkladem tohoto je chyba v aplikaci, které při updatu ukládá poškozená data. V tomto případě je mnohem lepší aplikaci odstavit a zabránit zničení většího množství dat, než ji nechat běžet a pracovat na vydání fixu.

Krok 2: Navigate

Okey, zabránili jsme zničení všech dat. Stále ale vzniká škoda, aplikace je nedostupná, klienti začínají být naštvaní. Teď je na čase začít zjišťovat co se stalo, zjišťovat celkové dopady a připravovat plán na obnovu. Lze opravit aplikaci jednoduchým fixem? Je potřeba obnovovat nějaká data ze zálohy? Jak dlouho bude trvat návrat do minimálního funkčního stavu a jak dlouho bude trvat kompletní oprava? O kolik dat jsme nenávratně přišli? To jsou všechno otázky, které jsou teď na stole a na které potřebujeme rychle znát odpověď.

Krok 3: Communicate

Víme co se stalo, víme co musíme udělat, víme jaké jsou dopady a jak rychle bude trvat oprava. Můžeme tedy komunikovat zákazníkům nějaké naše odhady. Je vhodné vyčlenit jednoho pracovníka jako styčný bod komunikace. Někoho, kdo bude od začátku komunikovat s obchodem, s podporou, se zákazníky a bude sloužit jako štít stojící před adminy, kteří zachraňují situaci. Tuto roli se hodí přidělit někomu z řízení projektu, v agile světě to bude project owner. A hlavně je potřeba zajistit, že všichni ve firmě vědí, na koho se mají obracet s dotazy.

Komunikace ven je bezesporu důležitá a v krizi o to víc. Ale nesmí být na úkor obnovy provozu. Hlavně pro obchod a podporu vždy platí, že informace, které jim předáváme, musí být aktuální a platné v daném časovém bodě, nemusí být ale přesné a neměnné. Vždy stavíme na tom, co v daném bodě víme. Situace se na začátku může zdát snadno opravitelná, ale další průzkum odhalí mnohem dramatičtější dopady, než jsme mysleli. Proto nikdy nesmíme komunikovat termíny a odhady jako definitivní. Vždy je potřeba říct “ale situace se může změnit”, vždy je potřeba počítat s výrazným prodloužením obnovy. A vždy s tím musí počítat všichni ve firmě.

Pravomoce krizového řízení

V klidných dobách je pochopitelné, že velké investice nebo zásahy je nutno konzultovat s vedením firmy a důkladně naplánovat. Že vybereme nejvýhodnějšího dodavatele, dohodneme dobré obchodní podmínky, analyzujeme a testujeme dopady. Jakmile ale udeří krize, tyhle věci musí jít stranou. Záchranný tým musí mít pravomoce činit rozhodnutí rychle, bez ohledu na efektivitu nebo obchodní dopady. Pokud umře nějaký klíčový hardware a nemáme skladem náhradní kus, není prostor na vyjednávání s dodavateli. Je potřeba vzít firemní kartu, sednout do auta a mazat do alzy pro nový kus i za cenu vyšších nákladů. Nebo je snad dlouhá odstávka firmy levnější? Pokud běžíme v cloudu, musí mít záchranný tým pravomoc ihned spustit další instance, bez ohledu na rozpočet infrastruktury.

Zálohy, zálohy, zálohy

Často se potkávám s názorem, že infrastrukturu a data v cloudu není potřeba zálohovat. Že proto si přece platíme cloud, abychom nemuseli utrácet za zálohy. Tento přístup je chybný a určitě povede teď po požáru OVH ke krachu několika firem. V cloudu si kupujete výpočetní kapacitu, kupujete si prostor na storage, kupujete si služby. Nekupujete si ale bezpečnost vašich dat. Kupujete si jistotu, že v případě problému můžete data do cloudu obnovit, můžete spustit novou sadu serverů. Je ale vaše zodpovědnost mít kopii dat k obnově, mít informace o konfiguraci serverů, mít popsaný postup nasazení aplikace. Cloud vám pouze poskytuje platformu, ale obchodní hodnotu ji dáváte vy. Cloud je schopen vám v tom pomoci pomocí georeplikace nebo pomocí služby na zálohování. Ale využít ji musíte vy, vy ji musíte dát smysl a vy musíte mít připravený proces obnovy dat.

A pak taky potřebujete mít jistotu, že zálohy jste schopni obnovit. Viděl jsem nejeden případ, kdy sice firma krásně zálohovala, ale když došlo na potřebu obnovy, zálohy byly nepoužitelné. A nemusí to být jenom problém v záloze jako takové, zálohy mohou být z důvodu problému nedostupné nebo nekompletní. Proto je potřeba zálohy pravidelně testovat. Vyzkoušet, že jste schopni ze zálohy data obnovit, že zálohujete vše, co potřebujete a že zálohujete dostatečné množství dat. Nikdy nebudete mít v záloze 100% dat, vždy o něco příjdete. Je ale otázka, jestli příjdete o týden, o den nebo o hodinu. A odpověď na ní musí dát vedení firmy. Vedení musí říct, o kolik dat je ochotno přijít, resp. kolik peněz je firma ochotná do zálohování a obnovy dát. A zde platí nelineární vztah – pokud zálohování 1x denně stojí Xkč, zálohování 2x denně nestojí 2Xkč, ale klidně 5X nebo 10X. Firma musí říct, jestli mají data mimo zálohu takovou hodnotu, nebo jestli je výhodnější tato data již obětovat.

Problémy se stávají. Každý admin už podobnou situaci zažil a nikdy to není příjemné. Ale vždy se dá na situaci připravit předem a minimalizovat dopady na chod firmy. Není to zadarmo, není to snadné a nepřináší to zisk. Ale zabrání to velkému problému v budoucnosti a vždy se to vyplatí. Myslete na to.