Miért nem ér véget a munka az élesítéssel
Egy foglalási alkalmazás nyolc hónapig fut gond nélkül. Senki nem nyúl hozzá, hiszen működik.
Aztán szeptemberben megjelenik az új iOS-verzió, a push értesítések elnémulnak, a fizetési szolgáltató kivezeti a régi API-t, és a foglalások egy része egyszerűen elakad.
A csapat két hét alatt veszi észre a bajt. Addigra a negatív értékelések elárasztják az App Store-t, és a visszatérő felhasználók harmada elpártol.
Ez nem kivételes eset… hanem a gondozatlan szoftverek tipikus életútja.
Ebben a cikkben az alkalmazás karbantartás tágabb értelemben szerepel: minden olyan rendszeres tevékenység, amely az élesített szoftvert működőképesen, biztonságosan és kompatibilisen tartja egy folyamatosan változó környezetben. Ide tartozik a hibajavítás, a függőségfrissítés, a biztonsági patchek telepítése, az API-kompatibilitás fenntartása és a monitoring is.
Röviden: minden, ami ahhoz kell, hogy a ma működő app holnap is működjön.
A szoftver ugyanis nem egy kész ház, hanem inkább egy kert. Ha magára hagyod, nem marad változatlan.
Lassan, de biztosan benövi a gaz.
A cikk négy részre épül:
Először tisztázzuk a fogalmakat, mert a karbantartás, az üzemeltetés, a támogatás és a továbbfejlesztés nem ugyanaz.
Utána végigmegyünk a napi, heti, havi és negyedéves feladatokon, majd a mérőszámokon, amelyekkel az app egészsége objektíven követhető. Végül a döntési szempontokról lesz szó: ki végezze a munkát, mi kerüljön a szerződésbe, és mikor éri meg inkább újraépíteni.
Ha vállalkozó, termékfelelős vagy startupcsapat tagja vagy, és a terméked már élesben fut, ez az útmutató neked szól.
Nem elméleti áttekintést kapsz. Konkrét feladatlistát, célértékeket és szerződéses ellenőrzőpontokat.
Karbantartás, üzemeltetés, támogatás, fejlesztés
A legtöbb félreértés egy ártatlan mondattal kezdődik: „a fejlesztő majd figyel rá”.
De mire is pontosan?
A négy feladatkör más készségeket, más ritmust és más költségkeretet igényel.
Mi különbözteti meg a négy feladatkört
A karbantartás a meglévő funkciók működőképességének megőrzése. Ide tartozik a hibajavítás (például egy Android 15-ön összeomló képernyő), a kompatibilitás fenntartása (az új iOS-verzió engedélykezelésének átvezetése) és a rendszeres SDK-frissítés.
A cél nem az, hogy az app többet tudjon, hanem hogy ugyanazt megbízhatóan tudja.
Az üzemeltetés az infrastruktúra oldala.
Szerverfelügyelet, monitoring és riasztások, biztonsági mentés, terhelés alatti skálázás és a rendelkezésre állás biztosítása. Egy webalkalmazás üzemeltetése akkor is folyamatos munka, ha a kódhoz hónapokig senki nem nyúl.
A támogatás az emberi kapcsolódási pont.
A felhasználói megkeresések és hibabejelentések fogadása, priorizálása és megválaszolása tartozik ide, jellemzően rögzített válaszidőkkel (SLA). Egy tipikus kkv-s SLA például kritikus hibára 2 órás reakcióidőt, normál kérésre 1 munkanapot vállal.
A továbbfejlesztés új értéket teremt: új funkciók, üzleti igényre reagáló módosítások, UX-bővítés. Egy hűségprogram beépítése vagy egy új fizetési mód bevezetése fejlesztés, nem karbantartás.
Ennek oka egyszerű: ezek nélkül a meglévő termék továbbra is működne.
A jó ökölszabály: ha a változtatás elmaradása miatt valami eltörik, az karbantartás. Ha a változtatás elmaradása miatt valami csak nem lesz jobb, az fejlesztés.
Miért keverik össze a cégek ezeket
Az első ok a szerződéses gyakorlat.
Sok projekt egyetlen „support” vagy „garancia” sorral zárul, amely mögött senki nem tudja pontosan, mi van. A garancia jellemzően csak az átadáskor már meglévő hibákra vonatkozik, a jövőbeli iOS-változásokra nem.
A második ok a költségvetés.
A karbantartás láthatatlan, a fejlesztés látványos. Ezért a cégek hajlamosak a karbantartási keretet új funkciókra „átcsoportosítani”, amíg a technikai adósság csendben halmozódik.
A harmadik ok emberi.
Kis csapatban ugyanaz a fejlesztő javít hibát, figyeli a szervert és válaszol a felhasználóknak.
A szerepek összemosódnak, és ami mindenkié, az végül senkié.
Mi tartozik valójában a karbantartásba
A legtöbb leállás nem drámai hiba miatt történik, hanem egy elfelejtett rutinfeladat miatt.
Egy lejárt SSL-tanúsítvány. Egy APNs-kulcs, amit senki nem újított meg. Egy elavult könyvtár, amelyben fél éve ismert sebezhetőség van.
Az alábbi ellenőrzőlista ezeket a rutinokat rendszerezi gyakoriság szerint. Nem kell mindent egyszerre bevezetni, de minden pontnak legyen gazdája.
Napi, heti, havi és negyedéves feladatok
Napi szint (10-15 perc):
- Crash log ellenőrzése: nézd át a crash reporting eszköz (például Firebase Crashlytics vagy Sentry) új hibacsoportjait. Az előző nap óta megjelent új összeomlás-típus szinte mindig azonnali vizsgálatot érdemel.
- Monitoring riasztások átnézése: a szerver, az adatbázis és a háttérfolyamatok riasztásait ne csak némítsd, hanem zárd le ok-megjelöléssel. Így kiderül, melyik riasztás valódi és melyik csak zaj.
- Biztonsági mentések állapota: ellenőrizd, hogy az éjszakai mentés lefutott-e, és a fájlméret reális-e. Egy hirtelen 0 KB-os mentés többet árul el, mint egy hibaüzenet.
Heti szint (1-2 óra):
- API és függőség-státusz: nézd át a használt külső szolgáltatások státuszoldalait és változásnaplóit. A kivezetési (deprecation) értesítések általában 3-12 hónappal a leállás előtt érkeznek, ha valaki elolvassa őket.
- Áruházi vélemények: az App Store és a Google Play értékelései gyakran előbb jelzik a hibát, mint a monitoring. Egy „nem tudok belépni” típusú vélemény-hullám egyértelmű vészjel.
- Teljesítménymutatók: a crash-free users arány, a válaszidők és a hibaarány heti trendje fontosabb, mint egy-egy napi kiugrás.
Havi szint (fél-egy nap):
- Biztonsági patchek telepítése: operációs rendszer, futtatókörnyezet (Node.js, PHP, Java) és adatbázis-motor frissítése staging környezetben tesztelve. A kritikus sebezhetőségeket ne várd meg a havi ciklussal.
- SDK-frissítés: analitika, push, hirdetési és fizetési SDK-k verzióinak felülvizsgálata. A régi SDK-k a leggyakoribb okai az áruházi elutasításoknak.
- Lejáró kulcsok és tanúsítványok: vezess listát minden lejárati dátumról. A CA/Browser Forum döntése alapján 2026 márciusától az SSL-tanúsítványok maximális érvényessége 200 napra csökken, 2029-re pedig 47 napra, így az automatikus megújítás már nem luxus.
Negyedéves szint (2-5 nap):
- Teljes biztonsági audit: sebezhetőség-szkennelés, OWASP-ellenőrzőlista átnézése, naplók elemzése gyanús mintázatokra.
- Jogosultság-felülvizsgálat: ki fér hozzá a szerverekhez, az áruházi fiókokhoz és az adatbázishoz? A volt munkatársak és alvállalkozók hozzáférései meglepően gyakran élnek évekig.
- Terheléses teszt: szimulálj a csúcsforgalom kétszeresét. Egy kampány vagy egy médiamegjelenés előtt ez fizeti meg magát leginkább.
- Függőségleltár frissítése: minden könyvtár, verzió, licenc és felelős egy helyen. Szolgáltatóváltáskor ez lesz a legértékesebb dokumentum.
Platformok szerinti eltérések
A fenti ritmus univerzális, a tartalom viszont platformonként eltér. Egy mobilapp, egy webes rendszer és a köztük futó integrációk egészen más módon tudnak elromlani.
Mobilalkalmazás
- Google Play target API szint: a Google évente emeli a kötelező cél API-szintet, és aki lemarad, annak alkalmazása új felhasználók számára elérhetetlenné válhat. A határidő jellemzően augusztus végén esedékes.
- Apple SDK-követelmények: az Apple tavaszonként előírja, hogy a beküldött buildeket a legfrissebb Xcode-dal és SDK-val kell elkészíteni. Egy egyszerű hibajavítás is elakadhat, ha a projekt nem fordul az új eszközkészlettel.
- Adatvédelmi szabályok: az áruházak adatvédelmi címkéi és az Apple privacy manifest követelményei minden SDK-frissítéskor újra ellenőrzést igényelnek.
Webalkalmazás és backend
- Böngészőkompatibilitás: a Chrome, Safari és Firefox négyhetente-havonta frissül, és a Safari különösen hajlamos a megszokottól eltérő viselkedésre. Negyedévente érdemes a fő felhasználói utakat mindhárom böngészőben végigtesztelni.
- Adatbázis-skálázás: a lekérdezések, amelyek 10 000 rekordnál villámgyorsak, 2 millió rekordnál percekig futhatnak. Az indexek és a lassú lekérdezések naplója havi felülvizsgálatot érdemel.
- Futtatókörnyezet életciklusa: a Node.js, PHP és Python verziók támogatási ideje véges. A már nem támogatott verzión futó backend biztonsági javítást sem kap.
Harmadik féltől származó integrációk
- Fizetési szolgáltatók: a Stripe, a Barion vagy a SimplePay API-verzióinak és az erős ügyfél-hitelesítési (SCA) követelményeknek való megfelelést félévente ellenőrizd.
- Push szolgáltatások: a Firebase Cloud Messaging 2024-ben kivezette a régi API-t, és aki nem állt át időben, annak értesítései egyszerűen megszűntek. Ez jó példa arra, milyen csendesen tud elromlani egy integráció.
- Hitelesítési szolgáltatók: a Google, Apple és Facebook bejelentkezés kulcsai, visszahívási címei és engedélykörei rendszeresen változnak. Egy hibás belépés a leggyorsabb módja annak, hogy elveszíts egy felhasználót.
Hogyan mérd és biztosítsd az app egészségét
Amit nem mérsz, azt nem tudod karbantartani.
Csak reagálni tudsz rá, amikor már baj van.
A jó hír: egy induló vállalkozásnak nem kell 40 mutatót figyelnie, hét is bőven elég.
Mérőszámok, amik tényleg számítanak
Az alábbi táblázat a startupok és kkv-k számára legfontosabb mutatókat foglalja össze, célértékkel és azzal, hogyan követheted őket külön eszköz nélkül is.
| Mutató | Célérték | Mit jelez | Követés eszköz nélkül |
|---|---|---|---|
| Crash-free users | 99% felett (érett appnál 99,5%+) | A felhasználók hány százaléka nem tapasztalt összeomlást | Firebase Crashlytics ingyenes csomag, Play Console és App Store Connect beépített riportjai |
| Hibaarány (HTTP 5xx) | A kérések 0,5%-a alatt | A backend stabilitását és a rejtett szerverhibákat | Szervernaplók heti szűrése 5xx státuszkódra |
| API-válaszidő (p95) | 300 ms alatt | Az app érzékelt gyorsaságát | Böngésző fejlesztői eszközei, a tárhelyszolgáltató alap metrikái |
| Rendelkezésre állás | 99,9% (havi ~43 perc kiesés) | Mennyi ideig érhető el a szolgáltatás | Ingyenes uptime-figyelők, például UptimeRobot vagy Better Stack alapcsomag |
| MTTR (átlagos helyreállítási idő) | 4 órán belül | Milyen gyorsan reagál a csapat egy incidensre | Egyszerű incidensnapló táblázatban: kezdet, észlelés, megoldás időpontja |
| Telepítési sikeresség | 98% felett | A letöltések hány százaléka jut el az első sikeres indításig | Play Console telepítési statisztikák, első megnyitás eseménye az analitikában |
| Felhasználói lemorzsolódás | 30 napos megtartás 20-30% felett (iparágfüggő) | Elhagyják-e a felhasználók az appot frissítés után | Kohorszjelentés a Firebase vagy a GA4 ingyenes verziójában |
Miért éppen ezek? Mert ezek kötődnek közvetlenül a bevételhez.
A Google Play nyíltan rontja a rangsorolást, ha a felhasználók által érzékelt összeomlási arány 1,09% fölé megy, vagyis a crash-free users mutató egyszerre minőségi és marketingmutató is.
A rendelkezésre állás és az MTTR együtt mutatja meg, mennyire vagy felkészülve a bajra. Egy 99,9%-os célérték havonta körülbelül 43 perc kiesést enged meg.
Ha egyetlen incidens javítása 4 óránál tovább tart, az egész negyedév célja odaveszhet.
Eszköz nélküli követéshez elég egy közös táblázat, amelyet minden hétfőn 15 percben frissít a felelős.
Nem elegáns, de működik.
A trendek fontosabbak, mint a pontos tizedesjegyek.
Biztonságos kiadási folyamat
A karbantartás paradoxona, hogy minden frissítés maga is kockázat.
Egy SDK-frissítés, amely biztonsági rést zár be, közben eltörheti a bejelentkezést.
A megoldás nem a frissítések kerülése, hanem egy fegyelmezett kiadási folyamat.
| Lépés | Mit csinálsz | Milyen kockázatot előz meg |
|---|---|---|
| 1. Staging környezet | Az éles rendszer pontos másolatán telepíted és próbálod ki a változást | Környezetfüggő hibák, hiányzó konfigurációk, migrációs problémák |
| 2. Regressziós tesztelés | Automatizált és kézi tesztekkel ellenőrzöd, hogy a régi funkciók továbbra is működnek | Mellékhatások: a javítás máshol okoz hibát |
| 3. Béta csoport | TestFlight vagy Play belső tesztelés 20-50 felhasználóval, 2-5 napig | Valós eszközökön jelentkező, laborban nem látható hibák |
| 4. Fokozatos rollout | 5% → 25% → 100%, minden lépcső után 24-48 óra megfigyelés | Tömeges összeomlás a teljes felhasználói bázison |
| 5. Rollback terv | Előre dokumentált visszaállítási lépések, adatbázis-mentés a kiadás előtt | Elhúzódó leállás, adatvesztés |
Három gyakorlat választja el a nyugodt kiadásokat a pénteki tűzoltástól.
Az első az automatizált tesztek köre: nem kell 100%-os lefedettség, de a pénzt hozó útvonalak (regisztráció, belépés, fizetés) legyenek minden buildnél automatikusan tesztelve.
A második a feature flag.
Ezzel az új vagy módosított kódrész távolról ki-be kapcsolható, így egy hibás funkciót percek alatt lekapcsolhatsz, új áruházi beküldés nélkül. Mobilon ez különösen értékes, hiszen az Apple felülvizsgálata akár egy-két napot is igénybe vehet.
A harmadik az élesítés utáni fokozott monitoring.
Az első 48 órában a felelős óránként nézze a crash-free users arányt és a hibaarányt. A legtöbb regresszió ebben az ablakban derül ki.
Ki végezze, és mikor éri meg váltani
Az iparági becslések szerint egy szoftver teljes életciklus-költségének 60-80%-a az élesítés után keletkezik.
A legfontosabb döntés tehát nem az, ki építi meg az appot, hanem az, ki gondoskodik róla utána.
Belső csapat vagy külső partner
Belső fejlesztőt akkor éri meg tartani, ha az alkalmazás a cég fő terméke, napi szintű változtatásokat igényel, és a karbantartás mellett folyamatos fejlesztés is zajlik.
Egy medior fejlesztő bérköltsége 2026-ban Magyarországon havi szinten jellemzően 1-1,5 millió forint körül mozog járulékokkal, és egyetlen ember még nem csapat: szabadság vagy betegség idején a tudás elérhetetlenné válik.
Külső stúdió akkor jobb választás, ha az app fontos, de nem igényel napi fejlesztést, és szükség van mobil, backend és infrastruktúra tudásra egyszerre.
Egy jó partner nem egy embert ad, hanem egy csapat tudását és helyettesíthetőségét.
A döntő szempont mégis a hozzáállás.
A CompletApp például nem egyszeri átadással zárja a projekteket: az élesítés után is a termék mellett marad, hibajavítással és rendszeres frissítésekkel.
Ez a modell azért működik, mert a fejlesztő ismeri a kódot, nem kell minden apró javításnál újra feltérképeznie a rendszert.
Mit tartalmazzon a karbantartási szerződés
A forráskód-hozzáférés az első és legfontosabb pont.
A szerződés rögzítse, hogy a kód a megrendelő tulajdona, és egy általa is elérhető verziókezelő tárolóban (GitHub, GitLab, Bitbucket) található.
A fejlesztői fiókok tulajdonjoga legalább ilyen fontos. Az Apple Developer, a Google Play Console, a felhőszolgáltató és a domain fiókja mindig a megrendelő nevén legyen, a szolgáltató csak meghívott felhasználóként férjen hozzá.
Ellenkező esetben egy vitás helyzetben az appod gyakorlatilag túsz.
Szerepeljen benne a dokumentáció elvárt szintje (architektúra, telepítési lépések, függőségleltár), a válaszidő-vállalások prioritási szintenként, és az átlátható költségstruktúra. Utóbbinál jellemző a havi átalány egy meghatározott óraszámmal, plusz óradíj a kereten felüli munkára.
Rögzítsd azt is, mi számít karbantartásnak és mi fejlesztésnek, mert ezen csúszik el a legtöbb együttműködés.
Mikor gazdaságtalan a patchelés
Egy idő után minden javítás drágább lesz, mint az előző.
Ezt a pontot három tünet jelzi.
Az első a felhalmozódó technikai adósság: a fejlesztők egyre gyakrabban mondják, hogy „ehhez előbb át kellene írni azt is”.
A második az egyre gyakoribb sürgősségi hibajavítás. Ha havonta kétszer is hétvégi tűzoltásra van szükség, a rendszer instabilitása már nem véletlen.
A harmadik az elavult keretrendszer.
Egy már nem támogatott React Native, Angular.js vagy régi PHP-verzió nem kap biztonsági javítást, és minden SDK-frissítés kompatibilitási csatává válik.
Ilyenkor a fejlesztők idejük nagyobb részét kerülőutak építésével töltik.
Gyakorlati ökölszabály: ha a karbantartási költség két egymást követő évben meghaladja az eredeti fejlesztési költség 40%-át, érdemes komolyan kiszámolni az újraépítés megtérülését.
Az újraépítés nem kudarc.
Sokszor ez a legolcsóbb út, főleg ha közben a termék is megérett, és pontosan tudod, mely funkciókat használják valóban a felhasználók.
Egy jól előkészített újraírás ráadásul az összegyűlt üzleti tudást is beépíti.
Egy stabil app nem véletlen
Azok az alkalmazások, amelyek évekig megbízhatóan futnak, nem szerencsések.
Gondozottak.
Valaki minden héten ránéz a crash logra, valaki tudja, mikor jár le a push-tanúsítvány, és valaki tesztel, mielőtt kiad.
Ha egyetlen dolgot viszel magaddal ebből az útmutatóból, legyen ez: állíts fel még ma egy negyedéves karbantartási naptárt, és rendelj hozzá felelőst minden ponthoz.
Nem holnap, nem a következő sprintben.
Egy egyszerű táblázat a fenti napi, heti, havi és negyedéves feladatokkal, nevekkel és dátumokkal már többet ér, mint a legjobb szándék.
És érdemes átkeretezni a gondolkodást is.
Az alkalmazás karbantartás nem utómunka, amit a „valódi” fejlesztés után kell letudni.
Ez a feltétele annak, hogy a terméked egyáltalán fejlődni tudjon.
Egy stabil alapra lehet építeni.
Egy repedezőre csak toldozni.
