Röviden
A frissítés sikerét nem a zöld üzenet bizonyítja. A saját üzleti funkciókat kell kipróbálni, és a teljes visszaállítást előre megtervezni.
Kezdd azzal, mit nem szabad elrontani
Írd össze a kritikus feladatokat: ajánlatkérés, bejelentkezés, vásárlás, fizetés, számlázás és e-mail-küldés. Egy egyszerű céges oldalnál öt rövid próba is elég lehet; egy webshopnál a rendelési útvonal több szereplőt és integrációt érint. Minden próbához legyen elvárt eredmény és felelős.
Jegyezd fel a WordPress, a PHP, a sablon és a fontos bővítmények jelenlegi verzióját. A frissítési lista mellett olvasd el a változásokat és a kompatibilitási megjegyzéseket. Ha egy egyedi módosításról nincs dokumentáció, előbb derítsd ki, hol található és mit csinál. A bizonytalan részeket ne az éles oldalon fedezd fel.
A mentés legyen teljes és visszaállítható
A WordPresshez a fájlok és az adatbázis együtt szükségesek. Az adatbázisban lehetnek a bejegyzések, beállítások és rendelések, a fájlok között pedig feltöltések, sablonok és bővítmények. Egyetlen letöltött könyvtár nem feltétlenül jelenti a teljes oldal mentését. Ellenőrizd, hogy a visszaállításhoz szükséges hozzáférések is rendelkezésre állnak.
A mentést ne csak elkészítsd: külön környezetben próbáld visszaállítani. Nyiss meg egy régebbi képet, lépj be, ellenőrizz egy terméket és egy fontos beállítást. A mentés időpontját rögzítsd. Ha közben rendelés érkezhet, az adatbázis visszaállítása rendelésvesztést okozhat; a leállási ablakot és az új adatok kezelését előre egyeztesd.
A tesztkörnyezetet válaszd le az éles üzletről
A tesztpéldányon tiltsd az indexelést, korlátozd a hozzáférést, és ne küldj valódi ügyfélleveleket. A fizetést tesztmódba állítsd, a számlázást és a készletkezelést pedig kezeld külön. Egy éles adatbázismásolat érzékeny ügyféladatot tartalmazhat, ezért a hozzáférést és a megőrzést is szabályozd.
Készíts a kritikus funkciókról frissítés előtti képernyőképet vagy rövid jegyzetet. Ne csak az asztali nézetet nézd: telefonon is nyisd meg a menüt és az űrlapot. A tesztkörnyezet eltérő gyorsítótára vagy PHP-beállítása elfedhet éles problémát, ezért a különbségeket dokumentáld.
Kis lépésekben frissíts és ellenőrizz
A megfelelő frissítési sorrend a függőségektől függ; nincs minden weboldalra jó bővítménylista. A kritikus elemeket teszteld elkülönítve, és rögzítsd, melyik változtatás után jelent meg hiba. A támogatott frissítési eljárást használd, egyedi fájlmódosítás előtt pedig legyen külön másolat.
Ha hibát látsz, ne folytasd találomra. Jegyezd fel a pontos műveletet, az időpontot és a hibaüzenetet. Nézd meg a releváns naplót, és csak a szükséges, titkokat nem tartalmazó részletet add tovább a fejlesztőnek. A jelszavak, kulcsok és személyes adatok nem tartoznak egy általános hibajegybe.
Élesítés után is legyen ellenőrzési kör
Az éles frissítést kisebb forgalmú időszakra időzítsd. Utána ismételd meg a kritikus próbákat, vizsgáld meg a hibajelzéseket, és ellenőrizd az e-mailek tényleges megérkezését. A visszaállítás feltételét előre határozd meg: például sikertelen fizetésnél ne várj a következő napig.
A lezárt napló tartalmazza a verziókat, a mentés helyét, a tesztek eredményét és a nyitott problémákat. A rendszeres karbantartás célja az, hogy ez a munkamenet ismételhető legyen. Az automatikus frissítés kényelmes, de a monitoringot és az üzleti funkciók ellenőrzését nem helyettesíti.
Példa: egy webshop fizetése hibás lesz
Képzelj el egy tesztet, amelyben a termékoldal és a kosár rendben működik, de a fizetési szolgáltató visszahívása után a rendelés nem vált állapotot. Ilyenkor a fizetési folyamatot kell elejétől végéig vizsgálni. A pénztár megnyitása önmagában nem bizonyítja, hogy a háttérben zajló értesítések, készletkezelés és e-mail-küldés is jó.
A teszt előtt készíts konkrét próbarendelést a megfelelő tesztmóddal. Rögzítsd a rendelési azonosítót és a várható állapotváltásokat. Valódi pénzügyi tranzakciót ne indíts pusztán azért, hogy egy frissítést ellenőrizz. A szolgáltatói tesztkörnyezethez tartozó kulcsokat és az éles beállításokat tartsd külön.
Mit tartalmazzon a karbantartási jelentés?
A jelentés rövid felsorolás helyett adjon ellenőrizhető eredményt: melyik komponens melyik verzióra változott, mikor készült mentés, mely műveleteket próbálták ki, és maradt-e teendő. A felügyelet, a frissítés és a hibajavítás munkaköre legyen előre tisztázva. Egy karbantartási szerződésből ne következtesd ki automatikusan, hogy az egyedi fejlesztés is benne van.
Ha egy bővítmény már nem támogatott, kérj helyettesítési tervet. A lecseréléshez az adatok átadása, a régi beállítások és a kapcsolódó sablonrészek felmérése is kellhet. A döntést az üzleti funkció és a karbantarthatóság alapján hozd meg, ne csak az alapján, hány napja jött ki új verzió.
- Mentés: fájlok és adatbázis, ismert visszaállítási eljárással.
- Funkciópróba: bejelentkezés, űrlap, vásárlás és értesítések.
- Átadás: verziók, ellenőrzött műveletek és nyitott feladatok naplója.
