Szoftverüzemeltetés és -támogatás a bevezetés után

Egy középvállalatnál munkaidőben leáll az üzletileg kritikus rendszer, és kiderül, hogy a fejlesztők a projekt lezárása óta nem érhetők el. Egyetlen óra ilyen váratlan leállás is milliós nagyságrendű közvetlen bevételkiesést okozhat, a gondozatlan kódban közben nyitva maradnak a biztonsági rések, és halad a technológiai avulás. Az átadással a digitális termék üzleti életciklusa kezdődik, és a hosszú távú stabilitás feltétele, hogy ebben az időszakban senior szakemberek üzemeltessék és támogassák a rendszert.

A cikk sorra veszi a támogatási szinteket, a proaktív üzemeltetést, a karbantartás típusait és költségét, az SLA-t, valamint a saját csapat és a kiszervezés közötti döntést, hogy a rendszer megbízható működése és a havi költség előre tervezhető legyen.

Mit jelent pontosan a szoftverüzemeltetés és -támogatás?

A szoftverfejlesztési piacon elterjedt tévhit, hogy az átadás pillanatában a termék „készen van”. 2026-ra a digitális ökoszisztéma olyan összetetté vált, hogy egy egyedi fejlesztésű alkalmazás életben tartása legalább annyi szakértelmet igényel, mint a megépítése. A szoftverüzemeltetés és -támogatás több a hibák javításánál: megelőző (proaktív) folyamat, amelynek célja, hogy az üzletileg kritikus rendszerek a hét minden napján, a nap 24 órájában elérhetők és biztonságosak maradjanak, és a növekvő terhelést is bírják.

A szoftver élő rendszer: folyamatos kölcsönhatásban áll a környezetével. A böngészők rendszeresen frissülnek – a Google Chrome például négyhetente kap új főverziót –, az operációs rendszerek és a külső API-kapcsolatok pedig évente akár több tucat alkalommal is változnak. Ha a forráskód nem követi ezeket a változásokat, a rendszer teljesítménye romlani kezd, végül működésképtelenné válhat. Tapasztalataink szerint egy karbantartás nélkül hagyott szoftver biztonsági kockázata egy év alatt jelentősen megnő.

Fontos különválasztani a klasszikus rendszergazdai feladatokat az alkalmazásszintű támogatástól. Míg egy IT-üzemeltető a szerverekért, a hálózatért és a hardveres háttérért felel, a szoftver támogatása a kód szintjén történik. A szerver futásán túl azt is figyeljük, hogy az üzleti logika pontosan és gyorsan hajtódik-e végre a felhasználók számára.

Az üzemeltetés alappillérei 2026-ban

• Infrastruktúra-felügyelet: a felhőalapú rendszerek (AWS, Azure) rugalmas kezelése a költségek optimalizálása és a magas, például 99,9%-os rendelkezésre állás érdekében.
• Alkalmazásszintű monitorozás: olyan diagnosztikai eszközök használata, amelyekkel a hibát már azelőtt észleljük, hogy a felhasználónál jelentkezne.
• Adatvédelem és GDPR: a jogszabályi környezet változásait követő, folyamatos biztonsági frissítések, amelyek az üzleti adatvagyon védelmét szolgálják.

Garancia, karbantartás vagy üzemeltetés?

Sok döntéshozó összekeveri a garanciális javítást a folyamatos támogatással, pedig a garancia, a karbantartás és az üzemeltetés más-más szintű biztonságot ad:

• Garancia: csak a fejlesztés során elkövetett, az átadáskor már meglévő kódhibák kijavítására vonatkozik, meghatározott ideig. Reagál a problémára, de nem előzi meg.
• Karbantartás: a szoftver „egészségének” megőrzése biztonsági frissítésekkel, a technológiai komponensek naprakészen tartásával és kisebb hibajavításokkal. Ez jórészt láthatatlan, megelőző munka – a felhasználók kérdéseire és bejelentéseire a támogatás (support) válaszol.
• Üzemeltetés: a legátfogóbb forma. Magában foglalja a karbantartást, és kiegészíti a rendszer folyamatos felügyeletével, a teljesítmény optimalizálásával és a felhasználók támogatásával; a kód mellett a teljes működési környezetet kezeli.

Az eredeti fejlesztési díj jellemzően csak az elkészítést és a garanciális időszakot fedezi; a hosszú távú karbantartás és üzemeltetés külön szolgáltatás. Egy üzletileg kritikus szoftvernél a garancia nem elegendő, hiszen nem fedezi az új operációs rendszerekkel való kompatibilitást vagy a növekvő terhelés miatti optimalizálást. Az üzemeltetés és a támogatás ezzel szemben a jövőbeni változásokra készíti fel a rendszert, és a termék teljes életciklusába beépül, hogy a technológiai háttér az üzleti növekedést szolgálja.

A stabil működés alapja az átláthatóság. Nálunk a támogatás az üzleti folyamatok és a piaci célok alapos megértésével kezdődik, így minden frissítés értéket teremthet a vállalkozása számára.

A szoftvertámogatás szintjei: L1, L2 és L3

A hatékony szoftverüzemeltetés és -támogatás alapja a szigorúan strukturált, többszintű védelmi rendszer. Ez a felosztás segít abban, hogy minden beérkező hibajegy a megfelelő kompetenciájú szakemberhez kerüljön, és ne vesszenek kárba az erőforrások. A tapasztalatok azt mutatják, hogy egy jól felépített támogatási struktúra bevezetése után a kritikus hibák megoldási ideje jelentősen csökkenhet. A szintezésnek üzleti haszna is van: megelőzi, hogy a magas óradíjú senior fejlesztők idejét olyan rutinfeladatok emésszék fel, amelyek egy jól dokumentált folyamat mentén alacsonyabb szinten is megoldhatók. Az átláthatóságot korszerű jegykezelő rendszerek, például a Jira Service Management vagy a Zendesk adják. Ezekben minden interakció mérhető, így pontos adatok állnak rendelkezésre a rendszer stabilitásáról és a csapat válaszidejéről.

A támogatás három pillére

A szintek azt határozzák meg, ki foglalkozik egy bejelentéssel; a támogatás tartalma pedig három, jól elkülöníthető területre épül:

• Hiba- és incidenskezelés: a reaktív réteg, amelyben a fejlesztők gyorsan beavatkoznak, ha a rendszer működése eltér az elvárttól. A cél a kritikus üzleti folyamatok – például egy webáruház fizetési moduljának – mielőbbi helyreállítása.
• Karbantartás és frissítés: az operációs rendszerek frissítéseinek, a külső API-k verzióváltásainak és a programkönyvtárak biztonsági javításainak követése, hogy a sebezhetőségek ne maradjanak nyitva.
• Továbbfejlesztés és optimalizálás: az üzleti igények változnak, ezért a támogatás része a rendszer igazítása, a teljesítmény finomhangolása és az új funkciók fejlesztése a meglévő kódbázison.

L1 és L2: az első védelmi vonal

Az L1-támogatás az általános, gyakran ismétlődő kérdésekért felel. Ide tartoznak a jogosultságkezelési problémák és a funkciók használatával kapcsolatos segítségnyújtás. Jó tudásbázissal az esetek nagy része – becslések szerint akár 70%-a – már ezen a szinten lezárható. Az L2-támogatás már mélyebb technikai ismereteket igényel: itt összetettebb konfigurációs feladatokat, adatbázis-lekérdezéseket és ismert, de technikai beavatkozást igénylő hibák elhárítását végzik. Ha egy digitális termék havonta – tájékoztató jelleggel – 200-nál több egyedi megkeresést generál, egy dedikált ügyfélszolgálati csapat fenntartása gazdaságilag is megtérülhet.

L3-támogatás: ahol a kód és az üzlet találkozik

Az L3 szinten történik a legmélyebb technikai elemzés. Itt tapasztalt, senior fejlesztők dolgoznak, akik közvetlenül a forráskódban azonosítják a hibákat, és elvégzik a szükséges módosításokat. Ez a szint elválaszthatatlan az egyedi szoftverfejlesztés folyamatától. A senior szakemberekre azért van szükség, mert ők látják át a kód és az üzleti logika közötti összefüggéseket. Ezen a szinten a hibák javítása mellett a technikai adósság megelőző csökkentése is cél. A 2026-os piaci elvárások szerint az L3 csapat visszajelzései alakítják a termék fejlesztési ütemtervét (roadmapjét). Egy tapasztalt partner abban segít, hogy a rendszere a növekvő terhelést is bírja.

A szintezett támogatás legnagyobb előnye a költségek optimalizálása. Míg egy L1 szintű incidens megoldása tájékoztató jelleggel 5000–8000 Ft költséget jelent, egy senior fejlesztő bevonása az L3 szinten ennek többszöröse is lehet. A cél az, hogy a problémák minél nagyobb részét az alacsonyabb szinteken tartsuk, a kritikus hibákhoz pedig gyors szakértői hozzáférést biztosítsunk.

A leállás költsége

Egy középvállalatnál már egyetlen óra váratlan leállás is milliós nagyságrendű közvetlen bevételkiesést okozhat.

Proaktív vagy reaktív üzemeltetés?

Proaktív megközelítés

• Folyamatos monitorozás és hibamegelőzés
• Tervezhető, fix havi költségek
• Nagyobb üzleti stabilitás és rendelkezésre állás (akár 99,9% vagy több)
• Védelem a technológiai avulás ellen
• Fejlesztési javaslatok a növekedésért

Reaktív „tűzoltás”

• Javítás csak a hiba bekövetkezte után
• Kiszámíthatatlan, magas vészhelyzeti költségek
• Gyakori leállások, bevételkiesés, presztízsveszteség
• Növekvő biztonsági kockázatok
• Csak a meglévő állapot fenntartása

Az elhanyagolt szoftver kockázatai

Egy karbantartás nélkül hagyott szoftver biztonsági kockázata egy év alatt jelentősen megnő. A rendszer teljesítménye romlik, végül a külső környezet (böngészők, operációs rendszerek, API-k) változásai miatt működésképtelenné válhat.

A támogatás szintjei: L1, L2, L3

A strukturált támogatás jelentősen rövidítheti a kritikus hibák megoldási idejét.

• L1: az első védelmi vonal

  Gyakori kérdések, jogosultságkezelés, felhasználói segítségnyújtás. Jó tudásbázissal az esetek nagy része – becslések szerint akár 70%-a – már ezen a szinten lezárható.

• L2: technikai támogatás

  Összetett konfigurációs feladatok, adatbázis-lekérdezések, ismert, de beavatkozást igénylő hibák elhárítása.

• L3: senior fejlesztők

  A legmélyebb technikai elemzés, forráskódszintű hibajavítás és fejlesztés. Itt találkozik a kód és az üzleti logika.

Az üzemeltetés alappillérei 2026-ban

• Infrastruktúra-felügyelet

  A felhőrendszerek (AWS, Azure) rugalmas kezelése a költséghatékonyság és a magas, például 99,9%-os rendelkezésre állás érdekében.

• Alkalmazásmonitorozás

  Diagnosztikai eszközök, amelyekkel a hiba már azelőtt észlelhető, hogy a felhasználónál jelentkezne.

• Adatvédelem és GDPR

  Folyamatos biztonsági frissítések a jogszabályi környezet változásait követve, az üzleti adatvagyon védelmében.

Támogatás vagy garancia: mi a különbség?

Garancia

• Csak a fejlesztés során elkövetett, már az átadáskor meglévő kódhibák javítására vonatkozik.

Szoftvertámogatás

• A rendszert a jövőbeni változásokra készíti fel: kompatibilitás, skálázhatóság, biztonság és új funkciók.

Proaktív vagy reaktív üzemeltetés: melyik éri meg jobban?

A reaktív modell lényege a tűzoltás: a fejlesztők csak akkor avatkoznak be, amikor a rendszer már leállt, vagy egy kritikus hiba akadályozza a felhasználókat. Ez a legdrágább üzemeltetési forma. Egy 50 fős magyar kkv-nál egy kritikus belső rendszer 4 órás kiesése a bérköltségeket és az elmaradt nyereséget is számolva akár 1,5–3,5 millió Ft veszteséget is okozhat. A szoftverüzemeltetés proaktív megközelítése ezzel szemben a megelőzésre épít.

Senior csapatunk rendszeresen átvizsgálja a forráskódot: keressük a memóriaszivárgásokat és a teljesítménybeli szűk keresztmetszeteket, mielőtt leállást okoznának. Az automatizált tesztelés itt kulcsszerepet játszik. A CI/CD-folyamatokba integrált egységtesztek (unit tests) és végponttól végpontig tartó (end-to-end) tesztek segítenek kiszűrni, ha egy új fejlesztés elrontaná a meglévő funkciókat. Ez a módszer jelentősen csökkenti a váratlan hibák esélyét az éles környezetben.

A technológiai avulás megelőzése

A keretrendszerek frissítését biztonsági okból nem lehet halogatni. A 2026-os kiberbiztonsági elvárások szerint a külső szoftverkönyvtárakat folyamatosan figyelni kell, mert egy elavult, harmadik féltől származó programkönyvtár nyitott kaput jelenthet a támadóknak. Ez megfelelési kérdés is: az uniós NIS2 irányelv – a hazai jogba átültetve – az érintett ágazatokban működő szervezeteknek kiberbiztonsági követelményeket ír elő, és ezek teljesítéséhez a biztonsági rések javítása és a függőségek frissítése is hozzátartozik. Ha egy használt modulban sebezhetőséget találnak, a javítás nem várhat napokat. A szakszerű IT-tanácsadás segít kijelölni azt a fejlesztési irányt, amellyel elkerülhetők a technológiai zsákutcák. Így megelőzhető, hogy a szoftver elavulása miatt később tízmilliós nagyságrendű újrafejlesztési költség merüljön fel.

Üzletmenet-folytonosság és katasztrófa-elhárítás

A biztonsági mentés önmagában nem garancia a túlélésre. A katasztrófa-elhárítási (disaster recovery, DR) terv része a rendszeres – például negyedéves – visszaállítási teszt. Nem az a fő kérdés, hogy van-e mentés, hanem az, hogy egy teljes szerverösszeomlás után mennyi idő alatt indul újra az üzlet. A skálázhatóság és a redundancia segít abban, hogy a rendszer bírja a növekvő terhelést.

• Rendelkezésre állás: a magas, például 99,9%-os rendelkezésre állást vállaló SLA teljesítéséhez redundáns, több szerverből álló környezet kell.
• Monitorozás: valós idejű riasztási rendszerek figyelik az erőforrás-használatot, így a túlterhelés előtt be lehet avatkozni.
• Átláthatóság: az üzleti döntéshozók rendszeresen – például havonta – jelentést kapnak a rendszer állapotáról és a végrehajtott frissítésekről.

A proaktív szoftverüzemeltetés így üzleti biztosításként is működik: kiszámíthatóvá teszi a költségeket, és segít megőrizni a digitális termék hosszú távú versenyképességét a magyar piacon.

A karbantartás négy típusa és költsége

A karbantartási költségek tervezésekor sok döntéshozó csak a váratlan hibák javításával számol. A szoftverkarbantartás azonban különböző célú beavatkozások összessége, amelyeket a szakma négy típusba sorol; mindegyik más üzleti kockázatot kezel:

• Korrektív karbantartás: az átadás után felszínre kerülő hibák javítása, hogy a szoftver ismét a specifikáció szerint működjön. Ez a legismertebb, de nem az egyetlen típus.
• Adaptív karbantartás: a szoftver igazítása a változó környezethez, például új böngésző- és operációsrendszer-verziókhoz, a külső API-k változásaihoz vagy egy adójogszabály módosításához.
• Perfektív karbantartás: a meglévő funkciók gyorsabbá, hatékonyabbá és jobban skálázhatóvá tétele, hogy a rendszer a növekvő felhasználószámot is kiszolgálja. Ez hozza a legnagyobb közvetlen üzleti értéket.
• Preventív karbantartás: a kód „tisztán tartása” refaktorálással, a függőségek és a dokumentáció frissítésével. Célja a technikai adósság csökkentése és a későbbi leállások megelőzése.

A típusok aránya a rendszer életkorával változik. Az élesítést követő stabilizációs szakaszban – jellemzően az első három hónapban – derülnek ki a valós használat terhelési csúcsai és a rejtett hibák, ezért ilyenkor a korrektív munka viszi a keret nagyobb részét. Egy érett rendszernél a hibajavítás aránya csökken, a perfektív és a preventív munkáé nő, és hosszú távon ez a kettő alapozza meg a jövedelmezőséget. Ha viszont egy szoftverre csak akkor költenek, amikor elromlik, a technikai adósság kamatos kamatként nő: minden elhalasztott frissítés és minden „gyors, de nem elegáns” megoldás drágítja a későbbi módosításokat, az üzemeltetési költségek pedig a rendszer avulásával meredeken emelkedhetnek.

A mobilalkalmazások karbantartása

Mobilalkalmazásoknál az adaptív karbantartás különösen hangsúlyos. Az Apple és a Google évente ad ki olyan iOS- és Android-főverziókat, amelyek elavulttá tehetnek korábban stabilan működő kódrészleteket, és a hardveres újdonságok, például az új kijelzőfelbontások követése is folyamatos igazítást kíván. A külső szolgáltatások – például a fizetési kapuk, a térképek vagy a közösségi bejelentkezések – API-jai is változnak; ha ezeket nem követik időben, az alkalmazás alapvető funkciói válhatnak elérhetetlenné.

Az egyik legsúlyosabb kockázat, hogy az alkalmazás eltűnhet az alkalmazásboltokból. Az Apple eltávolíthatja az évek óta nem frissített, alacsony letöltésszámú alkalmazásokat, a Google Play pedig az újabb Android-verziót használó új felhasználók elől elrejti azokat, amelyek nem célozzák meg a friss Android-verziókat; mindkét áruház megköveteli a biztonsági előírások betartását is. Egy ilyen eset után a piaci újrakezdés költsége jóval meghaladhatja a folyamatos karbantartás díját, nem beszélve az elveszített letöltésekről és a rangsorbeli helyezésről. A lassú, instabil működés az áruházi értékelésekben is hamar megjelenik, a negatív értékelések pedig elriasztják a lehetséges új felhasználókat.

Mennyibe kerül a karbantartás?

Iparági ökölszabály szerint egy egyedi szoftver karbantartásának éves költsége jellemzően a kezdeti fejlesztési költség 15–25%-a. Ez becslés, amely a rendszer összetettségétől és a vállalt szolgáltatási szinttől függően eltérhet. Egy 30 millió forintból elkészült rendszernél így évi nagyjából 4,5–7,5 millió forintos kerettel érdemes számolni, amely a hibajavításokon túl a biztonsági frissítéseket, a külső programkönyvtárak verzióinak követését és a környezeti változásokhoz való alkalmazkodást is fedezi. Az egyedi szoftver fenntartása azért igényel nagyobb ráfordítást egy dobozos megoldásénál, mert ott a fejlesztési költségek sok előfizető között oszlanak meg, itt viszont minden frissítést és optimalizálást kifejezetten az adott rendszeren kell elvégezni; cserébe nagyobb kontrollt ad.

A költséget leginkább ezek a tényezők befolyásolják:

• Technológia és architektúra: az elterjedt, stabil technológiákra épülő rendszer fenntartása általában olcsóbb. Az összetett AI-modelleket vagy mikroszolgáltatás-architektúrát használó rendszerek speciális szaktudást igényelnek, az AI-funkciók pedig a nagy nyelvi modellek (LLM) API-díjai, a promptok finomítása és a modellek rendszeres felügyelete miatt is növelik a havi költséget.
• Felhasználószám és forgalom: a felhőszolgáltatások (például AWS vagy Azure) díja a forgalommal együtt nő; a pontos összeg az adatforgalomtól és a szükséges számítási kapacitástól függ.
• Szolgáltatási szint: a rövidebb vállalt reakcióidő, a magasabb rendelkezésre állás vagy a 24/7 elérhetőség folyamatos monitorozást és készenlétben álló szakembereket igényel, ezért növeli a díjat.
• Külső szolgáltatások: a licencdíjak és a harmadik féltől igénybe vett szolgáltatások (például e-mail-küldés, online fizetés, térkép) API-díjai a tervezéskor gyakran rejtve maradnak.

Ötéves távlatban érdemes a teljes birtoklási költséggel (TCO) számolni. Az ökölszabály szerint öt év alatt a karbantartás önmagában a fejlesztési költség 75–125%-át teheti ki; a szerverekkel, a monitorozó eszközökkel, a külső szolgáltatásokkal és a fokozatos funkcióbővítéssel együtt a teljes költség így a fejlesztés árának kétszeresét is elérheti.

Hogyan csökkenthetők a karbantartási költségek?

Ezek a költségek nincsenek kőbe vésve: tudatos mérnöki munkával hosszú távon érdemben csökkenthetők. A megtakarítás alapja a minőségi forráskód és a naprakész dokumentáció. A tiszta kód (clean code) rövidíti a hibakeresést, hiányos dokumentáció mellett pedig már egy új szakember betanítása is sok munkaórát emészt fel.

• Minőségi kód: a tapasztalt fejlesztők munkája kevesebb utólagos javítást igényel.
• Automatizálás: az automatizált tesztek és a CI/CD-folyamatok a kézi ellenőrzés költségét és az emberi hiba lehetőségét is csökkentik.
• Szabványos technológiák: az elterjedt technológiákhoz, például a Node.js-hez vagy a Pythonhoz könnyebb elérhető áron szakembert találni.
• Folyamatos refaktorálás: a rendszeres átvilágítás és refaktorálás megállítja a kód romlását, és megelőzi a technikai adósság felhalmozódását.

A költségek jó része már a tervezéskor eldől: az alapos product discovery során összehangolt üzleti logika és műszaki megvalósítás megelőzi a későbbi, drága újratervezési ciklusokat. Az üzemeltetésben a felhőköltségek tudatos, adatalapú kezelése (FinOps) segít: automatikus skálázással a díj jobban követi a tényleges forgalmat, így nem kell fölösleges szerverkapacitásért fizetni.

Hogyan válasszunk partnert? Az SLA és a szerződés keretei

A szakszerű szoftverüzemeltetés és -támogatás szigorúan szabályozott üzleti folyamat is. A választásnál a legfontosabb szempont a bizalom és a szakértelem együttese. Egy senior csapat a kód mögött álló üzleti célokat is érti. A szerződéses kereteknek tükrözniük kell ezt a partnerséget: világosan rögzíteniük kell a felelősségi köröket, a biztonsági előírásokat és az adatkezelési szabályokat. Az átláthatóság alapkövetelmény. A havi jelentéseknek tartalmazniuk kell az elvégzett frissítéseket, a biztonsági mentések állapotát és a megoldott incidensek részleteit.

Házon belül vagy kiszervezve?

A partner kiválasztása előtt érdemes eldönteni, ki végezze a rendszer folyamatos felügyeletét, karbantartását és támogatását. Nincs mindenkire érvényes recept: a döntés a cég méretétől, a szoftver összetettségétől és a belső erőforrásoktól függ, a mérlegelés négy fő szempontja pedig a költség, a szükséges szakértelem, a működési rugalmasság és a vállalati fókusz.

Egy saját üzemeltetői csapat felállítása és fenntartása jelentős, gyakran rejtett költségekkel jár: a béreken és juttatásokon túl a folyamatos képzés, az eszközök és a licencek is komoly ráfordítást igényelnek. Kisebb cégeknél különösen nehéz olyan sokrétű tudású csapatot fenntartani, amely a szerverinfrastruktúrától a kiberbiztonságig minden területet lefed. Kockázatot jelent a kulcsemberektől való függés is: egy-egy szakember távozása vagy akár szabadsága is veszélyeztetheti a stabil működést.

A kiszervezéssel a cég a fő tevékenységére koncentrálhat, a kritikus informatikai feladatokat pedig erre szakosodott partnerre bízhatja. Egy-két saját szakember helyett így egy teljes, akár senior szakemberekből álló csapat tudásához fér hozzá, gyakran kedvezőbb költséggel. A működést a szolgáltatóval kötött SLA teszi kiszámíthatóvá. Az IT-outsourcing keretében megvalósuló üzemeltetést különösen akkor érdemes megfontolni, ha a belső csapat fenntartása túl magas fix költséggel járna.

Az SLA-paraméterek értelmezése

A szolgáltatási szintről szóló megállapodás (service level agreement, SLA) rögzíti a szolgáltatás minőségének mérőszámait. Sokan elkövetik azt a hibát, hogy csak a reakcióidőre figyelnek. A reakcióidő azt mutatja meg, hogy a partner hány percen belül igazolja vissza a hibabejelentést. Az üzletmenet folytonossága szempontjából azonban a megoldási idő a kritikus mutató. Nem mindegy, hogy egy leállt webáruház 45 perc vagy 12 óra múlva indul újra. A prioritási szinteket az üzleti hatás alapján kell meghatározni; egy szerződésben ez például így nézhet ki:

• Kritikus: a rendszer leállt, vagy a hiba a fő funkciókat, például a bevételszerzést akadályozza; azonnali beavatkozást igényel (például 1 órás reakcióidő, 4 órás megoldási idő).
• Magas: egy fontos, de nem a teljes rendszert érintő funkció hibás (például 4 órás reakcióidő, 8 munkaórás megoldási idő).
• Normál: kisebb funkcionális vagy megjelenítési hiba, amely nem akadályozza a használatot (például 8 munkaórás reakcióidő, javítás a következő kiadásban).

A 99,9%-os rendelkezésre állás 2026-ban már alapvető elvárás; ez éves szinten kevesebb mint 9 óra nem tervezett leállást enged meg, egy 99,5%-os vállalás pedig már nagyjából 44 órát. A mutatókon túl egy jó SLA azt is rögzíti, hogyan működik az együttműködés a gyakorlatban:

• A szolgáltatás pontos leírása: mi tartozik a havidíjba (például hibajavítás, biztonsági frissítések, monitorozás), és mi nem (például új funkciók fejlesztése, felhasználói oktatás).
• Kapcsolattartási pontok: kihez és milyen csatornán lehet fordulni hiba esetén (például dedikált kapcsolattartó, hibajegykezelő rendszer, telefonszám).
• Eszkalációs eljárásrend: mi a teendő, ha a probléma nem oldódik meg a vállalt időn belül, és kihez lehet fordulni magasabb szinten.

Költségmodellek az üzemeltetésben

A piacon két elszámolási mód uralkodik. A fix havidíjas modell kiszámítható költségtervezést tesz lehetővé; a díj a rendszer összetettségétől függ. Jellemzően ez teszi lehetővé a leggyorsabb reagálást is, mert a lekötött csapat már ismeri a forráskódot és a környezetet. Az AP4-nél az élő rendszer támogatására szolgáló havi keret 300 ezer Ft/hó-tól indul, írásos SLA-val (a sávok az Árak oldalon); az üzemeltetésre, a hibajavításra és a továbbfejlesztésre is kiterjed, rangsorolt feladatlistával, és bármikor lemondható.

Az időalapú elszámolás (time & material, T&M) ezzel szemben nagyobb rugalmasságot ad, de a költségek ingadozhatnak. Akkor előnyös, ha a támogatási igény alacsony vagy rendszertelen, mert csak a ténylegesen elvégzett munkáért kell fizetni. Gyakori a kettő kombinációja is: a havi díj előre meghatározott órakeretet tartalmaz, a kereten felüli munkát pedig időalapon számolják el; ilyenkor érdemes kikötni, hogy a hónap végén minden elvégzett feladatról részletes kimutatás készüljön.

A rejtett költségek elkerülése érdekében a szerződésben pontosan meg kell határozni, mi tartozik az alapüzemeltetésbe, és mi minősül egyedi fejlesztésnek. Az új funkciók fejlesztése vagy a meglévők jelentős átalakítása jellemzően továbbfejlesztésnek számít: a megállapodásban rögzített továbbfejlesztési kapacitás terhére, rangsorolt feladatlista szerint, vagy külön, pontos specifikáción alapuló árajánlat szerint valósulhat meg. A tapasztalatok szerint a pontatlanul megfogalmazott feladatkörök jelentősen növelhetik a várható kiadásokat.

A hatékony szoftverüzemeltetés alapja a megelőzés. Egy senior szakemberekből álló partner folyamatos monitorozással megelőzi a problémákat, és nem várja meg, amíg a rendszer összeomlik. Ez a szemlélet különbözteti meg a hosszú távú partnert az egyszerű beszállítótól. A jelentésekből kapott adatok alapján pedig folyamatosan optimalizálható a technológiai háttér, ami hosszú távon csökkenti a technikai adósságot.

Szeretné biztonságban tudni digitális termékét egy senior csapattal? Beszéljünk a projektjéről, és keressük meg együtt a megfelelő üzemeltetési modellt.

Szoftverüzemeltetés az AP4-nél: senior figyelem az üzleti sikerért

Az AP4-nél alapelv, hogy a szoftverüzemeltetés és -támogatás nem másodlagos, technikai feladat. Sokan elkövetik azt a hibát, hogy a költségcsökkentés reményében junior fejlesztőkre bízzák az élő rendszerek felügyeletét. Nálunk senior szakemberek felügyelik az élő rendszereket. Egy kritikus hiba esetén, amikor minden kiesett perc jelentős bevételkiesést okozhat, nincs idő a kísérletezésre. A senior tapasztalat segít a hiba okának gyors azonosításában és elhárításában.

A kód mellett az üzleti folyamatokat is látjuk. Ha egy logisztikai szoftver leáll, pontosan értjük, hogy ez a raktári kiszállítások csúszását és az ellátási lánc megszakadását jelenti. Ez a szemlélet teszi lehetővé, hogy a napi működés során proaktív javaslatokat tegyünk. Munkánk szorosan kapcsolódik az agilis módszertan elveihez: az üzemeltetés során szerzett tapasztalatok és a felhasználói visszajelzések gyorsan beépülnek a következő fejlesztési ciklusokba.

Folyamataink átláthatók az ügyfelek számára. Minden jegykezelési művelet követhető, így pontosan látja, min dolgozunk éppen. A havi keret része a havi riport: mi történt, mi javult, és mi a következő prioritás. A mi csapatunk az Ön csapata, ezért a közös munka alapja a nyílt kommunikáció és a közös felelősségvállalás.

Megbízható rendelkezésre állás

Az üzemeltetést és a támogatást külön megállapodásban vállaljuk: a rendelkezésre állást, a reakcióidőt, a monitorozást, a frissítéseket és a továbbfejlesztési kapacitást a támogatási megállapodás rögzíti. Az ügyfél saját felhőfiókjában (AWS, GCP vagy Azure) dolgozunk, így a hozzáférés és a számlázás is az ügyfélé marad. Saját fejlesztéseink mellett más által készített legacy rendszereket is átveszünk, ha az átvilágítás alapján a rendszer megbízhatóan üzemeltethető. Az átvétel első lépése a forráskódhoz fűződő jogok tisztázása és a hiányzó dokumentáció pótlása. Célunk a támogatási megállapodásban vállalt rendelkezésre állás – például 99,9% – teljesítése. Folyamatosan monitorozzuk a rendszereket, és rendszeresen javaslatot teszünk olyan optimalizálásra, amely csökkentheti a felhőinfrastruktúra költségeit, vagy gyorsíthatja a tranzakciókat.

Kezdjük el a közös munkát!

Az együttműködés alapos műszaki átvilágítással és helyzetfelméréssel indul. Felmérjük a meglévő architektúrát, és már az átvilágítás első szakaszában azonosítjuk a legsürgetőbb biztonsági kockázatokat. Ezután állítjuk össze a személyre szabott csomagot, amely tartalmazza a szükséges reakcióidőket és a senior kapacitást. A munka nálunk azzal kezdődik, hogy megértjük, hogyan működik a vállalkozása. A felmérést érdemes még azelőtt elvégezni, hogy egy váratlan leállás veszélyeztetné az üzletmenetet. Kérjen ajánlatot szoftverüzemeltetésre.

Tegye fenntarthatóvá digitális növekedését senior támogatással

A digitális termék sikere 2026-ban már nem ér véget az élesítéssel. A folyamatos szoftverüzemeltetés és -támogatás segít abban, hogy a rendszerek a gyorsan változó piaci környezetben is biztonságosak maradjanak, és a növekvő terhelést is bírják. A proaktív megközelítés, a tudatosan tervezett karbantartási keret és a pontosan meghatározott L1, L2, L3 támogatási szintek csökkentik a váratlan leállások kockázatát. Ez a stabilitás közvetlenül hat a cég nyereségességére és az ügyfélélményre is, hiszen a technikai hibák elkerülése alapvető üzleti érdek.

Az AP4-nél senior csapatunk a napi karbantartásban is az Ön konkrét üzleti céljai mentén optimalizálja a folyamatokat, hogy a technológia a vállalkozása növekedését segítse. Munkánk átlátható, a fejlesztési projekt végén pedig a teljes forráskódot átadjuk, így Ön rendelkezik a terméke felett. A senior szintű szakmai figyelem segít abban, hogy a frissítések és a javítások a bevett iparági szabványok szerint készüljenek. A technikai adósság és a kizárólag reaktív hibajavítás a cég növekedését is lassítja.

Beszéljünk a projektjéről: kérjen senior szintű üzemeltetési ajánlatot az AP4-től.

Gyakran ismételt kérdések a szoftverüzemeltetésről