
Egy kritikus üzleti rendszer leállásakor sok esetben nem triviális, hogy mi okozta a problémát, ki a felelős az elhárításért, és, hogy ez meddig tart. Nézzük meg egy tipikus példán keresztül, hogyan is zajlik ez!
Eszkalálódik a helyzet
Hétfő reggel egy országos nagykereskedő vállalat raktárában a műszak már teljes fordulatszámon dolgozik. A targoncák sorban állnak a rakodókapuk előtt, a futárcégek autói perceken belül érkeznek, az ügyfélszolgálat pedig folyamatosan fogadja a rendeléseket. Ekkor váratlanul eltűnik a kapcsolat a vállalat központi ERP-rendszerével.
Elsőre senki sem pánikol. Valószínűleg csak egy átmeneti hálózati hiba – jön az értesítés az IT-tól. Tíz perc múlva azonban már a raktári terminálok sem működnek. Az értékesítők nem látják a készleteket, a pénzügy nem tud számlát kiállítani, a beszerzés nem tud rendelést indítani. Az ügyfelek közben egyre türelmetlenebbek, a vezetők pedig egymás után hívják az informatikusokat: mikor lesz kész?
Az üzemeltetési csapat lázasan keresi a hibát. Egy hálózati eszköz meghibásodása? Egy félresikerült frissítés? Egy felhőszolgáltatás kimaradása? Esetleg zsarolóvírus? A probléma valódi oka ekkor még senki számára nem ismert, de az üzleti veszteség percről percre nő.
Fél órával később sem az a legnagyobb kérdés, hogy melyik szerver állt le. Sokkal inkább az, hogy ki vezeti az incidens kezelését, ki hozza a döntéseket, mi a hiteles információ és arról hogyan értesül a vezetés. Ugyanaz a technikai hiba egy felkészült szervezetnél néhány órás fennakadást okozhat, egy rosszul szervezett vállalatnál viszont teljes üzleti válsággá nőheti ki magát.
Ki a felelős az első percekben?
Az incidens kipattanásakor a legfontosabb feladat az irányítás fel/átvétele. Gyakran több rendszergazda egyszerre próbálja felderíteni a problémát, különböző vezetők egymástól kérnek információkat, az üzleti területek pedig saját csatornáikon próbálnak választ kapni arra, mikor áll helyre a szolgáltatás. Mindenki dolgozik, mégis hiányzik az összehangolt irányítás.
Ezen segít, ha már előre kijelölt az incidensvezető (Incident Manager). Személyében nem feltétlenül a legjobb technikai szakembert kapja a válság kezelése; a feladata sokkal inkább az, hogy koordinálja a résztvevőket, meghatározza a prioritásokat, biztosítsa az információáramlást, és folyamatosan tájékoztassa az üzleti vezetést. Ezzel párhuzamosan a műszaki szakértők kizárólag a hiba feltárására koncentrálhatnak.
Az incidenskezelés ugyanis akkor működik hatékonyan, ha a szerepkörök és felelősségi körök már az incidens bekövetkezése előtt egyértelműen meg vannak határozva. Az incidenskezelést a szervezeti kockázatkezelés részének kell tekinteni, amelyben a vezetői döntések legalább akkora jelentőséggel bírnak, mint a technikai beavatkozások.
Persze az sem mindegy, hogy van-e, aki átlátja a szervezet működési környezetét. Hiszen egyetlen szolgáltatás mögött gyakran több tucat komponens (például helyi szerverek, felhőszolgáltatások, identitáskezelés, hálózati eszközök, API-k, adatbázisok) működik együtt. Ha ezek kapcsolatait senki sem látja át teljes egészében, a hiba forrásának megtalálása jelentősen lelassul. Az incidens ekkor technikai és tudásmenedzsment-problémává is válik. Vagyis minél pontosabban ismeri egy szervezet saját működését, annál gyorsabban képes meghatározni, hogy egy látszólag egyszerű hiba valójában mely üzleti folyamatokat érinti.
Mi az információ és mi a zaj?
Incidens közben a vezetőknek ritkán van szükségük részletes technikai magyarázatokra. Sokkal fontosabb számukra, hogy mely szolgáltatások érintettek, milyen üzleti következmények várhatók, mekkora a becsült helyreállítási idő, és szükség van-e ügyfélkommunikációra vagy rendkívüli üzleti intézkedésekre.
Ez csak akkor működik, ha a technikai és az üzleti kommunikáció szétválik. A rendszermérnökök egymás között továbbra is részletes naplókat, hibakódokat és diagnosztikai adatokat elemeznek, míg a vezetők strukturált helyzetjelentéseket kapnak. A két kommunikációs szint közötti kapcsolatot általában az incidensvezető biztosítja.
A gyakorlatban sokkal nagyobb problémát okoz a bizonytalanság, mint maga a rossz hír. Egy vezető könnyebben tud döntést hozni akkor is, ha azt az információt kapja, hogy a helyreállítás várhatóan négy órát vesz igénybe, mint akkor, ha félóránként eltérő becslések érkeznek. A rendszeres, előre meghatározott időközönként kiadott státuszjelentések ezért önmagukban is csökkentik az üzleti károkat.
Hamar munka ritkán jó
A túlzott sietség könnyen újabb problémákat okozhat. Egy elhamarkodott újraindítás, egy visszaállított mentés vagy egy konfigurációs módosítás akár meg is semmisítheti azokat a nyomokat, amelyekből később kiderülhetne a hiba valódi oka. A hatékony incidenskezelés ezért előre definiált eljárásokat követ. Ismert, hogy mikor kell izolálni egy rendszert, mikor indokolt a szolgáltatás leállítása, mikor lehet visszaállítani egy mentést, és milyen feltételek teljesülése után tekinthető lezártnak a helyreállítás. Ezeket a folyamatokat rendszeresen tesztelni is kell, hiszen egy vészhelyzetben már nincs idő új módszereket kidolgozni.
A legsikeresebb incidenskezelések közös jellemzője, hogy valójában már jóval a hiba bekövetkezése előtt elkezdődtek. A naprakész dokumentáció, a rendszeresen frissített üzemeltetési leírások, a jól definiált felelősségi körök és a begyakorolt eljárások jelentősen lerövidítik a döntési időt.
Ugyanilyen fontos a megfelelő szakértői háttér. Egy modern vállalati környezetben gyakran több szolgáltató, felhőplatform és külső partner működik együtt. Ha előre tisztázott, hogy milyen incidens esetén kit kell bevonni, milyen szolgáltatási szintek (SLA) érvényesek, és milyen kommunikációs csatornákat kell használni, a helyreállítás sokkal kiszámíthatóbbá válik.
Az incidenskezelési útmutatók (mint például a CREST Cybersecurity Incident Management Guide-ja) gyakran külön kiemelik, hogy minden fontos döntést, végrehajtott műveletet és kommunikációs lépést dokumentálni kell. Az utólagos elemzés támogatása mellett azért is szükség van erre, mert egy elhúzódó incidens során több műszak, több csapat és több külső partner is bekapcsolódhat a munkába. A részletes eseménynapló biztosítja, hogy minden résztvevő ugyanabból az információból dolgozzon, ami végső soron megkönnyíti és felgyorsítja a kialakult helyzet sikeres lezárását.

Ez a cikk független szerkesztőségi tartalom, mely a One Solutions támogatásával készült. Részletek »
Projektek O-gyűrűje. Mit tanulhat egy projektvezető a Challenger tragédiájából?