თავი 3 · ProjectVIEW ERP-ის ძირითადი SaaS ჩარჩო
ProjectVIEW ERP-ის მომსახურების დონის შეთანხმება (SLA) ითვალისწინებს საწარმოო გარემოს 99.9%-იან თვიურ ხელმისაწვდომობას, აღდგენის წერტილის მიზანს (RPO) — 15 წუთს და აღდგენის დროის მიზანს (RTO) — 4 საათს. ინციდენტები კლასიფიცირდება P1-დან P4-მდე რეაგირებისა და გადაწყვეტის (MTTR) განსაზღვრული მაჩვენებლებით — P1 ინციდენტზე რეაგირება დაუყოვნებლივია, MTTR-ის მაჩვენებელი — 4 საათი, 24×7×365 — ხოლო SLA-ის შესრულების შესახებ ანგარიში წარედგინება ყოველთვიურად და განიხილება კვარტალურად.
- 99.9%თვიური ხელმისაწვდომობა (საწარმოო)
- 15 წთაღდგენის წერტილის მიზანი
- 4 სთაღდგენის დროის მიზანი
- 4 სთP1 MTTR მაჩვენებელი, 24×7×365
3.1 SLA-ის მიმოხილვა
წინამდებარე ნაწილი განსაზღვრავს მომსახურების დონეებს, რომლების მიღწევასაც მიმწოდებელი კისრულებს პლატფორმის მიწოდებისა და მხარდაჭერისას. მომსახურებების გაწევისას მიმწოდებელი გამოიყენებს კომერციულად გონივრულ ძალისხმევას წინამდებარე ნაწილში განსაზღვრული მომსახურების დონეების მიღწევისა ან გადაჭარბებისთვის.
მომსახურების დონეები მოიცავს პლატფორმის ხელმისაწვდომობას, ინციდენტებზე რეაგირებას, გადაწყვეტის მაჩვენებლებს, სარეზერვო ასლებისა და აღდგენის მიზნებს და შეუსაბამობის შემთხვევაში შესაბამის მომსახურების კრედიტებს.
SLA ვრცელდება მხოლოდ პლატფორმის საწარმოო გარემოზე. არასაწარმოო გარემოები (შემუშავების, sandbox/სატესტო) გამორიცხულია SLA-ის გაზომვიდან, თუ კომერციული ხელშეკრულება სხვა რამეს არ ითვალისწინებს.
3.1 პლატფორმის ხელმისაწვდომობა
3.1.1 მომსახურების დონის მიზანი (SLO)
მიმწოდებელი იღებს ვალდებულებას პლატფორმის საწარმოო გარემოსთვის უზრუნველყოს მომსახურების დონის მიზანი — ფუნქციონირების თვიური დრო 99.9%, გაზომილი შესაბამისი კალენდარული თვის წუთების საერთო რაოდენობის პროცენტული წილის სახით.
| მაჩვენებელი | მიზნობრივი მნიშვნელობა | გაზომვის პერიოდი |
|---|---|---|
| მომსახურების დონის მიზანი (SLO) | 99.9% | კალენდარული თვე |
| მოცდენის მაქსიმალური დასაშვები დრო | 43.2 წუთი / თვე | გამოთვლა: (1 – 0.999) × 43,200 წუთი |
3.1.2 ხელმისაწვდომობის გამოთვლა
თვიური ხელმისაწვდომობა გამოითვლება შემდეგი ფორმულით:
ხელმისაწვდომობა % = ((წუთების საერთო რაოდენობა – მოცდენის წუთები) / წუთების საერთო რაოდენობა) × 100
სადაც:
- წუთების საერთო რაოდენობა = შესაბამის კალენდარულ თვეში წუთების საერთო რაოდენობა
- მოცდენის წუთები = წუთების საერთო რაოდენობა, რომლის განმავლობაშიც საწარმოო გარემო მიუწვდომელია, დაგეგმილი ტექნიკური მომსახურებისა და გამონაკლისი მოვლენების გარეშე
3.1.3 დაგეგმილი ტექნიკური მომსახურება
მიმწოდებელი დაგეგმილ ტექნიკურ მომსახურებას ახორციელებს წინასწარ შეთანხმებულ ტექნიკური მომსახურების ფანჯრებში. დაგეგმილი ტექნიკური მომსახურება გამორიცხულია ხელმისაწვდომობის გამოთვლიდან, თუ:
- (a) მიმწოდებელი დაგეგმილი ტექნიკური მომსახურების შესახებ დამკვეთს უგზავნის მინიმუმ 5 სამუშაო დღით ადრე წერილობით შეტყობინებას;
- (b) ტექნიკური მომსახურება დაგეგმილია დატვირთვის გარეშე საათებში (22:00-დან 06:00-მდე დამკვეთის ძირითადი ობიექტის ადგილობრივი დროით), თუ სხვა რამ არ არის შეთანხმებული;
- (c) დაგეგმილი ტექნიკური მომსახურების ჯამური ხანგრძლივობა არ აღემატება 4 საათს კალენდარულ თვეში;
- (d) მიმწოდებელი იღებს კომერციულად გონივრულ ზომებს თითოეული ტექნიკური მომსახურების ფანჯრის ხანგრძლივობისა და გავლენის მინიმუმამდე შესამცირებლად. გადაუდებელი ტექნიკური მომსახურება: უსაფრთხოების კრიტიკული მოწყვლადობის ან სისტემური მწყობრიდან გამოსვლის უშუალო საფრთხის შემთხვევაში მიმწოდებელს უფლება აქვს ჩაატაროს გადაუდებელი ტექნიკური მომსახურება 5 სამუშაო დღეზე ნაკლები წინასწარი შეტყობინებით. მიმწოდებელი ვალდებულია შეტყობინოს დამკვეთს გონივრულად შესაძლო უმოკლეს ვადაში და 2 სამუშაო დღის განმავლობაში წარუდგინოს ტექნიკური მომსახურების შემდგომი ანგარიში.
3.2 გარემოს სასიცოცხლო ციკლი
დანერგვის დროს მიმწოდებელი დამკვეთისთვის უზრუნველყოფს ორ (2) ცალკე გარემოს:
| ფაზა | გარემო | დანიშნულება |
|---|---|---|
| დანერგვა | შემუშავება / Sandbox | კონფიგურაცია, მორგება, მონაცემების მიგრაცია, ინტეგრაციული ტესტირება და უნივერსალური სამომხმარებლო მიღების ტესტირება (UAT). დამკვეთი და მიმწოდებელი ექსპლუატაციაში გაშვებამდე ერთობლივად ადასტურებენ ყველა ფუნქციონალურ მოთხოვნას. |
| დანერგვა | საწარმოო (Production) | რეალური ოპერაციული გარემო ყველა უფლებამოსილი მომხმარებლისთვის. ექვემდებარება წინამდებარე მე-3 ნაწილით განსაზღვრულ SLA-ის სრულ მაჩვენებლებს. |
3.2.1 გარემოს გადასვლა ექსპლუატაციაში გაშვების შემდეგ
ექსპლუატაციაში გაშვებისას (Go-Live) გარემოების სტრუქტურა შემდეგნაირად იცვლება:
| გარემო | როლი ექსპლუატაციაში გაშვების შემდეგ | დანიშნულება |
|---|---|---|
| შემუშავება / Sandbox | Staging გარემო | ხდება მუდმივი Staging გარემო, რომელიც გამოიყენება: ხარვეზების აღმოფხვრისა და გამეორებისთვის, ცვლილებების მოთხოვნებისა და გაუმჯობესებების შემუშავებისთვის, პროგრამული განახლებებისა და პატჩების ტესტირებისთვის, ასევე უნივერსალური სამომხმარებლო მიღების ტესტირებისთვის (UAT) საწარმოო გარემოში განთავსებამდე. |
| საწარმოო | საწარმოო გარემო | რჩება რეალურ ოპერაციულ გარემოდ. საწარმოო გარემოში არცერთი ცვლილება არ ინერგება Staging გარემოში წინასწარი ვალიდაციისა და UAT-ის დადასტურების გარეშე. |
უნივერსალური სამომხმარებლო მიღების ტესტირება (UAT): ყველა პროგრამული ცვლილება, პატჩი, განახლება და ახალი ფუნქციონალის რელიზი საწარმოო გარემოში განთავსებამდე უნდა გაიაროს UAT Staging გარემოში. დამკვეთს UAT-ის დასასრულებლად ეძლევა მინიმუმ 5 სამუშაო დღე, ხოლო საწარმოო გარემოში განთავსება მოითხოვს დამკვეთის წერილობით დადასტურებას. მიმწოდებელი არ დანერგავს არცერთ ცვლილებას საწარმოო გარემოში UAT-ის დადასტურებული დამტკიცების გარეშე, გადაუდებელი ტექნიკური მომსახურების შემთხვევისა, როგორც ეს განსაზღვრულია ნაწილში 3.2.3.
მიმწოდებელი უზრუნველყოფს Staging და საწარმოო გარემოების იდენტურობას, რათა UAT-ის შედეგები ასახავდეს საწარმოო გარემოს ქცევას. ორივე გარემოში ყოველთვის უნდა გამოიყენებოდეს პროგრამული უზრუნველყოფის იდენტური ვერსიები, კონფიგურაციები და უსაფრთხოების პოლიტიკები და განსხვავდებოდეს მხოლოდ მონაცემების შინაარსით.
3.3 აღდგენის მიზნები
მიმწოდებელი საწარმოო გარემოსთვის იღებს აღდგენის შემდეგ მიზნებს, რომლებიც შესაბამისობაშია პლატფორმის ბიზნესის უწყვეტობისა და კატასტროფის შემდგომი აღდგენის (BC/DR) არქიტექტურასთან:
| მაჩვენებელი | მიზნობრივი მნიშვნელობა | განმარტება |
|---|---|---|
| აღდგენის წერტილის მიზანი (RPO) | 15 წუთი | მონაცემთა დაკარგვის მაქსიმალური დასაშვები ოდენობა, გაზომილი დროით. ტრანზაქციების ჟურნალის სარეზერვო ასლები იქმნება ყოველ 15 წუთში, რაც უზრუნველყოფს, რომ კატასტროფის სცენარიში შესაძლოა დაიკარგოს არაუმეტეს 15 წუთის მონაცემები. |
| აღდგენის დროის მიზანი (RTO) | 4 საათი | მომსახურების შეწყვეტის მაქსიმალური დასაშვები ხანგრძლივობა. მიმწოდებელი აღადგენს პლატფორმის სრულ ფუნქციონალს კატასტროფის მოვლენის გამოცხადებიდან 4 საათის განმავლობაში. |
აღდგენის ეს მიზნები უზრუნველყოფილია შემდეგი სარეზერვო ასლების არქიტექტურით :
| სარეზერვო ასლის ტიპი | სიხშირე | შენახვის ვადა | დაშიფვრა |
|---|---|---|---|
| ტრანზაქციების ჟურნალის სარეზერვო ასლები | ყოველ 15 წუთში | 7 დღე | AES-256 შენახვისას |
| მონაცემთა ბაზის სრული სარეზერვო ასლები | ყოველ 12 საათში | 30 დღე | AES-256 შენახვისას |
| ფაილების ინკრემენტული სარეზერვო ასლები | ყოველდღიურად | 30 დღე | AES-256 შენახვისას |
| ყოველკვირეული სრული სარეზერვო ასლები | ყოველკვირეულად (კვირა) | 90 დღე | AES-256 შენახვისას |
| ყოველთვიური საარქივო სარეზერვო ასლები | ყოველთვიურად (1-ლ რიცხვში) | 12 თვე | AES-256 შენახვისას |
ყველა სარეზერვო ასლი ინახება გეოგრაფიულად დუბლირებულ Azure საცავში დამკვეთისთვის განსაზღვრულ Azure-ის რეგიონში, რეგიონებს შორის რეპლიკაციის არჩევითი შესაძლებლობით, როგორც ეს განსაზღვრულია კომერციულ ხელშეკრულებაში. სარეზერვო ასლების მთლიანობა მოწმდება აღდგენის ავტომატური ტესტებით, რომლებიც ტარდება კვარტალურად.
Azure Backup-ის მიმოხილვა: https://azure.microsoft.com/en-us/products/backup
3.4 ინციდენტების პრიორიტეტულობის კლასიფიკაცია
მიმწოდებლის მომსახურების ცენტრში (PSD) რეგისტრირებული ყველა ინციდენტი კლასიფიცირდება პრიორიტეტულობის შემდეგი დონეების მიხედვით:
| პრიორიტეტი | სიმძიმე | განმარტება | მაგალითი |
|---|---|---|---|
| P1 | კრიტიკული | სისტემის სრული მიუწვდომლობა ან კრიტიკული ბიზნეს-ფუნქციის მწყობრიდან გამოსვლა, რომელიც ეხება ყველა ან თითქმის ყველა უფლებამოსილ მომხმარებელს. საფრთხეშია მონაცემთა მთლიანობა. | საწარმოო სერვერი გათიშულია, მონაცემთა ბაზის კრიტიკული დაზიანება, პლატფორმა სრულიად მიუწვდომელია, მონაცემთა დაკარგვის შემთხვევა. |
| P2 | საჩქარო | კრიტიკული ბიზნეს-ფუნქციის მნიშვნელოვანი გაუარესება. სისტემა ფუნქციონირებს, მაგრამ მკვეთრად შეზღუდული ფუნქციონალით. მნიშვნელოვანი ფუნქცია მიუწვდომელია. | ძირითადი მოდული არ ფუნქციონირებს (მაგ., ხარჯების კონტროლი), მწარმოებლურობის მკვეთრი დავარდნა, კრიტიკული ინტეგრაციის მწყობრიდან გამოსვლა. |
| P3 | მნიშვნელოვანი | არაკრიტიკული ფუნქციის დაზიანება ან მწარმოებლურობის გაუარესება, რომელიც ხელს არ უშლის ძირითად ბიზნეს-ოპერაციებს. არსებობს გონივრული დროებითი გამოსავალი. | ანგარიშის გენერირების ხარვეზი, არაკრიტიკული მოდულის პრობლემა, გამოყენებადობაზე მოქმედი ვიზუალური დეფექტი, ინტეგრაციის მცირე ხარვეზი. |
| P4 | მცირე | ვიზუალური ხარვეზი, საინფორმაციო მოთხოვნა ან გაუმჯობესების შეთავაზება დაუყოვნებლივი ოპერაციული გავლენის გარეშე. | მომხმარებლის ინტერფეისის გასწორების პრობლემა, დოკუმენტაციის შესწორება, ფუნქციის მოთხოვნა, ზოგადი შეკითხვა. |
პრიორიტეტულობის კლასიფიკაცია ურთიერთშეთანხმებით დადგენილია დამკვეთსა და მიმწოდებელს შორის თიქეთის რეგისტრაციისას. თუ მხარეები ვერ შეთანხმდებიან, უპირატესობა ენიჭება დამკვეთის კლასიფიკაციას მომსახურების მიწოდების მენეჯერის მიერ მომსახურების მომდევნო დაგეგმილ განხილვაზე განხილვამდე.
P1 და P2 ინციდენტების შესახებ მიმწოდებლის მომსახურების ცენტრს უნდა შეეტყობოს ტელეფონით დაუყოვნებლივი ყურადღების უზრუნველსაყოფად. P3 და P4 ინციდენტების შესახებ შეტყობინება შესაძლებელია ელ.ფოსტით, PSD პორტალით ან ტელეფონით.
3.5 SLA-ის რეაგირებისა და გადაწყვეტის მატრიცა
მიმწოდებელი ინციდენტებზე რეაგირებს და მათ გადაწყვეტს ქვემოთ მოცემულ SLA მატრიცაში განსაზღვრული მაჩვენებლების ფარგლებში:
| პრიორიტეტი | რეაგირების დრო | MTTR მაჩვენებელი | დროებითი გამოსავლის მაჩვენებელი | მომსახურების ფანჯარა | GOS მაჩვენებელი |
|---|---|---|---|---|---|
| P1 – კრიტიკული | დაუყოვნებლივ | 4 საათი | უწყვეტი მუშაობა გადაწყვეტამდე | 24 × 7 × 365 | 98% |
| P2 – საჩქარო | დაუყოვნებლივ | 8 საათი | 15 სამუშაო დღე | 24 × 7 × 365 | 95% |
| P3 – მნიშვნელოვანი | 2 საათში | 12 საათი | 20 სამუშაო დღე | 24 × 7 × 365 | 93% |
| P4 – მცირე | 4 საათში | მომდევნო რელიზი | მომდევნო დაგეგმილი რელიზი | სამუშაო საათები | 90% |
სადაც:
- რეაგირების დრო = დრო PSD-ის მიერ ინციდენტის მიღების დადასტურებიდან დანიშნული ინჟინრის პირველ დიაგნოსტიკურ ქმედებამდე
- MTTR (აღდგენის საშუალო დრო – Mean Time to Repair) = სამიზნე დრო ინციდენტის მიღების დადასტურებიდან სრულ გადაწყვეტამდე ან ეფექტურ დროებით გამოსავალამდე
- დროებითი გამოსავლის მაჩვენებელი = მაქსიმალური დრო დროებითი გადაწყვეტის უზრუნველსაყოფად, რომელიც მუდმივ გამოსწორებამდე აღადგენს ძირითად ბიზნეს-ფუნქციონალს
- GOS (მომსახურების ხარისხის დონე – Grade of Service) = თითოეული პრიორიტეტულობის დონის ინციდენტების პროცენტული წილი, რომლებიც გაზომვის პერიოდში გადაწყდა MTTR მაჩვენებლის ფარგლებში
3.6 SLA-ის გამონაკლისები
შემდეგი მოვლენები გამორიცხულია SLA-ის გაზომვიდან, არ ითვლება მოცდენად და გავლენას არ ახდენს GOS-ის გაანგარიშებაზე:
- (a) დაგეგმილი ტექნიკური მომსახურება : წინასწარ შეტყობინებული ტექნიკური მომსახურება, რომელიც სრულდება შეთანხმებული ტექნიკური მომსახურების ფანჯრების ფარგლებში, როგორც ეს განსაზღვრულია ნაწილში 3.2.3
- (b) უსაფრთხოების მოვლენები : ნებისმიერი მოცდენა, რომელიც გამოწვეულია უსაფრთხოების დარღვევით, DDoS შეტევებით ან პლატფორმისა და დამკვეთის მონაცემების დასაცავად გამოყენებული უსაფრთხოების გადაუდებელი პატჩებით
- (c) ფორს-მაჟორი : მიმწოდებლის გონივრულ კონტროლს მიღმა მოვლენები, როგორც ეს განსაზღვრულია მე-9 ნაწილში
- (d) დამკვეთის ბრალით გამოწვეული დაყოვნები : დაყოვნები, რომლებიც გამოწვეულია დამკვეთის მიერ ნაწილით 2.8 გათვალისწინებული ვალდებულებების შეუსრულებლობით, მათ შორის ინფორმაციის დროულად არაწარდგენით, დამტკიცების დაყოვნებით ან არაავტორიზებული ცვლილებებით
- (e) მესამე მხარის მწყობრიდან გამოსვლა : ინტერნეტზე მიერთების, DNS-ის ან სხვა მომსახურებების შეფერხება, რომლებიც არ არის მიმწოდებლის უშუალო კონტროლში, მათ შორის Microsoft Azure პლატფორმის გათიშვები, რომლებიც გავლენას ახდენს საბაზისო ინფრასტრუქტურაზე
- (f) დამტკიცების პროცესის დაყოვნები : დამკვეთის დამტკიცების სამუშაო პროცესებით ან დადასტურების პროცედურებით გამოწვეული დაყოვნები, რომლებიც ხელს უშლის მიმწოდებელს გადაწყვეტის სამუშაოების გაგრძელებაში. Azure პლატფორმის გათიშვის შემთხვევაში მიმწოდებელი დამკვეთს წარუდგენს Microsoft-ის შესაბამის ძირეული მიზეზის ანალიზის (RCA) ანგარიშს Microsoft-ის მიერ მისი გამოქვეყნებიდან 5 სამუშაო დღის განმავლობაში.
Azure Service Health (სერვისების მდგომარეობა): https://azure.microsoft.com/en-us/features/service-health/ Azure-ის სტატუსი: https://status.azure.com/
3.7 SLA-ის შეუსრულებლობის ჯარიმები
თუ მიმწოდებელი ვერ აღწევს წინამდებარე მე-3 ნაწილით განსაზღვრულ SLO-ს ან მომსახურების ხარისხის დონის (GOS) მაჩვენებლებს, დამკვეთს უფლება აქვს მიიღოს მიმწოდებლის მიერ გადახდილი ფინანსური ჯარიმები. ჯარიმების სკალა, გაანგარიშების საფუძველი და ზღვრული ოდენობები განსაზღვრულია თითოეული დამკვეთის კომერციულ ხელშეკრულებაში. მოკლედ:
- (a) გადახრის მიხედვით საფეხურებრივი: ჯარიმები იზრდება მაჩვენებლიდან ჩამორჩენის ოდენობის შესაბამისად. შეთანხმებული დასაშვები დიაპაზონის ფარგლებში მცირე გადახრა ჯარიმას არ იწვევს.
- (b) ორი მაჩვენებელი: ჯარიმის განსაზღვრისას გათვალისწინებულია როგორც ხელმისაწვდომობის (SLO), ასევე მომსახურების ხარისხის დონის (GOS) შესრულება, რომლის დროსაც უფრო მეტი წონა აქვს ხელმისაწვდომობას.
- (c) პირდაპირი გადახდა: ჯარიმები იხდება პირდაპირი ფულადი გადახდის სახით და არა საკრედიტო შეტყობინებით, დამკვეთის მოთხოვნის დადასტურების შემდეგ. ვრცელდება კვარტალური ზღვარი.
- (d) მოთხოვნის პროცესი: დამკვეთი წერილობით მოთხოვნას შესაბამისი ინციდენტებისა და დამადასტურებელი მტკიცებულებების მითითებით წარადგენს დარღვევის თვის დასრულებიდან 30 დღის განმავლობაში. მიმწოდებელი მოთხოვნას ადასტურებს ან სადავოდ ხდის 10 სამუშაო დღის განმავლობაში. დავები გადაეცემა სამეთვალყურეო კომიტეტს.
- (e) ფინანსური დაცვის ერთადერთი საშუალება: ჯარიმები წარმოადგენს დამკვეთის ფინანსური დაცვის ერთადერთ და გამორიცხვით საშუალებას მომსახურების დონეების შეუსრულებლობის შემთხვევაში. ეს არ ზღუდავს დამკვეთის უფლებას, შეწყვიტოს ჩარჩო არსებითი დარღვევის გამო მე-7 ნაწილის შესაბამისად.
- (f) გამონაკლისები: ჯარიმა არ გადაიხდება, თუ SLA-ის შეუსრულებლობა გამოწვეულია ნაწილში 3.6 განსაზღვრული გამონაკლისი მოვლენით.
3.8 დამატებითი ლიცენზიები და ახალი მომხმარებლები
თუ დამკვეთი გამოწერის ვადის განმავლობაში გადაწყვეტს ახალი უფლებამოსილი მომხმარებლების (დამატებითი ლიცენზიების) დამატებას, ვრცელდება შემდეგი დებულებები:
- (a) SLA-ის იგივე დაფარვა: წინამდებარე მე-3 ნაწილით განსაზღვრული ყველა მომსახურების დონე, სამიზნე მაჩვენებელი, აღდგენის მიზანი და ჯარიმების დებულება თანაბრად ვრცელდება ყველა დამატებით უფლებამოსილ მომხმარებელსა და ლიცენზიაზე აქტივაციის თარიღიდან. ახალი მომხმარებლებისთვის შემცირებული ან ეტაპობრივი SLA არ გამოიყენება.
- (b) ARR-ის კორექტირება: ნაწილის 3.8 შესაბამისად ჯარიმების გასაანგარიშებლად გამოყენებული ARR ხელახლა იანგარიშება დამატებითი სალიცენზიო საფასურის გათვალისწინებით აქტივაციის თარიღიდან, პროპორციულად შესაბამისი გაზომვის პერიოდის დარჩენილი დროსთვის.
- (c) გარემოს ერთგვაროვნება: ახალ მომხმარებლებს ექნებათ წვდომა იმავე საწარმოო და Staging გარემოებზე. მიმწოდებელი უზრუნველყოფს პლატფორმის მასშტაბირებას დამატებითი მომხმარებლების მოსათავსებლად მწარმოებლურობისა თუ ხელმისაწვდომობის გაუარესების გარეშე.
- (d) ჩართვის SLA: მიმწოდებელი ახალი მომხმარებლის ანგარიშებს ააქტიურებს დამკვეთისგან ლიცენზიის დამატების შევსებული მოთხოვნის მიღებიდან 2 სამუშაო დღის განმავლობაში, როლის მინიჭების, წვდომის უზრუნველყოფისა და საწყისი სატრენინგო მასალების ჩათვლით.
- (e) სიმძლავრის გარანტია: მიმწოდებელი იძლევა გარანტიას, რომ გამოყოფილ კერძო სუვერენულ გარემოს აქვს საკმარისი რეზერვი ან პროაქტიულად გაფართოვდება დამატებითი მომხმარებლების მხარდაჭერისთვის 99.9%-იან SLO-ზე ან ნებისმიერ GOS მაჩვენებელზე ზეგავლენის გარეშე. ახალი ლიცენზიების დამატების პროცედურა, მათ შორის ფასწარმოქმნა და კომერციული ხელშეკრულების ცვლილების მოთხოვნები, განსაზღვრულია მე-6 ნაწილში (საფასური, ინვოისირება და გადახდის პირობები).
3.9 SLA-ის ანგარიშგება და მომსახურების განხილვები
3.9.1 SLA-ის ყოველთვიური ანგარიში
დამკვეთის მოთხოვნის შემთხვევაში მიმწოდებელს შეუძლია დამკვეთს წარუდგინოს SLA-ის შესრულების ყოველთვიური ანგარიში თითოეული კალენდარული თვის დასრულებიდან 10 სამუშაო დღის განმავლობაში. ანგარიში მოიცავს:
- (e) თვიური ხელმისაწვდომობის პროცენტს და მის შედარებას SLO-ის მაჩვენებელთან
- (f) ინციდენტების საერთო რაოდენობას პრიორიტეტულობის დონეების მიხედვით, რეაგირებისა და გადაწყვეტის დროის მითითებით
- (g) GOS-ის მიღწევას თითოეული პრიორიტეტულობის დონისთვის
- (h) სარეზერვო ასლების წარმატების მაჩვენებლებს და სარეზერვო ასლების შექმნის ჩაშლის ნებისმიერ შემთხვევას
- (i) SLA-ის ნებისმიერ დარღვევას ძირეული მიზეზის ანალიზითა და მაკორექტირებელი ქმედებებით
- (j) ჯარიმების გაანგარიშებას (საჭიროების შემთხვევაში) ARR-ის საფუძვლის მითითებით
- (k) ტენდენციების ანალიზს, რომელიც ადარებს შესრულებას წინა 3 თვესთან
3.9.2 მომსახურების კვარტალური განხილვა
მხარეებს შეუძლიათ ჩაატარონ მომსახურების კვარტალური განხილვის შეხვედრა SLA-ის შესრულების განსახილველად, მომსახურების გაუმჯობესების ინიციატივების გასამსჯელად და გადაუჭრელი საკითხების გადასაწყვეტად. მიმწოდებელი თითოეულ განხილვამდე მინიმუმ 5 სამუშაო დღით ადრე ამზადებს და წარადგენს მომსახურების კვარტალურ ანგარიშს დამკვეთთან შეთანხმებული ფორმატით. კვარტალური ანგარიში მოიცავს:
- (l) SLA-ის კონსოლიდირებულ შესრულებას კვარტალის განმავლობაში
- (m) მნიშვნელოვანი ინციდენტების შეჯამებას ძირეული მიზეზის ანალიზით
- (n) მომსახურების გაუმჯობესების გეგმის განახლებებსა და პროგრესს
- (o) სიმძლავრისა და მწარმოებლურობის ტენდენციების ანალიზს
- (p) ცვლილებების მართვის შეჯამებას (განთავსებული პატჩები, განახლებები, რელიზები)
- (q) რისკების მომავლისკენ ორიენტირებულ შეფასებასა და შერბილების გეგმას
3.9.3 მომსახურების უწყვეტი გაუმჯობესება
მიმწოდებელი აწარმოებს მომსახურების უწყვეტი გაუმჯობესების (CSI) რეესტრს, რომელშიც აღრიცხულია გამოვლენილი გაუმჯობესების შესაძლებლობები, შეთანხმებული ქმედებები, პასუხისმგებელი მხარეები და დასრულების სამიზნე თარიღები. CSI რეესტრი განიხილება მომსახურების ყოველი კვარტალური განხილვისას.
3.10 SLA-ის მმართველობა
SLA-ის მართვაზე ვრცელდება მმართველობის შემდეგი სტრუქტურა:
| როლი | პასუხისმგებლობა | სიხშირე |
|---|---|---|
| მომსახურების მიწოდების მენეჯერი (მიმწოდებელი) | SLA-ის შესრულებაზე ანგარიშვალდებული ძირითადი პირი. პასუხისმგებელია SLA-ის ყოველთვიურ ანგარიშზე, ესკალაციების მართვაზე და CSI რეესტრზე. | მუდმივად |
| ანგარიშის მენეჯერი (მიმწოდებელი) | კომერციული ურთიერთობების მართვა. ესკალაციის წერტილი SLA-სთან დაკავშირებული დავებისა და მომსახურების კრედიტების მოთხოვნებისთვის. | საჭიროებისამებრ |
| დამკვეთის IT საკონტაქტო პირი | დამკვეთის ძირითადი საკონტაქტო პირი მომსახურების ყოველდღიური მართვისთვის, ინციდენტების შესახებ შეტყობინებისთვის და UAT-ის კოორდინაციისთვის. | მუდმივად |
| სამეთვალყურეო კომიტეტი | უფროსი ხელმძღვანელობის ერთობლივი ფორუმი მომსახურების ურთიერთობების სტრატეგიული განხილვისთვის, მნიშვნელოვანი ინციდენტების განხილვისთვის და ხელშეკრულების დონის გადაწყვეტილებების მისაღებად. | წელიწადში ორჯერ |
წინამდებარე ნაწილით განსაზღვრული SLA-ის მაჩვენებლები ყოველწლიურად განიხილება სამეთვალყურეო კომიტეტის სხდომაზე და შესაძლოა შეიცვალოს მხარეების ურთიერთი წერილობითი შეთანხმებით.
Azure SLA-ის შეჯამება: https://azure.microsoft.com/en-us/support/legal/sla/summary/ ITIL — მომსახურების დონის მართვა: https://www.axelos.com/best-practice-solutions/itil
3.11 პროცესების რეესტრი
ქვემოთ მოცემული ცხრილი აჯამებს ამ თავში დადგენილ SLA-ის მართვის პროცესებს, პასუხისმგებელ როლებს, მოსალოდნელ შედეგებს და მითითებებს სხვა თავებში აღწერილ დაკავშირებულ პროცესებზე.
როლების აღნიშვნები: P = მიმწოდებელი | C = დამკვეთი | PSD = მიმწოდებლის მომსახურების ცენტრი | SDM = მომსახურების მიწოდების მენეჯერი | SC = სამეთვალყურეო
კომიტეტი
3.11.1 პროცესების ჩამონათვალი
| № | პროცესი | ინიცირების საფუძველი | შემსრულებელი | დამმტკიცებელი | მოსალოდნელი შედეგი | მითითება |
|---|---|---|---|---|---|---|
| P-3.01 | ხელმისაწვდომობის მონიტორინგი | უწყვეტი (ავტომატიზებული) | მიმწოდებელი (NOC) | SDM | 99.9% SLO შენარჩუნებულია; გაფრთხილებები ზღვრული მნიშვნელობის დარღვევისას | § 3.2 |
| P-3.02 | ინციდენტის კლასიფიკაცია | ინციდენტის შესახებ შეტყობინება PSD-ში | PSD | დამკვეთი / SDM | ურთიერთშეთანხმებული პრიორიტეტი (P1–P4) | § 3.5, § 4.3 |
| P-3.03 | SLA-ის შესრულების გაზომვა | თვის დასრულება | SDM | — | SLA-ის ყოველთვიური ანგარიში 10 სამუშაო დღის განმავლობაში | § 3.10.1 |
| P-3.04 | SLA-ის დარღვევის გამოვლენა | SLA-ის ყოველთვიური ანგარიში ავლენს დარღვევას | SDM | მიმწოდებლის ანგარიშის მენეჯერი | ჯარიმის გაანგარიშება ინიცირებულია | § 3.8 |
| P-3.05 | ჯარიმის მოთხოვნა და გადახდა | დამკვეთი წარადგენს მოთხოვნას 30 დღის განმავლობაში | მიმწოდებლის ფინანსური სამსახური | მიმწოდებლის ანგარიშის მენეჯერი | ფულადი გადახდა დადასტურებიდან 30 დღის განმავლობაში | § 3.8.2 |
| P-3.06 | მომსახურების კვარტალური განხილვა | კვარტალის დასრულება | SDM + დამკვეთის IT საკონტაქტო პირი | სამეთვალყურეო კომიტეტი | მომსახურების განხილვა დასრულებულია; CSI რეესტრი განახლებულია | § 3.10.2, § 4.10 |
| P-3.07 | ახალი მომხმარებლის აქტივაცია | დამკვეთის მოთხოვნა ლიცენზიის დამატებაზე | მიმწოდებელი (PSD) | დამკვეთის IT საკონტაქტო პირი | მომხმარებელი აქტიურია 2 სამუშაო დღის განმავლობაში; ARR კორექტირებულია პროპორციულად | § 3.9, § 6 |
| P-3.08 | დაგეგმილი ტექნიკური მომსახურება | დაგეგმილია ტექნიკური მომსახურების ფანჯარა | მიმწოდებელი (ინფრასტრუქტურა) | SDM | ტექნიკური მომსახურება დასრულებულია; ≤ 4 სთ/თვე; დამკვეთს ეცნობება 5 სამუშაო დღით ადრე | § 3.2.3 |
3.11.2 RACI მატრიცა
| პროცესი (№) | მიმწოდებელი | PSD | დამკვეთი | SDM | SC |
|---|---|---|---|---|---|
| P-3.01 ხელმისაწვდომობის მონიტორინგი | R | I | I | A | — |
| P-3.02 ინციდენტის კლასიფიკაცია | — | R | C | A | — |
| P-3.03 SLA-ის გაზომვა | — | — | I | R/A | I |
| P-3.04 დარღვევის გამოვლენა | — | — | I | R | I |
| P-3.05 ჯარიმის მოთხოვნა | R | — | R | A | I |
| P-3.06 კვარტალური განხილვა | C | — | R | R | A |
| P-3.07 მომხმარებლის აქტივაცია | R | R | A | I | — |
| P-3.08 დაგეგმილი ტექნიკური მომსახურება | R | I | I | A | — |
R = პასუხისმგებელი (ასრულებს) | A = ანგარიშვალდებული (ამტკიცებს) | C = კონსულტირებული | I = ინფორმირებული | — = არ მონაწილეობს
3.11.3 პროცესის ნაკადი — SLA-ის სასიცოცხლო ციკლი
| ეტაპი | საქმიანობა | როლი | შედეგი |
|---|---|---|---|
| ① მონიტორინგი | ხელმისაწვდომობისა და მწარმოებლურობის უწყვეტი მონიტორინგი (Azure Monitor, Defender) | მიმწოდებელი (NOC) | რეალურ დროში გაფრთხილებები; ფუნქციონირების დროის მონაცემები |
| ② გამოვლენა | ინციდენტი გამოვლინდა ან მის შესახებ შეტყობინება მოხდა PSD-ის ომნიარხიანი არხებით | PSD / დამკვეთი | თიქეთი შექმნილია → § 4.3 |
| ③ კლასიფიკაცია | პრიორიტეტი მინიჭებულია (P1–P4), SLA-ის ათვლა იწყება | PSD + დამკვეთი | შეთანხმებული პრიორიტეტი; რეაგირების ტაიმერი |
| ④ გადაწყვეტა | გადაწყვეტა MTTR მაჩვენებლის შესაბამისად; საჭიროების შემთხვევაში ესკალაცია | მიმწოდებლის საინჟინრო გუნდი | ინციდენტი გადაწყვეტილია → § 4.4 |
| ⑤ ანგარიშგება | SLA-ის ყოველთვიური ანგარიში მომზადებულია; GOS და ხელმისაწვდომობა გამოთვლილია | SDM | SLA-ის ანგარიში → § 3.10.1 |
| ⑥ განხილვა | მომსახურების კვარტალური განხილვა; CSI რეესტრი განახლებულია | SDM + დამკვეთი + SC | CSI ქმედებები → § 4.10 |
| ⑦ ჯარიმა | დარღვევის შემთხვევაში: ჯარიმის მოთხოვნა, დადასტურება, ფულადი გადახდა | დამკვეთი → მიმწოდებლის ფინანსური სამსახური | გადახდა 30 დღის განმავლობაში |