კონტენტზე გადასვლა

ვებსაიტები / UPSCALE JOURNAL

ვებსაიტის მოვლის გეგმა: განახლებები, სარეზერვო ასლები და შემოწმება

როგორ დაგეგმო საიტის მოვლა ისე, რომ განახლებას ახლდეს შემოწმება, პრობლემას — პასუხისმგებელი, ხოლო ასლს — გამოცდილი აღდგენა.

UpScale6 წუთის საკითხავი

ვებსაიტის მოვლის კალენდარი, სარეზერვო ასლი და შემოწმების ეტაპები

გამოქვეყნებული საიტი დასრულებული სამუშაოს მხოლოდ ერთი ეტაპია. იცვლება პროდუქტები, თანამშრომლები, დამატებები, გადახდის სერვისები და მომხმარებლის მოწყობილობები. მოვლის გეგმა განსაზღვრავს, ვინ ამჩნევს პრობლემას, ვინ ასწორებს და როგორ ბრუნდება გუნდი გამართულ მდგომარეობაში. კარგი გეგმა მოკლე და შესასრულებელია: მასში კონკრეტული მოქმედება, პასუხისმგებელი და შემოწმების შედეგი ჩანს.

1. ჯერ გაიგე, რას ეყრდნობა შენი საიტი

შექმენი სისტემების მოკლე სია: დომენი, ჰოსტინგი, კონტენტის მართვის სისტემა, თემა, მნიშვნელოვანი დამატებები, ელფოსტა და გარე ინტეგრაციები. თითოეულთან მიუთითე პასუხისმგებელი, განახლების ან ვადის დასრულების თარიღი და მხარდაჭერის გზა. პაროლები ამ ცხრილში არ ჩაწერო; წვდომები დაცულად, შესაბამისი ადამიანებისთვის შეინახე.

სია განსაკუთრებით მნიშვნელოვანია, როცა საიტზე რამდენიმე შემსრულებელი მუშაობდა. შეიძლება დიზაინს ერთი გუნდი მართავდეს, გადახდის ინტეგრაციას მეორე, ხოლო დომენი ყოფილი თანამშრომლის ანგარიშზე იყოს. ასეთი გაურკვევლობა პრობლემისას დროს კარგავს. წინასწარ განსაზღვრე, ვის შეუძლია გადაწყვეტილების მიღება და ვის აქვს ტექნიკური მოქმედების უფლება. თანამშრომლის ცვლილებისას გადაამოწმე საჭირო წვდომები და შეტყობინებების მიმღებები. საბაზისო ინვენტარი ახალი ვებპროექტის ბრიფსაც დაეხმარება, თუ მომავალში რედიზაინს გადაწყვეტ.

2. სარეზერვო ასლის არსებობა აღდგენით გადაამოწმე

WordPress-ის სრული აღდგენისთვის ჩვეულებრივ საჭიროა მონაცემთა ბაზაც და ფაილებიც. მხოლოდ ფოტოებისა და თემის ჩამოტვირთვა შეკვეთებსა და სტატიებს სრულად ვერ შეინახავს. ოფიციალური WordPress-ის სარეზერვო ასლების გზამკვლევი ამ ორ ნაწილს ცალკე აღწერს და ასლების სხვადასხვა ადგილას შენახვას განიხილავს.

გეგმისთვის უპასუხე ორ ბიზნესკითხვას: რამდენი ახალი მონაცემის დაკარგვაა მისაღები და რამდენ ხანში უნდა აღდგეს მუშაობა? ხშირად განახლებულ მაღაზიას და იშვიათად შეცვლილ პორტფოლიოს განსხვავებული საჭიროება აქვთ. შეათანხმე სარეზერვო ასლების სიხშირე ამ განსხვავების მიხედვით. პერიოდულად ცალკე გარემოში აღადგინე ასლი და შეამოწმე გვერდები, მედია და საჭირო ჩანაწერები. წარმატებული შეტყობინება „ასლი შეიქმნა“ ჯერ არ ადასტურებს, რომ აღდგენის პროცესი გამოცდილია. შედეგს დაურთე თარიღი და პასუხისმგებელი.

3. განახლების წინ სატესტო გარემო მოამზადე

ცვლილების გამოსაცდელად გამოიყენე საიტის ცალკე ასლი, სადაც რეალური მომხმარებელი ვერ მოხვდება და შემთხვევით შეკვეთას ვერ გააკეთებს. შეზღუდე მასზე წვდომა, გამორთე რეალურ მიმღებებთან წერილები და გადახდისთვის გამოიყენე შესაბამისი სატესტო რეჟიმი. საჯარო საცდელ საიტზე მომხმარებლების მონაცემების გამოჩენა გამოსაცდელი სამუშაოს ნაწილი არ უნდა გახდეს.

WooCommerce განახლებების წინ სარეზერვო ასლსა და staging გარემოში შემოწმებას რეკომენდაციას უწევს — WooCommerce-ის განახლების ინსტრუქცია. შენი გუნდისთვის წინასწარ ჩამოწერე აუცილებელი სცენარები: პროდუქტის გახსნა, ვარიანტის არჩევა, კალათა, გადახდა და შეტყობინება. სხვა ტიპის საიტზე ეს იქნება ფორმა, დაჯავშნა ან მასალის ჩამოტვირთვა. სატესტო გარემოში მიღებული შედეგი მხოლოდ მაშინ არის გამოსადეგი, როცა მნიშვნელოვანი პირობები რეალურ საიტთან საკმარისად ახლოსაა.

4. განახლებას დაბრუნების კონკრეტული გზა დაურთე

განახლებამდე ჩაიწერე, რა იცვლება და რატომ. შეამოწმე განახლების აღწერა, საჭირო თავსებადობა და ახალი სარეზერვო ასლის არსებობა. WordPress-ის ოფიციალური განახლების ინსტრუქცია წინასწარ ასლის შექმნას გამოყოფს, რათა პრობლემის შემთხვევაში აღდგენა შესაძლებელი იყოს. ყოველდღიური გადაწყვეტილება პასუხისმგებელ ტექნიკურ პირს მიაბარე.

საილუსტრაციო სცენარი: მაღაზიის დამატება განახლდა და შეკვეთის ფორმამ მუშაობა შეწყვიტა. გუნდი უკვე იცნობს დაბრუნების პროცედურას, თუმცა ძველი ბაზის აღდგენამდე ამოწმებს, ხომ არ შემოვიდა ახალი შეკვეთები. ეს გამოგონილი მაგალითია. ძველი ასლის მთელ საიტზე დაუფიქრებლად დაბრუნებამ ახალი მონაცემი შეიძლება დაკარგოს. ამიტომ ცვლილების ტიპისა და მიმდინარე აქტივობის მიხედვით ტექნიკურმა პასუხისმგებელმა უნდა შეარჩიოს აღდგენის გზა. ჩანაწერში უნდა ჩანდეს დაწყებისა და დასრულების დრო, გამოყენებული ვერსიები და შემოწმებული სცენარები.

5. ყოველ შემოწმებაზე მომხმარებლის მთავარი გზა გაიარე

საიტი შეიძლება იხსნებოდეს, მაგრამ მოთხოვნის წერილი აღარ მოდიოდეს. ამიტომ ხელმისაწვდომობის შემოწმებას მოქმედების შემოწმებაც დაუმატე. პერიოდულად გააგზავნე ცნობადად მონიშნული ტესტური ფორმა, გადაამოწმე წერილის მიღება და დარწმუნდი, რომ მას შესაბამისი ადამიანი ხედავს. ტესტური ჩანაწერი შემდგომ ანალიტიკასა და გაყიდვების ანგარიშში რეალურ მოთხოვნად არ უნდა ითვლებოდეს.

  • მთავარი გვერდი და მნიშვნელოვანი მომსახურებები იხსნება.
  • მობილური მენიუ, ღილაკები და ფანჯრების დახურვა მუშაობს.
  • ფორმის გაგზავნას მკაფიო დადასტურება მოჰყვება.
  • საკონტაქტო ინფორმაცია მოქმედ მონაცემებს ემთხვევა.
  • მაღაზიაში რაოდენობა, მიწოდება და საბოლოო თანხა სწორია.

შეინახე პრობლემა, მისი გამეორების ნაბიჯები და გამოსწორების შედეგი. თუ საკითხი კალათას ეხება, გამოიყენე მობილური შეკვეთის ჩეკლისტი. ასე თანამშრომლებს აღარ მოუწევთ ყოველი განახლების შემდეგ თავიდან მოფიქრება, რას ამოწმებენ.

6. კონტენტის მოვლა ტექნიკურ გეგმას შეუერთე

გამართული პროგრამა მოძველებულ შეთავაზებას ვერ გამოასწორებს. პერიოდულად შეამოწმე ფასები, სამუშაო საათები, გუნდის ინფორმაცია, მომსახურების პირობები და ძველი კამპანიის ბანერები. თითოეულ მნიშვნელოვან გვერდს კონტენტის პასუხისმგებელი ჰყავდეს. ტექნიკურმა შემსრულებელმა შეიძლება ვერ იცოდეს, რომ მომსახურების კონკრეტული ფორმატი უკვე შეიცვალა.

განსაკუთრებით გადახედე ბმულებს, რომლებსაც რეკლამაში, სოციალურ პროფილებში და მომხმარებელთან მიმოწერაში იყენებთ. გვერდის წაშლის ან მისამართის შეცვლისას გადაწყვიტე, სად უნდა მივიდეს ძველი ბმულის მომხმარებელი. სტატიის განახლების თარიღი რეალურ ცვლილებას უნდა ასახავდეს; მხოლოდ თარიღის შეცვლა ტექსტს ახალ ინფორმაციას არ მატებს. სისწრაფეზე გავლენის შესამჩნევად მნიშვნელოვანი ახალი ვიზუალისა და დამატების შემდეგ Core Web Vitals-ის შემოწმებაც ჩაატარე. შენარჩუნებული ისტორია გაჩვენებს, რომელ ცვლილებას მოჰყვა ახალი ხარვეზი.

7. სიხშირე რისკსა და აქტივობას მოარგე

ერთი უნივერსალური განრიგი ყველა საიტს არ ერგება. ქვემოთ მოცემული ცხრილი დაგეგმვის საწყისი მაგალითია; აქტიური მაღაზიის მონაცემები და შეტყობინებები შეიძლება უფრო ხშირ კონტროლს მოითხოვდეს. დადასტურებული მნიშვნელოვანი უსაფრთხოების განახლება კი ჩვეულებრივ კალენდარში შემდეგი თავისუფალი დღის მოლოდინში არ უნდა დაიკარგოს — პრიორიტეტს პასუხისმგებელი გუნდი შეაფასებს.

როდის რა შემოწმდეს
მნიშვნელოვანი ცვლილების შემდეგ ფორმა, შეკვეთა, მობილური გზა და დაბრუნების შესაძლებლობა
პერიოდული მოკლე მიმოხილვა ასლების შედეგი, შეცდომები, წვდომები და მოქმედი შეთავაზებები
გეგმური ტექნიკური სესია განახლებები, საცდელი აღდგენა და ვადების მიმოხილვა

ბოლოს თითოეულ საქმეს დაურთე სახელი და შედეგის მოკლე ჩანაწერი. ფრაზა „ყველაფერი შემოწმებულია“ ნაკლებად გამოსადეგია, ვიდრე ინფორმაცია, რომ ფორმა გაიგზავნა და მიმღებმა მიღება დაადასტურა. ვებსაიტის განვითარებასთან ერთად მოვლის პროცესის შეთანხმება საიტს ყოველდღიური ბიზნესისთვის უფრო მართვადს ხდის.

წყაროები და დამატებითი კითხვა

Scroll to Top