ვებსაიტის გადატანა: როგორ შეიცვალოს სერვერი

ჰოსტინგის შეცვლა საქმეა, რომელსაც ბიზნესების უმეტესობა რამდენიმე წელიწადში ერთხელ აკეთებს და ყოველ ჯერზე ღელავს. ღელვის მიზეზი ცხადია: თუ ოპერაციისას საიტი მიუწვდომელი გახდა ან ელფოსტები დაიკარგა, ამას კლიენტი ამჩნევს. არადა, გადატანა, თანმიმდევრობის სწორად აწყობისას, უწყვეტად შესასრულებელი რუტინული ოპერაციაა; პრობლემები თითქმის ყოველთვის გამოტოვებული მოსამზადებელი ნაბიჯიდან იბადება.
საიტის გადატანისას შეფერხება იქნება?
სწორად კეთებისას — არა. მიზეზი ასეთია: ძველი სერვერი ახლის მზადყოფნამდე არ ითიშება. ახალ სერვერზე საიტი იდგმება და იტესტება, შემდეგ დომენის მიმართულება ახალ მისამართზე გადადის. მიმართულების ცვლილების გავრცელებისას ვიზიტორთა ნაწილი ძველზე მიდის, ნაწილი ახალზე — ორივე მუშა მდგომარეობაშია და შეფერხებას ვერავინ ხედავს. შეფერხება მხოლოდ მაშინ ხდება, როცა ძველი სერვერი ნაადრევად ითიშება ან ახალი საკმარისად დაუტესტავად გადადის.
გადატანამდე ინვენტარი შეადგინეთ
გადასატანი მხოლოდ ფაილები არ არის. დავიწყებული პუნქტები გადასვლიდან დღეების შემდეგ „ესეც აღარ მუშაობს თურმე“-ს სახით ჩნდება. მინიმუმ ეს ჩამოწერეთ:
- საიტის ფაილები და, თუ არის, ატვირთვების საქაღალდეები (გამოსახულებები, დოკუმენტები).
- მონაცემთა ბაზა და კავშირის ინფორმაცია.
- ელფოსტის ანგარიშები, ყუთებში არსებული წერილები, გადამისამართებები და ალიასები.
- ყველა DNS ჩანაწერი: A, AAAA, MX, TXT (SPF, DMARC, ვერიფიკაციის ჩანაწერები), CNAME, CAA.
- SSL სერტიფიკატი და განახლების მეთოდი.
- დაგეგმილი დავალებები (cron), თუ არის — ფონურად მომუშავე სერვისები.
- მესამე მხარის კავშირები: გადახდის პროვაიდერი, კურიერის ინტეგრაცია, ელფოსტის გაგზავნის სერვისი. ზოგი სერვერის IP მისამართის მიხედვით იძლევა ნებართვას და IP-ს შეცვლისას არ მუშაობს.
ამ სიის წერილობით შედგენა გადატანის ყველაზე სასარგებლო ნაბიჯია. ბოლო პუნქტი განსაკუთრებით ხშირად გამოიტოვება და გადასვლის შემდეგ გადახდის ან კურიერის ინტეგრაციის ჩუმად გაჩერებას იწვევს.
TTL წინასწარ დაწიეთ
DNS-ის თითოეულ ჩანაწერს TTL მნიშვნელობა აქვს: ის ამბობს, რამდენ ხანს ინახება ეს ჩანაწერი ქეშში. ნაგულისხმევი მნიშვნელობა უმეტეს ადგილას რამდენიმე საათია.
გადასვლამდე ერთი დღით ადრე TTL მნიშვნელობა 300 წამამდე (5 წუთი) დაწიეთ. ასე გადასვლის მომენტში მიმართულება სწრაფად ვრცელდება და ორ სერვერს შორის გაყოფილი ტრაფიკის დრო მოკლდება. გადასვლის დასრულებისა და ყველაფრის მუშაობის დადასტურების შემდეგ TTL ძველ მნიშვნელობას დაუბრუნეთ.
ეს ერთი ნაბიჯი გადატანას „რამდენიმე საათი შეშფოთებული ლოდინიდან“ „რამდენიმეწუთიან გადასვლად“ აქცევს.
ფაილები და მონაცემთა ბაზა
ფაილების გადატანისას დირექტორიების უფლებები და დამალული ფაილები (.htaccess, .env და მსგავსი) არ გამოტოვოთ; ყველაზე ხშირი „საიტი გაიხსნა, მაგრამ დამახინჯებულია“-ს სიტუაცია ნაკლული კონფიგურაციის ფაილიდან იბადება.
ბაზაში თანმიმდევრობა მნიშვნელოვანია: ჯერ ფაილები გადაიტანეთ, ბოლოს ბაზის სარეზერვო ასლი აიღეთ და გადაიტანეთ. თუ ამ დროის განმავლობაში საიტზე ახალი ჩანაწერი შეიქმნა (ფორმის შეტყობინება, შეკვეთა), ის ჩანაწერები ძველ ბაზაში რჩება. ინტენსიურად მომუშავე საიტებზე ამიტომ გადასვლა ყველაზე დაბალი ტრაფიკის საათზე იგეგმება.
ბაზის გადატანის შემდეგ კავშირის ინფორმაციის ახალი სერვერის მიხედვით განახლება არ დაგავიწყდეთ. ასევე, თუ საიტში ძველ სერვერზე ან ძველ დომენზე ჩაშენებული აბსოლუტური მისამართებია, ისინიც უნდა გასწორდეს.
ელფოსტა ცალკე საქმეა
ჰოსტინგის შეცვლისას მონაცემების ყველაზე დიდი დანაკარგი ელფოსტის მხარეს ხდება, რადგან ყუთებში არსებული წერილები ფაილების გადატანით არ მოდის.
ახალ სერვერზე ანგარიშები შექმენით, შემდეგ არსებული წერილები IMAP-ით დააკოპირეთ. ეს მეთოდი საქაღალდეების სტრუქტურას, წაკითხულ/წაუკითხავ სტატუსებსა და დანართებს ინარჩუნებს და წყარო ყუთს არ ეხება. გადატანის დასრულების შემდეგ ძველი ანგარიშები მაშინვე ნუ დახურავთ; MX ჩანაწერის გავრცელებისას კიდევ რაღაც დროით ძველ სერვერზე შეიძლება ჩავარდეს ელფოსტა. რამდენიმე კვირა ღიად დატოვება და ბოლოს მოსულების გადატანაც ყველაზე უსაფრთხო გზაა.
გამოქვეყნებამდე შეამოწმეთ
ახალი სერვერის ტესტირება დომენის იქ მიმართვამდე შეიძლება. თქვენი კომპიუტერის hosts ფაილში ახალი სერვერის IP მისამართის ჩაწერით საიტს მხოლოდ საკუთარ მანქანაზე ახალი სერვერიდან ხსნით. ასე ვიზიტორები ძველი სერვერიდან განაგრძობენ მომსახურების მიღებას, თქვენ კი ახალს რეალური დომენით ცდით.
ტესტში ამას დახედეთ: მთავარი და შიდა გვერდები იხსნება? ფორმის გაგზავნა მუშაობს? მართვის პანელში შესვლა შესაძლებელია? გამოსახულებები და ატვირთული ფაილები ჩანს? გადახდის ეტაპი ბოლომდე მიდის?
გადასვლის მომენტი
თუ ყველაფერი შემოწმებულია, გადასვლა მოკლეა: დომენის A ჩანაწერს (და, თუ საჭიროა, MX ჩანაწერებს) ახალ სერვერზე ცვლით. რადგან TTL დაბალია, გავრცელება წუთებში სრულდება.
გადასვლისას ძველი სერვერი მუშა მდგომარეობაში დატოვეთ. ზოგი ვიზიტორი და ზოგი ქსელი ძველ ჩანაწერს კიდევ რაღაც დროით იყენებს; სანამ ორივე მხარე ფეხზე დგას, ეს უხილავია.
SSL სერტიფიკატი ახალ სერვერზე გადასვლამდე მოამზადეთ. თუ სერტიფიკატის ვერიფიკაცია დომენის მიმართულებას უყურებს, გადასვლისთანავე შექმენით — ამ მოკლე ფანჯარაში ბრაუზერებმა შეიძლება უსაფრთხოების გაფრთხილება აჩვენონ.
საკონტროლო სია გადასვლის შემდეგ
- საიტი ორივე მისამართზე (www-თი და www-ს გარეშე) იხსნება?
- SSL ვალიდურია, ბრაუზერი გაფრთხილებას იძლევა?
- ფორმის გაგზავნა ელფოსტად აღწევს?
- ახალი მისამართიდან გაგზავნილი ელფოსტა სპამში ვარდება? SPF, DKIM და DMARC ჩანაწერები ახალი სერვერის მიხედვით განახლდა?
- დაგეგმილი დავალებები მუშაობს?
- საძიებო სისტემა გვერდებს ნორმალურად სკანერებს, სერვერის შეცდომას ხედავს?
- შიდა ბმულები და ფაილების მისამართები გატეხილია?
ბოლო პუნქტის ხელით შემოწმება რთულია; ბმულების შემოწმების გაშვება გადატანის შემდეგ გაჩენილ გატეხილ მისამართებს სწრაფად აჩვენებს.
უკან დაბრუნების გეგმა
გადატანის ყველაზე დამამშვიდებელი მხარე უკან დაბრუნების სიმარტივეა — სანამ ძველი სერვერი ფეხზე დგას. თუ პრობლემა წარმოიშვა, DNS ჩანაწერს ძველზე ცვლით და, რადგან TTL დაბალია, რამდენიმე წუთში ბრუნდებით.
ამიტომ ძველი ჰოსტინგი გადასვლისთანავე ნუ გააუქმებთ. მინიმუმ ორი კვირა, თუ შესაძლებელია — ერთი თვე, ღიად დატოვეთ. ამ დროის განმავლობაში უკან დაბრუნების შესაძლებლობაც გაქვთ და, თუ გამორჩენილი ფაილი გამოჩნდა, წყაროსაც მიწვდებით.
ხშირი შეცდომები
- ძველი სერვერის ნაადრევად გათიშვა. შეფერხებებისა და მონაცემთა დანაკარგების მთავარი მიზეზი.
- ყველა DNS ჩანაწერის დაუკოპირებლობა. მხოლოდ A ჩანაწერის გადატანა და ვერიფიკაციის TXT ჩანაწერების დავიწყება ელფოსტასა და მესამე მხარის ინტეგრაციებს ჩუმად აფუჭებს.
- TTL-ის დაუწევლად გადასვლა. გავრცელება საათებზე იწელება, გაყოფილი ტრაფიკის დრო გრძელდება.
- სარეზერვო ასლის გარეშე დაწყება. გადატანამდე სრული სარეზერვო ასლი უკან დაბრუნების ბოლო გარანტიაა.
- ელფოსტის გადატანის შემდეგისთვის დატოვება. MX-ის შეცვლის შემდეგ ძველ ყუთზე წვდომა რთულდება.
ხშირად დასმული კითხვები
რამდენ ხანს გრძელდება გადატანა? მომზადების ჩათვლით პატარა საიტისთვის ნახევარი დღე, საშუალო ზომის ელკომერციისთვის ერთი სამუშაო დღე გონივრული შეფასებაა. თავად გადასვლის მომენტი წუთებით იზომება.
ჩემი საძიებო რეიტინგი დაზარალდება? სანამ მისამართები არ იცვლება — არა. რეიტინგზე თავად გადატანა კი არა, გადატანისას წარმოქმნილი ხანგრძლივი შეფერხებები ან გატეხილი მისამართები მოქმედებს.
თუ დომენსაც ვცვლი? მაშინ საქმე მხოლოდ გადატანა არ არის: ძველი მისამართები ახალზე 301 მუდმივი გადამისამართებით უნდა შეუსაბამოთ და ძველი დომენი მინიმუმ ერთი წელი უნდა შეინარჩუნოთ.
მიმდინარე DNS ჩანაწერების გადატანამდე შესანახად და გადასვლის შემდეგ გადასამოწმებლად DNS შემოწმების ინსტრუმენტი, გადატანის შემდეგ გატეხილი ბმულების აღმოსაჩენად კი ბმულების შემოწმების ინსტრუმენტი გამოიყენეთ.