Plánování kontinuity činnosti (1)

11. 8. 2009

Sdílet

V dnešním světě dramaticky roste potřeba ochrany kontinuity činnosti. Tedy zajištění toho, aby organizace mohla poskytovat své služby nejen dnes, ale i zítra či pozítří, a to bez jakýchkoliv kompromisů v otázkách kvality.

S rostoucím propojením klasických systémů a procesů s informačními technologiemi narůstá větší tlak na to, aby se právě ICT nestalo nejslabším článkem celého systému.


Trvalý provoz

Potřeba zajištění kontinuity činnosti se začala objevovat poprvé zhruba v osmdesátých letech minulého století. Z pochopitelných důvodů se týkala ICT jen velmi okrajově. Tato role se ovšem od té doby podstatně otočila a s trochou nadsázky bychom mohli říci, že dnes se zajištění kontinuity týká jen okrajově oblastí, které nespadají do ICT (byť je nikdy nevytěsní a vytěsnit nemůže – k čemu je např. perfektně fungující informační systém v dopravním podniku, kterému nevyjedou vozy na trať?).

Není to jediný zásadní posun, ke kterému v uplynulých letech došlo. Dříve bylo hlavním a potažmo jediným cílem plánování kontinuity činnosti zajistit pokračování po nějakém velkém výpadku nebo události. Prostě zajistit, aby jedna mimořádná událost velkého rozsahu nemohla „srazit vaz“ organizaci, ta aby se z ní v relativně krátké době dokázala „otřepat“ a pokračovat dále ve své činnosti.

Dnešní svět je z tohoto úhlu pohledu výrazně tvrdší, protože na nějaké „otřepání se“ už nedává v podstatě žádný čas - buď fungujete, nebo ne. Pokud nefungujete, zpravidla jsou k dispozici jiné alternativy, které pracují bez omezení. Zákazník či klient nepočká. Takže dnešní úkol není „zajistit fungování organizace po katastrofě“, ale i při katastrofě. Dnešní požadavky na zajištění kontinuity jsou jasné: nejen nedopustit, aby ke katastrofě vůbec došlo, a pokud k ní už dojde, nedopustit, aby byla navenek patrná na provozu organizace.

Každý technik vám prozradí klasickou radu: je nutné dbát na redundanci, pestrost systémů (nespoléhat na jediné řešení), počítat s prvky bezpečnosti vestavěnými do hardwaru, softwaru, systémů i komunikačních sítí. A má pochopitelně pravdu. Ale redukovat zachování kontinuity pouze na technickou stránku věci by bylo chybou.


Proč technika nestačí?

Tím jsme se vlastně dostali k tomu, proč provádět „analýzu dopadů na činnost“ (BIA, Business Impact Assessement) a proč celá oblast „plánování kontinuity činnosti“ (BCP, Business Continuity Planning) vyžaduje více než technický přístup. Tedy i organizační stránku věci.

Důvod je prostý: čistě technický přístup nezaručuje, že postupy budou fungovat, že budou dostupné ve správný čas a na správném místě, že jsme připraveni na všechny možné situace apod. Tady musí nastoupit právě organizační stránka věci a BCP.

Ostatně, technická či jiná již existující opatření nepodložená jasnými fakty jsou často výsledkem emočních nebo zvykových rozhodnutí. Např. „když toto funguje jinde, proč by to nefungovalo i u nás“, nebo „takto je to zde již dlouho a dosud jsme s tím neměli problém“. Díky tomuto pohybu ve vyjetých kolejích dochází k duplikování, k nedostatku, k nejasnostem, chybám – a následným výpadkům, kterých se chceme vyvarovat.


Hledání kritických míst

K ochraně zdrojů a systémů je zapotřebí zcela jasně definovat, které z nich jsou nejkritičtější z hlediska hlavní činnosti organizace. Jinak by se také dalo říci, že se analyzuje vliv jednotlivých činností na chod organizace.

Klíčem úspěchu je v každém případě pomoc managementu, který musí kromě své podpory jasně definovat jednu hodnotu. A tou je „maximální přípustná doba výpadku“ (MTD, Maximum Tolerable Downtime). Je třeba ale upozornit, že hodnotu MTD je zapotřebí stanovit pro každý kritický proces zvlášť.

Někdy je též označována jako cílový čas obnovy [plného provozu] (RTO, Recovery Time Objective), což ale není úplně přesné. Hodnota je často dána i normami nebo legislativou. Pro úplnost: existuje ještě hodnota „cílový bod obnovy [plného provozu]“ (RPO, Recovery Point Objective), která stanovuje minimální požadavky na provoz a podobu systému, jakých musí být dosaženo po výpadku.

Proč je hodnota MTD tak důležitá?

  • Umožňuje identifikovat a prioritizovat jednotlivé kritické procesy.

  • Stanovuje závazné hodnoty (hodnota „co nejdříve“ je hodně vágní), kterých musí být dosaženo u procesů a podpůrných zdrojů.

  • Poutá důležitou pozornost směrem k otázkám zachování kontinuity činnosti.

  • Poskytuje empirická data, na kterých lze stavět funkční a platné strategie.


bitcoin školení listopad 24

Dokončení článku

Tento text vyšel v tištěném SecurityWorldu 1/2009.