Hogyan stabilizáljunk örökölt infrastruktúrát?

A hétfő reggeli indításnál egy régi szerver ismét nem válaszol. A raktár nem látja a rendeléseket, a számlázás vár, az ügyfélszolgálat pedig telefonon próbálja összerakni, mi történt. Ilyenkor a kérdés nem az, hogy régi-e a rendszer, hanem az, hogyan stabilizáljunk örökölt infrastruktúrát úgy, hogy közben az üzlet ne álljon meg, és ne egy újabb sürgősségi javítás legyen az egyetlen válasz.

Egy örökölt infrastruktúra gyakran évek alatt vált kritikussá. Egy korábbi alkalmazás csak egy adott szerveren fut, a hálózat bővítései dokumentálatlanok, a mentés létezik, de visszaállítást rég nem teszteltek. Közben a vállalat növekedett: több rendelés, több felhasználó, több integráció és nagyobb elvárás került ugyanarra a technikai alapra.

A stabilizálás nem egyenlő azzal, hogy mindent azonnal le kell cserélni. Sok esetben a teljes csere teremti a legnagyobb üzleti kockázatot. A cél először az, hogy az alapvető működés kiszámíthatóvá, ellenőrizhetővé és helyreállíthatóvá váljon. Csak ezután lehet felelősen dönteni a modernizáció üteméről.

Hogyan stabilizáljunk örökölt infrastruktúrát üzleti szemmel?

A kiindulópont nem a szerverek listája, hanem a kritikus üzleti folyamatok feltérképezése. Mely rendszerek nélkül nem lehet rendelést fogadni, termelést indítani, árut kiadni, számlázni vagy ügyfelet kiszolgálni? Mennyi ideig tolerálható egy kiesés az egyes területeken? Egy kétórás riportkésés lehet kellemetlen, de egy kétórás raktári leállás már közvetlen árbevétel- és bizalomveszteséget okozhat.

Ez a különbség határozza meg a prioritásokat. Gyakori hiba, hogy a technikai csapat azzal kezd, ami a legrégebbi vagy a legnehezebben kezelhető. Üzleti szempontból azonban előbb azt kell védeni, amelynek hibája a legnagyobb működési következménnyel jár.

Ne csak rendszereket, függőségeket is térképezzen fel

Egy üzleti alkalmazás ritkán önmagában hibásodik meg. Függhet adatbázistól, fájlszervertől, hálózati kapcsolattól, licenckiszolgálótól, külső partneri kapcsolattól vagy egyetlen, már nem támogatott kliensgéptől. A webshop működhet, de ha nem jut át a készletinformáció az ERP-be, az értékesítés és a raktár eltérő valóságból dolgozik.

A felmérésnek ezért azt is meg kell mutatnia, hol vannak rejtett egyedi megoldások. Például egy automatikusnak hitt adatátadást valójában egy kolléga indít el minden reggel. Vagy egy régi alkalmazás csak azért működik, mert valaki tudja, melyik szolgáltatást kell újraindítani. Ezek nem egyszerű IT-kockázatok, hanem személyfüggő üzemi kockázatok.

Érdemes minden kritikus szolgáltatásnál rögzíteni, mi a szerepe, hol fut, milyen adatokkal dolgozik, mihez kapcsolódik, ki felel érte, és mi történik a kiesésekor. Nem kell hónapokig tartó dokumentációs projektet indítani. De a döntésekhez szükség van egy valós, közösen elfogadott képre a jelenlegi állapotról.

Először a működési kontrollt állítsa helyre

A stabil infrastruktúra nem azt jelenti, hogy soha nem hibásodik meg semmi. Azt jelenti, hogy a hibákat időben észlelik, a hatásuk korlátozható, és a helyreállítás nem improvizációból áll.

Ennek első eleme a megfigyelhetőség. Ha a tárhely, memória, hálózati kapcsolat, szolgáltatásállapot vagy mentési folyamat csak akkor válik láthatóvá, amikor már panasz érkezik, akkor a cég folyamatosan késésben van. A megfelelő monitorozás nem technikai díszlet. Segít megkülönböztetni a lassuló, telítődő rendszert a váratlan meghibásodástól, és alapot ad a kapacitástervezéshez.

A második elem a változáskezelés. Sok örökölt környezetet nem egy nagy hiba tesz törékennyé, hanem sok apró, nyomon nem követett módosítás. Új felhasználó, kézzel megváltoztatott jogosultság, sürgős frissítés, ideiglenes tűzfalszabály, majd egy elfelejtett kivétel. Ha nem egyértelmű, mi változott, ki hagyta jóvá és hogyan lehet visszaállni, akkor minden beavatkozás kockázatot növel.

A harmadik elem a hozzáférések rendbetétele. Az általános adminisztrátori fiókok, megosztott jelszavak és korábbi munkatársak aktív jogosultságai egyszerre biztonsági és üzemeltetési problémák. Egy hiba kivizsgálásakor azt sem lehet megállapítani, ki mit tett. A jogosultságoknak munkakörhöz és felelősséghez kell kapcsolódniuk, a kritikus hozzáféréseket pedig rendszeresen felül kell vizsgálni.

A mentés csak akkor értékes, ha vissza is állítható

Sok szervezet megnyugszik attól, hogy a mentés naponta lefut. Ez kevés. A valódi kérdések mások: sértetlen-e a mentés, elkülönül-e az éles környezettől, mennyi adat veszne el egy visszaállításkor, és mennyi idő alatt indulhat újra a kritikus folyamat?

Egy gyártó vagy kereskedő vállalat számára nem mindegy, hogy egy adatbázis visszaállítása három órát vagy három napot vesz igénybe. Az sem, hogy a visszaállított rendszerhez kapcsolódó integrációk, jogosultságok és fájlmegosztások működnek-e. A mentési tervet ezért nem adminisztratív megfelelésként, hanem üzletmenet-folytonossági eszközként kell kezelni.

A rendszeres visszaállítási próba általában gyorsan felszínre hozza a rejtett hiányokat: hiányzó titkosítási kulcsot, nem dokumentált konfigurációt, elfogyott tárhelyet vagy olyan függőséget, amelyről senki sem tudott. Ez kellemetlen felfedezés, de kontrollált helyzetben sokkal olcsóbb, mint egy éles incidens közben.

Ne a teljes cserét tegye meg első projektnek

Az örökölt infrastruktúra modernizációjánál a „cseréljünk le mindent” sokszor érthető reakció, de ritkán jó első lépés. Egy nagy átállás egyszerre érinti az alkalmazásokat, adatokat, integrációkat, felhasználói szokásokat és üzemi folyamatokat. Ha ezek nincsenek feltárva, a projekt csak áthelyezi a bizonytalanságot egy új platformra.

A fokozatos megközelítés jellemzően kisebb kockázatot jelent. Előbb leválasztható vagy védhető a legkritikusabb komponens, rendezhető a mentés és a hozzáférés, dokumentálható a konfiguráció, majd külön ütemben modernizálhatók az elavult elemek. Ez lehet szervervirtualizáció, hálózati szegmentálás, támogatott operációs rendszerre költözés, felhős szolgáltatás bevezetése vagy egy alkalmazás kiváltása. A megfelelő út attól függ, milyen üzleti folyamatot szolgál az adott elem, és mennyire kötődik más rendszerekhez.

Van, amikor egy régi, de stabil alkalmazás megtartása indokolt, mert a cseréje túl nagy folyamatváltozást okozna. Ilyenkor a környezetét kell biztonságosabbá tenni, a kapcsolatait szabályozni, és elkészíteni a kiváltás későbbi tervét. Máskor éppen egy régi rendszerhez készített ideiglenes interfész vagy kézi export jelent nagyobb kockázatot, mint maga az alkalmazás.

A technikai stabilitás emberi felelősség is

Ha csak egy ember tudja, hogyan indul újra a vállalati rendszer, akkor nincs stabil üzemeltetés. Ha a pénzügy saját táblázatban korrigálja az adatokat, mert nem bízik a központi rendszerben, akkor az infrastruktúra problémája már a döntéstámogatást is érinti. A technikai bizonytalanság hamar kézi kerülőutakat, párhuzamos nyilvántartásokat és frusztrációt hoz létre.

Ezért a stabilizálás része az egyszerű, használható üzemeltetési rend: ki fogadja a riasztást, ki dönt incidens esetén, hol van a dokumentáció, hogyan történik az eszkaláció, és mikor vizsgálják felül a kockázatokat. Nem minden cégnek kell 24 órás belső ügyelet vagy összetett vállalati szabályrendszer. De minden kritikus működéshez kell kijelölt felelősség és egy kipróbált eljárás.

A jó stabilizálási program végén nem feltétlenül látványosan új a technológia. Inkább csendesebb az üzem: kevesebb a váratlan leállás, gyorsabb a hibaelhárítás, megbízhatóbbak az adatok, és nem egyetlen kolléga emlékezetén múlik a működés. Innen már nem kényszerből, hanem terv szerint lehet fejleszteni.