Co to je kvalitní ICT?
Mám důvodné podezření (podpořené stovkou konzultací u zákazníků na toto téma), že když se optám 10 lidí, co si představují pod pojmem „kvalitní IT“, dostanu 20 různých odpovědí … Pojmy kvality každý v branži používá, bohužel stále dochází k záměnám v kontextu či významu a častým nedorozuměním – proto se v tomto článku pokusím býti průvodcem po světě norem, doporučení a pojmů v oblasti spolehlivosti, provozuschopnosti, kontinuity provozu a kvality služeb v IT.
Spolehlivost a platnost Začněme tím (z pohledu ICT infrastruktury) jednodušším, co vesměs spadá do oblasti aplikací: Platnost (Validity) – udává, jak je správný konkrétní stav/výsledek. Např. jak správná je naměřená teplota, jak správný je výsledek nějaké operace. Tedy, že transakce je správně zaúčtovaná, dokument správně uložen na portále, e-mail korektně doručen. Chyba v této oblasti se zpravidla týká aplikace - řeší se v rámci její implementace a definice její funkčnosti. Spolehlivost (Reliability) – v čistě technickém pohledu je spojena s parametry jako je střední doba mezi poruchami (MTBF) a četnost závady (Failure Rate), ve vědeckém světě je jeho synonymem „opakovatelnost“ - tj. stav, kdy stejným postupem dospějeme ke stejnému výsledku. V prostředí ICT se pak pojmem spolehlivosti myslí konstantní kvalitativní stav určitého prvku/systému. Problémy s opakovatelností patří ke složitým úlohám k řešení zvláště, když se jedná o náhodné odchylky, u kterých nelze vysledovat souvislost s místem, časem, osobou, zařízením … Nicméně – u obou těchto pojmů je poměrně jasné rozlišení mezi stavem správným a závadným, které je potřeba opravit. O poznání složitější je to s dalším pojmem, kterým je =>
Dostupnost Čistě encyklopedicky udává dostupnost (Availability) dobu chodu vůči celkovému času provozu v %. Můžeme ji samozřejmě zjistit reaktivně (statisticky ze sledování provozu) a může v této podobě být i součástí servisních kontraktů, nás ale bude zajímat opačná otázka: „Jakou dostupnost má či bude mít moje ICT?“ Z toho pak lze totiž predikovat, jakou dobu výpadku lze v daném řešení očekávat, jaké ev. ztráty v primární činnosti to může způsobit a tedy – zda se vyplatí investovat do dalšího zlepšování ICT či to není efektivní a raději se smíříme se ztrátami, ev. se na ně pojistíme. Zde je klíčové rozlišit, zda se budeme bavit o dostupnosti v normální provozní situaci (kde se samozřejmě něco může porouchat) anebo o katastrofickém selhání, kde se jedná o zcela mimořádnou situaci, jejíž dopad se zdaleka neomezuje jen na ICT. Tedy zda jde o otázku
Provozuschopnosti (Uptime) anebo
Kontinuity činnosti (Business Continuity) resp. zotavení se z katastrofy (Disaster Recovery).
Sekundárně pak, zda je cílem oficiální certifikace řešení anebo „jen“ dosažení potřebného stavu – podle toho se zvolí formální přístup.
Provozuschopnost je základní úlohou při zajištění chodu ICT – po většinu času jde přece o to, aby vše blikalo, komunikovalo a „žilo“. Nejčastější interpretace staví na normě ISO/IEC 2700x Information Security Management System (zkráceně ISMS), která chápe cíle provozuschopnosti jako trojimperativ
Dostupnosti – aby byly systémy maximálně dostupné zejména v normálním provozním stavu;
Důvěrnosti – aby byla zajištěna ochrana informací před oprávněnými i neoprávněnými subjekty;
Integrity – aby byla zajištěna platnost a spolehlivost (viz výše).
ISO27k je (přes svou obsáhlost) velmi prakticky zaměřená norma (protože původně britská), která dává stovky návodů a inspirací, jak ošetřit to či ono; klade správné otázky a dává náměty, jak by ten který problém šel řešit. Tématem spolehlivosti a výsledné dostupnosti ICT infrastruktury (tedy ne aplikací!!) se zabývá další sada doporučení Uptime Institute, která definuje dva hlavní vlivy:
technicko-systémové řešení dané designem, umístěním, použitými prvky HW a SW, kvalitou instalace/implementace;
provozní zajištění tj. procesy a kvalitu lidských zdrojů;
opět ve vzájemné relaci. Naplněním těchto doporučení tak můžete získat ICT řešení s konkrétní věrohodnou dostupností v provozním stavu bez toho, abyste čekali, jak se osvědčí a sbírali vlastní data. Uptime Institute tedy zavádí hodnocení ICT jako celku ve 4 úrovních Tier I/II/III/IV a k nim předpokládanou spolehlivost (alias typický roční výpadek) a dává doporučení Jak by mělo být řešení technicky realizováno (Topology) a Jaké by mělo být provozní zajištění (Sustainability). Takže např. pro Tier III nestačí mít napájení zajištěné motorgenerátorem, ale musí být i sjednáno servisní zajištění (SLA) po celou dobu provozu.
Jak můžete vidět, minimální úroveň provozní dostupnosti pro Tier I je 99,67% a tedy cokoliv horšího může být max. pro domácí použití. Proto jsou tak „zábavné“ garance dostupnosti řady poskytovatelů cloudových, hostingových či datacom služeb, garantující „úžasnou“ kvalitu 99,5% … V laickém překladu Vám tedy sdělují, že si na nich nic nevezmete, ani když to týden v roce nepůjde. V elementární podobě lze provozuschopnost (a odpovídající řešení ICT) popsat známými:
RTO (Recovery Time Objective) - doba, za kterou dojde k obnovení provozu po závadě.
RPO (Recovery Point Objective) - interval, za který dojde ke ztrátě dat v případě závady (tato data je tedy nutné znova pořídit).
I zde ale dochází k chybné interpretaci a zasmluvnění hodnoty RTO jako času, za který dojde k obnově chodu dílčího subsystému (např. serveru ev. i s OS), ale nepočítá se s potřebou obnovy dat do plného obnovení chodu z pohledu uživatele. A o tom, že to může trvat neočekávaně dlouho jsem psal již dříve. Mělo by tedy být zcela jasné a vědomé upřesnit, co RTO zahrnuje, ev. jaká je ta opravdová hodnota … a pro jistotu to otestovat.
Jak už to tak bývá, ze sady doporučení se odvozují normy – v případě doporučení Uptime Institute z toho vznikla norma EIA/TIA-942, která se ale omezuje pouze na parametry výstavby datových center, a to ještě s ohledem na podmínky USA – ne vše je relevantní v ČR. Úrovně čísluje arabsky, tj. Tier 1/2/3/4 a také neřeší SLA parametry podpory - takže důležitější pro ICT jako celek jsou doporučení Uptime Institute!
Kontinuita a zotavení z katastrofy Navážeme na rozdělení výše a budeme se věnovat mimořádnému a mimoprovoznímu stavu = katastrofickému selhání, které má dopad na celou činnost společnosti, zdaleka ne jen na IT!!! Bohužel, opakovaně se na mě obracejí ITýci s dotazem jak uchopit zadání vedení společnosti, aby zpracovali „havarijní plán pro IT“ … a vesměs se ukáže, že je toto zadání vytrženo z kontextu BCM (Business Continuity Management) - jak se tato problematika oficiálně jmenuje. Předně – definice katastrofického selhání zahrnuje primárně ohrožení zdraví a života lidí (zamoření, epidemie), zásadní narušení provozu firmy (záplava, požár, celkový výpadek energií či dopravní dostupnosti), to vše v četnosti velmi výjimečné. A je zcela jasné, že v takovém případě to dostupnost IT nevytrhne – co je platné, že půjdou počítače v datovém centru, když zbytek výroby bude pod vodou a zaměstnanci na útěku? Proto je třeba držet se schématu níže a Havarijní plán IT řešit výhradně v kontextu BCM celé společnosti =>
Pokud už vedení trvá na zpracování určitých postupů pro řešení katastrofického selhání pouze pro oblast IT, mohu doporučit:
nepoužívat pojem „Havarijní plán“, implikující terminologii BCM celé organizace dle norem ISO/IEC 27031, 22313 a 22301, ale
zpracovat „Krizové scénáře“ ve smyslu ISMS normy ISO/IEC 27002:2013 kapitola 17. Tento postup se uplatňuje velmi často v podobě tzv. Disaster Recovery scénářů alias Řízení obnovy po havárii. Je to přesně ta část, ve které se „IT norma“ ISO/IEC27001 překrývá se BCM normou ISO/IEC 27031.
Prakticky to znamená, že podle ISO27001:
1) Dle článku 17.1.1. si můžete stanovit požadavky na dostupnost (RTO, RPO) a kontinuitu IT – zde se běžně používá pojem DRT = Disaster Recovery Time jako interval, kdy by výpadek IT způsobil závažné následky na chodu organizace. Zpravidla se jedná o několikanásobek „běžného výpadku“ RTO.
Všimněte si ve třetím odstavci kapitoly 17.1.1. normy, že se zde „zkušeně předpokládá“ absence plánování kontinuity činnosti organizace jako celku, tj. neexistence BCM na úrovni organizace!! A doporučuje se odvodit vstupní informace v relaci na hodnoty normálních provozních stavů – to je přesně to, co doporučujeme, když zmiňujeme relaci RTO=>DRT. Alternativně lze pak vyspecifikovat analýzu dopadů výpadku IT pro chod organizace.
2) Tím získáte „politické“ zadání pro zpracování DR scénářů bez toho, abyste se museli odkazovat na neexistující BCM :-) Pro autorizaci těchto parametrů doporučuji toto velmi stručné deklarativní prohlášení (premisu v matematickém slova smyslu) dát na vědomí či schválení vedení společnosti – tím získáte pevný bod, ze kterého pak lze dále odvozovat opatření ve smyslu kapitoly 17.1.2.
3) Poté se postupuje dále > a) stanoví se struktura řízení IT pro krizové situace – výčet pracovníků s nezbytnou kvalifikací, kontaktů, kompetencí ...
b) jmenovitě jsou uvedeni vedoucí pracovníci, mající kompetenci k rozhodnutí, které má závažný dopad – typicky, při řešení situace dojde ke ztrátě dat a je potřeba je znova pořídit – to musí někdo schválit! Podobně když v rámci krizového scénáře dojde k podstatnému narušení provozu, např. omezení přístupu jen pro část klíčových pracovníků.
c) Plány odezvy a obnovy (DR plány), tj. jak se budou řešit jednotlivé události, jak se budou pracovníci včetně uživatelů chovat, ev. Kompenzační plány (ev. samostatná kapitola DR plánů) pro případ, kdy nebude možné provoz zajistit.
4) Dle kapitoly 17.1.3. se navrhnou procesy přezkoumání a testování, aby se pravidelně ověřovalo, že jsou přijaté postupy funkční. O tom je samozřejmě nutné provádět záznamy. Typickým příkladem může být testování výpadku datového centra s fail-overem na záložní DC, testování obnovy dat (čitelnost, doba obnovy), chování při antivirovém zamoření (aktuálně zejména ransonware.
A konečně...
5) dle kapitoly 17.1.4. se pravidelně (při zpracování investičního plánu) reviduje, zda jsou jednotlivé subsystémy dostatečně redundantní a případně se navrhuje změna architektury nebo doplnění redundantním komponent. Což se i prakticky děje.
Celá oblast je samozřejmě podstatně širší a může být předmětem mé konzultační práce.
