Leállt a webshop: ki a felelős, és hogyan előzd meg?

Egy webshop sosem egyetlen rendszer. Legalább öt szereplő kell ahhoz, hogy egy vásárlás végigmenjen, és bármelyik kiesése leállást okoz. A tárhely vagy szerver a legkézenfekvőbb gyanúsított: túlterhelés, betelt tárhely, memórialimit, néha tényleges hardverhiba. A DNS (a rendszer, ami a domain nevet a szerver címére fordítja) ritkábban hibázik, de amikor igen, az látványos: lejárt domain, elrontott rekord egy költözésnél, és az oldalad egyszerűen eltűnik a netről.

A leggyakoribb okot viszont nem kívül találod, hanem belül: ez a plugin-frissítés. WordPress és WooCommerce alatt egy automatikus frissítés simán összeakadhat a sablonnal vagy egy másik bővítménnyel (plugin), és az oldal vagy teljesen elszáll, vagy ami rosszabb, csak a pénztár romlik el. A fizetési kapu (a bankkártyás fizetést kezelő külső szolgáltatás) kiesése hasonlóan alattomos: a shop látszólag él, a termékoldalak töltenek, csak épp senki nem tud fizetni. Én ezt csendes leállásnak hívom, mert semmilyen hibaoldal nem jelzi. Az ötödik szereplő pedig az ember: egy fejlesztői módosítás, ami tesztelés nélkül ment ki élesbe, jellemzően péntek délután.

Mielőtt bárkit felhívnál, három perc alatt le tudod szűkíteni a kört. A sorrend számít, mert mindegyik lépés kizár egy-egy gyanúsítottat.

1. 01Nézd meg az oldalt mobilnetről is, ne csak a saját wifidről. Ha mobilnetről működik, a hiba nálad van, nem a shopnál.
2. 02Figyeld meg, pontosan mit látsz. A „nem található a kiszolgáló” jellegű üzenet DNS- vagy domain-problémára utal, az 500-as hibakód vagy a fehér oldal a szerveren futó kódra, a végtelen töltés inkább túlterhelésre.
3. 03Próbáld megnyitni az admin felületet. Ha az él, de a publikus oldal nem, szinte biztos, hogy sablon- vagy plugin-hiba van.
4. 04Nézd meg a tárhelyszolgáltató státuszoldalát, és gondold végig, ki nyúlt utoljára az oldalhoz: frissítés, új plugin, fejlesztői módosítás.

És van egy lépés, amit leállás nélkül is érdemes rendszeresen megtenned: vigyél végig egy teszt-rendelést a pénztárig. A csendes leállást csak így veszed észre, mert a főoldal attól még hibátlanul tölt, hogy a fizetés napok óta halott.

A kényelmetlen válasz: alapból szinte senki. A tárhelyszolgáltatód 99,9%-os rendelkezésre állást ígér, ami jól hangzik, amíg ki nem számolod: évi nagyjából 8,7 óra kiesés még bőven belefér. Ráadásul ez a vállalás csak a szerverre vonatkozik. Ha a szerver fut, de az oldalad egy plugin-ütközés miatt fekszik, az az ő szemszögükből nem leállás. Jogosan, mert a te alkalmazásodért nem ők felelnek.

A fejlesztő felelőssége pedig attól függ, mit írtatok le előre. Ha projektalapon dolgozott neked, és a projekt lezárult, akkor a hétvégi tűzoltás jóindulat kérdése, nem kötelesség. Pontosan erre való az SLA (a szolgáltatási szintet, például a garantált reakcióidőt rögzítő megállapodás). Nálam ez a karbantartási csomag része, ami nettó 10 000 Ft/hó ártól indul és modulárisan bővíthető: standard szinten 72 órán belül reagálok, priority csomagnál 48, criticalnál 24, emergency szinten pedig 8 órán belül, munkaidőben, 8:00 és 18:00 között. Hétvégi lefedettséget kiegészítőként lehet hozzátenni.

A felelősség nem a leállás után dől el, hanem előtte. Amire nincs írásban rögzített reakcióidő, arra csak jóindulat van, és a jóindulat pont akkor nem elérhető, amikor a legnagyobb szükséged lenne rá.

Hozzáteszem: nem minden webshopnak kell fizetett SLA. Ha az oldal havi pár tízezer forint bevételt hoz, vagy inkább katalógus, mint bolt, akkor egy megbízható tárhely, egy működő mentés és egy ingyenes uptime-figyelő bőven elég lehet. Az SLA ott kezd megtérülni, ahol egy nap kiesés már több pénzbe kerül, mint egy év karbantartás.

A leállások jó része nem balszerencse, hanem hiányzó rutin. Négy dolog lefedi a kockázat nagy részét. Az első a monitoring: egy uptime-figyelő percenként vagy ötpercenként ránéz az oldaladra, és azonnal riaszt, ha baj van. Így nem az ügyfeledtől tudod meg, hanem a telefonodtól, és a hibakeresés órákkal korábban indul.

A második a mentés, de nem akármilyen: olyan, ami a tárhelytől független helyre is kerül, és amit legalább egyszer visszatöltöttél próbaképp. A mentés, amit sosem teszteltél, csak remény. A harmadik a staging környezet (az éles oldal másolata, ahol előbb kipróbálsz mindent): frissítés, új plugin, fejlesztői módosítás soha nem élesben landol először.

A negyedik a frissítés-fegyelem. Az automatikus mindent-frissítés élesben orosz rulett, a hónapokig halogatott frissítés viszont növekvő biztonsági rés. A kettő között van az arany középút: heti vagy kétheti, staging környezetben tesztelt frissítési kör. Egy WooCommerce-shopnál ez hatványozottan igaz, mert a webshop-, fizetési és szállítási bővítmények verziói egymásra is érzékenyek. Ha ez a rendszer most nincs meg nálad, a WooCommerce-fejlesztés és mentés oldalon leírom, hogyan szoktam felépíteni.

Ha ebből a cikkből egyetlen dolgot viszel el, az legyen ez: még ma állíts be egy uptime-figyelőt, és vigyél végig egy teszt-rendelést a saját shopodban. Húsz perc az egész, és onnantól nem vakon üzemelsz. Ha pedig kíváncsi vagy, mennyire stabil most az oldalad, van egy ingyenes technikai átvilágításom, ami pár perc alatt lefut, és rövid összefoglalót ad a kritikus pontokról. A leggyakoribb üzemeltetési kérdéseket pedig külön összegyűjtöttem a GYIK-oldalon, érdemes ott is körülnézned, mielőtt a következő frissítést elindítod.