Minden nagyobb szervezetben van egy örökölt rendszer, amelyről mindenki tudja, hogy gond, mégsem mer senki hozzányúlni.
Örökölt rendszernek – angolul legacy system-nek – nevezzük azokat az informatikai rendszereket és alkalmazásokat, amelyek elavult technológiákon alapulnak, mégis kritikus szerepet játszanak a szervezet napi működésében. Jellemzően évtizedekkel ezelőtt fejlesztették őket, a modern technológiák rég felülmúlták képességeiket – a vállalatok mégis nap mint nap ezekre támaszkodnak.
A legacy rendszerekkel a fő nehézség az, hogy bár ellátják a funkciójukat, jellemzően senki sem tudja pontosan, mi mindennel van összekötve. Mi fog összeomlani, ha valaki hozzányúl.
Ez a cikk arról szól, hogyan lehet visszaszerezni a láthatóságot a legacy rendszerek felett, mikor érdemes megtartani őket, és mikor érdemes migrálni.
Mi a fő probléma a legacy rendszerekkel?
A legacy rendszer fogalmát sokan az elavult technológiával azonosítják. Egy COBOL-ban írt banki core rendszer, egy 15 éves ERP, egy monolitikus alkalmazás – ezek valóban idejétmúltak, mégis működnek, és sok közülük hibátlanul ellátja a funkcióját.
A probléma tehát nem a technológia kora, hanem az, hogy ezek a rendszerek jellemzően láthatatlanok:
- a dokumentáció hiányos, vagy régen elvált a valóságtól
- az eredeti fejlesztők már nincsenek a cégnél
- az integrációk organikusan nőttek – mindennel össze van kötve, de senki sem tudja pontosan, mivel
- a rendszer fut, ezért senki sem nyúlt hozzá – és senki sem nézte meg belülről
Ez utóbbi a legveszélyesebb állapot. Azért ismeretlen, mert soha senki nem tette láthatóvá.
A klasszikus monitoring eszközök ebben nem segítenek. Megmutatják, hogy a rendszer fut vagy nem fut, azt viszont nem mutatják meg, hogy mi mihez kapcsolódik, mi mitől függ, és egy változtatás milyen láncreakciót indít el.
Ez az a pont, ahol az observability szemlélete más megközelítést kínál. Az observability – vagyis a rendszer teljes körű megfigyelhetősége – nem egyszerűen azt kérdezi: működik-e a rendszer? Azt kérdezi: értjük-e, hogyan működik?
Az observability eszközök – mint a Dynatrace vagy a Datadog – képesek feltérképezni egy legacy rendszer belső összefüggéseit: megmutatják a függőségeket, az integrációs pontokat, a terhelési mintákat és az anomáliákat. Nem azt mutatják meg, hogy a rendszer zöld vagy piros – hanem azt, hogy mi tartja életben, és mi az, amihez biztonságosan hozzá lehet nyúlni.
Mikor nem érdemes migrálni?
A migráció nem mindig a helyes válasz. Három helyzet van, amikor a maradás megalapozottabb döntés.
1. Ha a rendszer stabilan ellátja a funkcióját
Egy 20 éves rendszer, amely megbízhatóan fut, kevés incidensssel és alacsony üzemeltetési költséggel, nem jelent problémát pusztán azért, mert régi. A migráció ilyenkor több kockázatot hoz be, mint amennyit megold.
2. Ha az üzleti folyamat nem változik
Vannak olyan üzleti területek, ahol a követelmények évtizedek óta stabilak. Ha a rendszer pontosan azt csinálja, amit kell, és az üzlet nem igényel változást, a migráció önmagában nem teremt értéket.
3. Ha a láthatóság még hiányzik
Ez a leggyakrabban figyelmen kívül hagyott szempont. Ha még nem értjük, mit csinál a rendszer, mit integrál, mi függ tőle – a migráció vakrepülés. Az observability itt nem a migráció alternatívája, hanem annak előfeltétele.
Mikor válik szükségessé a migráció?
Négy jel mutatja, hogy a változás elkerülhetetlen.
1. Ha a rendszer már nem tartható fenn
Nincs fejlesztő, aki értené. Nincs gyártói támogatás. A szükséges szakértelem a piacon is egyre szűkebb. Egy rendszer, amelyet senki sem tud tovább fejleszteni, időzített bomba.
2. Ha az üzleti igények kinőtték
Az üzlet gyorsabb, rugalmasabb, digitálisabb működést vár – a rendszer ezt nem tudja követni. Ilyenkor a legacy rendszer már nem egyszerűen korlát, hanem versenyhátránnyal jár.
3. Ha a biztonsági kockázat kezelhetetlenné vált
A régi rendszerek jellemzően nem kapnak biztonsági frissítéseket. Ha a rendszer érzékeny adatokat kezel, a NIS2 által előírt kockázatkezelési kötelezettség teljesítése egyre nehezebben igazolható.
4. Ha az üzemeltetési költség már meghaladja a migrációét
A fenntartás sokszor drágább, mint elsőre látszik. Speciális szakértők, egyedi integrációk, folyamatos tűzoltás – ezek összeadódnak. Ha az observability segítségével ez számszerűsíthetővé válik, a döntés üzleti alapon meghozható.
Hogyan válik átláthatóvá a rendszer?
Az observability nem varázspálca – de a legjobb kiindulópont, amit egy CIO vagy IT Operations vezető ma használhat, mielőtt bármilyen döntést hoz egy legacy rendszerről.
A folyamat három lépésben épül fel.
1. Feltérképezés – mi mihez kapcsolódik?
Az első lépés nem a migráció tervezése. Az első lépés a valóság megismerése. Az observability eszközök automatikusan feltérképezik a rendszer függőségeit, integrációs pontjait és kommunikációs mintáit. Megmutatják azt a képet, amelyet a dokumentáció már régen nem tükröz. A modern log observability megoldások ezt legacy és cloud-native környezetben egyaránt lehetővé teszik.
2. Kockázatazonosítás – mi az, amihez nem lehet hozzányúlni?
A feltérképezés után láthatóvá válik, melyek a kritikus pontok. Melyek azok a komponensek, amelyektől a legtöbb folyamat függ. Melyek azok, amelyek egyetlen meghibásodása láncreakciót indít el. Ez az a tudás, ami nélkül a migráció tervezése vak becslés. A kiszámítható IT működés alapja pontosan ez a rálátás.
3. Döntési alap – marad vagy megy?
Amikor a rendszer látható, a döntés üzleti alapon meghozható. Nem félelem vezérli, hanem adat. Az observability megmutatja az üzemeltetési költségeket, a terhelési mintákat, a meghibásodási pontokat – mindazt, ami alapján egy CIO vagy CFO megalapozottan dönthet. A business observability szemlélete ezt a döntési folyamatot köti össze az üzleti valósággal. A felhő modernizációs projekteknél ez különösen kritikus: a migráció csak akkor kontrollált, ha az observability végig jelen van.
Láthatóság nélkül nincs megalapozott döntés
Mikor kerül többe a fenntartás, mint a váltás? Melyik rendszer jelent valódi kockázatot, és melyik csak kényelmetlenséget? Hol érdemes befektetni, és hol elég a status quo?
Ezekre a kérdésekre csak akkor lehet válaszolni, ha a rendszer látható. Ha a döntés mögött adat áll – nem feltételezés, nem félelem, nem halogatás.
Az observability pontosan ezt teszi lehetővé: a kártyavár kártyáit végre nevén lehet nevezni. Melyik kritikus, melyik cserélhető, melyikhez lehet hozzányúlni – és melyikhez nem. Az AIOps megoldások ebben tovább mennek: automatikusan kiszűrik a zajt, és csak arra hívják fel a figyelmet, ami valódi beavatkozást igényel.
A Telvice Zrt. observability szakértői segítenek feltérképezni a meglévő rendszereket, azonosítani a valódi kockázatokat, és üzleti alapon megalapozott migrációs döntést hozni. Kérjen ingyenes konzultációt!
Források:
- Dynatrace – Modernize legacy applications with full-stack observability https://www.dynatrace.com/news/blog/modernize-legacy-applications/
- Dynatrace – How to reduce technical debt with observability https://www.dynatrace.com/news/blog/technical-debt-observability/
- Datadog – Observability for legacy systems https://www.datadoghq.com/knowledge-center/observability/
- XXXLutz esettanulmány – Dynatrace end-to-end observability legacy és modern rendszereken https://www.dynatrace.com/news/customer-stories/xxxlutz/
Dynatrace – State of Observability 2025 https://www.dynatrace.com/info/reports/state-of-observability/
