Mit jelent valójában a rendelkezésre állás? – Miért nem elég, ha a szerver működik?
A vállalkozások informatikai rendszereivel kapcsolatban gyakran elhangzik egy megnyugtatónak tűnő mondat:
„A szerver működik, minden rendben.”
De valóban minden rendben van akkor, ha a szerver bekapcsolt állapotban van, miközben a munkatársak nem tudnak belépni az ügyviteli rendszerbe, nem érkeznek meg az e-mailek, vagy percekig tart egy dokumentum megnyitása?
A válasz egyértelmű: nem.
A vállalati informatika rendelkezésre állása nem egyszerűen azt jelenti, hogy a szerverek és hálózati eszközök működnek. Azt jelenti, hogy a vállalkozás számára szükséges informatikai szolgáltatások a megfelelő időben, megfelelő teljesítménnyel és megfelelő módon használhatók.
Egy 30–200 fős vállalkozásnál ez már nem pusztán technikai kérdés.
A rendelkezésre állás közvetlenül befolyásolhatja a munkatársak hatékonyságát, az ügyfélkiszolgálást, az értékesítést és végső soron a vállalkozás eredményességét.
Ebben a cikkben bemutatjuk:
- Mit jelent valójában az informatikai rendelkezésre állás?
- Mennyi leállást jelent a 99%, 99,9% vagy 99,99%?
- Miért nem elegendő, ha a monitoringrendszer zöld állapotot mutat?
- Mi a különbség a magas rendelkezésre állás, a redundancia és az adatmentés között?
- Mennyibe kerülhet egy vállalkozásnak egy informatikai leállás?
- Hogyan növelhető a kritikus rendszerek rendelkezésre állása?
- Milyen rendelkezésre állási szintre van ténylegesen szüksége egy vállalkozásnak?
1. Mit jelent az informatikai rendelkezésre állás?
Az informatikai rendelkezésre állás – angolul availability – azt fejezi ki, hogy egy rendszer vagy szolgáltatás a meghatározott időszakban milyen arányban képes ellátni a rendeltetésszerű feladatát.
A kulcsszó nem az, hogy működik, hanem az, hogy használható.
Vegyünk egy egyszerű példát.
Egy vállalkozás központi szervere bekapcsolt állapotban van.
A hálózati kapcsolat működik.
A monitoringrendszer eléri a szervert.
Mégis előfordulhat, hogy:
- Az adatbázis-szolgáltatás leállt.
- Az ügyviteli rendszer nem tud kapcsolódni az adatbázishoz.
- A felhasználók nem tudnak bejelentkezni.
- A fájlszerver válaszideje elfogadhatatlanul magas.
- A DNS-szolgáltatás hibásan működik.
- A hitelesítési szolgáltatás nem érhető el.
A szerver technikai szempontból elérhető, de az üzleti szolgáltatás nem használható.
Ezért a valódi rendelkezésre állást nem kizárólag az infrastruktúra, hanem az üzleti szolgáltatások szintjén kell vizsgálni.
Infrastruktúra és üzleti szolgáltatás: nem ugyanaz
| Vizsgált elem | Mit jelent az elérhetősége? | Mi maradhat hibás? |
|---|---|---|
| Fizikai szerver | A hardver működik | Az operációs rendszer vagy az alkalmazás |
| Virtuális gép | A VM fut | Az adatbázis vagy a szolgáltatás |
| Hálózat | Az eszközök kommunikálnak | DNS, hitelesítés vagy alkalmazáskapcsolat |
| Webszerver | A HTTP-szolgáltatás válaszol | Bejelentkezés, adatbázis vagy fizetési folyamat |
| Levelezőszerver | A szolgáltatás elérhető | Levélkézbesítés, hitelesítés vagy levélfeldolgozás |
| Ügyviteli rendszer | Az alkalmazás megnyílik | Egy kritikus üzleti művelet |
Egy vállalatvezető számára tehát nem az a legfontosabb kérdés, hogy „fut-e a szerver”.
Hanem az, hogy:
„A munkatársaim és ügyfeleim el tudják végezni azokat a feladatokat, amelyekre a vállalkozás működéséhez szükség van?”
2. Mit jelent a 99%, 99,9% és 99,99% rendelkezésre állás?
Az informatikai szolgáltatók gyakran százalékos értékkel fejezik ki a rendelkezésre állást.
A 99,9% vagy a 99,99% első hallásra nagyon hasonlónak tűnhet.
A különbség azonban jelentős.
A rendelkezésre állás egyszerűsített képlete:
Rendelkezésre állás (%) = (Teljes vizsgált idő – Kiesési idő) / Teljes vizsgált idő × 100
Ha egy szolgáltatásnak az év minden percében működnie kell, akkor 365 nappal és 24 órás működéssel számolunk.
Ez évente:
365 × 24 × 60 = 525 600 perc.
Mennyi kiesést enged meg az egyes rendelkezésre állási szint?
| Rendelkezésre állás | Maximális kiesés évente | Maximális kiesés 30 nap alatt |
|---|---|---|
| 99% | 87 óra 36 perc | 7 óra 12 perc |
| 99,5% | 43 óra 48 perc | 3 óra 36 perc |
| 99,9% | 8 óra 45 perc 36 másodperc | 43 perc 12 másodperc |
| 99,95% | 4 óra 22 perc 48 másodperc | 21 perc 36 másodperc |
| 99,99% | 52 perc 33,6 másodperc | 4 perc 19,2 másodperc |
| 99,999% | 5 perc 15,36 másodperc | 25,92 másodperc |
A táblázat 365 napos évvel, illetve 30 napos hónappal és folyamatos, 24/7 rendelkezésre állási időablakkal számol. A szerződéses SLA ettől eltérő mérési szabályokat alkalmazhat.
Miért jelentős a különbség?
Egy 99%-os rendelkezésre állású rendszer éves szinten közel 88 óra kiesést is megengedhet.
Ez több mint három és fél teljes nap.
A 99,9%-os rendelkezésre állás ezzel szemben körülbelül 8 óra 46 perc éves kiesést jelent.
A 99,99%-os szintnél az éves kiesési idő már kevesebb mint egy óra.
A 99% és a 99,99% közötti különbség nem két tizedesjegy. Hanem több mint 86 órányi potenciális éves kiesés.
Fontos azonban megérteni, hogy ezek matematikai értékek.
Egy szolgáltató által vállalt SLA esetében a mérési időszak, a tervezett karbantartások, a kizárt események és a mérési módszer jelentősen befolyásolhatják a ténylegesen vállalt szolgáltatási szintet.
3. A 99,9%-os rendelkezésre állás nem feltétlenül jelent folyamatos üzleti működést
Tegyük fel, hogy egy vállalkozás központi szervere 99,9%-os éves rendelkezésre állást teljesít.
Ez önmagában kedvező értéknek tűnhet.
De mi történik akkor, ha a kiesés éppen a vállalkozás legforgalmasabb időszakában következik be?
Például:
- Egy szállodában a reggeli kijelentkezések idején.
- Egy könyvelőirodában egy fontos bevallási határidő előtt.
- Egy kereskedelmi vállalatnál a napi rendelésfeldolgozás csúcsidőszakában.
- Egy gyártóvállalatnál a termelés kritikus szakaszában.
- Egy szolgáltatócégnél a havi számlázás idején.
Ugyanaz a kétórás kiesés egészen eltérő üzleti következményekkel járhat.
A rendelkezésre állás üzleti értékét nemcsak a kiesés időtartama, hanem annak időpontja és az érintett folyamat jelentősége is meghatározza.
Nem minden informatikai rendszer egyformán kritikus
Egy vállalkozásnál különböző rendszerek eltérő rendelkezésre állási követelményeket indokolhatnak.
| Rendszer | Lehetséges üzleti hatás kiesés esetén | Javasolt megközelítés |
|---|---|---|
| Belső tudásbázis | Kényelmetlenség, lassabb munkavégzés | Alapfelügyelet és mentés |
| Irodai fájlszerver | Több munkatárs munkája akadályozott | Monitoring és helyreállítási terv |
| Vállalati levelezés | Kommunikációs és ügyfélkiszolgálási problémák | Felügyelet, biztonsági kontrollok |
| ERP-rendszer | Rendelésfeldolgozás és üzleti folyamatok akadályozottak | Magasabb rendelkezésre állási cél |
| Termelésirányítás | Termeléskiesés lehetősége | Üzleti hatáselemzés és megfelelő redundancia |
| Szállodai foglalási rendszer | Foglalások és vendégkiszolgálás érintett | Kritikus szolgáltatásként történő kezelés |
A táblázat szemléltető jellegű. A tényleges prioritásokat minden vállalkozásnál egyedileg kell meghatározni.
Egy jól működő informatikai stratégia nem feltétlenül törekszik minden rendszer esetében 99,99%-os rendelkezésre állásra.
A cél az, hogy a vállalkozás a megfelelő rendszereknél a megfelelő rendelkezésre állási szintet biztosítsa.
4. Miért nem elég, ha a monitoringrendszer zöld állapotot mutat?
A monitoringrendszerek az informatikai üzemeltetés nélkülözhetetlen eszközei.
Ilyen rendszer például a Zabbix, amely képes szerverek, hálózati eszközök, szolgáltatások és különböző teljesítménymutatók folyamatos megfigyelésére.
A monitoring azonban csak azt képes megbízhatóan megállapítani, aminek az ellenőrzésére megfelelően konfigurálták.
Példa: a szerver elérhető, az alkalmazás mégsem működik
Tegyük fel, hogy egy vállalkozás ügyviteli rendszere egy virtuális szerveren fut.
A monitoring ellenőrzi:
- A szerver pingelhetőségét.
- A CPU-terhelést.
- A memóriahasználatot.
- A háttértár szabad kapacitását.
Minden érték megfelelő.
A monitoring zöld állapotot mutat.
A felhasználók mégsem tudnak számlát kiállítani.
Miért?
Mert az ügyviteli alkalmazás adatbázis-kapcsolata megszakadt.
Ha a monitoring kizárólag a szerver általános állapotát figyeli, a probléma észrevétlen maradhat.
Mit kellene ellenőrizni?
A megfelelő monitoring több szinten működik.
1. Infrastruktúraszintű monitoring
- Fizikai szerverek állapota.
- CPU- és memóriahasználat.
- Háttértárak és RAID-állapot.
- Hálózati kapcsolatok.
- Virtuális gépek állapota.
2. Szolgáltatásszintű monitoring
- Adatbázis-szolgáltatások.
- Webszolgáltatások.
- DNS és DHCP.
- Hitelesítési szolgáltatások.
- Levelezési szolgáltatások.
- Mentési feladatok.
3. Alkalmazásszintű monitoring
- Alkalmazások válaszideje.
- Bejelentkezési folyamatok.
- Adatbázis-lekérdezések.
- Kritikus alkalmazásfunkciók.
- API-végpontok.
4. Üzleti folyamatok ellenőrzése
- Sikeresen létrehozható-e egy rendelés?
- Működik-e a számlakiállítás?
- Végrehajtható-e egy foglalás?
- Elérhető-e a vállalat kritikus ügyviteli folyamata?
A legmagasabb szinten már nem egyszerűen azt ellenőrizzük, hogy működik-e a technológia.
Azt ellenőrizzük, hogy a technológia képes-e kiszolgálni az üzleti működést.
Kapcsolódó cikk:
Miért fontos a folyamatos szerver- és hálózati monitoring?
5. Mi a különbség a rendelkezésre állás, a redundancia és az adatmentés között?
Ez az egyik leggyakoribb félreértés a vállalati informatikában.
A három fogalom szorosan összefügg, de teljesen eltérő célt szolgál.
Rendelkezésre állás
Azt fejezi ki, hogy a rendszer vagy szolgáltatás mennyire használható a meghatározott időszakban.
Redundancia
Olyan tartalék komponensek vagy működési útvonalak alkalmazását jelenti, amelyek meghibásodás esetén átvehetik az elsődleges komponens szerepét.
Például:
- Két hálózati kapcsolat.
- Redundáns tápegységek.
- Több fizikai virtualizációs szerver.
- Több hálózati útvonal.
- Redundáns tárolási megoldás.
Adatmentés
Az adatok olyan másolatának elkészítése és megőrzése, amelyből szükség esetén visszaállítás végezhető.
Az adatmentés elsősorban az adatvesztés és a helyreállíthatatlanság kockázatát kezeli.
Miért nem helyettesítik egymást?
| Megoldás | Elsődleges cél | Mit nem garantál? |
|---|---|---|
| Monitoring | Hibák és rendellenességek felismerése | A hibák automatikus elhárítását |
| Redundancia | Komponenshiba hatásának csökkentése | Védelmet minden logikai hiba vagy adatvesztés ellen |
| Adatmentés | Adatok visszaállíthatósága | Folyamatos szolgáltatásműködést |
| Magas rendelkezésre állású architektúra | Kiesések csökkentése | Teljes hibamentességet |
| Katasztrófa-helyreállítás | Szolgáltatások helyreállítása súlyos incidens után | Azonnali, kiesés nélküli működést |
Példa: miért nem adatmentés a RAID?
Egy RAID1 tömbben két meghajtó tükrözheti egymás tartalmát.
Ha az egyik meghajtó meghibásodik, a rendszer megfelelő körülmények között tovább működhet.
Ez növelheti a tárolórendszer rendelkezésre állását.
Ha azonban egy felhasználó véletlenül töröl egy fontos fájlt, a törlés a tükrözött adatokon is érvényesül.
Ugyanez igaz lehet egy zsarolóvírus által végrehajtott titkosításra is.
A RAID nem helyettesíti az adatmentést.
Példa: miért nem jelent teljes biztonságot a virtualizációs HA?
Egy Proxmox VE környezetben megfelelően kialakított magas rendelkezésre állású konfiguráció esetén egy virtuális gép meghibásodott fizikai csomópont után másik csomóponton újraindítható.
Ez csökkentheti a fizikai szerver meghibásodásából eredő kiesést.
De önmagában nem garantálja, hogy:
- Az alkalmazás hibamentesen működik.
- Az adatbázis sértetlen.
- A közös tároló elérhető.
- A hálózat megfelelően működik.
- A virtuális gép megszakítás nélkül üzemel tovább.
A HA által végrehajtott újraindítás kieséssel járhat.
A rendelkezésre állást ezért mindig a teljes infrastruktúra és az alkalmazások összefüggésében kell vizsgálni.
6. Mennyibe kerül egy óra informatikai leállás?
A rendelkezésre állás üzleti jelentőségét legkönnyebben konkrét számításokkal lehet bemutatni.
Fontos azonban különbséget tenni a kiesés által érintett munkaidő értéke és a tényleges pénzügyi veszteség között.
A következő példák szemléltető számítások, nem valós SARABEL-ügyféladatok.
1. példa: 30 fős szolgáltatóvállalkozás
Tegyük fel, hogy egy 30 fős vállalkozásnál 20 munkatárs munkáját akadályozza egy központi informatikai rendszer leállása.
A kiesés időtartama két óra.
A munkatársankénti belső munkaidőköltség a példában 6 000 Ft/óra.
Számítás:
20 fő × 2 óra × 6 000 Ft = 240 000 Ft
Ez azt jelenti, hogy a kiesés 240 000 Ft értékű munkaidőt érinthet.
A tényleges veszteség attól függ, hogy a munkatársak tudtak-e más feladatot végezni, illetve az elmaradt munkát később pótolni kellett-e.
2. példa: 50 fős kereskedelmi vállalat
Egy 50 fős vállalkozásnál 35 munkatárs használja a központi ERP-rendszert.
A rendszer három órára elérhetetlenné válik.
A szemléltető belső munkaidőköltség 7 000 Ft/óra.
Számítás:
35 fő × 3 óra × 7 000 Ft = 735 000 Ft
A kiesés tehát 735 000 Ft értékű munkaidőt érinthet.
Ehhez további üzleti következmények társulhatnak:
- Késedelmes rendelésfeldolgozás.
- Elmaradó kiszállítások.
- Ügyfélpanaszok.
- Sürgősségi helyreállítás.
- Túlmunka.
- Esetleges szerződéses kötbérek.
Ezeket külön kell értékelni, és nem szabad automatikusan hozzáadni a munkaidőköltséghez, ha ugyanazt a veszteséget már tartalmazzák.
3. példa: 100 fős vállalkozás
Egy 100 fős vállalatnál 60 munkatárs munkáját akadályozza egy négyórás informatikai leállás.
A példában alkalmazott munkaidőköltség 7 500 Ft/óra.
Számítás:
60 fő × 4 óra × 7 500 Ft = 1 800 000 Ft
Ez már jelentős összeg.
Ugyanakkor továbbra sem állítható, hogy minden ilyen esemény pontosan 1,8 millió forint pénzügyi veszteséget okoz.
A számítás az érintett munkaidő értékét mutatja, amelyet a vállalkozás tényleges működési adataival kell pontosítani.
Összehasonlítás
| Vállalkozás | Érintett munkatársak | Kiesés | Feltételezett óraköltség | Érintett munkaidőköltség |
|---|---|---|---|---|
| 30 fős vállalat | 20 fő | 2 óra | 6 000 Ft | 240 000 Ft |
| 50 fős vállalat | 35 fő | 3 óra | 7 000 Ft | 735 000 Ft |
| 100 fős vállalat | 60 fő | 4 óra | 7 500 Ft | 1 800 000 Ft |
A következtetés nem az, hogy minden informatikai leállás ekkora veszteséget okoz.
Hanem az, hogy a rendelkezésre állásnak mérhető üzleti jelentősége van, amelyet érdemes figyelembe venni az informatikai költségvetés tervezésekor.
7. Hogyan növelhető a vállalati informatikai rendszerek rendelkezésre állása?
A magasabb rendelkezésre állás nem egyetlen eszköz vagy szoftver megvásárlásával érhető el.
Több, egymásra épülő műszaki és szervezési intézkedésre van szükség.
1. Kritikus rendszerek azonosítása
Elsőként meg kell határozni, mely rendszerek nélkül nem tud megfelelően működni a vállalkozás.
Nem feltétlenül szükséges minden munkaállomást és minden alkalmazást ugyanolyan magas rendelkezésre állási szinten üzemeltetni.
2. Folyamatos monitoring
A kritikus infrastruktúra, szolgáltatások és alkalmazások megfelelő felügyelete lehetővé teszi bizonyos hibák korábbi felismerését.
A monitoringnak azonban riasztási és beavatkozási folyamattal is rendelkeznie kell.
3. Redundáns infrastruktúra
A kritikus komponenseknél indokolt lehet tartalék kapacitást kialakítani.
Például:
- Több virtualizációs csomópont.
- Redundáns hálózati kapcsolatok.
- Tartalék internetkapcsolat.
- Redundáns tápegységek.
- Megfelelően kialakított tárolórendszer.
- Tartalék hálózati eszközök.
A redundancia kialakításánál figyelni kell a közös hibapontokra is.
Két szerver például nem jelent teljes redundanciát, ha mindkettő ugyanattól az egyetlen hibásodásra hajlamos tárolótól vagy hálózati eszköztől függ.
4. Megfelelő szünetmentes áramellátás
Egy UPS képes lehet áthidalni rövidebb áramkimaradásokat, illetve időt biztosítani a rendszerek szabályos leállítására.
Az UPS azonban nem jelent korlátlan üzemidőt.
Figyelembe kell venni:
- A tényleges fogyasztást.
- Az akkumulátorok állapotát.
- A várható áthidalási időt.
- A hálózati eszközök áramellátását.
- A szerverek szabályos leállításának folyamatát.
Hosszabb áramkimaradások esetére további intézkedések lehetnek szükségesek.
5. Rendszeres frissítés és megelőző karbantartás
Az elavult operációs rendszerek, firmware-ek és alkalmazások növelhetik a működési és biztonsági kockázatokat.
A frissítéseket azonban tervezetten, megfelelő teszteléssel és visszaállítási lehetőséggel kell végrehajtani.
Egy rosszul időzített vagy hibás frissítés önmagában is leállást okozhat.
6. Adatmentés és visszaállítási tesztek
A mentési rendszer csak akkor nyújt megfelelő védelmet, ha az adatok ténylegesen visszaállíthatók.
A vállalkozásnak ismernie kell:
- Az elfogadható adatvesztési időt.
- Az elvárt helyreállítási időt.
- A mentések tárolási helyét.
- A helyreállításhoz szükséges erőforrásokat.
- A próbavisszaállítások eredményeit.
Kapcsolódó cikk:
Mi az a 3-2-1 mentési stratégia, és miért életmentő a vállalkozások számára?
7. Dokumentált helyreállítási terv
Egy informatikai incidens során nem elegendő tudni, hogy létezik adatmentés.
Azt is tudni kell, hogy:
- Ki jogosult dönteni a helyreállításról?
- Ki hajtja végre a szükséges lépéseket?
- Milyen sorrendben indulnak újra a rendszerek?
- Mely szolgáltatások élveznek elsőbbséget?
- Hogyan történik a munkatársak tájékoztatása?
- Mikor tekinthető sikeresnek a helyreállítás?
A dokumentált, rendszeresen felülvizsgált eljárások csökkenthetik az incidensek során jelentkező bizonytalanságot.
8. Mit jelent valójában az SLA-ban vállalt rendelkezésre állás?
Az SLA – Service Level Agreement – a szolgáltató és az ügyfél között meghatározott szolgáltatási szinteket rögzíti.
Egy SLA tartalmazhat például:
- Rendelkezésre állási célértéket.
- Hibabejelentési csatornákat.
- Reakcióidőket.
- Helyreállítási célokat.
- Támogatási időablakokat.
- Karbantartási feltételeket.
- Kizárásokat.
- Riportolási kötelezettségeket.
- Szolgáltatási jóváírásokat.
A reakcióidő nem egyenlő a helyreállítási idővel
Tegyük fel, hogy egy szolgáltató kétórás reakcióidőt vállal.
Ez jellemzően azt jelenti, hogy a megfelelő prioritású hibabejelentés kezelését két órán belül megkezdi.
Nem feltétlenül jelenti azt, hogy a hibát két órán belül meg is szünteti.
A helyreállítás időtartama függhet a hiba jellegétől, a rendelkezésre álló alkatrészektől, a külső szolgáltatóktól és a helyreállítási folyamat összetettségétől.
Mire figyeljen a vállalkozás az SLA-ban?
Különösen fontos tisztázni:
- Pontosan mely szolgáltatásokra vonatkozik a vállalás?
- Milyen időszakban mérik a rendelkezésre állást?
- Mi számít kiesésnek?
- Hogyan történik a kiesés mérése?
- A tervezett karbantartások beleszámítanak-e?
- Milyen eseményeket zárnak ki?
- Milyen kötelezettség terheli a szolgáltatót a célérték elmaradása esetén?
- Hogyan ellenőrizheti az ügyfél a teljesítést?
Egy 99,9%-os rendelkezésre állási vállalás önmagában nem elegendő információ.
A százalék mellett a mérési módszer és a szerződéses feltételek is meghatározók.
9. Miért nem garantálható a 100%-os rendelkezésre állás?
Elméletben minden vállalkozás azt szeretné, hogy informatikai rendszerei soha ne álljanak le.
A gyakorlatban azonban minden informatikai rendszer rendelkezik kockázatokkal.
Ilyenek lehetnek:
- Hardverhibák.
- Szoftverhibák.
- Hálózati meghibásodások.
- Áramellátási problémák.
- Külső szolgáltatói kiesések.
- Hibás konfigurációk.
- Emberi mulasztások.
- Kibertámadások.
- Előre nem látható események.
A redundancia, a monitoring és a megfelelő üzemeltetési folyamatok csökkenthetik a kiesések valószínűségét vagy időtartamát.
A teljes kockázatot azonban nem szüntetik meg.
A rendkívül magas rendelkezésre állási szintek elérése ráadásul jelentős többletberuházást igényelhet.
Ezért minden vállalkozásnak mérlegelnie kell:
Mennyibe kerül a magasabb rendelkezésre állás biztosítása, és mekkora üzleti veszteséget előzhet meg?
Nem minden rendszerhez szükséges öt kilences rendelkezésre állás.
De az üzletkritikus rendszereknél a megfelelő rendelkezésre állási szint hiánya komoly kockázatot jelenthet.
10. Hogyan határozza meg vállalkozása a megfelelő rendelkezésre állási szintet?
A döntést célszerű üzleti hatáselemzéssel – Business Impact Analysis, BIA – kezdeni.
Ennek során a vállalkozás megvizsgálja, milyen következményekkel járna az egyes kritikus rendszerek kiesése.
Első lépés: az üzletkritikus folyamatok azonosítása
Mely tevékenységek nélkül nem működhet megfelelően a vállalkozás?
Például:
- Megrendelések feldolgozása.
- Számlázás.
- Termelés.
- Ügyfélkiszolgálás.
- Foglalások kezelése.
- Vállalati kommunikáció.
Második lépés: a rendszerek hozzárendelése
Mely informatikai szolgáltatások szükségesek ezekhez a folyamatokhoz?
Harmadik lépés: a kiesés hatásának meghatározása
Milyen következményekkel járna:
- 15 perc kiesés?
- 1 óra kiesés?
- 4 óra kiesés?
- 1 teljes munkanap kiesés?
Negyedik lépés: helyreállítási célok meghatározása
Meg kell határozni az elfogadható helyreállítási időt (RTO) és adatvesztési időt (RPO).
Ezeket nem szabad automatikusan azonosítani a rendelkezésre állási százalékkal.
Egy rendszer például rendelkezhet magas éves rendelkezésre állással, miközben egy ritka, súlyos incidensből történő helyreállítása hosszú időt vesz igénybe.
Ötödik lépés: megfelelő műszaki megoldás kiválasztása
Csak az üzleti követelmények ismeretében érdemes dönteni:
- A monitoring mélységéről.
- A redundáns komponensekről.
- A mentési stratégiáról.
- A helyreállítási megoldásokról.
- Az üzemeltetési szolgáltatási szintről.
- A szükséges beruházásokról.
A megfelelő rendelkezésre állás nem a legmagasabb százalék kiválasztását jelenti, hanem az üzleti igényekhez illeszkedő működési biztonság kialakítását.
11. Milyen szerepe van a rendszergazdának és az IT-üzemeltető szolgáltatónak?
Egy rendszergazda vagy IT-üzemeltető szolgáltató feladata nem kizárólag a meghibásodások javítása.
A megfelelő üzemeltetési modellben a rendelkezésre állás támogatása folyamatos tevékenység.
Ide tartozhat:
- A kritikus rendszerek felügyelete.
- A rendellenességek felismerése.
- A megelőző karbantartás.
- A frissítések tervezése.
- A kapacitásigények figyelése.
- Az adatmentések ellenőrzése.
- A dokumentáció naprakészen tartása.
- A helyreállítási folyamatok tesztelése.
- A fejlesztési javaslatok megfogalmazása.
A jó üzemeltetés egyik legfontosabb eredménye sokszor láthatatlan.
A munkatársak dolgoznak.
Az alkalmazások elérhetők.
A rendeléseket feldolgozzák.
Az ügyfelek kiszolgálása folyamatos.
Nem azért, mert az informatikai környezetben soha nem jelentkezik probléma, hanem azért, mert a megfelelően kialakított üzemeltetési folyamatok képesek bizonyos hibákat megelőzni, korán felismerni vagy hatásukat csökkenteni.
A rendszergazdai szolgáltatás értékét ezért nem kizárólag a megoldott hibajegyek számával érdemes mérni.
Kapcsolódó cikk:
Rendszergazda árak 2026–2027: saját informatikus vagy kiszervezett IT-üzemeltetés?
12. SARABEL Informatika: a rendelkezésre állás üzleti kérdés
A SARABEL Informatikánál az informatikai üzemeltetést nem pusztán szerverek és számítógépek karbantartásaként kezeljük.
A cél az, hogy az informatikai infrastruktúra támogassa a vállalkozás mindennapi működését, és a kritikus rendszerekhez kapcsolódó kockázatok megfelelő figyelmet kapjanak.
Egy fejlődő vállalkozás számára különösen fontos, hogy:
- Ismerje kritikus informatikai rendszereit.
- Átlássa az infrastruktúra kockázatait.
- Rendelkezzen megfelelő monitoringgal.
- Legyen dokumentált adatmentési és helyreállítási stratégiája.
- Az üzemeltetési szolgáltatások illeszkedjenek az üzleti igényekhez.
Nem minden vállalkozásnak van szüksége azonos infrastruktúrára vagy azonos rendelkezésre állási szintre.
A megfelelő megoldás meghatározásához azonban először meg kell ismerni a tényleges működési követelményeket.
Tudja, hogy vállalkozása informatikai rendszerei valójában milyen rendelkezésre állást biztosítanak?
Attól, hogy egy szerver működik, még nem biztos, hogy az üzleti folyamatok zavartalanok.
A SARABEL Informatika segít felmérni a kritikus informatikai rendszereket, azonosítani a működési kockázatokat, és meghatározni a vállalkozása számára megfelelő üzemeltetési megoldásokat.
Vegye fel velünk a kapcsolatot, és kérjen személyre szabott ajánlatot!
Gyakran ismételt kérdések (GYIK)
Mit jelent a 99,9%-os rendelkezésre állás?
Folyamatos, 24/7 működéssel és 365 napos évvel számolva a 99,9%-os rendelkezésre állás évente legfeljebb 8 óra 45 perc 36 másodperc kiesésnek felel meg. A tényleges SLA-számítás ettől eltérhet.
Mennyi leállást jelent a 99,99%-os rendelkezésre állás?
365 napos év és folyamatos működés esetén körülbelül 52 perc 34 másodperc éves kiesést.
Mi a különbség a rendelkezésre állás és a monitoring között?
A rendelkezésre állás azt mutatja, hogy a szolgáltatás mennyire használható. A monitoring a rendszerek és szolgáltatások állapotának ellenőrzésére, valamint a problémák felismerésére szolgál.
Ha a szerver működik, akkor az alkalmazás is elérhető?
Nem feltétlenül. Az alkalmazás működését adatbázis-, hálózati, hitelesítési vagy egyéb szolgáltatási hibák is akadályozhatják.
A RAID biztosítja a magas rendelkezésre állást?
A RAID megfelelő kialakítás esetén csökkentheti bizonyos meghajtóhibák hatását, de önmagában nem biztosít teljes körű magas rendelkezésre állást, és nem helyettesíti az adatmentést.
A Proxmox HA megakadályoz minden szerverleállást?
Nem. A Proxmox HA megfelelő konfiguráció esetén képes lehet virtuális gépeket másik csomóponton újraindítani, de ez kieséssel járhat, és nem véd minden alkalmazás-, tároló- vagy hálózati hiba ellen.
Mi a különbség az SLA és az RTO között?
Az SLA szerződésben rögzített szolgáltatási szinteket határoz meg. Az RTO azt a célidőt jelöli, amelyen belül egy adott szolgáltatást helyre kell állítani egy kiesés után.
Miért nem garantálható a 100%-os rendelkezésre állás?
Mert minden informatikai rendszer ki van téve műszaki, szoftveres, hálózati, emberi és külső szolgáltatói kockázatoknak. Ezek csökkenthetők, de teljesen nem szüntethetők meg.
Milyen rendelkezésre állásra van szüksége egy 50 fős vállalkozásnak?
Ez nem kizárólag a létszámtól függ. A kritikus üzleti folyamatok, a kiesések következményei és a vállalkozás helyreállítási követelményei alapján kell meghatározni.
Hogyan lehet mérni egy vállalkozás informatikai rendelkezésre állását?
A kritikus szolgáltatásokhoz megfelelő monitoringot, egyértelmű mérési szabályokat és rendszeres riportolást kell kialakítani. Az infrastruktúra állapotának figyelése mellett célszerű a felhasználók számára fontos alkalmazásfunkciókat is ellenőrizni.
Összegzés
A rendelkezésre állás nem egyenlő azzal, hogy a szerver bekapcsolt állapotban van.
Nem egyenlő a monitoringrendszer zöld jelzésével.
És nem garantálható pusztán redundáns hardverek vagy rendszeres adatmentések alkalmazásával sem.
A valódi rendelkezésre állás azt jelenti, hogy a vállalkozás számára kritikus informatikai szolgáltatások a meghatározott üzleti követelményeknek megfelelően használhatók.
Ehhez megfelelő infrastruktúra, monitoring, karbantartás, adatmentés, helyreállítási tervezés és dokumentált üzemeltetési folyamatok szükségesek.
A legfontosabb kérdés tehát nem az, hogy működik-e a szerver.
Hanem az, hogy a vállalkozás képes-e zavartalanul működni akkor, amikor az informatikára a legnagyobb szüksége van.
Szakmai források és további olvasmányok
-
NIST – SP 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations
https://csrc.nist.gov/pubs/sp/800/137/final -
NIST – SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final -
NIST – Cybersecurity Framework 2.0
https://www.nist.gov/cyberframework -
Proxmox VE – High Availability
https://pve.proxmox.com/wiki/High_Availability -
Zabbix – Hivatalos dokumentáció
https://www.zabbix.com/documentation/current/en/manual -
Microsoft Learn – Azure Well-Architected Framework: Reliability
https://learn.microsoft.com/en-us/azure/well-architected/reliability/ -
Google Cloud – Site Reliability Engineering
https://sre.google/sre-book/table-of-contents/