- Webshopnál, sok bővítményes WordPress-oldalnál és foglalási rendszernél a rendszeres karbantartás jó eséllyel indokolt, zárt platformon (Shopify, Wix) ritkábban.
- A mentés csak akkor ér valamit, ha az oldaltól külön helyen tárolódik, elég régre visszanyúlik, és ki is próbálták belőle a visszaállítást.
- A riportban a frissítések száma helyett a legutóbbi visszaállítási próba dátumát, időtartamát és eredményét kérd.
- A szerződés rögzítse a hibabejelentés módját, a mentések helyét, a hozzáférések tulajdonjogát és azt, mi számít külön munkának.
- Ha nem tudod megmondani, hol van a legutóbbi mentésed és mikor próbálták vissza, kérj felmérést az oldalad jelenlegi állapotáról.
A weboldal átadásakor sok fejlesztő egy havi karbantartási megállapodást is javasol. A tulajdonos ilyenkor jellemzően azt kérdezi magától, hogy ez valódi szükséglet vagy csak egy újabb havi tétel. A jól végzett karbantartás láthatatlan, ezért nehéz megítélni. Az elmaradt karbantartás viszont általában egyetlen rossz napon derül ki, amikor az oldal nem tölt be, a webshop nem fogad rendelést, vagy a Google figyelmeztetést tesz a találat mellé. Ez a cikk abban segít, hogy eldöntsd, kell-e neked, és ha igen, mit kérj bele a szerződésbe.
A szövegben külön jelöljük, mi hivatalosan igazolt (dokumentációban, szabványban, jogszabályban szereplő tény), mi saját tapasztalat (amit weboldalak üzemeltetése közben rendszeresen látunk), és mi szakmai feltételezés (jól megalapozott, de általánosan nem bizonyított következtetés).
Kell-e karbantartási szerződés a weboldaladhoz?
Ha az oldalad tartalomkezelőn fut (WordPress, Joomla, Drupal, saját tárhelyes webshopmotor), bővítményeket használ, és űrlapon, foglaláson vagy rendelésen keresztül ügyfél jön rajta, akkor jó eséllyel szükséged van rendszeres karbantartásra. Hogy ezt a fejlesztő, egy másik szolgáltató vagy egy belső munkatárs végzi, az másodlagos kérdés. A lényeg az, hogy a feladatnak legyen gazdája, és írásban rögzítve legyen, mit vállalt.
Szerződés nélkül is lehet jól karbantartott egy oldal, de ilyenkor jellemzően senki sem tudja megmondani, ki felel a mentésért, és mi történik, ha egy frissítés után hibás lesz az oldal. A szerződés értéke abban van, hogy ezek a kérdések egy baj előtt kapnak választ.
Mely oldaltípusoknál indokolt a havi karbantartás?
Ott indokolt leginkább, ahol az oldal gyakran változó szoftverkomponensekből áll, és ahol a kiesésnek közvetlen üzleti ára van.
- Saját tárhelyen futó webshop, például WooCommerce vagy PrestaShop alapon. Fizetési modul, vásárlói adatok és rendelések vannak rajta, itt a karbantartás szinte mindig indokolt.
- WordPress céges oldal sok bővítménnyel, oldalépítővel (Elementor, Divi) és ajánlatkérő űrlapokkal.
- Foglalási, időpontkérő vagy tagsági oldal, ahol felhasználói fiókok és személyes adatok vannak.
- Több szerkesztős oldal, ahol több ember fér hozzá az adminhoz, és nehezebb követni, ki mit változtatott.
Kevésbé indokolt a statikus HTML oldal és a zárt, szolgáltató által üzemeltetett rendszer (Shopify, Wix, Squarespace), ahol a szoftverfrissítést a platform végzi. Itt is van teendő (domain, DNS, mérőkódok, tartalom), de ez inkább eseti munka.
Saját tapasztalat. A legtöbb gondot a régóta nem frissített bővítmények és a fejlesztőjük által elhagyott témák okozzák, a WordPress mag ritkábban. Egy öt-hat éve átadott, azóta érintetlen oldalon gyakran találunk olyan bővítményt, amit már a hivatalos könyvtárból is levettek.
Mit jelent a gyakorlatban a frissítés?
A frissítés a tartalomkezelő mag, a bővítmények, a téma és a szerveroldali környezet (PHP-verzió, adatbázis-motor) újabb kiadásra emelése, előtte friss mentéssel, utána működés-ellenőrzéssel. A gombnyomás a munka kisebbik része.
Hivatalosan igazolt. Az OWASP Top 10 listája külön kockázati kategóriaként kezeli a sérülékeny és elavult komponenseket (Vulnerable and Outdated Components). A WordPress.org dokumentációja frissítés előtt teljes mentést javasol. A PHP minden kiadási ágának meghatározott támogatási ideje van, ezt a php.net Supported Versions oldala teszi közzé, és a lejárt ágra már biztonsági javítás sem jön.
Egy rendesen végzett frissítési kör lépései a következők.
- Friss mentés készül, és ellenőrzik, hogy a mentésfájl tényleg létrejött és nem üres.
- Átnézik, mi vár frissítésre. WordPress-oldalon ez parancssorból is látszik a WP-CLI hivatalos parancsaival, például
wp core check-updateéswp plugin list --update=available. - A nagyobb ugrásoknál (főverzió, PHP-váltás, oldalépítő új generációja) elolvassák a változásnaplót, és először tesztkörnyezetben (staging) próbálják ki.
- Frissítenek, majd végigkattintják a fontos útvonalakat, vagyis a főoldalt, az űrlapküldést, a kosarat, a fizetést és a belépést.
- Feljegyzik, mi frissült, mikor, és jelentkezett-e hiba.
Szakmai feltételezés. A kisebb biztonsági kiadások automatikus telepítése a legtöbb oldalon vállalható kockázat, a főverziók és a PHP-váltás viszont felügyeletet igényel, mert ezeknél a legnagyobb az esélye, hogy egy régebbi bővítmény vagy egyedi kód nem bírja a változást.
Mit jelent a mentés, és miért kevés annyi, hogy „van mentés”?
A mentés az oldal fájljainak és adatbázisának másolata, amiből egy korábbi állapot visszaállítható. Csak akkor ér valamit, ha az oldaltól külön helyen tárolódik, elég régre visszanyúlik, és teljes.
- Hely. Ha a mentés ugyanazon a tárhelyen van, mint az oldal, akkor egy feltörés, egy tárhelyhiba vagy egy felmondott tárhelyfiók a mentést is magával viheti. A széles körben használt 3-2-1 szabály három példányt, két különböző tárolót és egy máshol tartott példányt ajánl.
- Gyakoriság. Egy ritkán változó bemutatkozó oldalnál elég lehet a heti mentés. Webshopnál az adatbázist gyakrabban érdemes menteni, mert minden rendelés ott keletkezik.
- Megőrzési idő. Egy fertőzés hetekig rejtve maradhat. Ha csak az utolsó hét napot őrzik, előfordulhat, hogy minden mentés már a fertőzött állapotot tartalmazza.
- Teljesség. Kell a fájlrendszer (feltöltött képek, téma, bővítmények), az adatbázis és a konfiguráció is (WordPressnél a
wp-config.phpés a.htaccess). - Hozzáférés. Tudd, hol vannak a mentések, és legyen módod letölteni őket akkor is, ha a fejlesztővel megszakad a kapcsolat.
Saját tapasztalat. Átvételnél rendszeresen előfordul, hogy a mentés ugyanazon a tárhelyen, ugyanabban a fiókban van, mint az élő oldal, és a tulajdonos erről nem tud. Ez papíron mentés, a gyakorlatban egy feltörésnél vagy tárhelyhibánál keveset ér.
Mi az a visszaállítási próba, és miért ezt kérd számon?
A visszaállítási próba során egy mentésből ténylegesen felállítják az oldalt egy külön környezetben, és megnézik, hogy működik-e. Ez az egyetlen kézzelfogható bizonyíték arra, hogy baj esetén vissza lehet hozni az oldalt.
A mi nézőpontunk az, hogy megrendelőként a működő visszaállítást kell számon kérned. A havi riportban jól mutat a „47 frissítés”, de ebből semmit nem tudsz meg arról, hogy egy feltörés vagy egy elrontott frissítés után vissza lehetne-e állni egy tiszta állapotra. Egy riport, amelyben az áll, hogy a múlt negyedévben egy véletlenszerűen kiválasztott mentésből felállt az oldal, és a kosár meg az űrlap is működött, sokkal többet mond.
Hivatalosan igazolt. Az amerikai NIST SP 800-34 útmutató (informatikai vészhelyzeti tervezés) a helyreállítási tervek rendszeres tesztelését a terv részének tekinti. Ez nagyvállalati keretrendszer, de a gondolat egy kis cégre is igaz.
Egy egyszerű próba menete a következő.
- Kiválasztanak egy mentést, lehetőleg nem a legfrissebbet.
- Üres tesztkörnyezetbe töltik vissza, ami jelszóval védett és a keresők elől el van zárva.
- Ellenőrzik, hogy betölt-e az oldal, megvannak-e a képek, működik-e a belépés, az űrlap és webshopnál a kosár.
- Lemérik, mennyi ideig tartott a teljes visszaállítás.
- Az eredményt írásban rögzítik, a tesztkörnyezetet pedig törlik.
Saját tapasztalat. Az első próba gyakran hibát hoz felszínre. Kimaradt a médiamappa, az adatbázis túl nagy a visszatöltő eszköznek, vagy senkinél nincs meg a titkosított mentés jelszava. Ezeket jobb egy nyugodt napon megtudni.
Mit jelent a felügyelet?
A felügyelet automatikus figyelés, ami szól, ha az oldal leáll, lelassul, lejár a tanúsítványa vagy a domainje, sikertelen a mentés, vagy gyanús változás történik a fájlokban.
- Elérhetőség-figyelés pár percenként, riasztással egy megnevezett embernek.
- Az SSL-tanúsítvány és a domain lejáratának figyelése.
- Fájlváltozás-figyelés és kártevő-keresés.
- A mentések sikerességének ellenőrzése, mert a mentő bővítmény is leállhat csendben.
- Az űrlapértesítők kézbesítésének figyelése (SPF, DKIM, DMARC beállítások).
- A Google Search Console Biztonsági problémák jelentésének követése.
Saját tapasztalat. A legalattomosabb hiba a csendes. Az űrlap látszólag működik, a látogató megkapja a köszönő oldalt, de az értesítő levél a spam mappába kerül vagy meg sem érkezik, és ez hetekig senkinek nem tűnik fel.
Mi történhet, ha senki nem foglalkozik ezekkel?
A leggyakoribb következmény az ismert sérülékenységen keresztüli feltörés, a frissítés után összeomló oldal használható mentés nélkül, és a tárhelyszolgáltató PHP-váltása után megálló régi oldal.
Hivatalosan igazolt. A Google Search Central dokumentációja szerint a feltört oldalakat a Google a találati listában figyelmeztetéssel jelölheti, a Safe Browsing pedig a böngészőben is figyelmeztető oldalt mutathat. Ha az incidens személyes adatot érint (például egy webshop vásárlói adatait), a GDPR 33. cikke szerint az adatkezelőnek a felügyeleti hatóság felé bejelentési kötelezettsége lehet, a rendeletben rögzített határidőn belül.
Szakmai feltételezés. Egy feltörés utáni takarítás, helyreállítás és a keresőkben a figyelmeztetés megszüntetése jellemzően többszörös munkát jelent egy rendszeres karbantartáshoz képest, és közben az oldal bevétele és megkeresései is kieshetnek. Ezt pontosan előre kiszámolni nem lehet, mert a kár mértéke a fertőzés típusán múlik.
Mi legyen benne a karbantartási szerződésben?
A szerződésben legyen leírva, mit mentenek és hova, hogyan próbálják vissza, hogyan jelezheted a hibát, és mi számít külön munkának. Az alábbi ellenőrzőlistát érdemes végigvenni az ajánlat mellett.
- Hatókör. Melyik oldal, melyik domain, és melyik komponensek tartoznak bele (mag, bővítmények, téma, PHP-környezet).
- Frissítési rend. Milyen gyakran frissítenek, mi megy automatikusan, mi kézzel, és van-e tesztkörnyezet a nagyobb váltásokhoz.
- Mentések helye. Melyik szolgáltatónál, melyik országban vannak, külön szerveren-e, mennyi ideig őrzik őket, és te le tudod-e tölteni bármikor.
- Visszaállítási próba. Milyen gyakran végzik, mit ellenőriznek benne, és kapsz-e róla írásos eredményt a mért időtartammal.
- A reakció módja. Hol jelezheted a hibát (jegykezelő, e-mail, telefon), ki válaszol, mi számít sürgős hibának (nem tölt be az oldal, nem megy a fizetés), és munkaidőn kívül van-e elérés. Ha a szolgáltató reakcióidőt vállal, az is legyen leírva.
- Felügyelet. Mit figyelnek automatikusan, és ki kapja a riasztást.
- Riport tartalma. A mentések sikeressége, a próba eredménye, a talált és javított hibák, a darabszám csak kiegészítésként.
- Karbantartáson felüli munka. Új funkció, tartalomfeltöltés, design-módosítás, tárhelyköltöztetés, főverzió-váltás miatti átalakítás, és külön kérdésként a feltörés utáni takarítás. Legyen leírva, hogy ezek külön ajánlat alapján mennek, és előtte jóváhagyást kérnek tőled.
- Hozzáférések és kilépés. A domain, a tárhely és a főadmin a te nevedre szóljon. A szerződés megszűnésekor kapd meg az utolsó teljes mentést és minden belépést.
- Adatkezelés. Ha a karbantartó hozzáfér személyes adatokhoz, a GDPR 28. cikke szerint adatfeldolgozónak minősülhet, és ilyenkor erről írásos megállapodás kell.
Hogyan ellenőrizd, hogy a mostani karbantartásod működik-e?
Kérd el a legutóbbi visszaállítási próba eredményét és egy friss mentés pontos helyét. Ha erre nem jön gyors, konkrét válasz, az önmagában is jelzés.
- Hol van most a legutóbbi mentés, és melyik napon készült?
- Mikor állították vissza utoljára egy mentésből az oldalt, és mennyi ideig tartott?
- Melyik PHP-verzión fut az oldal, és az még kap-e biztonsági javítást?
- Van-e olyan bővítmény, ami több mint egy éve nem kapott frissítést?
- Ki kap értesítést, ha az oldal leáll, és te hogyan tudod ezt meg?
Ha ezekre most nem tudsz válaszolni, az nem feltétlenül jelent bajt, de azt igen, hogy nem látod az oldalad állapotát. Ilyenkor érdemes felmérést kérni az oldalad jelenlegi állapotáról. Egy jó felmérés megmutatja a verziókat, a mentések helyét és teljességét, a felügyelet hiányait, és azt, hogy egy visszaállítás ma működne-e. Ebből már el tudod dönteni, kell-e karbantartási szerződés, és ha igen, mit kérj bele. A felmérés eredményt nem garantál, de a döntésed tényeken alapul majd.
Források és további olvasnivalók
- WordPress.org dokumentáció, Updating WordPress és WordPress Backups
- WP-CLI hivatalos dokumentáció
- OWASP Top 10, Vulnerable and Outdated Components
- PHP.net, Supported Versions
- Google Search Central, feltört webhelyek és a Search Console Biztonsági problémák jelentése
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
- Az Európai Unió általános adatvédelmi rendelete (GDPR), 28. és 33. cikk
Gyakori kérdések
Kell-e karbantartás egy Wix vagy Shopify oldalra?
Szoftverfrissítés szempontjából ritkábban, mert azt a platform végzi. A domain, a mérőkódok, a tartalom és a hozzáférések rendben tartása itt is feladat, de ez jellemzően eseti munka.
Elég, ha a tárhelyszolgáltató ment?
Kiindulásnak jó, de nézd meg, hol tárolja a mentést, mennyi ideig őrzi, és vissza tudod-e állítani belőle önállóan az oldalt. Ha a mentés ugyanazon a szerveren van, egy szerverhiba mindkettőt érintheti.
Milyen gyakran kell visszaállítási próbát végezni?
Kötelező gyakoriság nincs. Szakmai feltételezés, hogy webshopnál és gyakran változó oldalnál negyedévente, egyszerű bemutatkozó oldalnál évente egyszer érdemes, és minden nagyobb átalakítás után.
Mit kérjek a havi riportban?
A mentések sikerességét, a legutóbbi visszaállítási próba dátumát és eredményét, a talált hibákat és a megoldásukat. A frissítések darabszáma csak kiegészítő adat.
Benne van-e a karbantartásban a feltört oldal helyreállítása?
Ez szolgáltatónként eltér, ezért a szerződésben külön rögzítsd. Ha nincs benne, legyen leírva, hogyan és milyen jóváhagyás után indul a munka.
Mi történik, ha megszűnik a karbantartási szerződés?
A szerződésben legyen rögzítve, hogy megkapod az utolsó teljes mentést és minden hozzáférést, a domain és a tárhely pedig eleve a te nevedre szóljon.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.