Disaster Recovery Plan (DRP), neboli Plán obnovy po havárii je strategický dokument popisující cestu k co nejrychlejšímu obnovení práce po neplánovaném incidentu, který narušil běžné fungování společnosti. V tomto článku se dozvíte, jak postupujeme při tvorbě DRP a co má správně obsahovat.
Díky tomu, že se v prostředí firem, kde došlo k aktuálnímu útoku pohybujeme prakticky neustále, vnímáme absenci smysluplně sepsaného plánu postupu jako velmi zásadní. Dobře sepsaný DRP zajistí rychlé a efektivní obnovení operací, ochranu dat, minimalizuje výpadek provozu, chrání reputaci firmy a zvyšuje šanci na přežití firmy po mimořádné události. Tím, že definuje kroky a postupy pro obnovení dat, systémů a operací, pomáhá minimalizovat škody a zajišťuje kontinuitu podnikání.
KDYŽ TO BOUCHNE…
Ideálně se v takové situaci vytáhne podrobný manuál, který rozdělí role a odpovědnosti a vede předem definované členy krizového týmu po cestě, jak co nejefektivněji obnovit fungování IT a tím samozřejmě i celé firmy.
Naopak nejčastěji se pohybujeme v prostředí, kde žádný podobný plán neexistuje. Jsme zvyklí na tvrzení: „Mám to někde rozepsané, ale nestihl jsem to dokončit..“, „Je to někde mezi zašifrovanými soubory…“, „Tohle jsem nedostal za úkol…“ apod.
Ono je ve výsledku zbytečné v takové situaci hledat viníka, jelikož vina bude obvykle na více stranách. Vnímání důležitosti IT oddělení je v dnešním firemním světě ještě stále podceňováno. Ve velké části i velmi úspěšných firem nejsou lidé z IT součástí vedení firmy, ale jsou podřízeni například provoznímu řediteli. Tím pádem jsou to více administrátoři než IT manažeři. Oproti tomu vypracování DRP je věcí překračující možnosti i kompetence běžného IT admina.
JAK SESTAVUJEME DRP?
Snažíme se neúkolovat IT adminy nebo IT manažery vyplňováním nutných podkladů, ale při společných workshopech si podstatné otázky necháme zodpovědět a sami zapisujeme. Struktura plánu je víceméně jednotná, samotný obsah ale ve firmách bývá natolik rozdílný, že se vlastně ani nedá poslat jako vzor k vyplnění.
Naše zkušenost je taková, že vhodným člověkem pro získávání informací a podkladů pro tvorbu DRP bývá někdo z oblasti řešení firemních procesů nebo HR. Tito lidé dokáží pracovat s texty a mívají větší povědomí o firemních souvislostech a tento typ práce je jim vlastní.
- Začínáme vždy deklarací v podobě krycího listu, jako v běžných projektech. Účel, obsah, zpracovatel, zkratky a pojmy, plán testování. Pro přehlednost připojujeme i grafické schéma procesu.
- Pokračujeme sestavením krizového týmu včetně zastupitelností s uvedením telefonických kontaktů.
- Popis IT infrastruktury je první z čistě technických částí plánu. A i kdyby se firma nebo organizace rozhodla DRP neřešit, popis IT infrastruktury prostě musí každá firma nebo organizace mít. Je to také jedno z prvních zadání, které má nový IT manažer převzít, nebo znovu vypracovat podrobný popis všeho, co vše má IT tým ve správě.
- V části Analýza rizik specifikujeme všechna možná rizika s návazností na fungování firmy a s uvedením odkazu na kapitoly s konkrétními řešeními. IT tým zde vedeme ke zvědomění si, co je pro firmu a provoz IT důležité a nakolik jsou jednotlivé části a situace rizikové.
- Plán obnovy je částí, která je v samotném jádru plánu a jeho autory v tomto případě bývají členové IT týmu. Tohle nikdo jiný sám dohromady nedá. Krok za krokem, včetně stanovení času, dodavatele a náhradního řešení.
- Plán komunikace už je netechnická, ale nezbytná část plánu. Řešíme zde, kdy, kdo a jak v případě havárie komunikuje jak směrem dovnitř firmy, tak i směrem ke klientům, partnerům, úřadům apod.. Paradoxně tato část obvykle spotřebuje více energie, než by se čekalo a stojí za to mít tyto otázky vyjasněny.
- Končíme Plánem testování, kde společně stanovujeme metody, způsoby, konkrétní odpovědné osoby, kdo a komu prezentuje výsledky testování. V návaznosti na výsledek testování pak předem definujeme, kdo přijímá nápravná opatření a kdo je zodpovědný za aktualizaci plánu a pravidelné proškolení celého krizového týmu.
Po vypracování DRP je zcela zásadní udržovat jej stále aktuální. Zbytečně se občas nechává zapadnout a při ostré akci jako neaktuální nesplní svůj původní úkol. Práce na tomto plánu navíc přesahují původní účel a výsledek má široký přesah do fungování IT týmů.