Miért áll le váratlanul egy cég informatikai rendszere? A leggyakoribb okok és hogyan előzhetők meg
Egy vállalkozás informatikai rendszere általában addig láthatatlan, amíg minden megfelelően működik.
A munkatársak bejelentkeznek, elérik a közös fájlokat, használják az ügyviteli programokat, küldik az e-maileket, csatlakoznak a szerverhez, és természetesnek veszik, hogy az informatikai háttér rendelkezésre áll.
Aztán egyik reggel valami megváltozik.
Nem érhető el a szerver. Nem indul az ügyviteli program. Eltűnik a hálózati meghajtó. Nem működik az internet vagy a VPN. A felhasználók nem tudnak bejelentkezni, esetleg egy teljes telephely munkája leáll.
Ilyenkor hangzik el a kérdés:
„Hogy állhatott le egyik pillanatról a másikra?”
A válasz sok esetben az, hogy nem egyik pillanatról a másikra történt.
A váratlan leállás gyakran csak a vállalkozás számára váratlan
Egy informatikai rendszer meghibásodását sokszor már órákkal, napokkal vagy akár hetekkel korábban különböző figyelmeztető jelek előzik meg.
Ilyen lehet például:
- folyamatosan csökkenő szabad tárhely;
- növekvő memória- vagy processzorterhelés;
- lemezhibák;
- sikertelen biztonsági mentések;
- rendszeresen újrainduló szolgáltatások;
- hálózati csomagvesztés;
- instabil internetkapcsolat;
- túlmelegedő hardver;
- hibát jelző szünetmentes tápegység;
- elmaradt rendszerfrissítések;
- lejáró tanúsítványok;
- ismétlődő alkalmazáshibák.
Ha ezeket senki nem figyeli, a vállalkozás számára valóban úgy tűnhet, hogy a rendszer minden előjel nélkül állt le.
Pedig az informatikai infrastruktúra gyakran már korábban jelezte, hogy valami nincs rendben.
Egy rendszerleállás nem csak informatikai probléma
Ha egy vállalkozás központi informatikai rendszere leáll, annak hatása gyorsan megjelenik az üzleti működésben is.
Előfordulhat, hogy:
- a munkatársak nem tudnak dolgozni;
- nem érhetők el az ügyféladatok;
- nem használható a könyvelő- vagy ügyviteli rendszer;
- leáll a számlázás;
- nem érhetők el a közös dokumentumok;
- megszakad a távoli munkavégzés;
- nem működik a telephelyek közötti kapcsolat;
- késnek az ügyfélkiszolgálási folyamatok;
- határidős feladatok maradnak el.
Egy többórás kiesés ezért már nem egyszerűen technikai kellemetlenség.
Közvetlen üzleti veszteséget okozhat.
Minél több üzleti folyamat függ az informatikai infrastruktúrától, annál nagyobb jelentősége van annak, hogy egy hiba milyen gyorsan észlelhető, diagnosztizálható és helyreállítható.
Mi okozhat váratlan informatikai leállást?
Nincs egyetlen tipikus ok.
A háttérben állhat:
- hardverhiba;
- megtelt háttértár;
- szerverhiba;
- hálózati probléma;
- internetkimaradás;
- DNS-hiba;
- hibás rendszerfrissítés;
- szoftverhiba;
- hibás konfiguráció;
- túlterhelés;
- áramszünet vagy UPS-probléma;
- kibertámadás;
- emberi hiba;
- vagy akár több kisebb probléma együttes hatása.
Ezért egy vállalati rendszer megbízhatóságát sem lehet kizárólag az alapján megítélni, hogy:
„Most éppen működik.”
A valódi kérdés inkább az, hogy észrevesszük-e időben, amikor már kezd valami rosszul működni.
Ebben van kiemelt szerepe a folyamatos szerver- és hálózati monitoringnak.
A témával részletesen foglalkozunk 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.
Mit mutatunk be ebben a cikkben?
Megnézzük:
- melyek a vállalati rendszerleállások leggyakoribb okai;
- milyen jelek utalhatnak közelgő meghibásodásra;
- mely hibák előzhetők meg monitoringgal;
- mi történik, ha maga a monitoring sem működik megfelelően;
- miért fontos a biztonsági mentés és a visszaállítás tesztelése;
- milyen szerepe van a redundanciának;
- hogyan csökkenthető egy meghibásodás üzleti hatása;
- és hogyan alakítható ki olyan informatikai környezet, ahol egyetlen hiba nem feltétlenül állítja le az egész vállalkozást.
A cél ugyanis nem az, hogy egy informatikai rendszerben soha ne történjen meghibásodás.
Ilyen rendszer gyakorlatilag nem létezik.
A cél az, hogy a problémákat lehetőség szerint még a leállás előtt észleljük, egy tényleges meghibásodás pedig ne okozzon aránytalanul hosszú üzleti kiesést.
A vállalati informatikai rendszerleállások leggyakoribb okai
Egy informatikai rendszer ritkán egyetlen komponensből áll.
A szerverek, hálózati eszközök, internetkapcsolatok, háttértárak, operációs rendszerek, virtuális gépek és üzleti alkalmazások egymásra épülnek.
Ez azt jelenti, hogy akár egyetlen kritikus komponens meghibásodása is több szolgáltatás kiesését okozhatja.
Nézzük a leggyakoribb okokat.
1. Hardverhiba
Minden fizikai eszköz meghibásodhat.
Ez igaz többek között:
- SSD-kre és merevlemezekre;
- memóriamodulokra;
- tápegységekre;
- RAID-vezérlőkre;
- hálózati kártyákra;
- switchekre;
- routerekre;
- ventilátorokra;
- szünetmentes tápegységekre;
- magára a szerverre.
A probléma különösen akkor jelentős, ha egy kritikus szolgáltatás egyetlen fizikai eszköztől függ.
Ha például egy vállalkozás összes fájlja, adatbázisa és üzleti alkalmazása ugyanazon a szerveren fut, annak meghibásodása egyszerre több szolgáltatást is elérhetetlenné tehet.
Milyen jelek utalhatnak közelgő hardverhibára?
Például:
- SMART figyelmeztetések;
- növekvő lemezhibaszám;
- RAID degradált állapota;
- váratlan újraindulások;
- memóriahibák;
- szokatlanul magas hőmérséklet;
- ventilátorhiba;
- tápegységhiba;
- rendszeresen megjelenő hardveres eseménynapló-bejegyzések.
Ezek egy része megfelelő monitoring mellett már azelőtt felismerhető, hogy az eszköz teljesen meghibásodna.
2. Megtelik a szerver tárhelye
Ez az egyik legegyszerűbbnek tűnő, mégis rendkívül gyakori probléma.
A szabad tárhely folyamatosan csökkenhet például:
- növekvő adatbázisok;
- felhasználói fájlok;
- naplófájlok;
- ideiglenes fájlok;
- biztonsági mentések;
- snapshotok;
- frissítési állományok
miatt.
Amikor egy rendszerpartíción vagy adatpartíción elfogy a szabad hely, annak következménye jóval súlyosabb lehet annál, hogy egyszerűen „nem lehet több fájlt rámásolni”.
Leállhat:
- egy adatbázis;
- egy virtuális gép;
- egy alkalmazás;
- a biztonsági mentés;
- egy Windows- vagy Linux-szolgáltatás.
A tárhelyfogyás tipikusan olyan probléma, amely nem váratlanul történik.
A megfelelő monitoring már jóval korábban képes jelezni, hogy egy meghajtó elérte például a meghatározott figyelmeztetési küszöbértéket.
3. Hálózati hiba
Előfordulhat, hogy maga a szerver tökéletesen működik, a felhasználók mégsem érik el.
Ilyenkor a probléma a hálózati infrastruktúrában lehet.
Gyakori okok:
- switchhiba;
- routerhiba;
- hibás hálózati kábel;
- VLAN-konfigurációs probléma;
- DHCP-hiba;
- DNS-hiba;
- IP-cím ütközés;
- hibás tűzfalszabály;
- hibás routing;
- túlterhelt hálózati kapcsolat.
A felhasználó ebből gyakran csak annyit érzékel:
„Nem működik a szerver.”
Pedig a szerver közben működhet, csak az odavezető hálózati kapcsolat szakadt meg.
4. Internetkapcsolat kiesése
A modern vállalkozások egyre több szolgáltatást használnak internetkapcsolaton keresztül.
Egy internetkimaradás ezért érintheti:
- a Microsoft 365-öt;
- a felhőalapú ügyviteli rendszereket;
- a távoli munkavégzést;
- a VPN-kapcsolatokat;
- a VoIP-telefonokat;
- a felhőalapú biztonsági mentéseket;
- a telephelyek közötti kapcsolatokat.
Ilyenkor a helyi szerverek akár hibátlanul működhetnek, a vállalkozás egy része mégis munkaképtelenné válhat.
Kritikus környezetben ezért indokolt lehet tartalék internetkapcsolat és automatikus WAN failover kialakítása.
5. Hibás vagy sikertelen rendszerfrissítés
Az operációs rendszerek és alkalmazások frissítése biztonsági szempontból elengedhetetlen.
Ugyanakkor egy hibásan települt vagy kompatibilitási problémát okozó frissítés szolgáltatáskiesést is eredményezhet.
Érintett lehet például:
- Windows Server;
- Linux Server;
- adatbázis-kezelő;
- virtualizációs platform;
- üzleti alkalmazás;
- hálózati eszköz firmware-e.
Ezért vállalati környezetben a frissítések kezelését célszerű tervezetten végezni.
Kritikus rendszernél különösen fontos:
- a frissítés előtti mentés;
- a kompatibilitás ellenőrzése;
- a karbantartási időablak;
- és a visszaállítási lehetőség.
6. Egyetlen hibapont – Single Point of Failure
Az egyik legveszélyesebb infrastruktúra-probléma az úgynevezett Single Point of Failure (SPOF).
Ez azt jelenti, hogy van a rendszerben egy olyan komponens, amelynek meghibásodása az egész szolgáltatás leállását okozhatja.
Ilyen lehet:
- egyetlen szerver;
- egyetlen switch;
- egyetlen router;
- egyetlen internetkapcsolat;
- egyetlen tápegység;
- egyetlen háttértár;
- egyetlen mentési célpont.
Például ha egy vállalkozás teljes működése egyetlen NAS-ra épül, annak meghibásodása egyszerre teheti elérhetetlenné a fájlokat és több, az eszköztől függő szolgáltatást.
Ahogy egy vállalkozás növekszik, ezért idővel érdemes megvizsgálni, hogy a meglévő infrastruktúra még megfelel-e az üzleti igényeknek.
Erről részletesen írunk a Mikor érdemes NAS helyett valódi szerverinfrastruktúrát használni? című cikkünkben.
A cél nem feltétlenül az, hogy minden komponensből kettő legyen. A redundanciát elsősorban azoknál a pontoknál érdemes kialakítani, amelyek kiesése elfogadhatatlan üzleti leállást okozna.
7. Túlterhelés és elégtelen erőforrások
Nem minden rendszerleállást okoz konkrét meghibásodás.
Előfordulhat, hogy az infrastruktúra egyszerűen eléri a teljesítőképességének határát.
Egy évekkel korábban megfelelően méretezett szerver idővel kevés lehet, ha közben:
- nőtt a felhasználók száma;
- több alkalmazás került rá;
- megnőttek az adatbázisok;
- új virtuális gépek indultak;
- jelentősen nőtt az adatforgalom;
- több távoli felhasználó csatlakozik;
- megváltoztak az üzleti alkalmazások erőforrásigényei.
Tipikus tünetek:
- tartósan magas CPU-terhelés;
- elfogyó memória;
- intenzív lapozás;
- magas lemezterhelés;
- lassú adatbázis-műveletek;
- hosszú bejelentkezési idő;
- akadozó alkalmazások;
- időtúllépések;
- időszakosan elérhetetlenné váló szolgáltatások.
A rendszer ilyenkor nem feltétlenül áll le azonnal.
Először csak lassabb lesz.
Majd egyre több hiba jelenik meg, végül egy kritikus szolgáltatás már nem képes megfelelően működni.
Ezért fontos a kapacitásadatok hosszabb távú vizsgálata is. Nemcsak azt kell látni, hogy mennyi a processzorterhelés ebben a pillanatban, hanem azt is, hogyan változott az elmúlt hetekben vagy hónapokban.
8. Szoftver- vagy szolgáltatáshiba
Egy szerver fizikailag teljesen egészséges lehet úgy is, hogy valamely rajta futó szolgáltatás már nem működik.
Leállhat például:
- adatbázis-szolgáltatás;
- webszerver;
- fájlmegosztás;
- DNS-szolgáltatás;
- hitelesítési szolgáltatás;
- levelezési szolgáltatás;
- üzleti alkalmazás háttérfolyamata.
Ilyenkor az egyszerű hálózati ellenőrzés akár azt is mutathatja, hogy a szerver elérhető.
A felhasználó mégsem tud dolgozni.
Ez fontos különbség.
Nem elegendő azt monitorozni, hogy egy szerver válaszol-e a hálózaton. A rajta futó kritikus szolgáltatások működését is ellenőrizni kell.
9. Hibás konfiguráció vagy emberi hiba
Az informatikai incidensek egy része nem meghibásodásból, hanem változtatásból ered.
Például:
- hibás tűzfalszabály kerül beállításra;
- rossz IP-cím kerül megadásra;
- törölnek egy DNS-rekordot;
- megváltoztatnak egy jogosultságot;
- leállítanak egy szükséges szolgáltatást;
- hibás frissítés kerül telepítésre;
- véletlenül törölnek egy virtuális gépet vagy fájlt;
- rossz hálózati konfiguráció kerül alkalmazásra.
Ezért fontos, hogy a kritikus rendszereken végzett módosítások:
- tervezetten történjenek;
- dokumentálva legyenek;
- lehetőség szerint visszafordíthatók legyenek;
- és rendelkezésre álljon megfelelő mentés a változtatás előtt.
A stabil informatikai működés egyik alapja nem az, hogy soha senki ne hibázzon, hanem hogy egy emberi hiba ne okozhasson helyreállíthatatlan következményeket.
10. Áramszünet és szünetmentes tápegység hibája
Egy néhány másodperces áramszünet vagy feszültségingadozás is elegendő lehet egy szerver, NAS vagy hálózati eszköz újraindulásához.
Ennek következménye lehet:
- fájlrendszer-sérülés;
- adatbázis-sérülés;
- virtuális gépek szabálytalan leállása;
- adatvesztés;
- hálózati szolgáltatások kiesése;
- hardverhiba.
A szünetmentes tápegység (UPS) ezért fontos része a vállalati infrastruktúrának.
De önmagában az sem elegendő, hogy „van UPS”.
Ellenőrizni kell többek között:
- az akkumulátor állapotát;
- a terhelést;
- a várható áthidalási időt;
- a kommunikációt a szerverrel;
- a hibajelzéseket;
- az automatikus szabályos leállítás működését.
Egy évekkel korábban telepített, soha nem ellenőrzött UPS hamis biztonságérzetet adhat.
11. Kibertámadás vagy kártékony program
Egy informatikai rendszer kiesésének oka biztonsági incidens is lehet.
Ilyen például:
- zsarolóvírus;
- feltört felhasználói fiók;
- kompromittált szerver;
- rosszindulatú program;
- jogosulatlan hozzáférés;
- szolgáltatásmegtagadásos támadás;
- sérülékenység kihasználása.
Egy zsarolóvírus-támadás különösen súlyos lehet, mert nemcsak a működő rendszert, hanem az elérhető biztonsági mentéseket is veszélyeztetheti.
Ezért az üzletmenet-folytonosság szempontjából a biztonsági mentésnek nem csupán léteznie kell, hanem megfelelően elkülönítettnek és visszaállíthatónak is kell lennie.
12. A biztonsági mentés hibája csak akkor derül ki, amikor már szükség lenne rá
A rendszerleállás és az adatvesztés nem ugyanaz.
Egy meghibásodott szerver megfelelő mentésből helyreállítható.
A valódi probléma akkor kezdődik, amikor a helyreállítás során derül ki, hogy:
- a mentés hónapok óta hibára fut;
- nem minden szükséges adat került mentésre;
- a mentési tárhely megtelt;
- a mentés sérült;
- a zsarolóvírus a mentést is elérte;
- nincs megfelelően dokumentált helyreállítási folyamat;
- soha nem történt próba-visszaállítás.
Ezért a „van biztonsági mentésünk” és a „vissza tudjuk állítani a rendszerünket” két külön állítás.
A megfelelő mentési stratégia kialakításának egyik jól ismert alapelve a 3-2-1 szabály. Erről részletesen olvashat 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.
Miért nem vették észre hamarabb a hibát?
Ez az egyik legfontosabb kérdés egy komolyabb rendszerleállás után.
Nem csak azt érdemes megvizsgálni:
„Mi romlott el?”
Hanem azt is:
„Miért csak akkor szereztünk róla tudomást, amikor már nem lehetett dolgozni?”
Ha egy szerver tárhelye heteken keresztül folyamatosan fogyott, egy RAID már korábban degradált állapotba került, a backup napok óta sikertelen volt vagy egy szolgáltatás rendszeresen leállt, akkor ezek egy része megfelelő rendszerfelügyelettel már korábban észlelhető lehetett volna.
A monitoring egyik legfontosabb feladata éppen ezért nem az, hogy látványos grafikonokat készítsen.
Hanem az, hogy időben jelezze azokat az eltéréseket, amelyekből később üzleti leállás lehet.
Egy korábbi projektünk gyakorlati tapasztalatait a Miért nem vették észre időben a szerverhibákat? Egy monitoring projekt tanulságai című esettanulmányunkban mutatjuk be.
Hogyan előzhetők meg a váratlan rendszerleállások?
A cél nem az, hogy egy vállalkozás informatikai rendszerében soha ne történjen meghibásodás.
Ezt gyakorlatilag lehetetlen garantálni.
Ehelyett olyan infrastruktúrát kell kialakítani, amelyben:
- a problémák jelentős része már a leállás előtt észlelhető;
- egyetlen eszköz meghibásodása lehetőleg nem állítja le az egész vállalkozást;
- a kritikus adatokról megfelelő biztonsági mentés készül;
- meghibásodás esetén ismert a helyreállítás menete;
- a rendszer állapota folyamatosan ellenőrizhető.
Ehhez több védelmi réteg együttes alkalmazása szükséges.
1. Folyamatos szerver- és hálózati monitoring
A monitoring segítségével nemcsak azt lehet ellenőrizni, hogy egy szerver működik-e.
Figyelhető többek között:
- CPU-terhelés;
- memóriahasználat;
- szabad tárhely;
- lemezállapot;
- hálózati forgalom;
- hálózati késleltetés és csomagvesztés;
- kritikus szolgáltatások állapota;
- biztonsági mentések eredménye;
- hálózati eszközök elérhetősége;
- UPS állapota;
- tanúsítványok lejárata.
A megfelelően beállított monitoring nem akkor szól, amikor már minden leállt.
Az igazán hasznos riasztás azt jelzi, hogy egy érték olyan irányba változik, amelyből később probléma lehet.
Például jelentős különbség van a következő két esemény között:
„A szerveren elfogyott a tárhely.”
és:
„A szerver tárhelyének kihasználtsága elérte a figyelmeztetési küszöböt.”
Az első esetben már hibát kell elhárítani.
A második esetben még van idő beavatkozni.
A monitoring szerepéről részletesen írunk 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.
2. A monitoringot is ellenőrizni kell
Egy felügyeleti rendszer önmagában még nem jelent védelmet.
Ha egy eszköz nincs megfelelően felvéve, az agent nem kommunikál, hibás a titkosítás, blokkolja a tűzfal a kapcsolatot vagy rosszul vannak meghatározva a riasztási feltételek, akkor a monitoring hamis biztonságérzetet adhat.
Zabbix környezetben például fontos lehet ellenőrizni:
- a Zabbix Server és Agent közötti kommunikációt;
- az aktív és passzív ellenőrzéseket;
- a hálózati elérhetőséget;
- a szükséges portokat;
- a TLS-beállításokat;
- a host konfigurációját;
- valamint azt, hogy valóban érkeznek-e friss mérési adatok.
A Zabbix kommunikációs és konfigurációs problémáinak gyakorlati vizsgálatához hasznos kiegészítő szakmai anyag a Zabbix: hibakeresés című útmutató.
A monitoring tehát nem egyszeri telepítési feladat. A felügyeleti rendszer működését és a riasztások célba érkezését is időszakosan ellenőrizni kell.
3. Megfelelő biztonsági mentési stratégia
A monitoring segíthet megelőzni egy leállást.
A biztonsági mentés pedig akkor válik kritikussá, amikor a hibát már nem lehetett megelőzni.
Egy megfelelő mentési rendszernek nemcsak az adatokat kell másolnia, hanem biztosítania kell, hogy azok ténylegesen visszaállíthatók legyenek.
Érdemes meghatározni:
- mit kell menteni;
- milyen gyakran kell menteni;
- mennyi ideig kell megőrizni a mentéseket;
- hol találhatók a mentési példányok;
- hozzáférhet-e hozzájuk a működő rendszer;
- mennyi idő alatt állítható vissza egy kritikus szolgáltatás;
- mikor történt utoljára sikeres próba-visszaállítás.
A megfelelő mentési rendszer kialakításához jó kiindulási alap a Mi az a 3-2-1 mentési stratégia, és miért életmentő vállalkozások számára? című útmutatónk.
4. Redundancia a kritikus pontokon
Nem szükséges minden vállalkozásnak teljesen redundáns adatközpontot építenie.
Azt viszont érdemes megvizsgálni:
Melyik az az egyetlen eszköz vagy szolgáltatás, amelynek kiesése az egész vállalkozást leállítaná?
Ha ilyen komponens található a rendszerben, érdemes megvizsgálni a kiesés kockázatát és a lehetséges tartalék megoldást.
Ez lehet például:
- RAID a háttértáraknál;
- redundáns tápegység;
- tartalék internetkapcsolat;
- másodlagos hálózati eszköz;
- virtualizált szerverkörnyezet;
- replikáció;
- másodlagos mentési célpont;
- megfelelően előkészített helyreállítási környezet.
A redundancia célja nem feltétlenül az, hogy a felhasználók soha semmilyen hibát ne érzékeljenek.
A cél az, hogy egy komponens meghibásodása ne okozzon aránytalanul nagy üzleti kiesést.
5. Tervezett karbantartás és frissítés
A „nem nyúlunk hozzá, mert működik” stratégia rövid távon kényelmesnek tűnhet, hosszabb távon azonban komoly kockázatot jelenthet.
Egy vállalati infrastruktúrában rendszeresen szükség lehet:
- operációs rendszer frissítésére;
- firmware-frissítésre;
- biztonsági javításokra;
- alkalmazásfrissítésekre;
- tárhely-karbantartásra;
- naplók ellenőrzésére;
- hardverállapot vizsgálatára;
- jogosultságok felülvizsgálatára;
- mentések ellenőrzésére.
A karbantartás célja nem kizárólag az aktuális hibák javítása.
A megfelelő IT-üzemeltetés egyik legfontosabb feladata, hogy megelőzze azokat a problémákat, amelyekből később leállás lehet.
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ű cikkünkben írunk.
Mit érdemes ellenőrizni egy komolyabb rendszerleállás után?
Egy rendszer helyreállítása után könnyű lezártnak tekinteni az incidenst.
A szerver újra működik.
A felhasználók ismét be tudnak jelentkezni.
Az alkalmazások elérhetők.
A probléma azonban ezzel még nem feltétlenül oldódott meg.
Ha nem derül ki pontosan, hogy mi okozta a leállást, ugyanaz a hiba később ismét megtörténhet.
Ezért egy komolyabb incidens után érdemes utólagos vizsgálatot végezni.
Az utólagos vizsgálat legfontosabb kérdései
Érdemes meghatározni:
- mi volt a hiba közvetlen oka;
- voltak-e korábbi figyelmeztető jelek;
- mikor kezdődött valójában a probléma;
- mikor észlelte először a vállalkozás;
- jelzett-e a monitoring;
- eljutott-e a riasztás a megfelelő személyhez;
- megfelelően működött-e a biztonsági mentés;
- mennyi ideig tartott a helyreállítás;
- mely üzleti szolgáltatásokat érintette a kiesés;
- milyen változtatással előzhető meg az ismétlődés.
A cél nem a hibás személy megtalálása.
A cél annak megértése, hogy melyik technikai vagy működési folyamat nem biztosított megfelelő védelmet.
RTO és RPO: mennyi kiesést és adatvesztést bír el a vállalkozás?
Egy informatikai rendszer tervezésénél két fontos kérdést érdemes előre megválaszolni.
Mennyi ideig állhat a rendszer?
Ezt fejezi ki az RTO (Recovery Time Objective).
Egyszerűbben:
Mennyi időn belül kell helyreállítani egy szolgáltatást egy komolyabb meghibásodás után?
Egy kevésbé fontos rendszer esetében elfogadható lehet akár egy munkanapos helyreállítás.
Egy központi ügyviteli, termelési vagy fájlszervernél azonban már néhány órás kiesés is komoly üzleti problémát okozhat.
Mennyi adat elvesztése fogadható el?
Ezt határozza meg az RPO (Recovery Point Objective).
Ha például naponta egyszer készül biztonsági mentés, egy meghibásodás esetén akár az utolsó mentés óta keletkezett teljes napi adatállomány elveszhet.
Ha ez elfogadhatatlan, gyakoribb mentésre vagy más adatvédelmi technológiára lehet szükség.
Az RTO és RPO tehát nem kizárólag informatikai kérdés.
Elsősorban üzleti döntés.
A vállalkozásnak kell meghatároznia, hogy egy adott szolgáltatás esetében mennyi kiesés és potenciális adatvesztés elfogadható.
Mennyi pénzbe kerül egy informatikai leállás?
A rendszerleállás valódi költsége gyakran jóval magasabb annál, mint amennyibe maga a javítás kerül.
Vegyünk egy egyszerű példát.
Ha egy 20 fős vállalkozás informatikai rendszere négy órára leáll, az már:
80 kiesett munkaórát jelenthet.
És ebben még nincs benne:
- az informatikai helyreállítás költsége;
- az elmaradt értékesítés;
- a később elvégzendő munka;
- a határidők csúszása;
- az ügyfelek várakozása;
- az esetleges adatvesztés;
- a reputációs kár.
Ezért az informatikai rendelkezésre állást nem célszerű kizárólag költségként kezelni.
A megfelelő infrastruktúra, monitoring, biztonsági mentés és karbantartás célja az üzleti kockázat csökkentése.
Milyen jelekből látható, hogy egy vállalkozás IT-rendszere kockázatos?
Nem szükséges megvárni az első komolyabb leállást.
Figyelmeztető jel lehet, ha:
- Senki nem monitorozza folyamatosan a szervereket.
- Nem ismert, hogy a biztonsági mentések valóban sikeresek-e.
- Soha nem történt próba-visszaállítás.
- Egyetlen szerveren fut minden kritikus szolgáltatás.
- Egyetlen internetkapcsolattól függ a teljes iroda.
- Nincs dokumentálva az infrastruktúra.
- A szerver tárhelyét csak akkor ellenőrzik, amikor megtelik.
- Nincs tervszerű frissítési és karbantartási folyamat.
- Egy hálózati eszköz meghibásodása az egész telephelyet leállítaná.
- Nem ismert, mennyi idő alatt lehetne helyreállítani a kritikus rendszereket.
- A mentések ugyanazon a rendszeren vagy hálózaton találhatók, amelyet védeniük kellene.
- Egyetlen informatikus fejében található meg minden szükséges konfiguráció és jelszó.
- A hibákról rendszeresen a felhasználók szólnak először.
- A hardverek állapotát és életkorát senki nem követi.
- Nincs incidenskezelési vagy helyreállítási eljárás.
Ha ezek közül több is igaz, akkor a kérdés nem feltétlenül az, hogy bekövetkezik-e egy komolyabb informatikai probléma, hanem az, hogy a vállalkozás mennyire lesz felkészülve, amikor megtörténik.
A stabil informatikai háttér jelentőségéről részletesen írunk a Miért létfontosságú a stabil és biztonságos IT háttér a KKV-k számára? című cikkünkben.
A reaktív és a proaktív IT-üzemeltetés közötti különbség
A két megközelítés közötti különbség egyszerű.
Reaktív üzemeltetés esetén:
Leáll a rendszer → valaki jelzi → elkezdődik a hibakeresés → megkezdődik a helyreállítás.
Proaktív üzemeltetés esetén:
Megjelenik egy rendellenesség → a monitoring jelzi → megtörténik a beavatkozás → a leállás lehetőség szerint elkerülhető.
Természetesen proaktív üzemeltetés mellett is történhet meghibásodás.
A különbség abban van, hogy a vállalkozás nem kizárólag akkor kezd foglalkozni az informatikával, amikor már áll a munka.
Ez az egyik legfontosabb szemléletváltás egy vállalkozás informatikai rendszerének fejlődésében:
nem a hibák utáni gyors javítás az egyetlen cél, hanem a megelőzhető hibák felismerése és az üzleti kiesés minimalizálása.
Gyakori kérdések
Miért áll le váratlanul egy cég informatikai rendszere?
A váratlan rendszerleállás hátterében állhat hardverhiba, megtelt tárhely, hálózati vagy internetkapcsolati probléma, hibás frissítés, túlterhelés, szoftverhiba, áramszünet, kibertámadás vagy emberi hiba.
Sok esetben azonban a meghibásodást már korábban olyan figyelmeztető jelek előzik meg, amelyek megfelelő monitoring mellett észlelhetők lennének.
Valóban előjel nélkül hibásodik meg egy szerver?
Előfordulhat hirtelen hardverhiba, amelynek nincs egyértelműen felismerhető előjele.
Számos probléma azonban fokozatosan alakul ki. Ilyen lehet:
- a tárhely folyamatos fogyása;
- növekvő erőforrás-terhelés;
- RAID degradáció;
- lemezhibák;
- ismétlődő szolgáltatásleállások;
- sikertelen mentések;
- hálózati problémák;
- túlmelegedés.
Ezért fontos a szerverek folyamatos állapotfelügyelete.
Mi az a szervermonitoring?
A szervermonitoring olyan folyamatos felügyelet, amely különböző mérőszámok és szolgáltatások állapotát ellenőrzi.
Figyelhető például:
- processzorterhelés;
- memóriahasználat;
- szabad tárhely;
- hálózati forgalom;
- szolgáltatások állapota;
- eszközök elérhetősége;
- biztonsági mentések eredménye;
- hardverállapot.
A cél, hogy egy potenciális probléma lehetőség szerint még a szolgáltatás kiesése előtt felismerhető legyen.
A témáról részletesebben 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 írunk.
Mire használható a Zabbix?
A Zabbix segítségével szerverek, hálózati eszközök, szolgáltatások és számos infrastruktúra-komponens állapota központilag monitorozható.
A megfelelően kialakított rendszer képes riasztást generálni, ha egy meghatározott érték vagy szolgáltatás állapota problémára utal.
Ha maga a Zabbix felügyeleti rendszer nem kap megfelelő adatokat, a kommunikáció és a konfiguráció hibakeresése is szükségessé válhat. Ehhez kapcsolódó technikai útmutató a Zabbix: hibakeresés című szakmai anyag.
Elég a monitoring a rendszerleállások megelőzéséhez?
Nem.
A monitoring az egyik védelmi réteg, de mellette szükség van többek között:
- rendszeres karbantartásra;
- biztonsági frissítésekre;
- megfelelő kapacitástervezésre;
- biztonsági mentésre;
- visszaállítási tesztekre;
- megfelelő hálózati infrastruktúrára;
- kritikus esetekben redundanciára.
A monitoring felismeri a problémák egy részét, de önmagában nem szünteti meg azokat.
A RAID megakadályozza a szerverleállást?
Nem.
A RAID bizonyos lemezhibák esetén növelheti a rendelkezésre állást, de nem helyettesíti a biztonsági mentést, és nem véd minden meghibásodástól.
Nem jelent önmagában védelmet például:
- zsarolóvírus;
- véletlen törlés;
- fájlsérülés;
- vezérlőhiba;
- szerverhiba;
- lopás;
- tűzkár
esetén.
Elég, ha naponta egyszer készül biztonsági mentés?
Ez az üzleti követelményektől függ.
Ha egy vállalkozás számára elfogadhatatlan akár egy teljes munkanap adatainak elvesztése, akkor a napi egyszeri mentés nem feltétlenül elegendő.
A mentések gyakoriságát az elfogadható adatvesztéshez, vagyis az RPO-hoz kell igazítani.
A mentési rendszer kialakításának egyik alapelvé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 mutatjuk be.
Mi az RTO és az RPO?
Az RTO (Recovery Time Objective) azt határozza meg, hogy egy meghibásodás után mennyi időn belül kell helyreállítani az adott szolgáltatást.
Az RPO (Recovery Point Objective) pedig azt fejezi ki, hogy legfeljebb mennyi adat elvesztése fogadható el.
Ezek alapján tervezhető meg megfelelően a mentési, helyreállítási és rendelkezésre állási stratégia.
Mi az a Single Point of Failure?
A Single Point of Failure (SPOF) olyan kritikus komponens, amelynek meghibásodása önmagában képes egy teljes szolgáltatás vagy rendszer leállását okozni.
Ilyen lehet például:
- egyetlen szerver;
- egyetlen router;
- egyetlen switch;
- egyetlen internetkapcsolat;
- egyetlen tápegység;
- egyetlen adattároló.
A megfelelő infrastruktúra-tervezés egyik célja a kritikus hibapontok azonosítása és szükség esetén megszüntetése vagy hatásuk csökkentése.
Kell minden vállalkozásnak redundáns szerver?
Nem.
A szükséges redundancia mértékét az üzleti kockázat alapján kell meghatározni.
Más infrastruktúrára van szüksége annak a vállalkozásnak, amely néhány órát problémamentesen tud működni egy adott rendszer nélkül, és másra annak, ahol már 30 perc kiesés is jelentős veszteséget okoz.
Mit kell tenni egy rendszerleállás után?
A szolgáltatás helyreállítása az elsődleges feladat, de utána célszerű megvizsgálni:
- mi okozta a hibát;
- mikor kezdődött;
- voltak-e előzetes figyelmeztető jelek;
- működött-e a monitoring;
- megfelelő volt-e a mentés;
- mennyi idő alatt történt meg a helyreállítás;
- hogyan előzhető meg az ismétlődés.
Összegzés
Egy vállalati informatikai rendszer leállása ritkán csak egy technikai probléma.
Ha nem érhető el a szerver, az ügyviteli rendszer, a hálózat vagy az internetkapcsolat, annak közvetlen hatása lehet a vállalkozás működésére.
Leállhat a munka, késhet az ügyfélkiszolgálás, elérhetetlenné válhatnak fontos adatok, és akár jelentős bevételkiesés is keletkezhet.
A legfontosabb tanulság ezért nem az, hogy:
„Minden meghibásodást meg kell akadályozni.”
Ez nem reális cél.
Sokkal fontosabb, hogy a vállalkozás informatikai környezete képes legyen:
- időben felismerni a rendellenességeket;
- riasztani a kritikus problémákról;
- csökkenteni az egyes komponensektől való függőséget;
- megfelelő biztonsági mentést biztosítani;
- gyors helyreállítást lehetővé tenni;
- dokumentált módon kezelni az incidenseket.
A különbség egy felkészült és egy felkészületlen informatikai környezet között sokszor nem az, hogy történik-e meghibásodás.
Hanem az, hogy a meghibásodásból lesz-e többnapos üzleti probléma.
Proaktív IT-üzemeltetés vállalkozások számára
A SARABEL Informatika Kft. vállalkozások informatikai rendszereinek üzemeltetésében, felügyeletében és fejlesztésében nyújt támogatást.
A feladat nem kizárólag a már bekövetkezett hibák elhárítása.
A cél olyan informatikai környezet kialakítása, amelyben a problémák jelentős része még azelőtt felismerhető, hogy azok a napi működés leállását okoznák.
A támogatás többek között kiterjedhet:
- szerverek üzemeltetésére;
- szerver- és hálózati monitoring kialakítására;
- Zabbix alapú rendszerfelügyeletre;
- virtualizációs környezetek üzemeltetésére;
- hálózati infrastruktúra felügyeletére;
- biztonsági mentések kialakítására és ellenőrzésére;
- rendszeres karbantartásra és frissítésre;
- infrastruktúra-felmérésre;
- incidenskezelésre;
- helyreállítási folyamatok kialakítására.
A proaktív IT-üzemeltetés lényege, hogy ne kizárólag akkor kezdődjön el a hibakeresés, amikor a munkatársak már nem tudnak dolgozni.
Források
A cikk elkészítése során hivatalos dokumentációk, iparági ajánlások és szakmai anyagok kerültek felhasználásra.
- Zabbix Documentation
- Microsoft Learn
- NIST – Cybersecurity Framework
- NIST – Contingency Planning Guide for Federal Information Systems
- CISA – Cybersecurity Guidance
- Zabbix: hibakeresés