მომსახურების მხარდაჭერა და ოპერაციები

4.1 მიმოხილვა

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

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

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

4.2 მიმწოდებლის მომსახურების ცენტრი (PSD)

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

4.2.1 ჩაშენებული თიქეთინგის სისტემა

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

• (a) თიქეთის რეგისტრაციას აპლიკაციის შიგნით: მომხმარებლები თიქეთებს ქმნიან უშუალოდ ProjectVIEW ERP-ის ინტერფეისში, კონტექსტური ინფორმაციის ავტომატური აღრიცხვით, მათ შორის აქტიური მოდულის, ეკრანის, მომხმარებლის როლისა და ნებისმიერი დაკავშირებული ჩანაწერის;
• (b) სტატუსის თვალყურის დევნებას რეალურ დროში: ERP-ში ერთიანი დაშბორდი აჩვენებს ყველა ღია, მიმდინარე და გადაწყვეტილ თიქეთს სასიცოცხლო ციკლის სრული ხილვადობით, SLA-ის უკუთვლის ტაიმერებითა და პრიორიტეტის ინდიკატორებით;
• (c) ორმხრივ კომუნიკაციას: დამკვეთსა და დანიშნულ მხარდაჭერის ინჟინერს შორის მიმოწერა ხორციელდება უშუალოდ თიქეთში, რაც ინარჩუნებს სრულ ქრონოლოგიურ აუდიტის კვალს;
• (d) დანართებისა და მტკიცებულებების აღრიცხვას: მომხმარებლები თიქეთებს უშუალოდ უთანართებენ ეკრანის სურათებს, შეცდომების ჟურნალებს, დოკუმენტებსა და ეკრანის ჩანაწერებს, რაც გამორიცხავს კონტექსტის დაკარგვას ესკალაციისას;
• (e) SLA-ის მაჩვენებლებსა და ანგარიშგებას: SLA-ის ჩაშენებული თვალყურის დევნება ავტომატური გაფრთხილებებით, როდესაც რეაგირების ან გადაწყვეტის ვადა ზღვრულ მნიშვნელობას უახლოვდება, ასევე თიქეთების მოცულობის, კატეგორიებისა და გადაწყვეტის შედეგიანობის რეალურ დროში ანგარიშგება;
• (f) ცოდნის ბაზასთან ინტეგრაციას: თიქეთინგის სისტემა დაკავშირებულია მიმწოდებლის ჩაშენებულ ცოდნის ბაზასთან (wiki) და თიქეთის შექმნისას გამოსახავს შესაბამის სტატიებსა და ცნობილ გადაწყვეტებს თვითმომსახურების გზით გადაწყვეტისთვის;
• (g) ავტომატურ შეტყობინებებს: თიქეთის სტატუსის ყოველი ცვლილებისას (რეგისტრირებული, მიღებული, დანიშნული, განახლებული, გადაწყვეტილი, დახურული) იგზავნება ელ.ფოსტისა და აპლიკაციის შიდა შეტყობინებები, რაც ყველა დაინტერესებულ მხარეს ინფორმირებულს ინახავს.

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

4.2.2 მხარდაჭერის ომნიარხიანი არხები

მიმწოდებელი დამკვეთს PSD-ზე წვდომას უზრუნველყოფს შემდეგი არხებით:

4.2.3 WhatsApp Business მხარდაჭერის არხი

მიმწოდებელი თითოეული დამკვეთისთვის ქმნის ცალკე WhatsApp Business ჯგუფს, რომელიც ადაკავშირებს დამკვეთის დანიშნულ ძირითად მომხმარებლებს მიმწოდებლის დანიშნულ კონსულტანტებთან. ეს არხი მოქმედებს როგორც სწრაფი არაოფიციალური კომუნიკაციის შრე, რომელიც ავსებს თიქეთინგის ოფიციალურ სისტემას. WhatsApp არხი რეგულირდება შემდეგი წესებით:

• (a) ფარგლები: სწრაფი შეკითხვები, გამოყენების შესახებ კონსულტაცია, ფუნქციონალის განმარტება, ცვლილების შესაძლო მოთხოვნების არაოფიციალური განხილვა და არაკრიტიკული საკითხების წინასწარი შეტყობინება. WhatsApp არხი არ ცვლის თიქეთის ოფიციალურ რეგისტრაციას;
• (b) ოფიციალურად გაფორმების წესი: WhatsApp-ით შეტყობინებული ნებისმიერი საკითხი, რომელიც ოფიციალურ თვალის დევნებას, SLA-ს გაზომვას, კოდის ცვლილებას, კონფიგურაციის შეცვლას ან ესკალაციას საჭიროებს, მიმწოდებლის კონსულტანტმა გამოვლენიდან 4 საათის განმავლობაში უნდა დაარეგისტრიროს თიქეთად ჩაშენებულ თიქეთინგის სისტემაში. დამკვეთს ეცნობება თიქეთის საცნობარო ნომერი;
• (c) SLA-დან გამონაკლისი: SLA-ს რეაგირებისა და გადაწყვეტის ტაიმერები იწყება ჩაშენებულ თიქეთინგის სისტემაში თიქეთის ოფიციალურად გაფორმებისას და არა WhatsApp-ით პირველი კომუნიკაციისას;
• (d) მონაცემთა დაცვა: მონაწილეებმა WhatsApp-ით არ უნდა გააზიარონ პერსონალური მონაცემები, საავტორიზაციო მონაცემები, მონაცემთა ბაზის შიგთავსი ან კონფიდენციალური ინფორმაცია. მიმწოდებელი ყველა მონაწილეს აწვდის ინფორმაციას მონაცემთა დამუშავების ვალდებულებების შესახებ მოქმედი მონაცემთა დაცვის კანონმდებლობის შესაბამისად (იხ. ნაწილი 17);
• (e) შენახვა: WhatsApp შეტყობინებები ინახება მიმწოდებლის მონაცემთა შენახვის პოლიტიკის შესაბამისად. აუდიტებადობის მიზნით WhatsApp-ით წარმართული ნებისმიერი არსებითი ტექნიკური განხილვა ან მიღებული გადაწყვეტილება შეჯამებულად უნდა აისახოს შესაბამისი თიქეთის ჩანაწერში;
• (f) ჯგუფის წევრობა: ჯგუფის წევრობა ერთობლივ იმართება. მიმწოდებელი ჯგუფის წევრობას ახლებს პერსონალის ნებისმიერი ცვლილებიდან 2 სამუშაო დღის განმავლობაში. დამკვეთი მიმწოდებელს აცნობს მის მიერ დანიშნულ ძირითად მომხმარებლებთან დაკავშირებულ ნებისმიერ ცვლილებაზე.

4.2.4 PSD-ს სამუშაო საათები და ხელმისაწვდომობა

PSD თიქეთების რეგისტრაციისთვის ყველა არხში მუშაობს დღეში 24 საათი, კვირაში 7 დღე, წელიწადში 365 დღე. გადაწყვეტის საქმიანობა ხორციელდება SLA-ს რეაგირებისა და გადაწყვეტის მატრიცაში განსაზღვრული სამუშაო ფანჯრების ფარგლებში (ნაწილი 3.6).

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

4.2.5 PSD-ს პასუხისმგებლობები

PSD:

• (a) აღრიცხავს დამკვეთის მიერ შეტყობინებულ ყველა ინციდენტსა და მომსახურების მოთხოვნას ჩაშენებულ თიქეთინგის სისტემაში და ანიჭებს თიქეთის უნიკალურ საცნობარო ნომერს კონტექსტური მეტამონაცემების ავტომატური აღრიცხვით;
• (b) დამკვეთთან ათანხმებს თითოეული თიქეთისთვის მინიჭებულ პრიორიტეტის დონეს ინციდენტების პრიორიტეტების კლასიფიკაციის შესაბამისად, რომელიც განსაზღვრულია ნაწილში 3.5;
• (c) დამკვეთს უგზავნის ელექტრონული თიქეთის მიღების დადასტურებას;
• (d) ახორციელებს ყველა საჭირო ესკალაციის მართვას, რათა მომსახურებები აღდგენილ იქნეს მომსახურების დონის შესაბამისი სამიზნე მნიშვნელობების ფარგლებში;
• (e) დამკვეთს რეგულარულად, ურთიერთშეთანხმებული ინტერვალებით აწვდის ინფორმაციას პროგრესის შესახებ თიქეთინგის სისტემის, ტელეფონის, ელ.ფოსტის ან WhatsApp-ის მეშვეობით;
• (f) თიქეთის გადაწყვეტისას აცნობს დამკვეთს, მათ შორის წარუდგენს ძირეული მიზეზის მოკლე აღწერას, გატარებულ მაკორექტირებელ ქმედებას და ინფორმაციას იმის შესახებ, უნდა დაიხუროს თიქეთი თუ საჭიროებს დამატებით ქმედებას;
• (g) შესაძლებლობის შემთხვევაში თიქეთების გადაწყვეტას ჯერ დისტანციურად ცდილობს. თუ დისტანციური გადაწყვეტა შეუძლებელია, მიმწოდებელი საჭიროებისამებრ აგზავნის კვალიფიცირებულ ინჟინრს დამკვეთის შენობაში;
• (h) WhatsApp-ით ან ტელეფონით თავდაპირველად შეტყობინებულ ნებისმიერ საკითხს 4 საათის განმავლობაში ოფიციალურად აფორმებს ჩაშენებულ თიქეთინგის სისტემაში;
• (i) ჩაშენებულ თიქეთინგის სისტემაში ინახავს თიქეთებთან დაკავშირებული ყველა ურთიერთქმედების, სტატუსის ცვლილებებისა და გადაწყვეტის საქმიანობის სრულ აუდიტის კვალს.

4.3 თიქეთის სასიცოცხლო ციკლის მართვა

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

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

4.3.1 თიქეთის რეგისტრაცია

დამკვეთის მიერ თიქეთის რეგისტრაციისას PSD-ს უნდა მიეწოდოს შემდეგი მინიმალური ინფორმაცია:

• (a) დამკვეთის დასახელება და ხელშეკრულების ნომერი ( ავტომატურად ივსება, როდესაც თიქეთი ჩაშენებული თიქეთინგის სისტემით იქმნება);
• (b) საკითხის შემტყობინებლი პირის სახელი და საკონტაქტო მონაცემები;
• (c) საკითხის მკაფიო აღწერა, მათ შორის გამეორების ნაბიჯები (ინციდენტებისთვის) ან მოთხოვნის ბუნება (მომსახურების მოთხოვნებისთვის);
• (d) დაზიანებული მოდულ(ებ)ი და გავლენის ქვეშ მყოფი უფლებამოსილი მომხმარებლების რაოდენობა;
• (e) დამკვეთის მიერ მიღებული ნებისმიერი დიაგნოსტიკური მონაცემები, ეკრანის სურათები ან შეცდომის შეტყობინებები;
• (f) თიქეთისთვის დამკვეთის მიერ შემოთავაზებული პრიორიტეტის დონე.

4.3.2 თიქეთის დამუშავების სამუშაო პროცესი

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

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

4.3.3 თიქეთების კლასიფიკაცია

თიქეთები კლასიფიცირდება შემდეგ კატეგორიებად:

4.4 ტექნიკური ესკალაცია

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

4.4.1 ესკალაციის დონეები

4.4.2 დამკვეთის ინიცირებული ესკალაცია

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

P1 (კრიტიკული) ინციდენტებისთვის მიმწოდებელი ავტომატურად ახდენს ესკალაციას დონე 2-ზე 30 წუთში, თუ საწყისმა რეაგირებამ გადაწყვეტის გზა ვერ გამოავლინა, ხოლო დონე 3-ზე — 2 საათში, თუ ინციდენტი კვლავ გადაუწყვეტელია. P1-ის ყველა ესკალაციის შესახებ რეალურ დროში ეცნობება დამკვეთის დანიშნულ IT საკონტაქტო პირს და მომსახურების მიწოდების მენეჯერს.

4.5 პრევენციული ტექნიკური მომსახურება

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

4.5.1 პრევენციული ტექნიკური მომსახურების ფარგლები

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

• (a) ინფრასტრუქტურის მდგომარეობის შემოწმება: ვირტუალური მანქანების წარმადობის მონიტორინგი, დისკის გამოყენება, მეხსიერების განაწილება, CPU-ს დატვირთვის ანალიზი და ქსელის შეყოვნების შეფასება;
• (b) მონაცემთა ბაზის მომსახურება: ინდექსების ხელახლა აგება, სტატისტიკის განახლება, ტრანზაქციების ჟურნალის მართვა, მთლიანობის შემოწმება (DBCC CHECKDB) და საცავის ოპტიმიზაცია;
• (c) უსაფრთხოების პატჩები: ოპერაციული სისტემის, შუალედური პროგრამული უზრუნველყოფისა და მონაცემთა ბაზის უსაფრთხოების პატჩების განხილვა და გამოყენება მიმწოდებლის პატჩების მართვის პოლიტიკის შესაბამისად (ტექნიკური მომსახურების ფანჯრებისთვის იხ. ნაწილი 3.2.3);
• (d) რეზერვირების ვერიფიკაცია: რეზერვირების ამოცანების დასრულების ვალიდაცია, რეზერვული ასლების მთლიანობის ტესტირება და აღდგენის სწავლების ჩატარება (კვარტალურად);
• (e) აპლიკაციის მდგომარეობა: მოდულების დონის ფუნქციონალური შემოწმები, API endpoint-ების ვალიდაცია, ინტეგრაციების მონიტორინგი და შეცდომების ჟურნალების განხილვა ProjectVIEW ERP-ის ყველა აქტიურ მოდულში;
• (f) SSL/TLS სერტიფიკატების მართვა: სერტიფიკატების ვადის გასვლის მონიტორინგი, განახლება და როტაცია;
• (g) სიმძლავრის განხილვა: რესურსების მიმდინარე გამოყენების შეფასება გამოყოფილ სიმძლავრესთან მიმართებაში და მასშტაბირების შესახებ პროაქტიული რეკომენდაციები, როდესაც გამოყენება 75%-იან ზღვარს აჭარბებს.

4.5.2 პრევენციული ტექნიკური მომსახურების ანგარიშგება

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

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

4.6 ცვლილებების მართვა

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

4.6.1 ცვლილებების კლასიფიკაცია

4.6.2 ცვლილებების მართვის სამუშაო პროცესი

ყველა ჩვეულებრივი და გადაუდებელი ცვლილება მიყვება შემდეგ სამუშაო პროცესს:

• (a) მოთხოვნა: დამკვეთი ან მიმწოდებელი PSD-ს მეშვეობით წარადგენს ცვლილების მოთხოვნას აღწერით, ბიზნესისთვის დასაბუთებით, დაზიანებული მოდულებითა და დანერგვის მოთხოვნილი თარიღით;
• (b) შეფასება: მიმწოდებელი ატარებს გავლენის შეფასებას, რომელიც მოიცავს: ტექნიკურ რისკს, დაზიანებულ მომხმარებლებს, უკუსვლის (rollback) გეგმას, სავარაუდო შრომის მოცულობასა და დამოკიდებულებებს;
• (c) დამტკიცება: ცვლილებების სასატერწხვო საბჭო (ან გადაუდებელი ცვლილებებისთვის — მომსახურების მიწოდების მენეჯერი) იხილავს ცვლილებას და ამტკიცებს ან უარყოფს მას;
• (d) დანერგვა: ცვლილება შეიქმნება და განთავსდება Staging გარემოში;
• (e) UAT: დამკვეთი Staging გარემოში ატარებს მომხმარებლის უნივერსალურ მიღების ტესტირებას. UAT-სთვის გამოიყოფა მინიმუმ 5 სამუშაო დღე. საჭიროა წერილობითი დადასტურება (იხ. ნაწილი 3.3.1);
• (f) განთავსება: დამკვეთის მიერ UAT-ის დადასტურების შემდეგ ცვლილება საწარმოო გარემოში განთავსდება შეთანხმებული ტექნიკური მომსახურების ფანჯრის განმავლობაში;
• (g) დანერგვის შემდგომი განხილვა: მიმწოდებელი განთავსების შემდეგ 5 სამუშაო დღის განმავლობაში აკონტროლებს ცვლილებას და დამკვეთს წარუდგენს დახურვის ანგარიშს.

უკუსვლა (Rollback): ყოველი ჩვეულებრივი და გადაუდებელი ცვლილება უნდა მოიცავდეს დოკუმენტირებულ უკუსვლის გეგმას. თუ ცვლილება მომსახურების დაუგეგმავ გაუარსებას იწვევს, მიმწოდებელი უკუსვლას ახორციელებს საკითხის გამოვლენიდან 2 საათის განმავლობაში და დაუყოვნებლივ აცნობს დამკვეთს.

4.6.3 ცვლილებების აუდიტებადობა

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

4.7 პროგრამული რელიზების მართვა

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

4.7.1 რელიზები და განახლებები (ინკრემენტული – მაგ. v11.xx)

რელიზები და განახლებები არის ინკრემენტული მიწოდებები პლატფორმის მიმდინარე ძირითადი ვერსიის ფარგლებში (მაგ., v11.01, v11.02, v11.15). ისინი მოიცავს ცვლილებების მოთხოვნებს, ხარვეზების გასწორებებს, კონფიგურაციის კორექტირებებს და მცირე ფუნქციონალურ გაუმჯობესებებს, რომლებიც დამკვეთის დანერგვის სპეციფიკას შეესაბამება. რელიზები მიწოდებულია Agile შესრულების მეთოდოლოგიით, რომელიც დამკვეთის ოპერაციულ რითმზეა მორგებული.

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

რელიზების ვერსიების სისტემა: ყოველ ინკრემენტულ რელიზს ენიჭება სემანტიკური ვერსიის ნომერი მიმდინარე ძირითადი ვერსიის ფარგლებში (მაგ., v11.01, v11.02… v11.xx). ვერსიის ნომერი თანმიმდევრულად იზრდება სპრინტის ყოველი მიწოდებისას. მიმწოდებელი ინახავს რელიზების ჟურნალს, რომელიც დამკვეთისთვის ხელმისაწვდომია პლატფორმის მეშვეობით.

4.7.2 აპგრეიდები (ძირითადი ვერსია – მაგ. v11 → v12)

აპგრეიდი არის პლატფორმის ახალი ძირითადი ვერსია (მაგ., v11 → v12, v12 → v13). აპგრეიდები არის მთლიანი პროდუქტის მასშტაბის რელიზები, რომლებიც მოიცავს მნიშვნელოვან ფუნქციონალურ გაუმჯობესებებს, ახალ მოდულებს, UI/UX-ის გადადიზაინებას, ახალ API/SDK-ებს, არქიტექტურულ გაუმჯობესებებს და COTS-ის ძირითადი ვერსიების განახლებას (მაგ., .NET ფრეიმვორკი, SQL Server-ის ძრავა). აპგრეიდები გამოიცემა დაახლოებით წელიწადში ერთხელ და პროგრამული უზრუნველყოფის ახალ ვერსიის ნომერს წარმოადგენს.

ძირითადი აპგრეიდები, ჩვეულებრივ, მოიცავს:

• ახალი ფუნქციონალური გაუმჯობესებები: ახალი ფუნქციები, მოდულების ახალი შესაძლებლობები და სამუშაო პროცესების გაუმჯობესებები, რომლებიც ეფუძნება მიმწოდებლის პროდუქტობრივ გეგმას და კლიენტების სასატერწხვო საბჭოს უკუკავშირს;
• UI/UX გაუმჯობესებები: ინტერფეისის გადადიზაინება, გამოყენების სიმარტივის გაუმჯობესება, ხელმისაწვდომობის (accessibility) გაუმჯობესება და ადაპტიური დიზაინის განახლებები;
• API და SDK გაფართოებები: ინტეგრაციის ახალი endpoint-ები, Web API-ს გაფართოებული შესაძლებლობები და განახლებული პროგრამული უზრუნველყოფის შემუშავების ნაკრები (SDK);
• COTS პლატფორმის აპგრეიდები: საბაზისო ტექნოლოგიების (.NET, SQL Server, IIS) ახალ ვერსიებზე გადასვლა მიმწოდებლის მიერ ტექნოლოგიური აქტუალურობის ვალდებულების ფარგლებში;
• უსაფრთხოების გაუმჯობესებები: უსაფრთხოების ახალი სტანდარტების დანერგვა, დაშიფვრის განახლება და ახალ რეგულაციურ მოთხოვნებთან შესაბამისობა.

4.7.3 რელიზების მართვისა და განთავსების ინტეგრირებული პროცესი

ყველა რელიზი (ინკრემენტული) და აპგრეიდი (ძირითადი ვერსია) იმართება პლატფორმის რელიზების ცენტრის (Platform Release Centre) მეშვეობით, რომელიც რელიზების მართვისა და გავრცელების ცენტრალურ პლატფორმად მოქმედებს. პლატფორმა უზრუნველყოფს შემდეგ შესაძლებლობებს:

• (h) რელიზების კატალოგი: თითოეული დამკვეთისთვის ხელმისაწვდომი ყველა რელიზის სრული კატალოგი, დალაგებული აპლიკაციებისა და ვერსიების მიხედვით. რელიზის თითოეული ჩანაწერი მოიცავს რელიზის თარიღს, ვერსიის ნომერს და დეტალურ შენიშვნებს (release notes) ახალი ფუნქციების, გასწორებებისა და ცნობილი საკითხების აღწერით;
• (i) საავტორიზაციო მონაცემებზე დაფუძნებული წვდომა: პლატფორმაზე წვდომა დაცულია დამკვეთის დანიშნულ ადმინისტრატორებზე გაცემული უნიკალური საავტორიზაციო მონაცემებით. წვდომის უფლებები განსაზღვრავს დამკვეთის ლიცენზირებულ მოდულებზე გამოყენებადი რელიზების ხილვადობას;
• (j) რელიზის შენიშვნები და ცვლილებების ჟურნალები: ყოველ რელიზს თან ახლავს სემანტიკური და კონტექსტური კომენტარები უახლესი ფუნქციების, შესაძლებლობებისა და ხარვეზების გასწორებების შესახებ, რომლებსაც გამოქვეყნებამდე იხილავს და ამტკიცებს მიმწოდებლის რეცენზენტი;
• (k) ხელმისაწვდომობა მოთხოვნისამებრ: რელიზები ჩამოსატვირთად ხელმისაწვდომია მოთხოვნისამებრ, დამკვეთის ადმინისტრატორის მიღების პირობით. მიმწოდებელი დამკვეთს აცნობს ახალი რელიზის ხელმისაწვდომობის შესახებ;
• (l) აუდიტის კვალი: პლატფორმა ინახავს სრულ ჩანაწერს იმის შესახებ, თუ რომელი რელიზები გახდა ხელმისაწვდომი, ჩამოტვირთული და განთავსებული დამკვეთის თითოეულ გარემოში. SaaS განთავსების მოდელი: SaaS მიწოდების მოდელში მიმწოდებელი მართავს ყველა განთავსებას დამკვეთის გამოყოფილ სუვერენულ გარემოში. დამკვეთი რელიზებს თავად არ აინსტალირებს. განთავსების პროცესი ასეთია:

4.7.4 მხარდაჭერის დასრულება და ვერსიაზე გადასვლა

მიმწოდებლის მხარდაჭერის დასრულების (EOL) პოლიტიკა, ვერსიაზე გადასვლის სასიცოცხლო ციკლი, მიგრაციის მომსახურებები, გადამზადების პროგრამა, მონაცემების დაბრუნების პროცედურები და გამოწერის შეწყვეტის პროცესები სრულად განსაზღვრულია მე-10 თავში — მხარდაჭერის დასრულება, ვერსიაზე გადასვლა და გამოწერის შეწყვეტა. მე-10 თავი არეგულირებს ვერსიის სასიცოცხლო ციკლის მართვის ყველა ასპექტს — საერთო ხელმისაწვდომობიდან (GA) EOL-ის გამოცხადების, საინჟინრო მხარდაჭერის დასრულების (EOE), მხარდაჭერის დასრულებისა და არჩევითი გაფართოებული მხარდაჭერის ჩათვლით.

წინამდებარე თავის მიზნებისთვის მოქმედებს შემდეგი შეჯამება: მიმწოდებელი დამკვეთს ძირითადი ვერსიის მხარდაჭერის დასრულებამდე უგზავნის მინიმუმ თორმეტი (12) თვით ადრე წერილობით შეტყობინებას. აპგრეიდის მხარდაჭერა, მათ შორის მიგრაციის დაგეგმვა, მონაცემების მიგრაცია, ინტეგრაციების ადაპტაცია, გადამზადება და UAT-ის მხარდაჭერა, გამოწერის ვადის ფარგლებში დამატებითი ღირებულების გარეშეა გათვალისწინებული. სრული პირობები, ვადები და პროცედურები ჩამოყალიბებულია ნაწილებში 10.1–10.14.

4.7.5 ვერსიების კონტროლი და წყარო კოდის ესქროუ

მიმწოდებელი ყველა წყარო კოდს ინახავს Git-ზე დაფუძნებულ ვერსიების კონტროლის სისტემაში, რომელიც მოიცავს:

• ძირითადი ტოტი (Master Branch): DANAOS-ის სტანდარტული აპლიკაცია ("Vanilla Version"), რომელიც მიმდინარე საერთო ხელმისაწვდომ რელიზს წარმოადგენს;
• კლიენტური ტოტები (Client Branches): დამკვეთისთვის სპეციფიკური კონფიგურაციები და მორგებები, რომლებიც ცალკე ტოტებად ინახება. სპრინტის რელიზები იქმნება კლიენტურ ტოტზე;
• სამუშაო კლონები (Working Clones): დეველოპერების სამუშაო ასლები, რომლებიც სტაბილურ პირობებში ერთიანდება (merge) ძირითად და კლიენტურ ტოტებში ახალი ფუნქციონალის დასამატებლად. კოდის ყველა ცვლილება გადის კოლეგიალურ განხილვას Pull Request-ების მეშვეობით, ავტომატურ ტესტირებას და უნდა შეესაბამებოდეს მიმწოდებლის პროგრამირების სახელმძღვანელო პრინციპებს, რომლებიც მოიცავს კოდის ხარისხს, ბიზნეს ლოგიკას და უსაფრთხოების საუკეთესო სტანდარტებს. Commit-ისა და Push-ის შესრულებისა და Pull Request-ის ნებისმიერი განხილვის შემდეგ აპლიკაციის ვერსიებს პასუხისმგებელი პროგრამისტი (ან Agile გუნდი) სრულად ასაბუთებს სემანტიკური და კონტექსტური კომენტარებით. რეცენზენტები ცვლილებებს იღებენ ან უარყოფენ მიმწოდებლის პროგრამირების სახელმძღვანელო პრინციპების საფუძველზე. ბიზნეს ლოგიკას დამატებით ამოწმებენ DANAOS-ის მხარდაჭერის ინჟინრები, რომლებიც თავიანთ სფეროში დარგობრივი ექსპერტები არიან.

მიმწოდებელი პროგრამული უზრუნველყოფის განთავსებისთვის, სადაც ეს მიზანშეუწოდებია, იყენებს უწყვეტ ინტეგრაციასა და უწყვეტ მიწოდებას (CI/CD). CI/CD მილსადენი ავტომატიზებს აწყობის, ტესტირებისა და განთავსების ეტაპებს Git რეპოზიტორიიდან Staging გარემომდე, რაც უზრუნველყოფს თანმიმდევრულობას და ამცირებს ხელით განთავსების შეცდომებს.

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

4.8 IMAC/RD მომსახურებები

მიმწოდებელი პლატფორმისთვის უზრუნველყოფს ინსტალაციის, გადატანის, დამატების, ცვლილების, მოხსნისა და უთარიგობის (IMAC/RD) მომსახურებებს მიმდინარე ოპერაციული მხარდაჭერის ფარგლებში. IMAC/RD საქმიანობა იმართება როგორც სტანდარტული ან ჩვეულებრივი ცვლილებები (იხ. ნაწილი 4.6.1) და მოიცავს შემდეგ ფარგლებს:

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

4.9 საწარმოს არქიტექტურული კონსულტაცია

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

• (a) ინტეგრაციის არქიტექტურა: კონსულტაცია ProjectVIEW ERP-ის დამკვეთის არსებულ საწარმო სისტემებთან (მაგ., SAP, Oracle, საბანკო პლატფორმები, HR სისტემები) დაკავშირების შესახებ პლატფორმის ჩაშენებული Web API-ს მეშვეობით (იხ. ნაწილი 2.5);
• (b) მონაცემთა არქიტექტურა: კონსულტაცია მონაცემთა ნაკადების, მონაცემთა მიგრაციის დაგეგმვის, ძირითადი მონაცემების მართვისა და ანგარიშგების არქიტექტურის შესახებ დამკვეთის გამოყოფილ სუვერენულ გარემოში;
• (c) უსაფრთხოების არქიტექტურა: კონსულტაცია ქსელის უსაფრთხოების, წვდომის კონტროლის პოლიტიკების, დაშიფვრის სტანდარტებისა და წინამდებარე ჩარჩოს B ნაწილში აღწერილ უსაფრთხოების ჩარჩოსთან შესაბამისობის შესახებ;
• (d) მასშტაბირების დაგეგმვა: გარემოს მასშტაბირების შესახებ პროაქტიული რეკომენდაციები მომხმარებლების რაოდენობის ზრდის პროგნოზების, მონაცემთა მოცულობის ტენდენციებისა და მოდულების აქტივაციის გეგმების საფუძველზე. საწარმოს არქიტექტურული კონსულტაცია წარმოადგენს საკონსულტაციო მომსახურებას და არ ვრცელდება მესამე მხარის სისტემების დაპროექტებაზე, შემუშავებაზე ან მხარდაჭერაზე. არქიტექტურული რეკომენდაციების დანერგვა ცალკე ფარგლების განსაზღვრასა და ღირებულების შეფასებას ექვემდებარება მხარეებს შორის შეთანხმების შესაბამისად.

4.10 მომსახურების უწყვეტი გაუმჯობესება (CSI)

მიმწოდებელი ახორციელებს მომსახურების უწყვეტი გაუმჯობესების (CSI) პროგრამას, რომელიც შესაბამისობაშია ITIL 4-ის პრაქტიკებთან და თანამედროვე AIOps მეთოდოლოგიებთან, მომსახურების ხარისხის, ოპერაციული ეფექტიანობისა და დამკვეთის კმაყოფილების უწყვეტი გაუმჯობესების მიზნით. CSI პროგრამა მოიცავს:

• AI-ის დახმარებით ტენდენციების ანალიზი: ინციდენტების მოცულობის, კატეგორიების, გამეორებადი საკითხებისა და გადაწყვეტის დროის ყოველთვიური ანალიზი შაბლონების ამოცნობისა და ანომალიების გამოვლენის მეშვეობით, სისტემური გაუმჯობესებების პროაქტიულად გამოსავლენად;
• ძირეული მიზეზების აღმოფხვრა: პრობლემების მართვის საქმიანობა, რომლის მიზანიც გამეორებადი ინციდენტების აღმოფხვრაა მუდმივი გადაწყვეტილებებით, თიქეთებს შორის კორელაციური ანალიზის საფუძველზე;
• პროცესების ოპტიმიზაცია: მხარდაჭერის პროცესების, თიქეთების სამუშაო პროცესების, ესკალაციის პროცედურებისა და ომნიარხიანი მხარდაჭერის ეფექტიანობის რეგულარული განხილვა გადაწყვეტის დროის შემცირებისა და დამკვეთის გამოცდილების გაუმჯობესების მიზნით;
• დამკვეთის უკუკავშირისა და გამოცდილების მართვა: დამკვეთის კმაყოფილების კვლევების შედეგების, მომსახურების კვარტალური განხილვის უკუკავშირისა და WhatsApp არხის ეფექტიანობის მაჩვენებლების ასახვა CSI რეესტრში;
• ტექნოლოგიური განახლება: COTS განახლებების, უსაფრთხოების გაუმჯობესებებისა და პლატფორმის ოპტიმიზაციების პროაქტიული გამოვლენა, რომლებიც დამკვეთს სარგებლობას მოუტანს;
• ცოდნის მართვა: ჩაშენებული ცოდნის ბაზის უწყვეტი გამდიდრება გადაწყვეტილი თიქეთების გადაწყვეტილებებით, რაც ზრდის თვითმომსახურებით გადაწყვეტის მაჩვენებლებს და ამცირებს გამეორებადი ინციდენტების მოცულობას. CSI რეესტრს აწარმოებს მომსახურების მიწოდების მენეჯერი და იგი განიხილება მომსახურების ყოველი კვარტალური განხილვისას (იხ. ნაწილი 3.10.2). CSI-ის ყველა ინიციატივას თვალყური ედება გამოვლენიდან დანერგვამდე გაზომვადი შედეგებით. თუ მიმწოდებელი მხარდაჭერის ოპერაციებში AI-ზე დაფუძნებულ ინსტრუმენტებს იყენებს, მათი გამოყენება უნდა შეესაბამებოდეს მართვის შესაბამის ჩარჩოებს, მათ შორის EU AI Act-სა და NIST AI Risk Management Framework (AI RMF 1.0)-ს.

წყაროების ბმულები:

ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission

4.11 პროცესების რეესტრი

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

როლების ლეგენდა: P = მიმწოდებელი | C = დამკვეთი | PSD = მიმწოდებლის მომსახურების ცენტრი | SDM = მომსახურების მიწოდების მენეჯერი | CAB = ცვლილებების

სასატერწხვო საბჭო | SC = სამეთვალყურეო კომიტეტი

4.11.1 პროცესების კატალოგი

4.11.2 RACI მატრიცა

R = შემსრულებელი | A = ანგარიშვალდებული (დამტკიცება) | C = კონსულტაცია | I = ინფორმირებული | — = ჩართული არ არის

4.11.3 პროცესის ნაკადი — მხარდაჭერისა და ოპერაციების სასიცოცხლო ციკლი