Service Level Agreement (SLA)
სერვისების ხელმისაწვდომობა, მხარდაჭერა, ბექაფები და კრედიტები
კომპანია: შპს „მაიგოუ“ (ბრენდი: SERVER1.GE)
კლიენტის კონსოლი/პორტალი: console.server1.ge
დოკუმენტის თარიღი: 05 თებერვალი 2026 | ვერსია: 3.6.9
მნიშვნელოვანი:
SLA განსაზღვრავს მხოლოდ ინფრასტრუქტურულ ხელმისაწვდომობას და მხარდაჭერის/კომპენსაციის წესებს.
აპლიკაციები/CMS (მაგ: WordPress, Joomla, Laravel, OpenCart), პლაგინები, თემები, კოდის შეცდომები, კონტენტი, SEO შედეგები
- SLA-ს ფარგლებს გარეთაა, გარდა იმ შემთხვევისა, როცა წერილობით შეთანხმებულია სპეციალური მართვა (მაგ: Managed VPS/Managed Server).
დეტალები იხილეთ ასევე:
Terms & Conditions და
System Policies.
იურიდიული ჩარჩო:
შპს „მაიგოუ“ არის საქართველოში რეგისტრირებული ორგანიზაცია და მოქმედებს საქართველოს კანონმდებლობის შესაბამისად.
თუ ამ SLA-ის რომელიმე ჩანაწერი ეწინააღმდეგება სავალდებულო სამართლებრივ ნორმას, უპირატესობა ენიჭება შესაბამის კანონს, ხოლო დანარჩენი პირობები ძალაში რჩება.
მესამე მხარის ინფრასტრუქტურა (Back-to-Back):
SERVER1.GE იყენებს/აერთიანებს საკუთარი და პარტნიორული ინფრასტრუქტურის რესურსებს (მაგ:
UGT / OVH / Vultr / Hetzner / Cloud9 - მათ შორის Cloud9 მონაცემთა ცენტრში განთავსებული ჩვენი სერვერებით).
იმ ნაწილში, სადაც მომსახურება დამოკიდებულია მესამე მხარის მონაცემთა ცენტრზე/ქსელზე/კლაუდ-პლატფორმაზე, ჩვენი სერვის კრედიტები და პასუხისმგებლობა
ვერ გადააჭარბებს იმ კომპენსაციას/პასუხისმგებლობას, რომელსაც რეალურად გვაძლევს შესაბამისი მესამე მხარე მისი პირობების ფარგლებში (back-to-back).
კომპანია მოქმედებს კეთილსინდისიერად და მაქსიმალურად ცდილობს აღდგენას, თუმცა მესამე მხარის კონტროლს მიღმა ავარიებზე პასუხისმგებლობა ამ დოკუმენტით განსაზღვრულს არ აღემატება.
რომელი სერვისებს მოიცავს SLA
SLA ვრცელდება SERVER1.GE-ის მიერ მიწოდებულ ქვემოთ ჩამოთვლილ სერვისებზე, თითოეული სერვისის სპეციფიკის გათვალისწინებით. სადაც „Uptime SLA“ ტექნიკურად არ არის რელევანტური (მაგ: დომენის რეგისტრაცია/ტრანსფერი, SSL გამოშვება, Google Workspace), გამოიყენება „Process SLA“/Best-effort მიდგომა.
| სერვისი | SLA ტიპი | რა ითვლება SLA-ად |
|---|---|---|
| დომენები (რეგისტრაცია/ტრანსფერი) | Process SLA (Best-effort) | შეკვეთის/ვერიფიკაციის/რეგისტრარებთან კოორდინაციის შესრულება; რეესტრი/რეგისტრატორი/WHOIS და DNS შეიძლება იყოს მესამე მხარის კონტროლში. |
| Web Hosting (Plesk), Cloud Hosting, WordPress Hosting, Reseller Hosting | Uptime SLA + Backup Policy | ჰოსტინგ პლატფორმის/ქსელის/საცავის/პანელის ინფრასტრუქტურული ხელმისაწვდომობა; ყოველდღიური ბექაფი (1 კვირა) + self-restore პლესკიდან. |
| VPS (Managed / Unmanaged) | Uptime SLA (IaaS/Managed განსხვავებით) | ჰიპერვაიზერი/ქსელი/საცავი; Unmanaged-ში OS/აპები კლიენტის პასუხისმგებლობაა, Managed-ში - შეთანხმებული ფარგლები. |
| Dedicated Servers / GPU Servers (Managed / Unmanaged) | Uptime SLA + Hardware Response Targets | დენი/ქსელი/ჰარდვერის ოპერირება; Managed-ში დამატებითი ადმინისტრირება შეთანხმებით. |
| ვებ საიტის უსაფრთხოება (WAF/Firewall/Monitoring) | Best-effort + Platform Uptime | დაცვითი პლატფორმის/პანელის ხელმისაწვდომობა; „0 ინციდენტი“ ან „100% დაცვა“ არ გარანტირდება. |
| ელ.ფოსტის უსაფრთხოება (anti-spam/anti-phishing) | Best-effort + Platform Uptime | ფილტრაციის პლატფორმის ხელმისაწვდომობა; 100% დაბლოკვა ან 0 false-positive არ გარანტირდება. |
| SSL სერთიფიკატები | Process SLA (CA-dependent) | შეკვეთის დამუშავება/ვერიფიკაციის მხარდაჭერა; გამოცემა დამოკიდებულია CA-ზე და დომენის კონტროლზე. |
| Google Workspace | Reseller/Support SLA (Third-party) | ბილინგი/აქტივაცია/საპორტო კოორდინაცია; Workspace-ის uptime არის Google-ის SLA. |
1. მომსახურების დონე (Uptime SLA) - ხელმისაწვდომობა
სამიზნე ხელმისაწვდომობა (Uptime): 99.5% / თვეში
მომსახურება: 24/7/365 (თუ კონკრეტული სერვისის აღწერაში/შეკვეთაში სხვაგვარად არ არის მითითებული)
ხელმისაწვდომობა ითვლება თვეში იმ დროის პროცენტად, როცა სერვისი ინფრასტრუქტურულად ხელმისაწვდომია. „ინფრასტრუქტურული ხელმისაწვდომობა“ მოიცავს პლატფორმის/ქსელის/საცავის/ჰიპერვაიზერის/ფიზიკური ჰარდვერის გამართულობას, და არ მოიცავს კლიენტის აპლიკაციების ლოგიკურ გაუმართაობას (CMS, კოდი, DB სქემა, პლაგინები და ა.შ.).
2. მხარდაჭერა (Support) - არხები, პრიორიტეტები, რეაგირება/აღდგენა
Support არხები:
- ტიკეტი კონსოლში - console.server1.ge
- ელ.ფოსტა - support@server1.ge
- საერთო საკონტაქტო - info@mygo.ge | +995 593 767 490
| კატეგორია | აღწერა | სამიზნე რეაგირება | სამიზნე აღდგენა* |
|---|---|---|---|
| P1 კრიტიკული | სერვისი ინფრასტრუქტურულად მიუწვდომელია (ქსელი/ჰიპერვაიზერი/პანელი/ფიზიკური ჰარდვერი) ან არსებითი I/O შეუძლებელია | 40 წუთი | 3 საათი |
| P2 მაღალი | შესამჩნევი დეგრადაცია/ქსელური ხარვეზი/შეფერხება, რომელიც გავლენას ახდენს მუშაობაზე | 55 წუთი | 5 საათი |
| P3 საშუალო | არაკრიტიკული შეფერხება/დაბალი რისკი (ინფრასტრუქტურული) | 75 წუთი | 9 საათი |
| Service Request | კონფიგურაცია/რესურსის ცვლილება/ინფორმაცია/კონსულტაცია (non-incident) | 6 საათი | 3 სამუშაო დღე |
3. სერვისების სპეციფიკური პირობები
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-ის შესაბამისად.
4. ბექაფები (Hosting) - კომპანიის ვალდებულება და შეზღუდვები
Web Hosting / Cloud Hosting / WordPress Hosting / Reseller Hosting სერვისებზე კომპანია იღებს ვალდებულებას უზრუნველყოს:
- ყოველდღიური ბექაფი და შენახვა 1 კვირის განმავლობაში (თუ გეგმაში/პორტალში სხვაგვარად არ არის მითითებული).
- Self-restore შესაძლებლობა Plesk-იდან (ხელმისაწვდომობის შემთხვევაში).
შეზღუდვები: კომპანია არ იღებს CMS/კოდის/პლაგინების მართვის ან გამართულობის პასუხისმგებლობას. ბექაფი არის რისკის შემცირების ინსტრუმენტი და არ გამორიცხავს მონაცემთა დაკარგვის ყველა სცენარს (მომხმარებლის შეცდომა, ransomware, მესამე მხარის კომპრომეტაცია და სხვ.). ბიზნეს-კრიტიკული პროექტებისთვის რეკომენდებულია დამატებითი off-site ბექაფი.
5. დაგეგმილი სამუშაოები და შეტყობინებები
- დაგეგმილი პროფილაქტიკური/ტექნიკური სამუშაოები, რომლებმაც შეიძლება გავლენა მოახდინოს ხელმისაწვდომობაზე, როგორც წესი, ცხადდება მინიმუმ 48 საათით ადრე.
- გეგმიური სამუშაოები ტარდება ძირითადად 22:00-09:00 (GE დრო) პერიოდში, როცა შესაძლებელია.
- გადაუდებელ შემთხვევებში (უსაფრთხოება/ავარია) სამუშაოები შეიძლება შესრულდეს წინასწარი შეტყობინების გარეშე; ინფორმირება მოხდება მაქსიმალურად სწრაფად.
6. სერვის კრედიტები (კომპენსაცია SLA დარღვევისას)
SLA დარღვევისას კლიენტს შეუძლია მოითხოვოს სერვის კრედიტი როგორც ერთადერთი კომპენსაცია. კრედიტები ვრცელდება მხოლოდ იმ სერვისებზე, სადაც მოქმედებს Uptime SLA (ჰოსტინგი/VPS/სერვერები/უსაფრთხოების პლატფორმის ინფრასტრუქტურული კომპონენტი).
| თვიური ხელმისაწვდომობა | კრედიტი (თვიური საფასურის %) |
|---|---|
| 98.0% - 99.5% | 5% |
| 97.0% - 98.0% | 10% |
| 96.0% - 97.0% | 20% |
| 95.0% - 96.0% | 40% |
| 94.0% - 95.0% | 60% |
| 94.0%-ზე ნაკლები | 100% |
- კრედიტი გაიცემა მხოლოდ იმ სერვისის ბაზისურ თვიურ საფასურზე, რომელსაც SLA მოთხოვნა ეხება (one-time fees, add-on ლიცენზიები, მესამე მხარის საფასურები, ტრანსფერი/ტრეფიკი - არ შედის, თუ სხვაგვარად არ არის შეთანხმებული).
- SLA Claim: მოთხოვნა უნდა გაიგზავნოს ინციდენტიდან ან შესაბამისი თვის დასრულებიდან 7 კალენდარული დღის განმავლობაში (ტიკეტით console.server1.ge-ში) და უნდა შეიცავდეს სერვისის ID-ს, დროებს (UTC/GE), სიმპტომებს და მოკლე აღწერას.
- Back-to-Back შეზღუდვა: მესამე მხარის ინფრასტრუქტურაზე დამოკიდებულ კომპონენტებში კრედიტები შესაძლოა შეიზღუდოს იმ კომპენსაციით, რასაც კომპანია რეალურად მიიღებს მესამე მხარისგან.
- ერთადერთი კომპენსაცია: SLA კრედიტები წარმოადგენს ხელმისაწვდომობის დარღვევისას ერთადერთ და საბოლოო კომპენსაციას.
7. გამონაკლისები 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 გარემოებებით (სტიქია, ფართო მასშტაბის ენერგო/ქსელის ავარია, სახელმწიფო შეზღუდვები, ომი/საბოტაჟი და სხვ.)
8. უსაფრთხოება, ბოროტად გამოყენება და ბლოკირების წესები
- კომპანია უფლებამოსილია განახორციელოს უსაფრთხოების ღონისძიებები ინფრასტრუქტურის და სხვა მომხმარებლების დასაცავად (ფილტრაცია, rate-limit, ბლოკირება, პორტების შეზღუდვა, დროებითი შეჩერება).
- პირველ შემთხვევაზე (Policy violation/abuse) - როგორც წესი გამოიყენება დროებითი ბლოკი ან შეზღუდვა და იგზავნება შეტყობინება (სადაც შესაძლებელია).
- განმეორების შემთხვევაში - შესაძლოა განხორციელდეს სრული ბლოკი (IP/სერვისი/ანგარიში) ან მომსახურების შეწყვეტა, System Policies/Terms-ის შესაბამისად.
- DDoS დაცვა არ არის ულიმიტო; შეტევის მასშტაბის/ხასიათის მიხედვით შესაძლებელია დროებითი შეზღუდვები/ტრაფიკის ჩახშობა ინფრასტრუქტურის დასაცავად.
9. პასუხისმგებლობის შეზღუდვა
- კომპანია არ არის პასუხისმგებელი არაპირდაპირ/შედეგობრივ ზიანზე (მოგება, მონაცემი, downtime, რეპუტაცია, მესამე პირების მოთხოვნები, ჯარიმები და სხვ.).
- კომპანიის მთლიანი პასუხისმგებლობა შემოიფარგლება ბოლო 1 თვის იმ სერვისის თვიური საფასურით, რომელსაც მოთხოვნა ეხება (თუ სავალდებულო კანონმდებლობა სხვაგვარად არ ითხოვს).
- SLA კრედიტები არის ერთადერთი და საბოლოო კომპენსაციის გზა ხელმისაწვდომობის დარღვევისას.
10. მომსახურების შეჩერება/შეწყვეტა და მონაცემების წაშლა
- გადაუხდელობის, წესების/კანონის დარღვევის ან უსაფრთხოების კრიტიკული რისკის შემთხვევაში კომპანიას შეუძლია დროებით შეზღუდოს ან შეწყვიტოს მომსახურება.
- მომსახურების გაუქმების/დეაქტივაციის შემდეგ, თუ პორტალში/ხელშეკრულებაში სხვაგვარად არ არის მითითებული, კლიენტს ეძლევა 3 სამუშაო დღე მონაცემების გასატანად. შემდეგ შესაძლებელია წვდომის გაუქმება და მონაცემების წაშლა.
- დომენის მომსახურებაზე მონაცემთა წაშლა არ არის რელევანტური; მოქმედებს რეესტრის/რეგისტრატორის წესები.
11. Refund Policy (ანაზღაურება/დაბრუნება)
ეს სექცია აღწერს თანხის დაბრუნების ზოგად წესებს 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 არ ზღუდავს მომხმარებლის იმ უფლებებს, რომლებიც გარანტირებულია საქართველოს კანონმდებლობით სავალდებულო წესით.
12. ტერმინთა განმარტება
- ხელმისაწვდომობა (Availability/Uptime): თვეში დროის პროცენტი, როცა სერვისი ინფრასტრუქტურულად ხელმისაწვდომია.
- რეაგირება: ინციდენტზე პირველადი პასუხი/დადასტურება და სამუშაოს დაწყება, და არა აუცილებლად საბოლოო გადაწყვეტა.
- აღდგენა: ინფრასტრუქტურული ხელმისაწვდომობის აღდგენა (არ მოიცავს კლიენტის აპების/CMS/DB-ის ლოგიკურ აღდგენას, თუ არ არის Managed შეთანხმება).
- მესამე მხარის ინფრასტრუქტურა: მონაცემთა ცენტრი/ქსელი/კლაუდ-პლატფორმა, რომლის რესურსებით ან ნაწილით კომპანია აწვდის მომსახურებას (UGT/OVH/Vultr/Hetzner/Cloud9 და სხვ.).
Availability ფორმულა (სტანდარტულად):
Availability % = (თვეში სულ წუთები − SLA-დან გამონაკლისი წუთები − დაუგეგმავი ინფრასტრუქტურული downtime წუთები) / (თვეში სულ წუთები − SLA-დან გამონაკლისი წუთები) × 100. „გამონაკლისი წუთები“ მოიცავს დაგეგმილ სამუშაოებს, Force Majeure-ს, კლიენტის ქმედებებს და სექცია 7-ში ჩამოთვლილ სხვა შემთხვევებს.