Կայքի միգրացիայի գործնական ուղեցույց 7 քայլով

Կայքի միգրացիայի գործնական ուղեցույցը սկսվում է աուդիտից

Նախ պարզեք, թե իրականում ինչ եք տեղափոխում։ Միայն կայքի public_html թղթապանակը հաճախ բավարար չէ։ WordPress, Joomla, Laravel և այլ հարթակներ պահում են կարևոր տվյալներ տվյալների բազայում, իսկ առանձին կառավարվող ծառայությունները կարող են ներառել էլ. փոստ, ենթադոմեններ, cron առաջադրանքներ, SSL վկայագրեր, վերահղումներ և DNS գրառումներ։

Գրեք գործող միջավայրի տեխնիկական պատկերը՝ PHP-ի տարբերակը, տվյալների բազայի տեսակը և տարբերակը, սկավառակի իրական օգտագործումը, ամսական տրաֆիկը, ակտիվ հավելումները, cache-ի մեխանիզմները և արտաքին ինտեգրացիաները։ Եթե կայքը ընդունում է օնլայն վճարումներ կամ պատվերներ, առանձնացրեք նաև այն համակարգերը, որոնք փոխանցում են webhook-եր, նամակներ կամ API հարցումներ։

Այս փուլում պետք չէ ենթադրել, որ «նոր սերվերը հաստատ ավելի հզոր է»։ Օրինակ՝ նոր VPS-ը կարող է ավելի շատ ռեսուրս տալ, բայց պահանջել սերվերի կառավարման գիտելիք։ Shared Linux hosting-ը կարող է ավելի հարմար լինել կայքի համար, որն ունի կանխատեսելի այցելություններ և կարիք չունի root հասանելիության։ Ընտրությունը կախված է ոչ միայն արագությունից, այլ նաև այն բանից, թե ով է պատասխանելու թարմացումների, պահուստների և անվտանգության համար։

1. Ստեղծեք անկախ պահուստ և ստուգեք այն

Պահուստը պետք է լինի ամբողջական և օգտագործելի։ Ներբեռնեք կայքի ֆայլերը, արտահանեք տվյալների բազան, պահպանեք կոնֆիգուրացիոն ֆայլերը և առանձին արձանագրեք էլ. փոստի հաշիվների ու փոխանցումների կարգավորումները։ Եթե հնարավոր է, պահուստը պահեք ոչ միայն հին հոսթինգի ներսում, այլ նաև առանձին անվտանգ պահոցում։

Մի սահմանափակվեք «backup completed» ծանուցմամբ։ Փորձնական միջավայրում բացեք տվյալների բազայի արտահանումը, ստուգեք արխիվի ֆայլերը և համոզվեք, որ վերականգնման համար ունեք անհրաժեշտ գաղտնաբառերը։ Ամենաանհարմար պահը վնասված պահուստ հայտնաբերելու համար DNS-ի փոփոխությունից հետո է։

2. Պատրաստեք նոր հոսթինգը մինչև տեղափոխումը

Նոր ծառայության վրա ստեղծեք դոմենը, տվյալների բազան, անհրաժեշտ օգտատերերին և համապատասխան PHP կարգավորումները։ Եթե կայքը պահանջում է հատուկ ընդլայնումներ, օրինակ՝ ionCube, Imagick կամ որոշակի PHP մոդուլներ, ստուգեք դրանք նախապես։ Laravel նախագծերի դեպքում հաշվի առեք environment ֆայլը, հերթերի մշակումը, scheduler-ը և գրելու թույլտվություն պահանջող թղթապանակները։

Ստեղծեք նաև անհրաժեշտ էլ. փոստի հաշիվները, բայց մի շտապեք ակտիվացնել MX գրառումների փոփոխությունը։ Այդպես կարող եք նախ համոզվել, որ նոր փոստային միջավայրը պատրաստ է, առանց ընթացիկ նամակագրությունը կտրելու։ Եթե օգտագործում եք Google Workspace կամ այլ արտաքին փոստային ծառայություն, միգրացիայի ընթացքում հատկապես ուշադիր պահպանեք MX, SPF, DKIM և DMARC գրառումները։

3. Կրճատեք DNS TTL-ը և պատճենեք տվյալները

DNS փոփոխությունից 24-48 ժամ առաջ TTL-ը կրճատեք, օրինակ՝ 300 կամ 600 վայրկյանի։ Սա նշանակում է, որ փոփոխությունից հետո ինտերնետային մատակարարների cache-երը սովորաբար ավելի արագ կթարմանան։ TTL-ի կրճատումը ակնթարթային արդյունք չի տալիս, քանի որ նախկին բարձր արժեքը կարող է դեռ պահպանված լինել որոշ resolver-ներում։ Այդ պատճառով այն պետք է անել նախօրոք, ոչ թե տեղափոխման պահին։

Այնուհետև պատճենեք ֆայլերը և տվյալների բազան նոր սերվեր։ Մեծ կայքերի համար ֆայլերի արխիվացումը և SFTP կամ rsync փոխանցումը հաճախ ավելի հուսալի է, քան հազարավոր փոքր ֆայլերի առանձին տեղափոխումը։ Տվյալների բազան ներմուծելուց հետո թարմացրեք կոնֆիգուրացիան՝ database host, անուն, օգտատեր և գաղտնաբառ։

Եթե URL-ները փոխվում են, օրինակ՝ կայքը տեղափոխվում է ժամանակավոր հասցեից հիմնական դոմեն, կատարեք վերահսկվող որոնում և փոխարինում տվյալների բազայում։ WordPress-ում պարզապես տեքստային փոխարինումը կարող է վնասել serialized տվյալները, ուստի օգտագործեք տվյալ հարթակին համապատասխան գործիք կամ փորձառու մասնագետի աջակցություն։

4. Փորձարկեք կայքը առանց հանրային DNS փոփոխության

Մինչև այցելուներին նոր սերվեր ուղղելը, ստուգեք կայքը hosts ֆայլի միջոցով կամ հոսթինգի տրամադրած ժամանակավոր հասցեով։ Սա թույլ է տալիս ձեր համակարգչից բացել դոմենը նոր IP-ով, մինչ մյուս օգտատերերը շարունակում են տեսնել գործող կայքը։

Փորձարկումը պետք է ներառի ոչ միայն գլխավոր էջը։ Բացեք ներքին էջեր, լրացրեք կապի ձև, փորձարկեք որոնումը, մուտք գործեք ադմին վահանակ, ստուգեք նկարների բեռնումը և դիտեք error log-երը։ Եթե կայքը վաճառք է կատարում, ավարտեք փորձնական պատվերի ամբողջ ընթացքը՝ զամբյուղից մինչև վճարման էջ և պատվերի նամակ։

Հատուկ ուշադրություն դարձրեք այս չորս կետերին.

• HTTPS վկայագիրը և ավտոմատ վերականգնումը
• 301 վերահղումները և www կամ non-www հիմնական տարբերակը
• Կոնտակտային ձևերից ուղարկվող նամակների առաքումը
• Կայքի արագությունը բջջային և աշխատասեղանի տարբերակներում

Եթե օգտագործում եք Cloudflare կամ այլ CDN, մի մոռացեք, որ cache-ը կարող է թաքցնել իրական խնդիրը։ Փորձարկման ընթացքում ժամանակավորապես մաքրեք cache-ը կամ համոզվեք, որ ստուգում եք նոր origin սերվերի պատասխանը։

5. Պլանավորեք վերջնական սինխրոնացումը

Կայքերը, որոնցում տվյալները հաճախ են փոխվում, չեն կարող պարզապես մեկ անգամ պատճենվել։ Նոր հոդված, պատվեր, օգտատեր կամ հայտ կարող է ավելացվել հենց այն ընթացքում, երբ դուք փոխանցում եք բազան։ Այդ պատճառով ընտրեք ցածր ակտիվության ժամ, սահմանափակեք ադմինիստրատիվ փոփոխությունները և կատարեք վերջնական տվյալների բազայի արտահանում։

Էլեկտրոնային առևտրի կամ բարձր տրաֆիկով մեդիա կայքի դեպքում կարող է պահանջվել կարճ սպասարկման ռեժիմ։ Դա ավելի լավ ընտրություն է, քան պատվերների կամ հրապարակումների լուռ կորուստը։ Օգտատերը կարող է ընդունել մի քանի րոպե սպասարկման էջ, բայց դժվար թե վստահի անհետացած վճարման կամ չպատասխանված հայտի դեպքում։

6. Փոխեք DNS գրառումները և պահեք հինը հասանելի

Միայն վերջնական սինխրոնացումից հետո փոխեք A կամ CNAME գրառումները դեպի նոր հոսթինգը։ Եթե դոմենը, հոսթինգը և DNS կառավարումը տարբեր մատակարարների մոտ են, նախապես համոզվեք, որ ունեք բոլոր հաշիվների հասանելիությունը և գիտեք փոփոխությունների պատասխանատու անձին։ Միգրացիայի օրը գաղտնաբառի վերականգնումով զբաղվելը ժամանակ է խլում և մեծացնում սխալի հավանականությունը։

Հին հոսթինգը մի անջատեք անմիջապես։ Պահեք այն ակտիվ առնվազն 48-72 ժամ, իսկ բարդ կամ միջազգային լսարան ունեցող կայքերի դեպքում՝ ավելի երկար։ DNS տարածումը տարբեր տարածաշրջաններում կարող է տարբեր արագություն ունենալ, և այդ ընթացքում հին սերվերը կպաշտպանի այն այցելուներին, որոնց cache-ը դեռ չի թարմացվել։

7. Վերահսկեք կայքը առաջին 72 ժամում

DNS փոփոխությունից հետո ստուգեք կայքը տարբեր ցանցերից և սարքերից։ Դիտարկեք uptime-ը, server error-երը, PHP log-երը, CPU և հիշողության օգտագործումը, ինչպես նաև նամակների առաքումը։ Եթե կայքը ունի վերլուծական համակարգ, համեմատեք տրաֆիկը, պատվերները և ձևերի լրացումները նախորդ օրերի տվյալների հետ։ Կտրուկ անկումը միշտ չէ, որ SEO խնդիր է. երբեմն այն պարզապես չաշխատող ձև կամ սխալ redirect է։

SEO տեսանելիությունը պաշտպանելու համար պահպանեք էջերի հասցեները, title-ները, canonical պիտակները և sitemap-ը։ Եթե URL կառուցվածքն անխուսափելիորեն փոխվել է, յուրաքանչյուր արժեքավոր հին հասցեի համար սահմանեք համապատասխան 301 վերահղում։ Բոլոր հին էջերը գլխավոր էջ վերահղելը հեշտ լուծում է, բայց օգտատիրոջ և որոնողական համակարգի համար հաճախ սխալ ազդանշան է։

Internet.am-ի նման մեկ վայրում դոմենի, հոսթինգի, SSL-ի և DNS-ի կառավարումը կարող է կրճատել միգրացիայի ընթացքում համակարգերի միջև շփոթը, հատկապես երբ պատասխանատու է փոքր թիմը։ Այնուամենայնիվ, նույնիսկ մեկ մատակարարի դեպքում փորձարկման և պահուստավորման փուլերը չպետք է բաց թողնել։

Միգրացիան հաջողված է ոչ այն ժամանակ, երբ նոր սերվերը բացվում է, այլ երբ հաճախորդը շարունակում է տեսնել արագ, անվտանգ և աշխատող կայք, իսկ ձեր թիմը գիտի, թե ինչպես վերականգնել այն ցանկացած անսպասելի իրավիճակում։