Van egy kérdés, amit szinte soha nem tesz fel senki egy cégnél, pedig a válasz sokszor sokkolóbb, mint egy komolyabb biztonsági incidens költsége: mennyi munkaidő megy el havonta olyan IT-problémákra, amik rendszeresen előfordulnak?
A legtöbb szervezetben az IT-hibákat egyenként, egymástól elszigetelten kezelik. Elromlik valami, valaki megoldja – a rendszergazda, a külsős szolgáltató, néha maga a felhasználó egy egyszerű újraindítással – aztán mindenki továbbmegy a napi teendőire. Ritkán néz vissza bárki, hogy ugyanaz a hiba hányadszor fordul elő, és ha összeadnánk az összes ilyen apró incidenst, mekkora számot kapnánk egy hónap alatt. A válasz legtöbbször meglepően magas.
Most megnézzük, miért marad láthatatlan ez a költség, honnan erednek a leggyakoribb, megelőzhető problémák, és mit jelent a gyakorlatban a proaktív rendszerfelügyelet.
A reaktív IT-működés csendben felemészti az időt
Egy tipikus reaktív IT-modellben a munka ciklikus: hiba jelentkezik, valaki reagál, a probléma látszólag megoldódik, a hibajegy lezárul. Ha egyáltalán volt róla hibajegy, és a szervezeti memória nem tárolja el, hogy ez már a harmadik vagy negyedik alkalom, amikor ugyanaz történik.
Ennek két súlyos következménye van. Minden egyes előfordulás önmagában kicsinek tűnik. Egy tíz perces újraindítás, egy húsz perces jelszó-visszaállítás, egy fél órás nyomtatóhiba-elhárítás nem néz ki drámainak, és senki nem fog emiatt vészhelyzeti értekezletet összehívni. A mikroszintű költségek nem generálnak elég feszültséget ahhoz, hogy bárki foglalkozzon velük, miközben makroszinten, havi összesítésben simán kitehetnek annyi munkaórát, amennyi egy komolyabb infrastruktúra-fejlesztési projektre is elegendő lenne.
A másik következmény, hogy a tünetet kezeljük, az okot legtöbbször nem. Ha egy szerver havonta kétszer fagy le, és mindig csak újraindítjuk, technikailag megoldottuk a problémát – a felhasználó tud tovább dolgozni –, de a mögöttes ok, legyen az memóriaszivárgás, elavult driver, túlterhelt lemez vagy rosszul konfigurált szolgáltatás, érintetlen marad. A hiba nem szűnt meg, csak kitoltuk a legközelebbi jelentkezését.
Honnan erednek a leggyakoribb, megelőzhető problémák?
A tapasztalat – és számos IT-üzemeltetési felmérés is – azt mutatja, hogy a visszatérő incidensek túlnyomó többsége néhány jól beazonosítható forrásra vezethető vissza.
Elavult, karban nem tartott eszközök.
Azok a gépek, szerverek és hálózati eszközök, amikre régóta nem telepítettek frissítést, firmware-frissítést vagy karbantartást, ezek statisztikailag jóval nagyobb eséllyel produkálnak visszatérő hibákat. Egy elavult meghajtóprogram, egy be nem foltozott operációs rendszer vagy egy teleírt lemez nem egyszer okoz gondot, hanem rendszeresen, amíg valaki tényleg nem néz utána a probléma forrásának.
Soha át nem vizsgált rendszerbeállítások.
Sok szervezetnél a szerver- és hálózati konfigurációk évekre visszamenőleg érintetlenek maradnak. Egy ideiglenesnek szánt beállítás – például egy megnövelt jogosultsági kör, egy ideiglenes tűzfal kivétel vagy egy rosszul méretezett erőforrás-limit – állandósul, és évekkel később még mindig az okozza a lassulásokat vagy a hozzáférési anomáliákat, csak akkor már senki nem emlékszik rá, miért is van ott.
A legritkábban vizsgált kategória a már korábban is előfordult, de sosem kivizsgált hiba.
Ide tartozik minden olyan incidens, ami már másodszor, harmadszor vagy tizedszer jelentkezik, de mivel mindig sikerült gyorsan eltüntetni, soha nem jutott el odáig, hogy valaki megnézze, mi áll a háttérben. Ezek a problémák jellemzően nem véletlenszerűen térnek vissza. Van egy konkrét trigger, egy időzített feladat, egy terhelési csúcs, egy adott felhasználói művelet, amit csak akkor lehet azonosítani, ha az egyedi eseteket mintázatként kezeljük, nem elszigetelt hibaként egyenként.
Egy egyszerű becslés, ami sokakat meglep
Próbáljuk meg konkrétan megbecsülni. Vegyünk egy közepes méretű szervezetet, mondjuk 50 munkaállomással és néhány szerverrel.
Heti 3-4 apró, ismétlődő incidens, pl. lassú gép, nyomtatási hiba, VPN-kapcsolati probléma, jelszó-visszaállítás, átlagosan 15-20 perc elhárítási idővel havonta kb. 4-5 órát tesz ki. Ehhez jön havonta 1-2 nagyobb, visszatérő rendszerhiba: szerver újraindítás, adatbázis-lassulás, tárhely-telítettség, ami 1-2 órát vesz igénybe minden alkalommal, plusz a felhasználói leállás miatti termelékenység-kiesés. Ez önmagában újabb 4-6 óra közvetlen munkaidő havonta, és ennek gyakran a többszöröse közvetett veszteségként jelentkezik a dolgozók várakozása és kontextusváltása miatt.
Az ismétlődő biztonsági riasztások vagy figyelmen kívül hagyott naplóbejegyzések nehezen számszerűsíthetők, de tapasztalat szerint pont ezek okozzák a legdrágább, egyszeri nagy incidenseket, amikor a sok kis jel végül egy komolyabb leállásba vagy biztonsági eseménybe torkollik.
Ezeket összeadva egy közepes cégnél simán összejöhet havi 10-15 óra olyan munkaidő, ami kizárólag azért merül fel, mert ugyanazok a problémák újra és újra visszatérnek. Ez egy teljes munkanapnál is több, minden hónapban, miközben ez idő alatt egyetlen új funkció, fejlesztés vagy stratégiai IT-feladat sem valósul meg, csak ugyanazok a tüzek oltódnak el ismételten.
Miben más a proaktív, folyamatosan monitorozó üzemeltetés?
A proaktív IT-üzemeltetés lényege nem az, hogy gyorsabban reagál a hibákra, bár általában az is igaz. A lényeg inkább az, hogy másképp gondolkodik a hibákról. Három konkrét pontban tér el a reaktív modelltől.
Folyamatos a monitorozás, eseti ellenőrzés helyett.
A rendszerek állapotát – lemezterhelés, memóriahasználat, szolgáltatás-elérhetőség, biztonsági napló – folyamatosan figyelik, nem csak akkor, amikor már panasz érkezik. Így egy lassan növekvő lemezhasználat vagy egy fokozatosan romló szolgáltatás-válaszidő azelőtt kiderül, hogy a felhasználó észrevenné.
Mintázatot keresnek az egyedi esetek mögött.
Amikor egy incidens lezárul, a kérdés az, hogy előfordult-e már korábban, és ha igen, mi a közös bennük. Ez a lépés a legtöbb reaktív működésből teljesen hiányzik, pedig itt derül ki, hogy a „véletlenszerű” hibák valójában egy konkrét, javítható gyökérokra vezethetők vissza.
A karbantartás ütemezett, nem csak baj esetén történik.
A frissítések, a konfiguráció-felülvizsgálatok és a kapacitástervezés előre meghatározott ütemben zajlanak, még azelőtt, hogy bármi elromlana. Ez az, ami a legtöbb elavult gép vagy soha át nem nézett beállítás típusú problémát eleve megszünteti.
A gyakorlati különbség tehát nem az, hogy a proaktív modellben nincsenek hibák, hanem hogy a visszatérő, megelőzhető hibák aránya drasztikusan lecsökken. A felszabaduló idő olyan munkára megy el, ami tényleg előre viszi a céget, nem csak a status quót tartja fenn.
Érdemes megkérdezni magunktól
Ha végigolvastad ezt a cikket, érdemes feltenni a bevezetőben szereplő kérdést a saját szervezetedre vetítve: mennyi idő megy el nálatok havonta olyan hibákra, amik már korábban is előfordultak, de megelőzhetők lennének?
Ha nincs erre pontos adatotok, és tapasztalatunk szerint a legtöbb cégnél nincs ilyen, az önmagában is jelzésértékű.
Az első lépés az, hogy elkezditek nyomon követni: mely incidensek ismétlődnek, milyen gyakran, és mennyi időt vesznek el minden alkalommal. Ha ez az adat egyszer láthatóvá válik, a proaktív működésre való átállás indoklása és az arra fordítandó erőforrás jogosultsága szinte adja magát.
Ha ti sem tudjátok pontosan, mennyi időt visznek el nálatok a visszatérő IT-hibák, szívesen segítünk feltérképezni és kialakítani egy proaktív, monitorozáson alapuló üzemeltetést. Keressetek minket bizalommal.
