Tárhelyköltözés: mi kerüljön az átállási tervbe?

Leltár a másolás előtt

Készíts listát a domainekről, weboldalakról, adatbázisokról, postafiókokról, ütemezett feladatokról és külső kapcsolódásokról. A tárhelyen lehet olyan aldomain vagy régi űrlap, amely nincs a főmenüben, mégis használatban van. A DNS-zóna és a levelezési beállítások mentését ne hagyd az utolsó percre.

Minden elemhez jelölj felelőst és tesztet. Egy kapcsolatfelvételi űrlapnál például a böngészős küldés és a levél beérkezése két külön ellenőrzés. A hozzáféréseket biztonságos csatornán kezeld. Az átállási dokumentumba ne másold be a jelszavakat; a hozzáférés helyét és jogosultját rögzítsd.

Külön teszteld az új környezetet

Másold át a fájlokat és az adatbázist, majd ellenőrizd a futtatókörnyezetet: verziók, kiegészítők, írási jogosultságok és háttérfeladatok. Az új címen vagy helyi névfeloldással próbáld ki az oldalt úgy, hogy az éles látogatók még a régi rendszert használják. Figyelj az SSL-tanúsítvány és az átirányítások működésére.

Ne tekintsd sikernek, ha csak a nyitólap látszik. Nyiss meg belső oldalt, képet, letöltést és adminfelületet is. A tesztben ellenőrizd a feltöltést és a levélküldést. Egy fájlmásolási hiba csak akkor derülhet ki, amikor a látogató egy ritkán használt dokumentumot keres.

DNS és levelezés: két külön változás

A weboldal címe és a levelezés útvonala nem ugyanaz a beállítás. A webes rekordok módosítása mellett az MX- és a kapcsolódó TXT-rekordokat külön ellenőrizd. Ha a levelezés marad a régi szolgáltatónál, az új DNS-zónában is meg kell őrizni a megfelelő rekordokat.

A TTL az előzményektől függően hat a gyorsítótárakra; a csökkentése nem törli azonnal a már eltárolt választ. Az átállás idején számolj azzal, hogy különböző látogatók eltérő szerverhez jutnak. A levelek tesztjét külső postafiókból befelé és kifelé is végezd el.

Mi történik az új adatokkal?

Egy bemutatkozó oldalon rövid szerkesztési szünet is elegendő lehet. Webshopnál vagy ügyfélrendszernél viszont a másolás óta új rendelések és felhasználók keletkezhettek. Határozd meg a végső adatátvitel időpontját, a karbantartási ablakot és azt, hogyan kerülhető el a párhuzamos írás.

Például ne indítsd újra az új webshopot egy tegnapi adatbázissal anélkül, hogy a közben beérkező rendeléseket egyeztetted volna. Az adatvesztés toleranciája üzleti döntés. Írd le, ki állíthatja le a folyamatot, és milyen helyzetben kell visszatérni a régi rendszerhez.

Átállás után és keresőszempontból

Ha csak a tárhely változik, a meglévő URL-eket tartsd meg. Domain- vagy útvonalváltozásnál külön URL-térképre és megfelelő átirányításokra van szükség. Ellenőrizd a canonical címeket, a belső linkeket, a sitemapet és azt, hogy a tesztkörnyezet noindex beállítása nem maradt-e az éles oldalon.

A régi környezetet csak az adategyeztetés és a megfigyelési időszak után zárd le. Ellenőrizd a hibanaplót, a forgalmat, az űrlapokat és a levelezést. A sikeres költözés lezárási jegyzőkönyve rövid is lehet: mit teszteltetek, mely adatok kerültek át, hol van mentés és maradt-e nyitott feladat.

Példa: a weboldal átkerül, a levelek eltűnnek

Gyakori félreértés, hogy a weboldal sikeres megnyitása a teljes domainköltözés sikerét bizonyítja. Ha az új névszervereken csak a webes rekordokat hozták létre, a levelezés útvonala hiányozhat. A bejövő levél ekkor nem feltétlenül jut a megszokott postafiókhoz. Előbb hasonlítsd össze a régi és az új zónát, majd ellenőrizd a levelezési szolgáltató előírt rekordjait.

A javítás előtt mentsd a pillanatnyi állapotot is. Egy kapkodva visszaállított teljes zóna a már működő weboldalt is visszaterelheti a régi tárhelyre. A webes és levelezési próbákat külön eredményként vezesd, és a felelősök azonos átállási jegyzetet használjanak.

Mikor tekinthető lezártnak a költözés?

A lezáráshoz legyen sikeres funkcióteszt, adategyeztetés és ismert mentési állapot. Ellenőrizd, nem fut-e ugyanaz az ütemezett feladat mindkét szerveren: például két rendszer egyszerre ne küldjön emlékeztetőket vagy számlázási kéréseket. A használaton kívüli régi környezet hozzáféréseit és díjait ezután lehet rendezni.

A keresőforgalmat és a hibás URL-eket az átállás után is figyeld. Az eltérés nem minden esetben költözési hiba, ezért konkrét címeket és időpontokat vizsgálj. A régi oldal lekapcsolásának időpontját ne egy általános napértékből vezesd le: a forgalom, gyorsítótárak, levelezés és visszaállítási igény alapján döntsetek.

• Leltár: weboldal, adatbázis, postafiókok és háttérfeladatok.
• Teszt: belső oldalak, fájlok, HTTPS és kétirányú levelezés.
• Visszaállítás: adatvesztési határ, felelős és működő mentés.