საიტის მიგრაცია ტექნიკურად შეიძლება რამდენიმე ბრძანებად გამოიყურებოდეს: ფაილები გადაიტანე, database ჩაასხი, DNS შეცვალე. რეალურ პროექტში ყველაზე მეტი პრობლემა სწორედ იმ ნივთებიდან მოდის, რომლებიც ამ სამ სიტყვაში არ ჩანს - cron jobs, mailboxes, API keys, PHP extensions, DNS records, uploads, checkout და მონაცემი, რომელიც მიგრაციის პროცესშიც იცვლება.
ამიტომ migration-ს ერთ მოვლენად კი არა, პატარა timeline-ად ვგეგმავდი.
თუ SERVER1-ზე გადმოტანას გეგმავთ, ჰოსტინგის მიგრაციის სერვისი სწორედ ფაილების, ბაზების, ელფოსტისა და გაშვების შემდგომი შემოწმების პროცესზეა აგებული; scope კონკრეტული პროექტის მიხედვით წინასწარ უნდა გაიწეროს.
T−7 დღე - inventory, სანამ რამეს შეეხებით
ჩამოწერეთ ყველაფერი, რაც ძველ გარემოზეა დამოკიდებული
- domains და subdomains;
- databases და users;
- mailboxes და mail-related DNS;
- SSL certificates;
- cron/scheduled tasks;
- PHP/runtime versions და extensions;
- external APIs, payment callbacks და IP allowlists.
თუ dependency ამ სიაში არ მოხვდა, დიდია შანსი cutover-ის შემდეგ გაგახსენდეთ.
ახალი გარემოს არჩევამდე ასევე გადაამოწმეთ ჰოსტინგ პაკეტის შერჩევის კრიტერიუმები, რათა migration-ის შემდეგ ისევ რესურსის დეფიციტით არ დაიწყოთ.
T−1 დღე - ახალი VPS უკვე უნდა იყოს სატესტოდ მზად
DNS ჯერ არ შეცვალოთ
ახალი გარემო შეგიძლიათ hosts-file override-ით ან staging hostname-ით შეამოწმოთ. გაიარეთ login, forms, uploads, checkout, background jobs და outbound mail. შეადარეთ PHP/runtime configuration და permissions ძველ გარემოს.
თუ WordPress გადააქვთ, სასარგებლოა ასევე WordPress Toolkit-ის შესაძლებლობების ცოდნა, განსაკუთრებით თუ Plesk-ს იყენებთ.
Cutover-ის დაგეგმვისას downtime-ის მიზეზებისა და გავლენის წინასწარ გააზრება დაგეხმარებათ, რომ maintenance window რეალისტურად განსაზღვროთ.
T0 - cutover-ის დღე
ჯერ final sync, მერე DNS
დინამიკურ საიტზე პირველი copy-ის შემდეგ მონაცემი ისევ იცვლება. ონლაინ მაღაზიაში შეიძლება ახალი შეკვეთა შემოვიდეს, მომხმარებელმა ფაილი ატვირთოს ან ადმინისტრატორმა კონტენტი შეცვალოს. ამიტომ cutover-მდე საჭიროა final sync ან მოკლე maintenance window.
შემდეგ იცვლება DNS. ამ დროს ორივე გარემო მზად უნდა იყოს, რადგან propagation-ის პერიოდში სხვადასხვა მომხმარებელი დროებით სხვადასხვა სერვერს შეიძლება ხედავდეს.
T+1 დღე - ძველი სერვერი ჯერ არ გამორთოთ
ნახეთ არა მხოლოდ homepage, არამედ ბიზნეს ფუნქციები
შეამოწმეთ web-server logs, error logs, mail delivery, scheduled jobs, payment callbacks, SSL და analytics. ძველი ჰოსტინგი რამდენიმე დღე შეინარჩუნეთ როგორც fallback, სანამ დარწმუნდებით, რომ ახალი გარემო სრულად მუშაობს.
Rollback-ის პირობა წინასწარ დაწერეთ
თუ checkout არ მუშაობს, მონაცემები არ ემთხვევა ან critical integration ვერ დასტაბილურდა შეთანხმებულ დროში - ვბრუნდებით ძველ გარემოზე და პრობლემას მშვიდად ვასწორებთ.
ასეთი წინასწარი პირობა cutover-ის დროს ემოციურ გადაწყვეტილებებს ამცირებს.
Managed VPS-ის პროვაიდერმა მიგრაციაში შესაძლოა დაგეხმაროთ, მაგრამ ზუსტად უნდა იცოდეთ scope: შედის მხოლოდ ვებ-საიტი, თუ mail, DNS და application-specific სამუშაოებიც. კარგი მიგრაცია მთავრდება არა DNS-ის შეცვლით, არამედ იმ მომენტით, როცა ახალი გარემო დადასტურებულად მუშაობს და rollback აღარ გჭირდებათ.
