Mennyi ideig működne a cége informatika nélkül? – Így készülhet fel egy teljes IT-leállásra

Tegyen fel egy egyszerű kérdést:

Ha holnap reggel 8 órakor teljesen leállna a vállalkozás informatikai rendszere, meddig tudnának tovább dolgozni a munkatársak?

Egy óráig?

Négy óráig?

Egy teljes munkanapig?

Vagy gyakorlatilag azonnal megállna a munka?

Nem működik a szerver.

Nem érhetők el a közös dokumentumok.

Nem indul az ügyviteli vagy könyvelési rendszer.

Nincs internet.

Nem működik a VPN.

Nem érhető el a céges levelezés.

A munkatársak nem tudnak bejelentkezni.

A számlázás, ügyfélkiszolgálás vagy más kritikus üzleti folyamat pedig részben vagy teljesen leáll.

Ilyenkor derül ki igazán, hogy az informatika már nem egyszerűen egy háttérszolgáltatás.

A legtöbb modern vállalkozás működésének egyik alapvető függősége.

Nem az a kérdés, hogy történhet-e informatikai leállás

Minden informatikai rendszer meghibásodhat.

Leállhat:

egy fizikai szerver;
egy virtuális gép;
egy NAS;
egy switch;
egy router;
az internetkapcsolat;
egy adatbázis;
egy üzleti alkalmazás;
egy felhőszolgáltatás;
a Microsoft 365 valamely szolgáltatása;
vagy akár egy teljes telephely informatikai infrastruktúrája.

A háttérben állhat:

hardverhiba;
szoftverhiba;
hibás frissítés;
emberi hiba;
hálózati probléma;
áramszünet;
szolgáltatói kiesés;
konfigurációs hiba;
kibertámadás;
adatvesztés;
vagy több probléma együttes hatása.

A rendszerleállások technikai okait részletesen bemutatjuk a Miért áll le váratlanul egy cég informatikai rendszere? A leggyakoribb okok és hogyan előzhetők meg című cikkünkben.

Ebben az útmutatóban azonban egy másik kérdésre koncentrálunk:

Mi történik a vállalkozással akkor, ha a hibát nem sikerült megelőzni, és a kritikus informatikai rendszer valóban leáll?

Egy informatikai leállás valójában üzleti leállás lehet

Egy szerver meghibásodása technikai esemény.

Az viszont már üzleti probléma, ha emiatt húsz munkatárs négy órán keresztül nem tud dolgozni.

Ugyanez igaz arra, ha:

nem lehet számlát kiállítani;
nem érhetők el az ügyféladatok;
nem működik a könyvelési rendszer;
nem lehet megrendelést feldolgozni;
nem érhető el a vállalati ERP vagy CRM;
nem működik a telephelyek közötti kapcsolat;
megszűnik a távoli munkavégzés;
nem lehet hozzáférni a közös dokumentumokhoz;
vagy az ügyfelek nem tudják igénybe venni a vállalkozás online szolgáltatását.

Ezért egy IT-leállás súlyosságát nem kizárólag technikai szempontból kell meghatározni.

A valódi kérdés:

Milyen üzleti folyamat áll le, hány embert érint, mennyi ideig tarthat a kiesés, és mekkora veszteséget okozhat?

A legfontosabb kérdés: mennyi kiesést engedhet meg magának a vállalkozás?

Nincs minden vállalkozás számára egyformán megfelelő válasz.

Egy kisebb irodában elképzelhető, hogy egy kétórás fájlszerver-kiesés kellemetlen, de kezelhető.

Egy másik vállalkozásnál ugyanennyi idő alatt:

több tucat munkatárs munkája állhat le;
megrendelések maradhatnak feldolgozatlanul;
ügyfelek várhatnak;
határidők csúszhatnak;
bevétel eshet ki.

Ezért nem az alapján kell meghatározni egy rendszer fontosságát, hogy:

„Ez egy szerver.”

Hanem az alapján, hogy:

„Mi történik a vállalkozással, ha ez a szerver nem működik?”

Nem minden informatikai rendszer egyformán kritikus

Ez az üzletmenet-folytonossági tervezés egyik legfontosabb alapelve.

Egy vállalkozás informatikai környezetében lehet például:

Active Directory;
fájlszerver;
adatbázis-szerver;
könyvelési rendszer;
ERP;
CRM;
Microsoft 365;
VPN;
NAS;
weboldal;
belső alkalmazás;
nyomtatási szolgáltatás;
telefonközpont;
monitoring rendszer.

Ezek közül azonban nem feltétlenül kell mindegyiket ugyanabban a pillanatban helyreállítani.

Egy megfelelő helyreállítási terv ezért prioritásokat határoz meg.

Például:

1. prioritás – kritikus

A vállalkozás működése nélkülük gyakorlatilag leáll.

2. prioritás – fontos

Néhány órás kiesés még kezelhető, hosszabb leállás azonban már komoly problémát okoz.

3. prioritás – támogató

Ideiglenesen nélkülözhetők, és csak a kritikus szolgáltatások után szükséges a helyreállításuk.

Ez azért fontos, mert egy teljes rendszerleállás esetén ritkán az a leghatékonyabb stratégia, hogy:

„Indítsunk vissza mindent egyszerre.”

Először azt kell helyreállítani, ami nélkül a vállalkozás nem tud működni.

Mit jelent az üzletmenet-folytonosság?

Az üzletmenet-folytonosság – Business Continuity – célja, hogy a vállalkozás egy komolyabb meghibásodás vagy incidens során is képes legyen a kritikus működését fenntartani, illetve elfogadható időn belül helyreállítani.

Ez jóval több egyszerű biztonsági mentésnél.

Egy megfelelő tervnek választ kell adnia például arra, hogy:

mely üzleti folyamatok kritikusak;
mely informatikai rendszerektől függenek;
mennyi ideig tolerálható a kiesésük;
mennyi adatvesztés fogadható el;
milyen sorrendben történik a helyreállítás;
honnan állíthatók vissza az adatok;
ki végzi a helyreállítást;
milyen tartalék infrastruktúra áll rendelkezésre;
hogyan kommunikál a vállalkozás a munkatársakkal és ügyfelekkel;
mi történik akkor, ha az elsődleges telephely vagy infrastruktúra sem használható.

A cél nem feltétlenül az, hogy soha semmi ne álljon le.

Ez sok esetben irreális vagy aránytalanul költséges elvárás lenne.

A cél inkább az, hogy a vállalkozás előre tudja:

mit kell tenni, milyen sorrendben, kinek, és mennyi idő alatt.

RTO és RPO – két szám, amit minden vállalkozásnak érdemes ismernie

Kép leírása

Az üzletmenet-folytonosság és a katasztrófa utáni helyreállítás tervezésének két alapvető fogalma az RTO és az RPO.

RTO – Recovery Time Objective

Az RTO azt határozza meg, hogy egy szolgáltatás kiesése után legfeljebb mennyi időn belül kell annak ismét működnie.

Például:

fájlszerver: 4 óra;
kritikus adatbázis: 1 óra;
könyvelési rendszer: 2 óra;
kevésbé fontos belső szolgáltatás: 24 óra.

Az RTO tehát alapvetően erre a kérdésre válaszol:

Mennyi ideig lehetünk az adott rendszer nélkül?

RPO – Recovery Point Objective

Az RPO azt határozza meg, hogy legfeljebb mennyi adat elvesztése fogadható el.

Ha például egy adatbázis RPO-ja 1 óra, akkor a mentési és replikációs rendszernek olyan módon kell működnie, hogy egy komolyabb hiba esetén lehetőleg legfeljebb körülbelül egyórányi adatváltozás vesszen el.

Az RPO kérdése tehát:

Mennyi adatot engedhetünk meg magunknak elveszíteni?

A két érték együtt alapvetően meghatározza, milyen infrastruktúrára, mentési rendszerre, redundanciára és helyreállítási folyamatra van szükség.

A „van mentésünk” még nem helyreállítási terv

Ez az egyik legfontosabb különbség.

Egy vállalkozás mondhatja azt, hogy:

„Minden éjjel készül biztonsági mentés.”

Ez önmagában még nem mondja meg:

sikeres volt-e az utolsó mentés;
sértetlen-e;
hozzáférhető-e;
mennyi adatot tartalmaz;
mennyi idő alatt tölthető vissza;
van-e hová visszaállítani;
rendelkezésre állnak-e a szükséges jelszavak és konfigurációk;
valaki végzett-e valaha teljes próba-visszaállítást.

Ha egy 2 TB-os szerverről van mentés, de annak teljes helyreállítása két napot vesz igénybe, miközben a vállalkozás legfeljebb négyórás kiesést engedhet meg magának, akkor:

van biztonsági mentés – de nincs az üzleti igénynek megfelelő helyreállítási képesség.

A biztonsági mentés tehát csak az egyik építőeleme az üzletmenet-folytonosságnak.

A megfelelő IT-üzemeltetésben a mentéseket nemcsak elkészíteni, hanem ellenőrizni és visszaállíthatóság szempontjából is tesztelni kell. Erről részletesebben a Mi az IT üzemeltetés, és miért létfontosságú minden vállalkozás számára? című útmutatónkban írunk.

A következő kérdés nem az, hogy „van-e backup?”

Hanem ez:

Ha most minden leállna, mikor tudnánk újra dolgozni?

Ez a kérdés választja el egymástól a puszta adatmentést és a valódi helyreállítási stratégiát.

A következőkben ezért megvizsgáljuk:

hogyan azonosíthatók a vállalkozás kritikus informatikai rendszerei;
hogyan számítható ki egy IT-leállás valódi költsége;
hogyan kell meghatározni az RTO és RPO értékeket;
mik azok a Single Point of Failure pontok;
milyen szerepe van a redundanciának;
hogyan épüljön fel a biztonsági mentés;
miért fontos az offsite mentés;
hogyan segít a monitoring a kiesés megelőzésében;
hogyan készül egy használható Disaster Recovery terv;
és hogyan lehet tesztelni, hogy a vállalkozás valóban képes-e helyreállni egy teljes IT-leállás után.

Hogyan azonosíthatók a vállalkozás valóban kritikus informatikai rendszerei?

Egy üzletmenet-folytonossági terv elkészítésének első lépése nem a mentési szoftver kiválasztása, és nem is egy új szerver beszerzése.

Először azt kell meghatározni:

Mely informatikai szolgáltatások kiesése akadályozná ténylegesen a vállalkozás működését?

Ez elsőre egyszerű kérdésnek tűnhet, a gyakorlatban azonban könnyű rosszul meghatározni a prioritásokat.

Egy szerver például önmagában nem üzleti folyamat.

A rajta működő:

adatbázis;
könyvelési rendszer;
fájlmegosztás;
ügyviteli alkalmazás;
hitelesítési szolgáltatás;
vagy más vállalati rendszer

viszont már közvetlenül kapcsolódhat a napi működéshez.

Ezért nem kizárólag az eszközöket kell felmérni, hanem az üzleti folyamatok és az informatikai infrastruktúra közötti függőségeket is.

Induljunk az üzleti folyamatokból, ne a szerverekből

Tegyük fel, hogy egy vállalkozás számára kritikus a számlázás.

Első pillantásra úgy tűnhet, hogy ehhez mindössze a számlázóprogramnak kell működnie.

A valóságban azonban szükség lehet:

Internetkapcsolatra → hálózatra → DNS-re → felhasználói hitelesítésre → adatbázisra → alkalmazásszerverre → kliensgépre → esetleg e-mail-szolgáltatásra.

Ha a lánc bármely kritikus eleme kiesik, az üzleti folyamat ugyanúgy megállhat.

Ugyanez igaz például egy fájlszerverre is.

Hiába működik maga a szerver, ha:

a switch meghibásodott;
nem működik a hitelesítés;
hálózati hiba van;
a VPN-en keresztül dolgozó munkatársak nem érik el;
vagy az adattároló hibája miatt nem érhetők el a szükséges fájlok.

Ezért az infrastruktúrát szolgáltatási láncként érdemes vizsgálni.

Egy jól felépített IT-üzemeltetésnek pontosan ezeket a függőségeket kell ismernie és dokumentálnia. Az üzemeltetés ennél jóval többet jelent, mint a hibák alkalmi javítása; erről részletesen a Mi az IT üzemeltetés, és miért létfontosságú minden vállalkozás számára? című cikkünkben írunk.

Készítsünk prioritási sorrendet

Miután ismertté váltak az üzleti folyamatok informatikai függőségei, minden rendszernél érdemes meghatározni, milyen következménnyel járna a kiesése.

Például:

Rendszer	Kiesés hatása	Maximálisan tolerálható kiesés	Prioritás
Hitelesítési infrastruktúra	A felhasználók egy része vagy egésze nem tud megfelelően hozzáférni a szolgáltatásokhoz	1 óra	Kritikus
ERP / ügyviteli rendszer	Az alapvető üzleti folyamatok leállnak	1–2 óra	Kritikus
Fájlszerver	Dokumentumok és közös állományok nem érhetők el	2–4 óra	Magas
VPN	Távoli munkavégzés vagy telephelyi kapcsolat megszűnhet	2–4 óra	Magas
Belső nyomtatás	Egyes munkafolyamatok lassulnak	8 óra	Közepes
Archiváló rendszer	Azonnali működésre kisebb hatással lehet	24 óra	Alacsonyabb

A konkrét értékek természetesen vállalkozásonként eltérnek.

Egy könyvelőiroda, egy szálloda, egy ügyvédi iroda, egy gyártóvállalat és egy webáruház teljesen eltérő informatikai függőségekkel rendelkezhet.

A lényeg nem egy általános sablon lemásolása.

A cél annak meghatározása, hogy:

az adott vállalkozás számára mely rendszer kiesése mikor válik üzletileg elfogadhatatlanná.

Mennyi pénzbe kerül valójában egy informatikai leállás?

Az IT-leállás költsége gyakran jóval nagyobb, mint maga a meghibásodott eszköz.

Tegyük fel, hogy egy 25 fős vállalkozásnál egy kritikus rendszer négy órára leáll.

Ha ebből 15 munkatárs nem tud megfelelően dolgozni, akkor már önmagában:

15 munkatárs × 4 kiesett munkaóra = 60 munkaóra

veszteségről beszélünk.

Ehhez azonban még hozzáadódhat:

az elmaradt árbevétel;
a kieső ügyfélkiszolgálás;
a határidők csúszása;
a helyreállítást végző szakemberek költsége;
az esetleges túlóra;
az adatvesztés;
a szerződéses kötelezettségek megszegésének következménye;
az ügyfelek elégedetlensége;
és súlyosabb esetben a vállalkozás reputációs vesztesége.

Ezért egy infrastruktúra üzembiztonságának költségét nem kizárólag ahhoz kell viszonyítani, hogy mennyibe kerül például egy tartalék szerver, UPS, másodlagos internetkapcsolat vagy megfelelő mentési rendszer.

A másik oldalon azt is meg kell vizsgálni:

Mennyibe kerülne, ha ezek hiánya miatt a vállalkozás órákig vagy akár napokig nem tudna megfelelően működni?

A leállási költség egyszerűen is megbecsülhető

Nem szükséges rögtön bonyolult pénzügyi modellt készíteni.

Első közelítésként érdemes meghatározni:

Leállás költsége ≈ kieső munkaerőköltség + kieső fedezet/árbevétel + helyreállítás költsége + egyéb közvetlen veszteségek

Ez már elegendő lehet ahhoz, hogy más szemszögből lássuk például egy redundáns infrastruktúra vagy egy professzionális mentési rendszer költségét.

Ha egy négyórás leállás több százezer forintos veszteséget okozhat, akkor egy olyan beruházás, amely ezt a kiesést jelentősen csökkenti, már nem egyszerűen „informatikai költség”.

Üzleti kockázatot csökkentő beruházás.

Az RTO-t nem az informatikusnak kell egyedül eldöntenie

Gyakori hiba, hogy a helyreállítási célokat kizárólag technikai szempontból határozzák meg.

Például:

„Ezt a szervert körülbelül hat óra alatt tudjuk visszaállítani.”

Ez technikai információ.

Az üzleti kérdés azonban ez:

A vállalkozás kibír hat órát a rendszer nélkül?

Ha a válasz nem, akkor a jelenlegi helyreállítási megoldás nem felel meg az üzleti követelménynek.

Az RTO meghatározása ezért üzleti és informatikai döntés egyszerre.

Az üzleti oldal meghatározza, hogy:

mennyi kiesés fogadható el.

Az informatikai oldal pedig megtervezi, hogy:

milyen technikai megoldással teljesíthető ez az elvárás.

Ugyanez igaz az RPO-ra is

Tegyük fel, hogy egy rendszer minden éjjel 23:00-kor készít biztonsági mentést.

Másnap 16:00-kor meghibásodik.

Ha kizárólag az előző esti mentés áll rendelkezésre, akár 17 órányi adatváltozás is elveszhet.

Technikai értelemben tehát van mentés.

Üzleti szempontból viszont fel kell tenni a kérdést:

Elfogadható 17 órányi munka elvesztése?

Ha nem, akkor a mentési gyakoriság nem felel meg az elvárt RPO-nak.

Ezért nincs olyan univerzális szabály, hogy:

„A napi egy mentés elegendő.”

Egy ritkán változó fájltárnál lehet megfelelő.

Egy folyamatosan változó üzleti adatbázisnál viszont akár teljesen elfogadhatatlan is lehet.

A mentési stratégia kialakításánál ezért a mentések gyakorisága mellett a példányszám, az elkülönített tárolás és a visszaállíthatóság is lényeges. Ennek egyik bevált alapelve a Mi az a 3-2-1 mentési stratégia, és miért életmentő vállalkozások számára? című cikkünkben részletesen bemutatott 3-2-1 megközelítés.

Mi történik, ha maga a mentési cél is meghibásodik?

Ez különösen fontos kérdés.

Egy NAS például kiváló eszköz lehet:

központi adattárolásra;
fájlmegosztásra;
mentési célként;
verziózott mentések tárolására;
bizonyos esetekben másodlagos adatpéldány fenntartására.

De attól, hogy egy adat NAS-on található, még nem feltétlenül rendelkezünk megfelelő biztonsági mentéssel.

Ha az eredeti adat és annak egyetlen másolata ugyanazon a telephelyen található, egy:

tűzeset;
beázás;
lopás;
túlfeszültség;
súlyos hardverhiba;
vagy megfelelő hozzáférés esetén egy kibertámadás

egyszerre több adatpéldányt is veszélyeztethet.

A NAS vállalati infrastruktúrában betöltött szerepéről részletesebben a NAS: okos adattárolási megoldás vállalkozásoknak című cikkünkben írunk.

A következő lépés ezért az, hogy megkeressük az infrastruktúrában azokat a pontokat, amelyek kiesése önmagában képes leállítani egy teljes szolgáltatást.

Ezek az úgynevezett Single Point of Failure, vagyis SPOF pontok.

Single Point of Failure – az egyetlen hiba, amely mindent leállíthat

Kép leírása

Egy vállalkozás informatikai infrastruktúrája első ránézésre akár kifejezetten összetett és megbízható rendszernek is tűnhet.

Lehet több szerver.

Lehet virtualizáció.

Lehet RAID.

Lehet NAS.

Lehet UPS.

Lehet professzionális hálózati infrastruktúra.

Ettől azonban még létezhet benne egyetlen olyan komponens, amelynek meghibásodása az egész szolgáltatási láncot megszakítja.

Ezt nevezzük Single Point of Failurenek (SPOF).

Vagyis:

olyan egyedi hibapontnak, amelynek nincs megfelelő tartaléka vagy alternatív útvonala, ezért a meghibásodása önmagában szolgáltatáskiesést okozhat.

Az üzletmenet-folytonosság tervezésének egyik legfontosabb feladata ezeknek a pontoknak a feltárása.

Hol lehet Single Point of Failure egy vállalati infrastruktúrában?

Gyakorlatilag bárhol.

Tipikus példa lehet:

egyetlen internetkapcsolat;
egyetlen router;
egyetlen központi switch;
egyetlen fizikai szerver;
egyetlen virtualizációs host;
egyetlen adattároló;
egyetlen NAS;
egyetlen tápegység;
egyetlen UPS;
egyetlen Active Directory tartományvezérlő;
egyetlen DNS-szolgáltatás;
vagy akár egyetlen olyan munkatárs, aki ismeri a rendszer működését és rendelkezik a szükséges hozzáférésekkel.

Az utolsó pont különösen fontos.

A Single Point of Failure nem feltétlenül hardver.

Lehet ember, dokumentáció, jelszó, konfiguráció vagy külső szolgáltatás is.

Ha például egy kritikus rendszer adminisztrátori hozzáférését kizárólag egy ember ismeri, és az illető nem elérhető, akkor hiába működik tökéletesen az infrastruktúra.

Egy incidens során maga a hozzáférés hiánya válhat kritikus hibaponttá.

Egyetlen fizikai szerver több rendszer kiesését is okozhatja

A virtualizáció jelentősen hatékonyabbá teheti a vállalati infrastruktúrát.

Egyetlen fizikai gépen több virtuális szerver működhet, például:

Active Directory;
fájlszerver;
adatbázis;
alkalmazásszerver;
monitoring;
belső webes szolgáltatás.

Ez erőforrás- és költségoldalon jelentős előnyt jelenthet.

Van azonban egy fontos következménye.

Ha minden kritikus virtuális gép egyetlen fizikai hoston fut, annak meghibásodásakor nem egy szolgáltatás áll le.

Akár az összes.

A virtualizáció tehát önmagában nem jelent magas rendelkezésre állást.

Egy Proxmox VE vagy VMware környezetben is külön kell megtervezni:

a hostok redundanciáját;
az adattárolást;
a hálózatot;
a mentést;
a replikációt;
és szükség esetén a virtuális gépek másik hoston történő indításának lehetőségét.

A RAID sem jelent teljes védelmet

Gyakori tévhit, hogy ha egy szerverben vagy NAS-ban RAID működik, akkor az adatok megfelelően védettek.

A RAID valóban növelheti a rendelkezésre állást bizonyos lemeghibák esetén.

Például megfelelő RAID-konfigurációnál egy meghajtó meghibásodása nem feltétlenül okoz azonnali szolgáltatásleállást.

De a RAID nem véd minden ellen.

Nem oldja meg automatikusan:

a vezérlő meghibásodását;
a fájlrendszer sérülését;
a véletlen törlést;
a hibás alkalmazás által okozott adatkárosodást;
a zsarolóvírust;
a teljes szerver meghibásodását;
a lopást;
a tűzesetet;
vagy más telephelyi katasztrófát.

Ezért fontos különválasztani három fogalmat:

redundancia ≠ biztonsági mentés ≠ katasztrófa utáni helyreállítás.

Mindhárom más problémát kezel.

Redundancia: amikor egy komponens kiesése nem feltétlenül jelent leállást

A redundancia lényege, hogy egy kritikus komponens meghibásodása esetén rendelkezésre álljon egy másik komponens vagy útvonal, amely átveheti annak szerepét.

Ez lehet például:

Internet

Elsődleges vezetékes internetkapcsolat mellett másodlagos szolgáltatói kapcsolat vagy mobilinternet.

Tápellátás

Redundáns tápegységek, megfelelő UPS, illetve nagyobb rendelkezésre állási követelménynél alternatív energiaellátás.

Adattárolás

RAID, redundáns storage-rendszer vagy replikált adattárolás.

Virtualizáció

Több fizikai host, amelyek között a virtuális gépek áthelyezhetők vagy megfelelő architektúra esetén automatikusan újraindíthatók.

Hálózat

Redundáns switchek, uplinkek és hálózati útvonalak.

Hitelesítés

Több tartományvezérlő vagy más redundáns identitásszolgáltatás.

A megfelelő redundancia jelentősen csökkentheti egyetlen komponens meghibásodásának üzleti hatását.

De van egy fontos korlát.

Nem kell mindent megduplázni

A magas rendelkezésre állásnak ára van.

Két szerver drágább, mint egy.

Két internetkapcsolat drágább, mint egy.

Több switch, több adattároló, cluster, replikáció és tartalék infrastruktúra pedig nemcsak beszerzési költséget jelent.

Növeli:

az infrastruktúra komplexitását;
az üzemeltetési igényt;
a konfigurációk számát;
a monitoring szükségességét;
és bizonyos esetekben maga a hibalehetőségek száma is növekedhet.

Ezért a helyes kérdés nem az, hogy:

„Hogyan lehet mindent redundánssá tenni?”

Hanem:

„Mely rendszerek kiesése okozna akkora üzleti kárt, hogy indokolt legyen a redundancia költsége?”

Itt kapcsolódik össze az infrastruktúra tervezése a korábban meghatározott RTO-val.

Ha egy szolgáltatásnak néhány percen belül ismét működnie kell, akkor valószínűleg nem elegendő arra számítani, hogy meghibásodás esetén majd visszaállítjuk egy biztonsági mentésből.

Ha azonban egy kevésbé kritikus rendszer 8–24 órás RTO-val rendelkezik, előfordulhat, hogy gazdaságilag indokolatlan teljesen redundáns infrastruktúrát fenntartani számára.

A technikai megoldásnak az üzleti követelményt kell követnie.

Mi történik, ha az internetkapcsolat áll le?

Az internetkapcsolat ma már sok vállalkozás egyik legkritikusabb infrastruktúra-eleme.

Internet nélkül kieshet:

a Microsoft 365;
a felhőalapú ERP vagy CRM;
a VoIP-telefon;
a távoli elérés;
a VPN;
a felhős fájltárolás;
a webes ügyviteli rendszer;
számos banki és hatósági szolgáltatás;
valamint a külső partnerekkel történő kommunikáció.

Ilyenkor teljesen mindegy, hogy a helyi szerverek működnek-e.

A felhasználó szempontjából:

„nem működik az informatika.”

Egy kritikus internetkapcsolatnál ezért érdemes megvizsgálni, szükséges-e másodlagos kapcsolat.

De itt sem elegendő egyszerűen két előfizetést vásárolni.

Ha mindkét kapcsolat:

ugyanazon fizikai nyomvonalon érkezik;
ugyanazon szolgáltatói infrastruktúrától függ;
ugyanabba az eszközbe csatlakozik;
vagy ugyanazon áramellátást használja,

akkor továbbra is maradhatnak közös hibapontok.

A valódi redundanciához tehát a függőségeket is vizsgálni kell.

A router és a központi switch is lehet kritikus hibapont

Képzeljünk el egy irodát két internetkapcsolattal.

Első pillantásra már redundáns az internet.

Mindkét kapcsolat azonban ugyanabba az egyetlen routerbe érkezik.

Ha a router meghibásodik:

mindkét internetkapcsolat használhatatlanná válhat.

Ugyanez történhet egy központi switch esetében.

Lehet:

több szerver;
több NAS;
több internetkapcsolat;
több access point;

ha minden kommunikáció egyetlen központi switchen halad keresztül, annak meghibásodása jelentős vagy teljes hálózati kiesést okozhat.

Ez jól mutatja, hogy a redundanciát nem komponensenként, hanem teljes szolgáltatási útvonalakban kell vizsgálni.

És mi történik áramszünet esetén?

A szünetmentes tápegység – UPS – fontos része lehet az üzembiztos infrastruktúrának.

De az UPS sem teszi automatikusan áramszünetbiztossá a teljes rendszert.

Fel kell tenni például ezeket a kérdéseket:

Mennyi ideig képes működtetni a rendszert?
A szerver mellett a switch is UPS-ről működik?
A router is?
Az internetszolgáltató helyi végberendezése is?
A NAS is?
Figyeli valaki az akkumulátor állapotát?
Kap értesítést az üzemeltető akkumulátorhibáról?
Tudnak a szerverek szabályosan leállni hosszabb áramszünet esetén?

Ha a szerver UPS-en van, de a központi switch nincs, akkor áramszünetben a szerver ugyan tovább működhet, a felhasználók mégsem érik el.

Ez ismét azt mutatja, hogy nem egyes eszközökben, hanem teljes szolgáltatási láncokban kell gondolkodni.

A kritikus infrastruktúra állapotának folyamatos ellenőrzésében ezért fontos szerepet kaphat a monitoring. A Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben részletesen bemutatjuk, hogyan jelezhetők előre olyan problémák, amelyek később szolgáltatáskiesést okozhatnak.

A redundancia önmagában még mindig nem elég

Tegyük fel, hogy a vállalkozás rendelkezik:

redundáns szerverrel;
RAID-del;
két internetkapcsolattal;
UPS-sel;
több hálózati eszközzel.

Ez jelentősen növelheti a rendelkezésre állást.

Egy problémát azonban továbbra sem old meg:

Mi történik, ha nem egy eszköz hibásodik meg, hanem maga az adat sérül vagy eltűnik?

Például:

valaki véletlenül töröl egy teljes mappát;
hibás alkalmazás módosítja az adatbázist;
zsarolóvírus titkosítja az állományokat;
támadó törli az adatokat;
hibás szinkronizáció felülírja a megfelelő verziót.

Ha az adatok valós időben replikálódnak egy másodlagos rendszerre, bizonyos hibák a másodlagos példányra is átkerülhetnek.

Ha egy fájlt törölnek, a törlés is szinkronizálódhat.

Ha egy fájlt titkosít a zsarolóvírus, a titkosított változat is replikálódhat.

Ezért:

A redundancia a rendelkezésre állást növeli. A biztonsági mentés a korábbi állapot helyreállításának lehetőségét biztosítja.

A kettő nem helyettesíti egymást.

A biztonsági mentésnek túl kell élnie azt a hibát, amely ellen készült

Kép leírása

Ez az egyik legfontosabb alapelv.

Ha a szerver meghibásodása ellen készítünk mentést, a mentés ne kizárólag ugyanazon a szerveren legyen.

Ha a NAS meghibásodása ellen készítünk mentést, ne kizárólag ugyanazon a NAS-on legyen.

Ha egy teljes telephely elvesztésére is fel akarunk készülni, legalább egy megfelelő adatpéldánynak fizikailag más helyen kell rendelkezésre állnia.

Ha pedig zsarolóvírus ellen is védekezünk, olyan mentési megoldást is érdemes kialakítani, amelyet egy kompromittált rendszergazdai fiókkal vagy kliensgéppel nem lehet egyszerűen törölni vagy titkosítani.

Ezért válik fontossá az offsite, illetve megfelelő esetben az offline vagy immutable mentés.

Miért fontos az offsite mentés?

Az offsite mentés lényege, hogy legalább egy biztonsági másolat fizikailag elkülönüljön az elsődleges infrastruktúrától.

Ez lehet például:

másik telephely;
távoli adatközpont;
megfelelő felhős objektumtárolás;
vagy más elkülönített mentési infrastruktúra.

Ennek jelentősége akkor válik igazán láthatóvá, ha nem egyetlen szerverhibával számolunk.

Hanem például:

tűzzel, beázással, lopással, súlyos elektromos kárral vagy teljes telephelyi incidenssel.

Ha az elsődleges szerver és az összes mentése ugyanabban a rackben található, akkor fizikailag ugyanattól a kockázattól függhetnek.

A mentési stratégia kialakításánál ezért nemcsak azt kell meghatározni, hogy:

„Hány másolatunk van?”

Hanem azt is:

„Hol vannak ezek a másolatok, és ugyanaz az esemény képes-e egyszerre megsemmisíteni őket?”

A Microsoft 365 sem kivétel az üzletmenet-folytonosság alól

A felhőszolgáltatások jelentősen átalakították a vállalati infrastruktúrát.

Sok vállalkozás ma már a Microsoft 365-ben kezeli:

a levelezést;
OneDrive-adatokat;
SharePoint-dokumentumokat;
Teams-együttműködést;
felhasználói identitásokat;
és számos napi munkafolyamatot.

Ez csökkentheti a helyi infrastruktúrától való függést, de nem szünteti meg az üzletmenet-folytonossági kockázatokat.

Problémát jelenthet például:

felhasználói hiba;
jogosultsági probléma;
fiókkompromittálás;
hibás konfiguráció;
törölt adat;
szinkronizációs probléma;
vagy szolgáltatáskiesés.

Ezért a Microsoft 365 környezetet is ugyanúgy bele kell venni a vállalkozás kritikus rendszereinek felmérésébe.

A Microsoft 365 adatvédelmével és külön biztonsági mentésével részletesen a Microsoft 365 adatmentés – Hogyan védje meg vállalkozása kritikus adatait? című cikkünkben foglalkozunk.

Ha pedig maga a Microsoft 365 működése válik problémássá, érdemes elkülöníteni a helyi hálózati, hitelesítési, kliensoldali és szolgáltatói hibákat. Ezeket a Miért nem működik a Microsoft 365? A 12 leggyakoribb hiba és megoldás vállalkozások számára című útmutatónkban mutatjuk be.

A következő szint: mi történik, amikor tényleg minden leáll?

Eddig azt vizsgáltuk, hogyan lehet:

csökkenteni az egyedi hibapontokat;
redundanciát kialakítani;
megfelelő mentést készíteni;
és elkülönített adatpéldányokat fenntartani.

De még egy jól megtervezett infrastruktúrában is bekövetkezhet olyan esemény, amelyet nem sikerül automatikusan kivédeni.

Ilyenkor már nem az a kérdés, hogyan előzzük meg a hibát.

Hanem az:

Ki mit csinál az első 10 percben, az első órában és az azt követő időszakban?

Ehhez szükséges egy Disaster Recovery Plan, vagyis informatikai katasztrófa utáni helyreállítási terv.

És egy ilyen terv csak akkor ér valamit, ha nem kizárólag egy dokumentum valahol a szerveren – amelyet éppen a leállás miatt senki nem tud megnyitni.

Disaster Recovery Plan – mi történik, amikor a megelőzés már nem elég?

Kép leírása

Egy megfelelően kialakított informatikai infrastruktúra jelentősen csökkentheti a leállások valószínűségét és azok üzleti hatását.

De nincs olyan rendszer, amelyben minden meghibásodás kizárható.

Bekövetkezhet:

több komponens egyidejű meghibásodása;
súlyos hardverhiba;
adatvesztés;
zsarolóvírus-támadás;
hibás frissítés vagy konfiguráció;
hosszabb áramszünet;
szolgáltatói kiesés;
vagy akár egy teljes telephelyet érintő esemény.

Ilyenkor már nem elegendő tudni, hogy van biztonsági mentés.

Pontosan tudni kell:

mit kell helyreállítani, milyen sorrendben, honnan, kinek és milyen időn belül.

Ezt határozza meg a Disaster Recovery Plan, vagyis az informatikai katasztrófa utáni helyreállítási terv.

Mit kell tartalmaznia egy használható helyreállítási tervnek?

Egy jó Disaster Recovery Plan nem egy több száz oldalas dokumentum, amelyet elkészítése után senki nem olvas el.

A gyakorlatban használhatónak kell lennie.

Legalább az alábbi kérdésekre egyértelmű választ kell adnia.

1. Mely rendszerek kritikusak?

A korábban meghatározott prioritási sorrendnek itt konkrét helyreállítási sorrenddé kell válnia.

Például:

1. hálózati alapinfrastruktúra → 2. hitelesítés és DNS → 3. virtualizációs környezet → 4. kritikus adatbázis → 5. üzleti alkalmazás → 6. fájlszolgáltatás → 7. kevésbé kritikus rendszerek

A sorrend vállalkozásonként eltérhet.

A lényeg az, hogy ezt ne az incidens közben kelljen először eldönteni.

2. Hol találhatók a biztonsági mentések?

Dokumentálni kell:

milyen rendszerekről készül mentés;
milyen gyakorisággal;
milyen megőrzési idővel;
milyen tárolóra;
hol található az offsite példány;
mely mentések immutable vagy más módon védettek;
és milyen eszközzel állíthatók vissza.

Egy incidens közben nem szerencsés akkor elkezdeni keresni, hogy:

„Hol van ennek a szervernek a legutolsó használható mentése?”

A Mi az a 3-2-1 mentési stratégia, és miért életmentő vállalkozások számára? című cikkünkben részletesen bemutatjuk, hogyan csökkenthető annak kockázata, hogy egyetlen esemény az elsődleges adatokat és azok biztonsági másolatait is elérhetetlenné tegye.

3. Hol találhatók a szükséges hozzáférések?

Egy helyreállítás könnyen megakadhat akkor is, ha az adatok sértetlenek.

Szükség lehet például:

szerverek adminisztrátori hozzáférésére;
virtualizációs platform hozzáférésére;
router- és switch-konfigurációkra;
NAS-adminisztrációra;
Microsoft 365 adminisztrátori fiókra;
DNS- és domainkezelő hozzáférésre;
backup rendszer hitelesítő adataira;
titkosítási kulcsokra;
licencekre;
szolgáltatói ügyféladatokra.

Ezeket természetesen nem szabad védelem nélkül egy egyszerű dokumentumban tárolni.

De biztosítani kell, hogy egy kritikus incidens esetén az arra jogosult személyek hozzáférjenek a helyreállításhoz szükséges információkhoz.

Ha minden jelszó egy olyan szerveren található, amely éppen nem működik, az önmagában komoly helyreállítási akadály lehet.

A konfigurációk mentése ugyanolyan fontos lehet, mint az adatoké

Sok vállalkozás az adatmentésre koncentrál, miközben megfeledkezik az infrastruktúra konfigurációjáról.

Pedig egy teljes helyreállítás során szükség lehet például:

router konfigurációjára;
VPN-beállításokra;
tűzfalszabályokra;
VLAN-konfigurációkra;
switch-beállításokra;
virtualizációs konfigurációkra;
backup jobokra;
DNS-beállításokra;
szolgáltatásfiókokra;
alkalmazások konfigurációjára.

Ha egy kritikus hálózati eszköz meghibásodik, jelentős különbség van aközött, hogy:

„Van róla friss konfigurációs mentésünk.”

vagy:

„Valahogy újra be kell állítani az egészet.”

A dokumentáció és a konfigurációmentés ezért ugyanúgy része az üzletmenet-folytonosságnak, mint maga az adatmentés.

Ki mit csinál egy teljes IT-leállás első 10 percében?

Egy komoly incidens első perceiben az egyik legnagyobb veszély a kapkodás.

Valaki újraindítja a szervert.

Más kihúzza a hálózati kábelt.

Valaki visszakapcsol egy szolgáltatást.

Egy másik munkatárs elkezd fájlokat másolni.

Közben senki nem tudja pontosan:

mi történt;
mikor kezdődött;
mely rendszereket érinti;
és melyik beavatkozás milyen következménnyel járhat.

Ezért az első feladat általában nem az, hogy:

„Indítsunk újra mindent.”

Hanem az, hogy meghatározzuk az incidens természetét és kiterjedését.

Az első percekben tisztázni kell:

Mi nem működik?

Egy alkalmazás?

Egy virtuális gép?

A teljes szerver?

A hálózat?

Az internet?

Az adattároló?

Vagy több rendszer egyszerre?

Mikor kezdődött a probléma?

Ez különösen fontos lehet a naplók és a megfelelő visszaállítási pont kiválasztása miatt.

Történt-e változtatás közvetlenül előtte?

Frissítés?

Konfigurációmódosítás?

Új eszköz?

Karbantartás?

Lehet-e biztonsági incidens?

Ha például zsarolóvírus vagy illetéktelen hozzáférés gyanúja merül fel, teljesen más eljárásra lehet szükség, mint egy egyszerű hardverhiba esetén.

Nem minden hibánál szabad azonnal visszakapcsolni a rendszereket

Ez különösen fontos kibertámadás esetén.

Ha egy kompromittált rendszer egyszerűen visszakerül a hálózatba anélkül, hogy a támadás okát és terjedését feltárták volna, előfordulhat, hogy:

a támadó továbbra is rendelkezik hozzáféréssel;
a kártékony program újra elindul;
más rendszerek ismét megfertőződnek;
a frissen visszaállított adatok ismét titkosításra kerülnek.

Ezért egy helyreállításnak nemcsak gyorsnak kell lennie.

Biztonságosnak is.

A vállalkozásnak nem az a célja, hogy a kompromittált környezetet a lehető leggyorsabban pontosan ugyanabba az állapotba visszaállítsa.

A cél egy ellenőrzött, működő és megbízható környezet helyreállítása.

Mi történjen az első órában?

Miután sikerült meghatározni az incidens jellegét és megakadályozni a további károkat, megkezdődhet a tényleges helyreállítás.

Egy lehetséges folyamat:

1. Az incidens kiterjedésének meghatározása

Pontosan mely rendszerek érintettek?

2. A további károk megakadályozása

Szükség esetén érintett rendszerek vagy hálózati szegmensek izolálása.

3. A mentések állapotának ellenőrzése

Melyik az utolsó ismerten megfelelő visszaállítási pont?

4. A helyreállítási prioritás alkalmazása

Nem feltétlenül mindent egyszerre kell visszaállítani.

5. Az alapinfrastruktúra helyreállítása

Hálózat, névfeloldás, hitelesítés és az adott környezethez szükséges alapvető szolgáltatások.

6. A kritikus üzleti rendszerek helyreállítása

Adatbázisok, alkalmazások, fájlszolgáltatások és más prioritást élvező rendszerek.

7. Működési ellenőrzés

Nem elég, hogy a virtuális gép elindult.

Azt is ellenőrizni kell, hogy az üzleti szolgáltatás valóban használható-e.

„Elindult a szerver” nem ugyanaz, mint „helyreállt a szolgáltatás”

Ez egy nagyon fontos különbség.

Egy virtuális gép lehet bekapcsolt állapotban, miközben:

az adatbázis nem indul;
az alkalmazás nem éri el az adatbázist;
a DNS hibás;
a felhasználók nem tudnak hitelesíteni;
a hálózati megosztás nem érhető el;
az alkalmazás licence nem működik;
vagy a szolgáltatás kívülről továbbra sem hozzáférhető.

Ezért a helyreállítás végét üzleti szolgáltatási szinten kell ellenőrizni.

Nem azt kell kérdezni:

„Fut a VM?”

Hanem:

„A felhasználó ismét el tudja végezni azt a munkát, amelyhez ezt a rendszert használja?”

Mi történik, ha az eredeti szerver nem állítható helyre?

Itt válik különösen fontossá a helyreállítási stratégia.

Ha egy fizikai szerver teljesen meghibásodik, több lehetőség létezhet:

hardver javítása;
alkatrészcsere;
teljes szervercsere;
virtuális gép másik hoston történő elindítása;
backupból történő teljes visszaállítás;
ideiglenes helyreállítás tartalék infrastruktúrán;
vagy bizonyos környezetekben felhős infrastruktúra használata.

A megfelelő megoldást az elvárt RTO határozza meg.

Ha a vállalkozás 24–48 órás kiesést képes tolerálni, egy hagyományos hardvercsere és restore is elfogadható lehet.

Ha viszont a kritikus rendszernek egy órán belül működnie kell, akkor olyan infrastruktúrát kell kialakítani, amely már az incidens előtt lehetővé teszi ezt a helyreállítási időt.

Katasztrófa közben már késő magas rendelkezésre állású architektúrát tervezni.

A mentés sebessége nem ugyanaz, mint a visszaállítás sebessége

Egy másik gyakori félreértés.

Lehetséges, hogy egy backup minden éjjel problémamentesen elkészül.

Ez azonban nem mondja meg, mennyi ideig tart annak visszaállítása.

Tegyük fel, hogy egy rendszer:

4 TB adatot tartalmaz.

A mentés rendelkezésre áll.

De a teljes visszatöltéshez szükséges:

az új vagy tartalék storage előkészítése;
a mentés átvitele;
az adatok visszaállítása;
a virtuális gépek vagy alkalmazások indítása;
az adatbázis ellenőrzése;
a szolgáltatások tesztelése.

A folyamat könnyen órákig vagy akár tovább is tarthat.

Ezért az RTO meghatározásakor nem a backup elkészülésének idejéből kell kiindulni.

A tényleges restore folyamatot kell mérni.

A próba-visszaállítás az egyetlen valódi bizonyíték

A backup rendszer zöld státusza fontos.

De önmagában nem bizonyítja, hogy egy teljes katasztrófa után a vállalkozás ténylegesen helyre tud állni.

A valódi kérdés:

Próbáltuk már visszaállítani?

Érdemes időszakosan tesztelni például:

egy fájl visszaállítását;
egy teljes virtuális gép visszaállítását;
egy adatbázis visszaállítását;
egy kritikus alkalmazás helyreállítását;
a konfigurációk használhatóságát;
az offsite mentések elérhetőségét.

Nagyobb vagy kritikusabb infrastruktúránál pedig indokolt lehet egy teljes Disaster Recovery teszt.

Ilyenkor kontrollált körülmények között azt vizsgáljuk:

Mi történne, ha az elsődleges rendszer most valóban nem lenne elérhető?

Mérjük meg a tényleges RTO-t

A teszt során érdemes időt mérni.

Például:

Helyreállítási lépés	Idő
Incidens felismerése és döntés	15 perc
Tartalék infrastruktúra előkészítése	20 perc
Kritikus VM visszaállítása	35 perc
Adatbázis ellenőrzése	15 perc
Alkalmazás indítása és tesztelése	15 perc
Teljes helyreállítás	100 perc

Ha az adott szolgáltatás üzleti RTO-ja 2 óra, akkor a folyamat megfelelő lehet.

Ha az RTO 30 perc, akkor viszont nem.

Ez már nem feltételezés.

Mérhető adat.

A monitoring a helyreállítási időt is csökkentheti

Kép leírása

A monitoringot gyakran kizárólag hibajelző rendszerként kezelik.

Pedig az üzletmenet-folytonosságban ennél nagyobb szerepe lehet.

Egy megfelelő monitoring rendszer segíthet abban, hogy a problémát még azelőtt észrevegyük, hogy a felhasználók tömegesen jeleznék.

Figyelhető például:

CPU- és memóriahasználat;
tárhelykapacitás;
RAID állapot;
lemezhibák;
hálózati interfészek;
internetkapcsolatok;
szolgáltatások;
adatbázisok;
backup jobok;
UPS-ek;
virtualizációs hostok;
NAS-ok;
hálózati eszközök.

Ha egy RAID degradált állapotát vagy egy backup hibáját hetekkel korábban észlelhetjük, akkor egy későbbi teljes leállás akár meg is előzhető.

Ezért a monitoring nem egyszerű kényelmi funkció.

A rendelkezésre állási stratégia egyik eleme.

A témát részletesen a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben mutatjuk be.

A helyreállítási tervnek offline is elérhetőnek kell lennie

Van egy egyszerű probléma, amelyet könnyű figyelmen kívül hagyni.

Tegyük fel, hogy elkészült a tökéletes Disaster Recovery dokumentáció.

Tartalmazza:

a szervereket;
IP-címeket;
függőségeket;
helyreállítási sorrendet;
kapcsolattartókat;
backup információkat;
konfigurációkat;
eljárásokat.

Majd elmentjük:

a vállalati fájlszerverre.

Ha éppen a fájlszerver és a kapcsolódó infrastruktúra állt le, a dokumentáció nem feltétlenül érhető el.

Ezért a kritikus helyreállítási információkból megfelelően védett, az elsődleges infrastruktúrától függetlenül hozzáférhető példányra is szükség lehet.

Ugyanez igaz a szolgáltatói elérhetőségekre és a kritikus konfigurációs információkra.

A technikai helyreállítás mellett kommunikációs terv is kell

Egy teljes IT-leállás nem kizárólag az informatikus problémája.

Ha a munkatársak nem tudják, mi történik, rövid időn belül elkezdődhet:

az IT folyamatos telefonos keresése;
egymásnak ellentmondó információk terjedése;
önálló újraindítások;
nem engedélyezett kerülőmegoldások használata;
saját e-mail-címek vagy fájlmegosztók használata;
felesleges beavatkozások.

Ez tovább nehezítheti a helyreállítást.

Ezért előre meg kell határozni:

ki koordinálja az incidenst;
ki kommunikál a munkatársakkal;
milyen csatornán történik a kommunikáció;
ki kommunikál az ügyfelekkel vagy partnerekkel, ha szükséges;
és milyen időközönként kapnak állapotfrissítést az érintettek.

Ha pedig a vállalati e-mail-rendszer is érintett, rendelkezni kell alternatív kommunikációs lehetőséggel.

A legrosszabb Disaster Recovery terv az, amelyet soha nem teszteltek

Papíron szinte minden működhet.

A dokumentáció szerint:

van backup;
van tartalék eszköz;
van UPS;
van másodlagos internet;
van helyreállítási terv.

A valóság azonban csak teszteléskor derül ki.

Lehet, hogy:

a backup sérült;
a visszaállítás sokkal lassabb a vártnál;
hiányzik egy jelszó;
lejárt egy licenc;
a tartalék hardver nem kompatibilis;
egy konfiguráció elavult;
a másodlagos internetkapcsolat nem vált át megfelelően;
vagy a dokumentáció már nem tükrözi a jelenlegi infrastruktúrát.

Ezért az üzletmenet-folytonosság nem egyszeri projekt.

Folyamatosan karbantartott képesség.

A következő részben azt vizsgáljuk meg, milyen gyakran érdemes tesztelni a mentéseket és a teljes helyreállítási tervet, milyen figyelmeztető jelekből látható, hogy egy vállalkozás nincs felkészülve egy komoly IT-leállásra, és hogyan építhető fel mindez reálisan egy KKV-nál anélkül, hogy indokolatlanul drága infrastruktúrát kellene fenntartani.

Mennyire van felkészülve vállalkozása egy teljes IT-leállásra?

Egy vállalkozás informatikai infrastruktúrája éveken keresztül működhet komolyabb probléma nélkül.

Ez azonban könnyen hamis biztonságérzetet teremthet.

Az, hogy eddig nem történt komolyabb leállás, nem bizonyítja, hogy a vállalkozás felkészült egy ilyen eseményre.

A valódi felkészültség akkor derül ki, amikor meg kell válaszolni néhány egyszerű kérdést.

Ha most meghibásodna a legfontosabb szerver:

honnan állítanánk vissza;
mennyi idő alatt;
milyen hardverre;
ki végezné el;
melyik rendszer indulna el elsőként;
és mennyi adat veszne el?

Ha ezekre nincs egyértelmű válasz, akkor a vállalkozás helyreállítási képessége valójában nem ismert.

10 figyelmeztető jel, hogy a vállalkozás nincs felkészülve egy komoly IT-leállásra

1. „Van mentésünk”, de még senki nem próbálta visszaállítani

A sikeres backup és a sikeres restore két külön dolog.

Egy mentési feladat attól még lehet zöld státuszú, hogy egy teljes rendszer helyreállítása során olyan probléma jelentkezik, amely korábban nem volt látható.

Ezért időszakosan tényleges visszaállítási tesztet is kell végezni.

2. Senki nem tudja pontosan, mennyi idő alatt lehetne helyreállni

Ha egy kritikus szerver RTO-ja négy óra, de még soha nem mérték meg a teljes visszaállítás idejét, akkor a négy óra nem helyreállítási képesség.

Csak feltételezés.

Az RTO akkor válik valóban használható adattá, amikor az infrastruktúra és a helyreállítási folyamat képes azt teljesíteni.

3. Minden mentés ugyanazon a telephelyen található

Ez egy szerver vagy egy meghajtó meghibásodása ellen megfelelő védelmet jelenthet.

Egy teljes telephelyet érintő esemény ellen azonban nem feltétlenül.

Tűz, beázás, lopás vagy súlyos elektromos probléma egyszerre veszélyeztetheti az elsődleges infrastruktúrát és a helyben tárolt mentéseket.

Ezért fontos a fizikailag elkülönített adatpéldány.

4. A kritikus infrastruktúra egyetlen eszköztől függ

Egyetlen:

szerver;
router;
switch;
internetkapcsolat;
NAS;
UPS;
vagy más kritikus komponens

meghibásodása akár teljes szolgáltatáskiesést okozhat.

Ezeket a Single Point of Failure pontokat tudatosan kell feltárni.

A rendszerleállások tipikus technikai okait és a megelőzés lehetőségeit részletesen bemutatjuk a Miért áll le váratlanul egy cég informatikai rendszere? A leggyakoribb okok és hogyan előzhetők meg című cikkünkben.

5. A hibákról először a felhasználók szólnak

Ha az IT-rendszer állapotáról rendszeresen úgy értesül az üzemeltető, hogy:

„Nem működik.”

akkor hiányozhat a megfelelő proaktív felügyelet.

Egy monitoring rendszer számos problémát már korábban jelezhet.

Ilyen lehet például:

fogyó tárhely;
magas erőforrás-használat;
lemezhiba;
degradált RAID;
sikertelen backup;
szolgáltatásleállás;
hálózati kapcsolat megszakadása;
UPS-probléma.

A proaktív felügyelet szerepét részletesen bemutatjuk a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben.

6. Nincs naprakész infrastruktúra-dokumentáció

Egy komolyabb leállás során értékes idő veszhet el annak kiderítésével, hogy:

melyik rendszer hol fut;
milyen IP-címet használ;
mitől függ;
mely portokra van szüksége;
hol található a mentése;
milyen konfiguráció tartozik hozzá;
és milyen sorrendben kell elindítani.

Egy megfelelő dokumentáció jelentősen gyorsíthatja a hibakeresést és a helyreállítást.

7. Egyetlen ember ismeri az egész rendszert

Ez szervezeti Single Point of Failure.

Ha kizárólag egy ember tudja:

hogyan működik az infrastruktúra;
hol vannak a jelszavak;
hogyan működik a backup;
melyik szolgáltatás mitől függ;
és hogyan lehet helyreállítani,

akkor az ő elérhetetlensége önmagában üzletmenet-folytonossági kockázat.

A megfelelő dokumentáció ezért nem adminisztratív teher.

A helyreállíthatóság része.

8. A mentések működését senki nem figyeli

A backup rendszer is meghibásodhat.

Elfogyhat a tárhely.

Megszakadhat a kapcsolat a mentési célhoz.

Lejárhat egy hitelesítő adat.

Megváltozhat egy jogosultság.

Hibás lehet egy mentési feladat.

Ha erről senki nem kap értesítést, előfordulhat, hogy a probléma csak akkor derül ki, amikor már szükség lenne a mentésre.

Ez az egyik oka annak, hogy a backup monitoringnak ugyanúgy része kell lennie az infrastruktúra felügyeletének, mint a szerverek vagy hálózati eszközök figyelésének.

9. A frissítések és karbantartások rendszertelenül történnek

Az üzembiztonság nem kizárólag redundanciából és backupból áll.

Egy régóta nem frissített:

operációs rendszer;
hypervisor;
router;
NAS;
alkalmazás;
firmware

biztonsági és stabilitási kockázatot is jelenthet.

Ugyanakkor a frissítések kontroll nélküli telepítése szintén problémát okozhat.

A cél ezért nem egyszerűen az, hogy „minden legyen mindig friss”, hanem a tervezett, ellenőrzött és dokumentált karbantartás.

Ennek jelentőségéről a Miért fontosak a szoftverfrissítések? című cikkünkben részletesebben is írunk.

10. Nincs leírva, mi történik egy teljes leállás esetén

Ez talán a legegyértelműbb figyelmeztető jel.

Ha egy komoly incidens során minden döntést ott és akkor kell meghozni, akkor a helyreállítás:

lassabb;
kiszámíthatatlanabb;
és nagyobb hibakockázattal jár.

Egy Disaster Recovery Plannek nem kell indokolatlanul bonyolultnak lennie.

De egyértelműen meg kell határoznia:

Mi történt? → Mit izolálunk? → Mit állítunk helyre? → Honnan? → Milyen sorrendben? → Ki végzi? → Hogyan ellenőrizzük?

Milyen gyakran kell tesztelni a mentéseket és a helyreállítást?

Erre nincs minden vállalkozás számára megfelelő univerzális időköz.

A gyakoriságot többek között befolyásolja:

az adatok fontossága;
az adatok változásának sebessége;
az infrastruktúra komplexitása;
az RTO és RPO;
a vállalkozás kockázati profilja;
valamint az, milyen gyakran változik maga az infrastruktúra.

Egy kritikus rendszer esetében azonban nem célszerű arra várni, hogy az első teljes visszaállítási próba egy valódi katasztrófa legyen.

A tesztelés több szinten történhet.

Fájlszintű restore teszt

Egy vagy több fájl tényleges visszaállítása.

Rendszerszintű restore teszt

Egy teljes virtuális gép vagy szerver helyreállítása izolált környezetben.

Alkalmazásszintű teszt

Nemcsak azt ellenőrizzük, hogy a szerver elindul-e, hanem azt is, hogy a rajta működő alkalmazás és adatbázis használható-e.

Teljes Disaster Recovery teszt

Egy előre meghatározott forgatókönyv alapján szimuláljuk egy kritikus rendszer vagy infrastruktúra kiesését, majd mérjük a helyreállítás folyamatát és idejét.

A teszt után pedig dokumentálni kell:

mi működött;
mi nem működött;
hol keletkezett késés;
milyen információ hiányzott;
és mit kell módosítani a helyreállítási tervben.

Egy KKV-nak is szüksége van Disaster Recovery tervre?

Igen, de nem feltétlenül ugyanolyan infrastruktúrára, mint egy nagyvállalatnak.

Egy kisebb vállalkozás számára általában nem az a cél, hogy minden szolgáltatás:

0–24 órában, nulla másodperc kieséssel, teljesen redundáns adatközpontok között működjön.

Ez rendkívül költséges lenne, és sok esetben üzletileg sem lenne indokolt.

A cél az arányos védelem.

Egy KKV-nál például sokkal nagyobb üzleti értéke lehet annak, hogy rendelkezésre áll:

megfelelő 3-2-1 mentés;
offsite adatpéldány;
dokumentált infrastruktúra;
UPS;
rendszeres monitoring;
konfigurációmentés;
tesztelt visszaállítás;
meghatározott RTO és RPO;
valamint egyszerű, de használható helyreállítási terv.

mint annak, hogy minden egyes komponensből kettő működjön.

A legjobb megoldás nem feltétlenül a legdrágább

Az üzletmenet-folytonosság nem arról szól, hogy minden vállalkozásnak enterprise infrastruktúrát kell építenie.

Hanem arról, hogy a rendelkezésre álló költségkeretet a valódi üzleti kockázatok alapján használjuk fel.

Lehet például, hogy egy vállalkozás számára fontosabb:

egy megfelelő offsite backup

mint egy második fizikai szerver.

Más környezetben viszont az egyórás RTO miatt éppen a tartalék virtualizációs host lesz kritikus.

Egy harmadik vállalkozásnál pedig a legnagyobb kockázat nem a szerver, hanem az egyetlen internetkapcsolat.

Ezért nincs univerzális infrastruktúra-recept.

A megfelelő architektúra mindig abból indul ki:

Mely üzleti folyamatot kell megvédenünk, milyen eseménytől, mekkora kiesést engedhetünk meg, és mennyi adatot veszíthetünk el?

Egyszerű IT üzletmenet-folytonossági ellenőrzőlista

Egy vállalkozás felkészültségének első felméréséhez érdemes megválaszolni az alábbi kérdéseket:

Tudjuk, mely informatikai rendszereink üzletileg kritikusak?
Ismerjük ezek egymás közötti függőségeit?
Meghatároztuk az RTO értékeket?
Meghatároztuk az RPO értékeket?
Ismerjük a Single Point of Failure pontokat?
Van megfelelő biztonsági mentés?
Van fizikailag elkülönített vagy offsite mentés?
Ellenőrzött a mentések sikeressége?
Történt tényleges próba-visszaállítás?
Tudjuk, mennyi ideig tart egy teljes restore?
Rendelkezünk konfigurációmentésekkel?
Dokumentált az infrastruktúra?
A dokumentáció leállás esetén is elérhető?
Monitorozzuk a kritikus rendszereket?
Van kijelölt helyreállítási sorrend?
Egyértelmű, ki koordinál egy komoly IT-incidenst?
Van alternatív kommunikációs csatorna?
Tudjuk, hogyan működne tovább a vállalkozás a helyreállítás ideje alatt?
Teszteltük már a Disaster Recovery tervet?

Ha ezek közül több kérdésre a válasz:

„Nem tudjuk.”

akkor nem feltétlenül az jelenti a legnagyobb problémát, hogy nincs elegendő technológia.

Hanem az, hogy nem ismert a vállalkozás tényleges helyreállítási képessége.

A valódi cél nem a nulla meghibásodás

Minden szerver meghibásodhat.

Minden merevlemez meghibásodhat.

Minden hálózati eszköz meghibásodhat.

Minden szolgáltatás kieshet.

És emberi hiba is bármikor történhet.

Ezért a megfelelően felépített informatikai környezet célja nem az az irreális feltételezés, hogy:

„Nálunk semmi nem romolhat el.”

Hanem az, hogy:

„Ha valami elromlik, időben észrevesszük, tudjuk, mit kell tenni, rendelkezünk használható mentéssel, és az üzletileg elfogadható időn belül képesek vagyunk helyreállítani a kritikus szolgáltatásokat.”

Ez a különbség az egyszerűen működő és a helyreállításra is felkészített informatikai infrastruktúra között.

Gyakran ismételt kérdések az IT-leállásról és az üzletmenet-folytonosságról

Mennyi ideig működhet egy vállalkozás informatika nélkül?

Ez teljes mértékben a vállalkozás működésétől és informatikai függőségeitől függ.

Egyes vállalkozások bizonyos feladatokat órákig képesek manuálisan folytatni, míg más környezetekben egy kritikus szerver, internetkapcsolat, adatbázis vagy felhőszolgáltatás kiesése gyakorlatilag azonnal megállíthatja a munkát.

Ezért minden kritikus rendszerhez érdemes meghatározni, mennyi ideig tolerálható annak kiesése.

Mi az RTO?

Az RTO (Recovery Time Objective) azt határozza meg, hogy egy informatikai rendszer vagy szolgáltatás kiesése után legfeljebb mennyi időn belül kell annak ismét működnie.

Ha például egy vállalati adatbázis RTO-ja két óra, akkor a helyreállítási infrastruktúrát és folyamatot úgy kell kialakítani, hogy a szolgáltatás lehetőleg ezen időn belül újra használható legyen.

Az RTO tehát arra a kérdésre válaszol:

Mennyi ideig lehetünk az adott rendszer nélkül?

Mi az RPO?

Az RPO (Recovery Point Objective) azt határozza meg, hogy egy incidens során legfeljebb mennyi adat elvesztése tekinthető elfogadhatónak.

Ha például egy rendszer RPO-ja egy óra, akkor olyan mentési, replikációs vagy adatvédelmi megoldásra van szükség, amely lehetővé teszi, hogy egy komolyabb hiba esetén lehetőleg legfeljebb körülbelül egyórányi adatváltozás vesszen el.

Az RPO tehát arra a kérdésre válaszol:

Mennyi adatot engedhetünk meg magunknak elveszíteni?

Mi a különbség az üzletmenet-folytonosság és a Disaster Recovery között?

Az üzletmenet-folytonosság (Business Continuity) tágabb fogalom.

Azt vizsgálja, hogyan tarthatók fenn vagy állíthatók helyre a vállalkozás kritikus üzleti folyamatai egy komolyabb esemény során.

A Disaster Recovery elsősorban az informatikai rendszerek és adatok helyreállítására koncentrál.

Egyszerűen:

Business Continuity → hogyan működjön tovább a vállalkozás?

Disaster Recovery → hogyan állítsuk helyre az informatikát?

A kettő szorosan összefügg.

Elég egy biztonsági mentés egy teljes IT-leállás kezeléséhez?

Nem feltétlenül.

A biztonsági mentés az egyik legfontosabb alap, de önmagában nem határozza meg:

milyen gyorsan állítható helyre a rendszer;
milyen infrastruktúrára történik a visszaállítás;
milyen sorrendben kell helyreállítani a szolgáltatásokat;
rendelkezésre állnak-e a szükséges konfigurációk és hozzáférések;
működőképes-e maga a backup;
és valóban teljesíthető-e az elvárt RTO és RPO.

Ezért a kérdés nem egyszerűen az, hogy:

„Van mentésünk?”

Hanem az:

„Ha most leállna a rendszer, mennyi idő alatt tudnánk ebből ténylegesen újra működő szolgáltatást létrehozni?”

Milyen gyakran kell biztonsági mentést készíteni?

Nincs minden rendszerre alkalmazható általános időköz.

A mentési gyakoriságot elsősorban az határozza meg, hogy mennyi adatvesztés elfogadható, vagyis mekkora az adott rendszer RPO-ja.

Egy ritkán változó adattár esetében megfelelő lehet a ritkább mentés.

Egy folyamatosan változó üzleti adatbázis esetében viszont akár a napi egyszeri mentés is túl ritka lehet.

A gyakoriság mellett fontos a mentések elkülönítése és több példány fenntartása is. Ennek egyik ismert megközelítését a Mi az a 3-2-1 mentési stratégia, és miért életmentő vállalkozások számára? című cikkünkben részletesen bemutatjuk.

A RAID helyettesíti a biztonsági mentést?

Nem.

A RAID bizonyos lemezhibák esetén növelheti a rendelkezésre állást, de nem nyújt megfelelő védelmet például:

véletlen fájltörlés;
adatbázis-sérülés;
hibás módosítás;
zsarolóvírus;
teljes szerverhiba;
lopás;
vagy telephelyet érintő fizikai káresemény

ellen.

A RAID redundancia, nem biztonsági mentés.

A NAS biztonsági mentésnek számít?

Attól függ, hogyan használják.

Ha egy szerver adatairól külön másolat készül egy NAS-ra, akkor a NAS lehet a mentési infrastruktúra egyik eleme.

Ha azonban az adatok kizárólag a NAS-on találhatók, attól még nincs róluk biztonsági mentés.

A NAS és a vállalati adattárolás kapcsolatáról részletesebben a NAS: okos adattárolási megoldás vállalkozásoknak című cikkünkben írunk.

Mi az offsite mentés?

Az offsite mentés olyan biztonsági másolat, amely fizikailag elkülönül az elsődleges informatikai infrastruktúrától.

Lehet például:

másik telephelyen;
adatközpontban;
vagy megfelelő felhős infrastruktúrában.

Ennek célja, hogy egy teljes telephelyet érintő esemény ne tegye egyszerre elérhetetlenné az elsődleges adatokat és valamennyi biztonsági másolatot.

Mi az a Single Point of Failure?

A Single Point of Failure (SPOF) olyan komponens vagy függőség, amelynek meghibásodása önmagában képes egy kritikus szolgáltatás leállását okozni.

Ilyen lehet például:

egyetlen szerver;
egyetlen router;
egyetlen központi switch;
egyetlen internetkapcsolat;
egyetlen adattároló;
vagy akár egyetlen személy, aki rendelkezik a rendszer helyreállításához szükséges tudással és hozzáférésekkel.

A SPOF pontok azonosítása az üzletmenet-folytonossági tervezés egyik alapvető lépése.

Szüksége van egy kisebb vállalkozásnak is Disaster Recovery tervre?

Igen.

Ez azonban nem jelenti azt, hogy egy kisebb vállalkozásnak több adatközpontból álló, teljesen redundáns enterprise infrastruktúrát kell fenntartania.

Egy KKV számára a megfelelő Disaster Recovery stratégia lehet egyszerűbb és költséghatékonyabb.

A lényeg, hogy dokumentált legyen:

mely rendszerek kritikusak;
hol vannak a mentések;
milyen sorrendben történik a helyreállítás;
ki végzi azt;
és milyen időn belül kell ismét működnie a kritikus szolgáltatásoknak.

Milyen gyakran kell tesztelni a biztonsági mentések visszaállítását?

A tesztelés gyakoriságát a rendszer kritikussága, változásának gyakorisága, valamint az RTO és RPO követelmények alapján érdemes meghatározni.

Kritikus rendszereknél rendszeres próba-visszaállítás indokolt.

Fontos, hogy ne csak egy fájl visszaállíthatóságát vizsgáljuk.

Időszakosan érdemes ellenőrizni azt is, hogy:

egy teljes szerver, virtuális gép, adatbázis vagy üzleti alkalmazás valóban működőképes állapotba állítható-e vissza.

Miért fontos a monitoring az üzletmenet-folytonosságban?

Mert minél korábban észlelünk egy problémát, annál nagyobb az esély arra, hogy az még a teljes szolgáltatáskiesés előtt kezelhető.

Monitoringgal figyelhető többek között:

a szerverek erőforrás-használata;
a tárhely;
a lemezek és RAID állapota;
a hálózat;
az internetkapcsolat;
a szolgáltatások;
a virtualizációs infrastruktúra;
az UPS;
valamint a mentési feladatok állapota.

A témával részletesen a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben foglalkozunk.

Mit kell először helyreállítani egy teljes IT-leállás után?

Nem feltétlenül azt a rendszert, amelyet technikailag a legegyszerűbb visszaállítani.

A helyreállítási sorrendet az üzleti kritikuság és a rendszerek közötti függőségek alapján kell meghatározni.

Előfordulhat például, hogy egy üzleti alkalmazás csak akkor működik, ha előtte rendelkezésre áll:

hálózat → DNS → hitelesítés → adatbázis → alkalmazásszerver.

Ezért a Disaster Recovery Plannek nem egyszerű szerverlistát, hanem helyreállítási sorrendet és függőségeket is tartalmaznia kell.

Mi a legfontosabb kérdés, amit egy cégvezetőnek fel kell tennie az informatikai mentésekről?

Nem azt, hogy:

„Készül backup?”

Hanem ezt:

„Ha ma teljesen leállna a kritikus informatikai rendszerünk, mennyi adatot veszítenénk el, és hány óra múlva tudnánk újra dolgozni?”

Ha erre nincs konkrét, lehetőleg teszttel alátámasztott válasz, akkor a vállalkozás tényleges helyreállítási képessége nem ismert.

Összegzés – nem az a kérdés, hogy leállhat-e az informatika, hanem az, hogy felkészültünk-e rá

Egy vállalkozás informatikai rendszerének leállása nem feltétlenül jelent katasztrófát.

A valódi probléma akkor kezdődik, ha a vállalkozás nem tudja:

mely rendszerei kritikusak;
mennyi ideig működhet nélkülük;
mennyi adatvesztést képes elfogadni;
honnan lehet az adatokat visszaállítani;
mennyi ideig tart a helyreállítás;
milyen sorrendben kell elindítani a szolgáltatásokat;
és ki mit csinál egy komoly incidens esetén.

Egy megfelelő üzletmenet-folytonossági stratégia ezért nem egyetlen technológiai megoldásból áll.

Nem elég önmagában:

egy UPS;
egy RAID;
egy NAS;
egy második szerver;
egy biztonsági mentés;
vagy egy monitoring rendszer.

Ezek mind fontos építőelemek lehetnek, de csak akkor alkotnak valódi védelmet, ha egy előre megtervezett helyreállítási stratégia részei.

A felkészülés öt alapvető kérdéssel kezdődik

Egy vállalkozásnak legalább az alábbi öt kérdésre érdemes konkrét választ adnia:

1. Mi állítaná le a vállalkozást?

Fel kell térképezni a kritikus üzleti folyamatokat és az azokat kiszolgáló informatikai rendszereket.

2. Mennyi kiesést engedhetünk meg?

Ezt határozza meg az RTO – Recovery Time Objective.

3. Mennyi adatot veszíthetünk el?

Ezt határozza meg az RPO – Recovery Point Objective.

4. Hogyan állítjuk helyre a rendszert?

Ehhez szükséges:

mentés + redundancia + dokumentáció + konfigurációmentés + helyreállítási sorrend + felelősségi körök.

5. Tudjuk bizonyítani, hogy működik?

Erre csak egy valódi válasz létezik:

teszteltük a helyreállítást.

A mentés csak akkor ér valamit, ha vissza is állítható

A „van backupunk” önmagában kevés információ.

Egy megfelelő mentési rendszer esetében azt is tudni kell:

mikor készült az utolsó sikeres mentés;
milyen adatokat tartalmaz;
hol található;
megfelelően elkülönített-e;
sértetlen-e;
mennyi idő alatt állítható vissza;
és a visszaállított rendszer ténylegesen használható-e.

A mentési stratégia egyik széles körben alkalmazott alapelve a több adatpéldány és az elkülönített tárolás. Ennek gyakorlati megközelítését a Mi az a 3-2-1 mentési stratégia, és miért életmentő vállalkozások számára? című cikkünkben részletesen bemutatjuk.

A hibát jobb a leállás előtt észrevenni

A Disaster Recovery arra készít fel, mi történjen egy komolyabb meghibásodás után.

A monitoring ezzel szemben abban segíthet, hogy bizonyos problémákat még a teljes kiesés előtt felismerjünk.

Egy fogyó tárhely, meghibásodó lemez, degradált RAID, sikertelen mentés vagy instabil hálózati kapcsolat sok esetben már jóval a teljes leállás előtt figyelmeztető jeleket adhat.

Ezért a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben bemutatott proaktív felügyelet az üzletmenet-folytonosság fontos része lehet.

Nem kell minden vállalkozásnak enterprise infrastruktúra

Egy kisebb vagy közepes vállalkozásnak nem feltétlenül van szüksége:

több adatközpontra;
mindenből két példányra;
bonyolult cluster infrastruktúrára;
vagy rendkívül költséges magas rendelkezésre állású rendszerre.

A cél nem a technológia maximalizálása.

A cél az üzleti kockázattal arányos informatikai védelem.

Egy vállalkozás számára sokszor nagyobb értéket jelenthet egy jól megtervezett 3-2-1 mentési rendszer, egy offsite adatpéldány, megfelelő monitoring és egy ténylegesen kipróbált helyreállítási folyamat, mint egy drága, de nem megfelelően dokumentált infrastruktúra.

A technológiát ezért mindig az üzleti követelményhez kell igazítani.

Mennyi ideig működne az Ön cége informatika nélkül?

Érdemes ezt a kérdést nem egy valódi leállás közben először feltenni.

Mi történne, ha holnap reggel:

nem indulna el a szerver;
elérhetetlenné válna a NAS;
megszűnne az internetkapcsolat;
nem működne a Microsoft 365;
nem lenne elérhető a vállalati adatbázis;
vagy egy biztonsági incidens miatt több rendszert egyszerre le kellene választani?

Tudná a vállalkozás:

mi a legfontosabb rendszer → honnan állítható vissza → milyen sorrendben → ki végzi → és mennyi idő alatt?

Ha igen, akkor már létezik egy fontos alap az üzletmenet-folytonossághoz.

Ha nem, akkor érdemes ezt még a következő komolyabb meghibásodás előtt felmérni.

Hogyan segíthet a SARABEL Informatika?

A SARABEL Informatika vállalati informatikai környezetek felmérésében, üzemeltetésében és üzembiztonságának fejlesztésében nyújt támogatást.

A felmérés során többek között vizsgálható:

a kritikus informatikai rendszerek és függőségeik;
a Single Point of Failure pontok;
a szerver- és virtualizációs infrastruktúra;
a hálózati infrastruktúra;
a NAS- és adattárolási környezet;
a biztonsági mentések;
az offsite mentési lehetőségek;
a monitoring;
az RTO és RPO követelmények;
valamint a helyreállítási folyamatok.

A cél nem feltétlenül egy nagyobb vagy drágább infrastruktúra kialakítása.

A cél egy olyan informatikai környezet kialakítása, amelynek ismert a kockázata, ellenőrzött a mentése, monitorozott az állapota, és meghibásodás esetén tervezhető a helyreállítása.

Ha szeretné felmérni, hogy vállalkozása informatikai rendszere mennyire lenne felkészülve egy komolyabb leállásra, vegye fel velünk a kapcsolatot.

Kapcsolódó szakmai útmutatók

A témához kapcsolódóan az alábbi útmutatóinkat is ajánljuk:

Források és szakmai háttér

A cikkben bemutatott üzletmenet-folytonossági és helyreállítási alapelvekhez kapcsolódó fontosabb szakmai keretrendszerek és források:

NIST – Cybersecurity Framework (CSF)
NIST SP 800-34 – Contingency Planning Guide for Federal Information Systems
CISA – Business Continuity / Cybersecurity Guidance
ENISA – Business Continuity and cyber resilience guidance
ISO 22301 – Business Continuity Management Systems
ISO/IEC 27001 – Information Security Management Systems

A kérdés tehát nem az, hogy meghibásodhat-e egy szerver, hálózati eszköz vagy szolgáltatás.

Hanem az, hogy amikor megtörténik, a vállalkozás perceket, órákat vagy napokat veszít-e – és pontosan tudja-e, hogyan álljon talpra.