ენა
ვებსაიტი უკვე ახალ სერვერზე იხსნება, მაგრამ თანამშრომლის წერილი დანიშნულების ადგილამდე აღარ მიდის. ასეთ დროს „მიგრაცია დასრულებულია“ ნაადრევი დასკვნაა. ვები და ელფოსტა შეიძლება სხვადასხვა მომწოდებელთან მუშაობდეს, ხოლო DNS ზონა მესამე სისტემაში იმართებოდეს. გადატანის გეგმამ ეს საზღვრები თავიდანვე უნდა გამოყოს.
გადატანის წინა დღე: შექმენით ინვენტარი
დაადგინეთ, ვინ ინახავს დომენის რეგისტრაციას, სად არის nameserver delegation, რომელი სისტემა მართავს DNS ზონას და ვინ ემსახურება საფოსტო ყუთებს. ცალკე მონიშნეთ საიტის სერვერი. ერთი კომპანიის პანელში რამდენიმე სერვისის ხილვა მათი ტექნიკური მართვის ერთიანობას არ ამტკიცებს.
ჩამოწერეთ პასუხისმგებელი პირები და წვდომები. ვებდეველოპერს შეიძლება DNS-ზე წვდომა ჰქონდეს, თუმცა mailbox-ის გადატანის უფლება არ ჰქონდეს. პაროლები სამუშაო ცხრილში არ შეინახოთ; მიუთითეთ უსაფრთხო წვდომის მფლობელი და გადაცემის შეთანხმებული მეთოდი.
ჩამოწერეთ სისტემები სახელებით და მიუთითეთ პასუხისმგებელი. „დომენზე წვდომა გვაქვს“ ბუნდოვანი ჩანაწერია: შეიძლება მხოლოდ რეგისტრატორის ანგარიშს გულისხმობდეს და DNS ზონის ცვლილების უფლებას საერთოდ არ მოიცავდეს. ანალოგიურად, ჰოსტინგის პანელი შეიძლება საიტის ფაილებს მართავდეს, ხოლო MX ჩანაწერები სრულიად სხვა მომწოდებლისკენ მიუთითებდეს.
აღრიცხეთ A/AAAA, CNAME, MX და mail-related TXT ჩანაწერები, მათ შორის DKIM selector-ები. მიუთითეთ TTL, მოქმედი მნიშვნელობა, დანიშნულება და ცვლილების საჭიროება. სხვა ბიზნესსერვისების verification ჩანაწერები შემთხვევით არ წაშალოთ. საჭიროებისას შეინახეთ ზონის ექსპორტი და current state-ის თარიღი.
ცვლილებამდე შეინახეთ DNS ზონის სრული ექსპორტი ან ისეთი ჩანაწერი, საიდანაც თითოეული record აღდგება. ეკრანის ერთი ფოტო ხშირად ვერ აჩვენებს გრძელ TXT მნიშვნელობას. განსაკუთრებით გადაამოწმეთ ქვედომენები, მესამე მხარის ვერიფიკაციის ჩანაწერები და DKIM selector-ები. საიტის გადატანა მათი წაშლის საფუძველი არ არის.
ფოსტისთვის ცალკე შეთანხმება გჭირდებათ
წინასწარ გადაწყვიტეთ, გადადის თუ არა mailbox-ები. თუ ფოსტა არსებულ პროვაიდერთან რჩება, სამუშაოს მიზანიც ეს უნდა იყოს: web-ის მისამართის შეცვლა ფოსტის განზრახ გადაადგილების გარეშე. თუ mailbox-ებიც გადადის, მოცულობის, სინქრონიზაციის, პაროლებისა და მომხმარებლის მოწყობილობების საკითხები ცალკე გეგმაში მოაქციეთ. წარსული წერილების ასლი და ახალი წერილების მიღება ერთი შემოწმება არ არის.
MX მიუთითებს შემომავალი ფოსტის მომსახურე სერვერს. SPF აღწერს შესაბამისი დომენით გამგზავნ უფლებამოსილ სისტემებს; იმავე სახელზე რამდენიმე დამოუკიდებელი SPF ჩანაწერის გამოქვეყნება სწორი მიდგომა არ არის. ერთი TXT ჩანაწერის რამდენიმე ტექსტურ ნაწილად დაყოფა სხვა შემთხვევაა.
DKIM წერილს დომენთან დაკავშირებული კრიპტოგრაფიული ხელმოწერით ამოწმებს; საჯარო გასაღები DNS-შია, private key კი გასაიდუმლოებულია. DMARC ამოწმებს ხილულ From დომენთან SPF-ის ან DKIM-ის alignment-ს. ერთი მექანიზმის ცალკე წარმატება ყველა სხვა პირობის სისწორეს არ ადასტურებს.
მიგრაციისას შეამოწმეთ ყველა ლეგიტიმური გამგზავნი: თანამშრომლების ფოსტა, საიტის ფორმა, ინვოისის სისტემა და მარკეტინგული პლატფორმა. მკაცრი DMARC პოლიტიკა შეუმოწმებლად არ გაააქტიუროთ. მოქმედი პოლიტიკისა და ცვლილების გეგმა mail provider-თან შეათანხმეთ.
გადართვის ფანჯარა
ქვემოთ მოცემული რიგი საორგანიზაციო ნიმუშია. ზუსტი ნაბიჯები დამოკიდებულია მოქმედ DNS პროვაიდერზე, ჰოსტინგზე და ფოსტის სისტემაზე. გამოყავით ცვლილება, მისი შემოწმება და შემდეგ ნაბიჯზე გადასვლის პირობა; რამდენიმე სისტემის ერთდროული შეუმოწმებელი ცვლილება მიზეზის პოვნას ართულებს.
- შეამოწმეთ ახალი გარემო DNS გადართვამდე და შეინახეთ მიღებული შედეგები.
- შეასრულეთ შეთანხმებული ბოლო სინქრონიზაცია და მონაცემის ჩაწერის მართვის გეგმა.
- შეცვალეთ მხოლოდ დაგეგმილი web ან mail ჩანაწერები; ზონის სრული ჩანაცვლება ცალკე გადაწყვეტილებაა.
- შეადარეთ authoritative DNS-ის პასუხი და ჩვეულებრივი resolver-ის პასუხი; განსხვავება ყოველთვის შეცდომას არ ნიშნავს.
- გაიარეთ ვების და ელფოსტის ცალ-ცალკე მიღების ტესტი და მხოლოდ შემდეგ დახურეთ ცვლილების ფანჯარა.
ჰიპოთეზურ example.com-ს ვებსაიტი ძველ ჰოსტინგზე აქვს, ელფოსტა კი ცალკე პროვაიდერთან. საიტის გადატანისას ახალი origin-ისთვის საჭირო ვებჩანაწერი იცვლება, MX კი იგივე შეიძლება დარჩეს. მხოლოდ ვებსაიტის გადასატანად nameserver-ის შეცვლა ავტომატურად საჭირო არ ხდება.
თუმცა საიტის საკონტაქტო ფორმის გამავალი SMTP ცალკე უნდა შემოწმდეს. თუ ფორმა ახალი სერვერის ადგილობრივ mail transport-ს იყენებს, წინა ავთენტიფიკაციის მოდელი შეიძლება აღარ იყოს შესაბამისი. სასურველია დადასტურებული გამგზავნი არხი და მისი საკუთარი ინსტრუქციების დაცვა.
ახალ ჰოსტზე საიტის შემოწმება მხოლოდ მთავარი გვერდის გახსნას ნუ დაეყრდნობა. ნახეთ მნიშვნელოვანი შიდა მისამართი, ფაილის ატვირთვა და ის ოპერაცია, რომელიც ბაზაში მონაცემს ინახავს. შემოწმების გზა ისე შეარჩიეთ, რომ ორივე გარემოში პარალელურად რეალური მომხმარებლის ურთიერთგამომრიცხავი მონაცემები არ გაჩნდეს. აქტიური მაღაზიისთვის ბოლო სინქრონიზაციისა და ჩაწერის ფანჯარა განსაკუთრებით მნიშვნელოვანია.
ვებგვერდი რომ მუშაობს, ფოსტაც გადაამოწმეთ
TTL-ის შემცირება ადრე შენახულ DNS პასუხებს მყისიერად არ აუქმებს. ცვლილების შემდეგ შეადარეთ authoritative პასუხი და მომხმარებლების მიერ გამოყენებული resolver-ები. ერთ მოწყობილობაზე სწორი შედეგი ყველა ქსელში დასრულებულ გადასვლას არ ამტკიცებს.
თუ mail provider-იც იცვლება, შეთანხმდით mailbox-ების პირველადი კოპირების, ბოლო სინქრონიზაციისა და გადასვლის დროზე. ცალკე შეამოწმეთ aliases, forwarding, shared mailbox და მოწყობილობების SMTP/IMAP პარამეტრები. მხოლოდ ახალი საფოსტო ყუთის შექმნა ძველ წერილებს არ გადაიტანს.
ელფოსტის ტესტში ცალ-ცალკე ჩაიწეროს გამავალი და შემომავალი მიმართულება. შეთანხმებული სატესტო წერილით გადაამოწმეთ გარე მისამართთან გაცვლა, მიღებული წერილის authentication შედეგი და ის SMTP ანგარიში, რომელსაც თვითონ საიტი იყენებს. თანამშრომლის mailbox-ის გამართული მუშაობა ჯერ კიდევ არ ადასტურებს, რომ საიტის ფორმის SMTP პარამეტრებიც სწორია.
უკან დაბრუნება რას ნიშნავს კონკრეტულად
DNS ჩანაწერის დაბრუნება უკვე სხვა სისტემაში მიღებულ წერილებს უკან არ გადაიტანს. ამიტომ rollback გეგმაში უნდა ეწეროს, სად ინახება თითოეულ ეტაპზე ახალი ფოსტა, ვინ აკეთებს საბოლოო სინქრონიზაციას და როდის შეიძლება ძველი სერვისის გაუქმება. მონაცემები ნაჩქარევად არ წაშალოთ.
Rollback-ს დროის ერთი პირობა არ ჰყოფნის. თუ ძველ გარემოში დაბრუნების შემდეგ უკვე ახალ სისტემაში მიღებული წერილები ან შექმნილი შეკვეთები დაიკარგება, უბრალოდ DNS მისამართის დაბრუნება საკმარისი გამოსავალი აღარ არის. წინასწარ გადაწყვიტეთ, რომელი გარემოა მონაცემის წყარო, როგორ შედარდება ცვლილებები და ვინ მიიღებს გადაწყვეტილებას.
რა უნდა დარჩეს სამუშაოს ჩაბარებისას
ჩაბარებისას დამკვეთს მიეცით მოკლე ჩანაწერი ჩვეულებრივი ენით: ვები სად მუშაობს, ფოსტა სად დარჩა ან გადავიდა, ვინ მართავს ზონას და რომელი ტესტები დასრულდა. დაუდასტურებელი ნაწილი ცალკე მიუთითეთ. ასე მომდევნო თანამშრომელს თავიდან აღარ მოუწევს გამოცნობა, თუ რომელი სისტემის შეცვლა იყო სამუშაოს მიზანი.
თუ გჭირდებათ ჰოსტინგის მიგრაცია, მოთხოვნას დაურთეთ ეს ინვენტარი და წერილობით გამოყავით mailbox-ების მოცულობა. ვებჰოსტინგის პაკეტის არჩევისას კი გადაამოწმეთ, რომელი სამუშაო შედის შეთავაზებაში და რომელი საჭიროებს ცალკე შეთანხმებას.
გადატანის შემდეგ გარემოს შერჩევისთვის გამოგადგებათ როგორ ავირჩიოთ ვებ ჰოსტინგი ბიზნეს საიტისთვის: 7 კითხვა ფასამდე.
DNS და mail authentication მექანიზმების ტექნიკური საფუძვლები: IETF - SPF, RFC 7208; IETF - DKIM, RFC 6376; IETF - DMARC, RFC 9989.
