Už víte, že BC/DR je kritickou součástí úspěchu organizace. A víme, že jsou potřeba metriky pro měření efektivity úsilí. Prvním krokem je porozumět metrikám, které jsou důležité při plánování kontinuity podnikání a obnovy po havárii, což je přesně to, o čem bude tento článek. Budete také potřebovat nástroj ke shromažďování těchto metrik a vytváření přehledů o nich. V závislosti na velikosti vaší organizace a úrovni vyspělosti vašeho programu BC/DR to může sahat od šablony Excel až po výkonný automatizovaný software.
Existuje 7 důležitých metrik BC/DR, které je třeba sledovat za účelem růstu a měření plánů obnovy:
I když existuje mnoho dalších metrik ke sledování, tyto metriky slouží jako základní přehled programu a ukazují, jak dobře jste skutečně připraveni na řešení problému s blokováním.
První dvě důležité metriky BC/DR jsou Cíle doby zotavení (RTO) a Cíle bodů obnovy (RPO). RTO je maximální přijatelná doba, po kterou může být položka nečinná. RPO určují, jak stará data si můžete dovolit ztratit a zda vaše zálohy zachrání zbytek. Pokud si například můžete dovolit přijít o hodinu dat, budete muset zálohovat alespoň každou hodinu.
Procedury zálohování a obnovy jsou jádrem dobrého plánu BC/DR, takže musíte vzít v úvahu RTO i RPO, abyste určili nejlepší nástroje zálohování a obnovy pro danou úlohu. Pokud například generujete nepřetržité transakce se středním až vysokým objemem a hodnotou, kolik minut transakce si můžete dovolit ztratit? Jak dlouho jste si mohli dovolit být mimo službu? Taková aplikace by mohla těžit z velmi častých záloh na úrovni bloků, které jsou možné s nepřetržitou ochranou dat (CDP), ale to byste nevěděli, pokud byste se nepodívali na RTO a RPO.
Nakonec je potřeba změřit počet plánů, které pokrývají každý obchodní proces , jakož i čas, který uplynul od aktualizace každého plánu . Klíčové ukazatele výkonu (KPI) jsou měřítkem toho, jak dobře program funguje, a nelze je ignorovat. Můžete nastavit KPI, jak často kontrolujete a aktualizujete své plány (například měsíčně, 6 měsíců nebo ročně) a kolik obchodních funkcí pokrývá plán obnovy, s akčním plánem pro dosažení 100% pokrytí. Máte-li nedostatek času a zdrojů, začněte s nejdůležitějšími obchodními procesy.
Podniky mohou mít stovky až tisíce procesů a není možné obnovit proces bez plánu. Klíčovou metrikou pro plánování BC/DR je počet procesů ohrožených potenciální katastrofou .
Měli byste začít s analýzou rizik a analýzou dopadu na podnikání, abyste:
Poté můžete vytvořit plány na ochranu těchto procesů a minimalizaci narušení v případě katastrofy.
Statické plány ale mohou stagnovat. Procesy nelze vrátit zpět, pokud pravidelně neaktualizujete své plány, abyste zohlednili změny v aplikacích, datech, prostředích, zaměstnancích a rizicích. Měli byste si nastavit připomenutí, abyste ve vhodných bodech cyklu vyvolali kontroly plánu. V dokonalém světě byste dostali potvrzení od vedoucích různých oddělení, že zkontrolovali a aktualizovali své plány, ale buďme upřímní: kontrola a aktualizace těchto plánů je obrovský problém a je téměř zázračné, pokud to stihnou včas. Použití softwaru může zmírnit tento problém: Můžete automatizovat e-mailové připomenutí různým vlastníkům plánů a sledovat jejich pokrok v rámci softwaru – nepotřebujete žádné pasivní agresivní e-maily! Software také odstraňuje mnoho zdlouhavých úkolů souvisejících s řízením změn. Například automatizovaná integrace dat bude udržovat vaše data automaticky aktualizovaná při změnách dat v jiných aplikacích. Je-li jeden kontakt použit ve 100 plánech a jejich telefonní číslo se změní, integrovaný systém tuto změnu promítne také do vašich plánů kontinuity podnikání a krizového řízení.
Jedním z nejjednodušších způsobů, jak určit, jak jsou obchodní funkce vzájemně závislé, je použít nástroj pro modelování závislostí. To vám pomůže vizualizovat, zda vám závislosti vaší aplikace umožňují splnit RTO a SLA.
Pokud například potřebujete obnovit službu Accounts Payable za 12 hodin, ale to závisí na finančním softwaru, jehož obnovení může trvat až 24 hodin, Accounts Payable nemůže splnit 12hodinovou smlouvu SLA. Modelář závislostí tyto závislé vztahy dynamicky ilustruje a kdy a jak se v důsledku toho plán rozpadne.
Měli byste měřit skutečný čas potřebný k obnovení obchodního procesu . Postupy obnovy můžete otestovat pomocí nástroje BC/DR a sledovat, jak dlouho každý krok trvá.
Případně můžete použít starou metodu načasování každého kroku ručně. Tyto testy vám pomohou určit, zda vaši lidé a procesy mohou splnit RTO pomocí vašeho stávajícího plánu. Měli byste být schopni dokončit úkoly obnovy v čase povoleném vaším plánem, a pokud nemůžete, musíte svůj plán revidovat tak, aby byl realistický a dosažitelný.
A konečně poslední metrikou obsaženou v tomto zdroji je rozdíl mezi skutečnou a očekávanou dobou zotavení , také známý jako analýza mezer. Můžete testovat mezery pomocí testování převzetí služeb při selhání a obnovy, testování BC/DR na podnikové úrovni a analýzy mezer. Jakmile najdete mezery ve svých plánech, můžete nastavit KPI a použít je v procesu plánování.
Data shromážděná softwarem BC/DR musí být „čistá“, aby bylo zajištěno přesné vykazování a plánování. Pro dobrou hygienu dat nezapomeňte standardizovat zadávání dat pomocí rozevíracích nabídek, výběrových seznamů, formátování textu a ověřování dat. Pokud například zařadíme telefonní čísla zaměstnanců do plánu, doporučujeme zkontrolovat, zda tato telefonní čísla obsahují směrové číslo oblasti a zůstávají používána.
Deduplikace a správa identit a přístupu (IAM) mohou pomoci vytvářet elegantní data. Deduplikaci můžete použít k odstranění více aspektů stejných položek. Můžete použít přihlašovací údaje (autentizace) spolu s oprávněními (povolení), aby bylo zajištěno, že záznamy a kmenová data budou zadávat pouze kvalifikovaní uživatelé. Také ušetříte spoustu času a námahy integrací vašeho BC/DR systému s jinými aplikacemi (například s vaším HR systémem), abyste se vyhnuli duplicitě záznamů a jakékoli možnosti chyb.
Pomocí nástroje pro modelování vztahů určete kritické obchodní funkce a jejich vzájemnou závislost.
Dále nastavíme přijatelný práh prostojů pomocí metrik RTO a RPO. Testujeme plány, abychom zjistili, zda se těmto prahům přiblížíme nebo je překročíme. Poté si plány projdeme a znovu je otestujeme. Měli bychom nastavit KPI, abychom měřili, jak často jsou plány aktualizovány a testovány, a provádět analýzu nedostatků pro porovnání plánované a skutečné doby zotavení.
Nakonec se ujistěte, že data udržujete „hygienická“ pro přesné hlášení. Metriky BC/DR jsou zcela zbytečné, pokud jsou data nepřesná. Může se to zdát jako samozřejmost, ale je překvapivé, kolik společností se ukolébá falešným pocitem bezpečí se zprávami, které zkreslují jejich SLA. Vždy je nejlepší být realistou, i když to znamená přijmout s tím spojená rizika.
Ercole Palmeri
Námořní sektor je skutečnou globální ekonomickou velmocí, která se dostala na 150miliardový trh...
Minulé pondělí Financial Times oznámily dohodu s OpenAI. FT licencuje svou prvotřídní žurnalistiku…
Miliony lidí platí za streamovací služby a platí měsíční předplatné. Je obecný názor, že jste…
Společnost Coveware od společnosti Veeam bude i nadále poskytovat služby reakce na incidenty v oblasti kybernetického vydírání. Coveware nabídne forenzní a sanační schopnosti…