SLA ვრცელდება SERVER1.GE-ის მიერ მიწოდებულ ქვემოთ ჩამოთვლილ სერვისებზე, თითოეული სერვისის სპეციფიკის გათვალისწინებით. სადაც „Uptime SLA“ ტექნიკურად არ არის რელევანტური (მაგ: დომენის რეგისტრაცია/ტრანსფერი, SSL გამოშვება, Google Workspace), გამოიყენება „Process SLA“/Best-effort მიდგომა.

სამიზნე ხელმისაწვდომობა (Uptime): 99.5% / თვეში
მომსახურება: 24/7/365 (თუ კონკრეტული სერვისის აღწერაში/შეკვეთაში სხვაგვარად არ არის მითითებული)

ხელმისაწვდომობა ითვლება თვეში იმ დროის პროცენტად, როცა სერვისი ინფრასტრუქტურულად ხელმისაწვდომია. „ინფრასტრუქტურული ხელმისაწვდომობა“ მოიცავს პლატფორმის/ქსელის/საცავის/ჰიპერვაიზერის/ფიზიკური ჰარდვერის გამართულობას, და არ მოიცავს კლიენტის აპლიკაციების ლოგიკურ გაუმართაობას (CMS, კოდი, DB სქემა, პლაგინები და ა.შ.).

3.1 Web Hosting (Plesk) / Cloud Hosting / WordPress Hosting / Reseller Hosting

• მართვა (Managed პლატფორმა): ჰოსტინგ პლატფორმა/პანელი/ინფრასტრუქტურა იმართება კომპანიის მიერ. CMS/კოდი/პლაგინები/თემები/კონტენტი კლიენტის პასუხისმგებლობაა.
• ბექაფები: ყოველდღიური ბექაფი, რომელიც ინახება 1 კვირის განმავლობაში. დამატებითი/გაფართოებული ბექაფისთვის საჭიროა შესაბამისი Backup Add-on-ის შეძენა (თუ ხელმისაწვდომია პორტალში).
• Self-restore: კლიენტს შეუძლია აღდგენა Plesk პანელიდან (ხელმისაწვდომობის შემთხვევაში). აღდგენის შედეგი დამოკიდებულია ხელმისაწვდომ ბექაფზე და კლიენტის მიერ შერჩეულ აღდგენის წერტილზე.
• DDoS დაცვა: უზრუნველყოფილია გარკვეული ლიმიტით და არ არის ულიმიტო. შეტევის მასშტაბის მიხედვით შესაძლებელია rate-limit/ფილტრაცია/დროებითი შეზღუდვები ან ტრაფიკის დროებითი „ჩახშობა“ (null-route) ინფრასტრუქტურის დასაცავად.
• აპლიკაციური/ლოგიკური პრობლემები: თუ საიტი არ იხსნება კოდის/პლაგინის/DB-ის გამო, ეს არ ითვლება SLA დარღვევად, თუ პლატფორმა ინფრასტრუქტურულად ხელმისაწვდომია.

3.2 VPS (Unmanaged / Managed)

• Unmanaged VPS (IaaS): კომპანია უზრუნველყოფს ჰიპერვაიზერს/ქსელს/საცავს; VPS-ის შიგნით OS/აპლიკაციები/უსაფრთხოება/განახლებები/ბექაფები - კლიენტის პასუხისმგებლობაა.
• Managed VPS: მართვის ფარგლები განისაზღვრება წერილობით/შეკვეთაში (მაგ: patching, hardening, monitoring, incident handling). რაც წერილობით არ არის შეთანხმებული, ითვლება კლიენტის პასუხისმგებლობად.
• Snapshot/Backup: VPS-ზე ბექაფი/სნეპშოტი განისაზღვრება გეგმით. თუ გეგმა არ მოიცავს - არ ითვლება გარანტირებულ სისტემად და რეკომენდებულია off-site ბექაფი.

3.3 Dedicated Servers / GPU Servers (Managed / Unmanaged)

• Unmanaged Server: კომპანია უზრუნველყოფს DC/ქსელს/დენს/ჰარდვერის ოპერირებას; OS/აპლიკაციები/უსაფრთხოება/კონფიგურაცია - კლიენტის პასუხისმგებლობაა.
• Managed Server: მართვის ფარგლები განისაზღვრება წერილობით/შეკვეთაში (მაგ: OS updates, monitoring, hardening). ფარგლებს გარეთ პასუხისმგებლობა არ ვრცელდება.
• ჰარდვერის ინციდენტები: კრიტიკული ჰარდვერის პრობლემა (დისკი/RAID/Power/Network) მუშავდება პრიორიტეტულად. აღდგენის ვადები დამოკიდებულია მარაგზე/მესამე მხარის DC-ზე და შეიძლება შეიცვალოს ობიექტური გარემოებების მიხედვით.

3.4 დომენები (რეგისტრაცია / ტრანსფერი)

• დომენის რეგისტრაცია/ტრანსფერი დამოკიდებულია რეესტრსა და/ან რეგისტრატორზე, ასევე კლიენტის მიერ მოწოდებული მონაცემების სისწორეზე.
• Uptime SLA დომენებზე არ ვრცელდება; კომპანია უზრუნველყოფს პროცესის შესრულებას Best-effort რეჟიმში და საჭიროებისას კოორდინაციას რეგისტრატორთან.
• დომენის DNS/Nameserver ხელმისაწვდომობა შეიძლება იყოს მესამე მხარის სერვისზე. ასეთ შემთხვევაში SLA არ ვრცელდება მესამე მხარის DNS-ის ხელმისაწვდომობაზე.

3.5 SSL სერთიფიკატები

• SSL სერთიფიკატის გამოცემა დამოკიდებულია სერტიფიკაციის ცენტრზე (CA), დომენის კონტროლის ვერიფიკაციაზე და კლიენტის კონფიგურაციაზე.
• Uptime SLA SSL „გამოშვებაზე“ არ ვრცელდება; კომპანია უზრუნველყოფს შეკვეთის/ვერიფიკაციის მხარდაჭერას Best-effort რეჟიმში.

3.6 Google Workspace

• Google Workspace-ის პლატფორმის ხელმისაწვდომობა რეგულირდება Google-ის მიერ და ექვემდებარება Google-ის პირობებს/SLA-ს.
• SERVER1.GE უზრუნველყოფს ბილინგის/აქტივაციის/საპორტო კოორდინაციას Best-effort რეჟიმში, მესამე მხარის წესების გათვალისწინებით.

3.7 ვებ საიტის უსაფრთხოება / ელ.ფოსტის უსაფრთხოება

• დაცვითი სერვისები ამცირებს რისკს, თუმცა 100% თავდაცვა, 0 ინციდენტი ან 0 false-positive არ არის გარანტირებული.
• კომპანია უფლებამოსილია განახორციელოს ფილტრაცია/ბლოკირება უსაფრთხოების მიზნით, მათ შორის ინციდენტის ლოკალიზაციისთვის.
• Policy enforcement: როგორც წესი, პირველ შემთხვევაზე დროებითი ბლოკი, ხოლო განმეორების შემთხვევაში სრული ბლოკი (IP/პორტი/სერვისი/ანგარიში) - System Policies/Terms-ის შესაბამისად.

Web Hosting / Cloud Hosting / WordPress Hosting / Reseller Hosting სერვისებზე კომპანია იღებს ვალდებულებას უზრუნველყოს:

• ყოველდღიური ბექაფი და შენახვა 1 კვირის განმავლობაში (თუ გეგმაში/პორტალში სხვაგვარად არ არის მითითებული).
• Self-restore შესაძლებლობა Plesk-იდან (ხელმისაწვდომობის შემთხვევაში).

შეზღუდვები: კომპანია არ იღებს CMS/კოდის/პლაგინების მართვის ან გამართულობის პასუხისმგებლობას. ბექაფი არის რისკის შემცირების ინსტრუმენტი და არ გამორიცხავს მონაცემთა დაკარგვის ყველა სცენარს (მომხმარებლის შეცდომა, ransomware, მესამე მხარის კომპრომეტაცია და სხვ.). ბიზნეს-კრიტიკული პროექტებისთვის რეკომენდებულია დამატებითი off-site ბექაფი.

1. დაგეგმილი პროფილაქტიკური/ტექნიკური სამუშაოები, რომლებმაც შეიძლება გავლენა მოახდინოს ხელმისაწვდომობაზე, როგორც წესი, ცხადდება მინიმუმ 48 საათით ადრე.
2. გეგმიური სამუშაოები ტარდება ძირითადად 22:00-09:00 (GE დრო) პერიოდში, როცა შესაძლებელია.
3. გადაუდებელ შემთხვევებში (უსაფრთხოება/ავარია) სამუშაოები შეიძლება შესრულდეს წინასწარი შეტყობინების გარეშე; ინფორმირება მოხდება მაქსიმალურად სწრაფად.

SLA დარღვევისას კლიენტს შეუძლია მოითხოვოს სერვის კრედიტი როგორც ერთადერთი კომპენსაცია. კრედიტები ვრცელდება მხოლოდ იმ სერვისებზე, სადაც მოქმედებს Uptime SLA (ჰოსტინგი/VPS/სერვერები/უსაფრთხოების პლატფორმის ინფრასტრუქტურული კომპონენტი).

• კრედიტი გაიცემა მხოლოდ იმ სერვისის ბაზისურ თვიურ საფასურზე, რომელსაც SLA მოთხოვნა ეხება (one-time fees, add-on ლიცენზიები, მესამე მხარის საფასურები, ტრანსფერი/ტრეფიკი - არ შედის, თუ სხვაგვარად არ არის შეთანხმებული).
• SLA Claim: მოთხოვნა უნდა გაიგზავნოს ინციდენტიდან ან შესაბამისი თვის დასრულებიდან 7 კალენდარული დღის განმავლობაში (ტიკეტით console.server1.ge-ში) და უნდა შეიცავდეს სერვისის ID-ს, დროებს (UTC/GE), სიმპტომებს და მოკლე აღწერას.
• Back-to-Back შეზღუდვა: მესამე მხარის ინფრასტრუქტურაზე დამოკიდებულ კომპონენტებში კრედიტები შესაძლოა შეიზღუდოს იმ კომპენსაციით, რასაც კომპანია რეალურად მიიღებს მესამე მხარისგან.
• ერთადერთი კომპენსაცია: SLA კრედიტები წარმოადგენს ხელმისაწვდომობის დარღვევისას ერთადერთ და საბოლოო კომპენსაციას.

SLA დარღვევად არ ითვლება და სერვის კრედიტი არ გაიცემა, თუ შეფერხება გამოწვეულია:

• კლიენტის/კონტრაქტორების ქმედებით ან უმოქმედობით (არასწორი კონფიგურაცია, წვდომის დაკარგვა, პაროლის შეცდომა, OS crash, malware, CMS/plugin შეცდომები და სხვ.)
• კლიენტის მიერ ინიცირებული ოპერაციებით (stop/start/reboot/rebuild/restore/upgrade/resize/transfer და სხვ.)
• მესამე მხარის სერვისებით/ინტეგრაციებით (CDN, DNS, external DB, mail gateway, payment, API და სხვ.)
• რესურსების გადავსებით (დისკი 100%, inode overflow, RAM exhaustion, CPU saturation მომხმარებლის ლოდით და სხვ.)
• დაგეგმილი პროფილაქტიკით
• DoS/DDoS შეტევით, რომელიც სცდება სტანდარტულ დაცვის ზღვარს ან მოითხოვს საგანგებო ფილტრაციას/შეზღუდვებს
• კანონით/რეგულაციით მოთხოვნილი შეზღუდვებით ან სამართალდამცავი/რეგულატორის მოთხოვნით განხორციელებული ქმედებებით
• Force Majeure გარემოებებით (სტიქია, ფართო მასშტაბის ენერგო/ქსელის ავარია, სახელმწიფო შეზღუდვები, ომი/საბოტაჟი და სხვ.)

1. კომპანია უფლებამოსილია განახორციელოს უსაფრთხოების ღონისძიებები ინფრასტრუქტურის და სხვა მომხმარებლების დასაცავად (ფილტრაცია, rate-limit, ბლოკირება, პორტების შეზღუდვა, დროებითი შეჩერება).
2. პირველ შემთხვევაზე (Policy violation/abuse) - როგორც წესი გამოიყენება დროებითი ბლოკი ან შეზღუდვა და იგზავნება შეტყობინება (სადაც შესაძლებელია).
3. განმეორების შემთხვევაში - შესაძლოა განხორციელდეს სრული ბლოკი (IP/სერვისი/ანგარიში) ან მომსახურების შეწყვეტა, System Policies/Terms-ის შესაბამისად.
4. DDoS დაცვა არ არის ულიმიტო; შეტევის მასშტაბის/ხასიათის მიხედვით შესაძლებელია დროებითი შეზღუდვები/ტრაფიკის ჩახშობა ინფრასტრუქტურის დასაცავად.

1. კომპანია არ არის პასუხისმგებელი არაპირდაპირ/შედეგობრივ ზიანზე (მოგება, მონაცემი, downtime, რეპუტაცია, მესამე პირების მოთხოვნები, ჯარიმები და სხვ.).
2. კომპანიის მთლიანი პასუხისმგებლობა შემოიფარგლება ბოლო 1 თვის იმ სერვისის თვიური საფასურით, რომელსაც მოთხოვნა ეხება (თუ სავალდებულო კანონმდებლობა სხვაგვარად არ ითხოვს).
3. SLA კრედიტები არის ერთადერთი და საბოლოო კომპენსაციის გზა ხელმისაწვდომობის დარღვევისას.

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

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

• ჰოსტინგი/VPS/სერვერები (მიმდინარე საანგარიშო პერიოდი): როგორც წესი, მომსახურება არის წინასწარ გადახდილი და გამოყენებულ პერიოდზე თანხა არ ბრუნდება. გამონაკლისები შესაძლებელია მხოლოდ წერილობითი დადასტურებით (მაგ: ორმხრივი შეცდომა ბილინგში).
• სერვის კრედიტები: ხელმისაწვდომობის დარღვევის შემთხვევაში კომპენსაციის ძირითადი მექანიზმი არის სერვის კრედიტები (სექცია 6), ხოლო არა ნაღდი თანხის დაბრუნება, გარდა კანონით სავალდებულო შემთხვევებისა.
• დომენები (რეგისტრაცია/განახლება/ტრანსფერი): დომენი რეგისტრაციის/განახლების/ტრანსფერის დასრულების შემდეგ, როგორც წესი, არ ექვემდებარება დაბრუნებას, რადგან რეესტრის/რეგისტრატორის საფასური არის irreversable და მომსახურება ითვლება შესრულებულად.
• SSL სერთიფიკატები: სერთიფიკატის გაცემის შემდეგ თანხა, როგორც წესი, არ ბრუნდება (CA-ის წესებიდან გამომდინარე). თუ შეკვეთა შეჩერდა/ვერიფიკაცია ვერ შესრულდა კლიენტის მონაცემების/კონფიგურაციის გამო, თანხის დაბრუნება დამოკიდებულია CA/მესამე მხარის პოლიტიკაზე.
• Google Workspace: არის მესამე მხარის (Google) პროდუქტი; დაბრუნება/ანაზღაურება შეიძლება ექვემდებარებოდეს Google-ის/რეგისტრირებული რეზელერის წესებს, და ხშირად არ მოიცავს გამოყენებულ პერიოდს.
• Add-ons / ლიცენზიები / one-time fees: აქტივაციის/მიწოდების შემდეგ, როგორც წესი, არ ბრუნდება (მაგ: ლიცენზია, სპეციალური კონფიგურაცია, სამუშაო საათები).
• Refund-ის მოთხოვნა: Refund-ის მოთხოვნა იგზავნება მხოლოდ ტიკეტით (console.server1.ge) და უნდა შეიცავდეს: სერვისის ID-ს, ინვოისის ნომერს, მოთხოვნის მიზეზს და მტკიცებულებას (საჭიროების შემთხვევაში).
• Chargeback/დისპუტი: არასანქცირებული chargeback/დისპუტი შეიძლება გამოიწვიოს სერვისების დაუყოვნებლივი შეჩერება და ანგარიშის რესტრიქცია System Policies-ის შესაბამისად, სანამ საკითხი არ დარეგულირდება.

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