„თიბისი ბანკის მისია ისეთი ფინანსური მომსახურების მიწოდებაა, რომელიც ადამიანებს ცხოვრებას გაუმარტივებს. როგორც კავკასიის რეგიონში ერთ–ერთი უდიდესი ფინანსური ინსტიტუტი, თიბისი ბანკი საქართველოში ყოველთვიურად 1.3 მილიონ აქტიურ მომხმარებელს სთავაზობს საბანკო და ციფრულ მომსახურებას” – ვკითხულობთ Amazon-ის ვებგვერდზე განთავსებულ სტატიაში.
სტატია აღწერს, თუ როგორ დაიწყო საქართველოში ერთ–ერთმა ლიდერმა ფინანსურმა ინსტიტუტმა ამაზონის ღრუბლოვანი სერვისების (AWS Cloud) დანერგვა, რითაც კიდევ უფრო გააუმჯობესა ციფრული სერვისების სიჩქარე და უსაფრთხოება.
თიბისის მისია ყოველთვის იყო მომხმარებლის ცხოვრების გამარტივება და ეს მიდგომა კარგად ჩანს როგორც გარეთ, ისე ბრენდის შიგნიდან. დღესდღეობით კომპანიას 200-ამდე საჯარო ციფრული მომსახურება აქვს, რომლის სწორად სტრუქტურირება და დაცვაც სასიცოცხლოდ მნიშვნელოვანია.
გაუადვილო ცხოვრება შენს მომხმარებელს, საკმაოდ ამბიციურად ჟღერს, თუმცა ეს ყველაფერი თიბისის ტექნოლოგიური გუნდის დახმარებით ხდება შესაძლებელი, რომელმაც AWS სერვისთან ერთად შექმნა ტესტირების მოქნილი გარემო და მოახდინა პროგრამული უზრუნველყოფის განვითარების პროცესის მოდერნიზება, რაც მომხმარებლისთვის უფრო სწრაფ და დაცულ მომსახურებას უზრუნველყოფს.
ჩვენ ვესაუბრეთ თიბისის ტექგუნდის იმ ლიდერებს, რომლებმაც უშუალოდ იმუშავეს პროექტზე. მათ გვიამბეს, რა ეტაპები გაიარეს და როგორ იმუშავა მთელმა გუნდმა სისტემის გამართვაზე.
M: 1.3 მილიონი აქტიური მომხმარებელი და 200-ამდე ციფრული სერვისი – ეს თიბისის ტექმიმართულების ციფრებია. როგორ შეიცვალა თქვენი გუნდის ყოველდღიური მუშაობა მას შემდეგ, რაც ინფრასტრუქტურა on-premises მოდელიდან AWS Cloud-ზე გადავიდა? და რა სარგებელი მიიღო ამ ცვლილებით მომხმარებელმა?
ნიკა ქუტიძე, პლატფორმული სერვისების მართვის ლიდერი:
on-premises მოდელში გუნდის დიდი ნაწილი დაკავებული იყო ინფრასტრუქტურის „შენახვით“, რაც ნიშნავდა სიმძლავრეების წინასწარ დაგეგმვას, ამ სიმძლავრეების შეზღუდვების მართვას, დანერგვის შენელებულ პროცესს. AWS Cloud-ზე გადასვლის შემდეგ ფოკუსი გადავიტანეთ არა ინფრასტრუქტურის არსებობაზე, არამედ მის გამოყენებაზე.
დღეს გუნდები ბევრად უფრო დამოუკიდებლად მუშაობენ: შეუძლიათ სწრაფად გაუშვან ახალი სერვისი, გააფართოონ რესურსები პიკური დატვირთვის დროს და შეამცირონ შეცდომების რისკები. ეს განსაკუთრებით მნიშვნელოვანია, როცა ასობით ციფრულ სერვისზე ერთდროულად ვმუშაობთ.
მომხმარებლისთვის სარგებელი მარტივია: ნაკლები შეფერხება, უფრო სწრაფი რეაგირება, დრო და სტაბილური მუშაობა მაშინაც, როცა დატვირთვა მკვეთრად იზრდება; მაგალითად, ხელფასების დარიცხვის დღეებში ან მარკეტინგული კამპანიების დროს.
M: კიბერშეტევები, განსაკუთრებით DDoS ტიპის შეტევები, ბანკისთვის სერიოზული გამოწვევა იყო. მარტივად რომ ავხსნათ, რა პრობლემას ქმნიდა ეს ყოველდღიურ ოპერაციებში და როგორ „შეცვალა თამაშის წესები“ ამაზონის ახალმა სერვისებმა?
DDoS შეტევა რეალურად არ არის „ჰაკი“, ეს არის სისტემის გადატვირთვა ყალბი ტრაფიკით. on-premises გარემოში ეს ნიშნავდა, რომ ინფრასტრუქტურა უბრალოდ ვერ ასწრებდა რეაგირებას: სერვისები ნელდებოდა ან დროებით მიუწვდომელი ხდებოდა, რაც პირდაპირ აისახებოდა მომხმარებელზე.
AWS-ში ამ მიდგომამ შეცვალა ფილოსოფია: დაცვა რეაქციული კი არა, უკვე მუდმივად ჩართული პროცესია. ტრაფიკის ფილტრაცია, ავტომატური მასშტაბირება და გლობალური ქსელი ნიშნავს, რომ შეტევის დიდი ნაწილი საერთოდ ვერ აღწევს ბანკის შიდა სისტემებამდე.
„თამაშის წესების შეცვლაც“ სწორედ ესაა – პრობლემაზე რეაგირების ნაცვლად, სისტემა თავიდანვე ისეა აგებული, რომ მსგავსი შეტევები ყოველდღიურ ოპერაციებზე თითქმის არ აისახოს.
M: თიბისის კულტურაში გუნდურობა ერთ–ერთი მთავარი ღირებულებაა. როგორ იმუშავა სხვადასხვა ტექნოლოგიურმა გუნდმა ერთად ამ ტრანსფორმაციის პროცესში და რა როლი ითამაშა თანამშრომლობამ პროექტის წარმატებაში?
ინფრასტრუქტურის, უსაფრთხოების, დეველოპერული ოპერაციების, პლატფორმებისა და ქლაუდების მიმართულებები – ყველა ეს გუნდი ერთად მუშაობდა, ერთ არქიტექტურულ ხედვაზე შეთანხმებით.
მნიშვნელოვანი იყო არა ის, რომ „ჩვენი პასუხისმგებლობა აქ მთავრდება“, არამედ – „ეს საერთო სისტემაა“. არქიტექტურის დონეზე ეს ნიშნავს სტანდარტებს, ხოლო ყოველდღიურ მუშაობაში – მუდმივ კომუნიკაციასა და გადაწყვეტილებების გაზიარებას.
სწორედ ამ თანამშრომლობამ მოგვცა შედეგი: ტრანსფორმაცია არ აღმოჩნდა მომხმარებლისთვის მტკივნეული და ბანკმა შეძლო პარალელურად გაეგრძელებინა განვითარება, მასშტაბირება და უსაფრთხოების გაძლიერება.
M: ციფრული პროდუქტების ზრდასთან ერთად ინჟინრების დიდი ნაწილი სერვისების ხელმისაწვდომობის დაცვაზე მუშაობდა. როგორ დაგეხმარათ AWS ინფრასტრუქტურა იმაში, რომ მეტი რესურსი გადაგეტანათ ინოვაციებსა და ახალი ფუნქციონალის განვითარებაზე?
ალექსანდრე კვაიჭაძე, ინფრასტრუქტურული სერვისების მართვის ლიდერი:
მანამდე ინჟინრების დიდი ნაწილი დაკავებული იყო იმით, რომ სერვისები უბრალოდ „ცოცხალი“ ყოფილიყო: მონიტორინგი, ავარიებზე რეაგირება, რესურსების ხელით მართვა. AWS-ში ამ პროცესების დიდი ნაწილი ავტომატიზებულია ან პლატფორმის პასუხისმგებლობაა.
ამის შედეგად, გუნდებს გაუჩნდათ დრო და ენერგია, რომ რეალურ განვითარებაზე ემუშავათ: ახალი ფუნქციონალი, გაუმჯობესებული UX, ოპტიმიზაცია. პრაქტიკაში ეს ნიშნავს, რომ ინჟინერი ნაკლებ დროს ხარჯავს ინფრასტრუქტურულ პრობლემებზე და მეტს – მომხმარებლის საჭიროებებზე.
M: რას ნიშნავს პრაქტიკაში ისეთი ტექნოლოგიების გამოყენება, როგორებიცაა AWS Direct Connect და AWS PrivateLink? როგორ ავუხსნათ მომხმარებელს, რატომ არის მნიშვნელოვანი, რომ მონაცემები ღია ინტერნეტში არ გადის და დაცულ გარემოში რჩება?
პრაქტიკულად ეს ნიშნავს, რომ ბანკის კრიტიკული სისტემები AWS-ს უკავშირდება არა ჩვეულებრივი ინტერნეტით, არამედ გამოყოფილი, კონტროლირებადი არხებით. მონაცემები მოძრაობს დახურულ ქსელში, წინასწარ განსაზღვრული წესებით.
მომხმარებლისთვის ეს მარტივად შეიძლება აიხსნას: მათი მონაცემები არ „დადის ინტერნეტში“, სადაც ბევრი გაურკვეველი რისკია. ისინი გადადის დაცულ გარემოში, სადაც კონტროლი გვაქვს როგორც ტრაფიკზე, ისე – წვდომაზე. ეს ზრდის არა მხოლოდ უსაფრთხოებას, არამედ სტაბილურობასაც; კავშირი უფრო პროგნოზირებადია და ნაკლებად დამოკიდებული გარე ფაქტორებზე.
M: როგორ შეიცვალა ტესტირებისა და პროგრამული უზრუნველყოფის განვითარების პროცესი მას შემდეგ, რაც შექმენით მოქნილი, ქლაუდზე დაფუძნებული გარემო?
ქლაუდმა მოგვცა მოქნილობა. ახლა გუნდს შეუძლია სწრაფად შექმნას ტესტირების გარემო, სცადოს ცვლილება და იგივე სისწრაფით გამორთოს ის.
განვითარების პროცესიც გახდა უფრო მოკლე ციკლებისგან შემდგარი: მცირე ცვლილებები, ხშირი ტესტირება, სწრაფი უკუკავშირი. ეს ამცირებს შეცდომების რისკს და გვაძლევს საშუალებას ახალი ფუნქციები მომხმარებლამდე მივიტანოთ უფრო სწრაფად, ხარისხის დაკარგვის გარეშე.
საბოლოოდ, ეს ისევ მომხმარებელზე აისახება – ნაკლები ხარვეზი, უფრო სტაბილური განახლებები და მუდმივად გაუმჯობესებული ციფრული გამოცდილება.
M: რა იყო ყველაზე დიდი ტექნოლოგიური გამოწვევა თიბისის ციფრული სერვისების გლობალურად მასშტაბირებაში და როგორ დაგეხმარათ Amazon CloudFront ამ მიზნის მიღწევაში?
ზურა ტალიკაძე, ტექნოლოგიური ინფრასტრუქტურის არქიტექტორი:
ყველაზე დიდი გამოწვევა იყო ლატენტობა და პროგნოზირებადობა. როცა სერვისი მხოლოდ ერთ რეგიონზეა მორგებული, ყველაფერი მუშაობს მანამ, სანამ მომხმარებელიც იმავე გეოგრაფიულ არეალშია. როგორც კი იწყება გლობალური გამოყენება, ჩნდება დაგვიანებები, არათანაბარი შესრულება და განსხვავებული გამოცდილება სხვადასხვა ქვეყნიდან. ამ მხრივ ძალიან მნიშვნელოვანი გამოცდილება მივიღეთ TBC Uzbekistan-ში მუშაობისასაც. უზბეკეთი ბევრად დიდი ქვეყანაა, განსხვავებული ქსელური რეალობითა და მომხმარებელთა მასშტაბით და ეს გვაიძულებს არქიტექტურას უფრო მკაცრად შევხედოთ – არა „იდეალურ“, არამედ რეალურ პირობებში.
CloudFront-მა აქ პრაქტიკული როლი ითამაშა – კონტენტი და API-ებზე წვდომა მომხმარებელთან მაქსიმალურად ახლოს მივიტანეთ. ეს ნიშნავს ნაკლებ ქსელურ ჰოპებს, ნაკლებ ლოდინს და უფრო სტაბილურ ქცევას პიკური დატვირთვის დროს, როგორც საქართველოში, ისე უზბეკეთში.
რეგიონულად ოპტიმიზებული ბანკი რეაგირებს „საშუალო სცენარზე“. გლობალურად მაღალმწარმოებლური სერვისი კი გათვლილია უარეს სცენარზეც – სხვადასხვა გეოგრაფია, სხვადასხვა ქსელი, სხვადასხვა დატვირთვა. მომხმარებლისთვის ეს გამოიხატა ძალიან მარტივად: აპლიკაცია იხსნება სწრაფად, ოპერაციები არ „იყინება“ და გამოცდილება ერთნაირია, მნიშვნელობა არ აქვს სად იმყოფება მომხმარებელი.
M: თიბისის მისია მომხმარებლისთვის ცხოვრების გამარტივებაა. ტექნოლოგიური არქიტექტურის შექმნისას როგორ პოულობთ ბალანსს ინოვაციას, სიჩქარესა და უსაფრთხოებას შორის, რათა საბოლოოდ მომხმარებელმა მიიღოს სწრაფი და დაცული სერვისი?
ბალანსი არ მიიღწევა ერთ გადაწყვეტილებაში – ეს პროცესია. ჩემი, როგორც არქიტექტორის როლი, არის ეს ბალანსი ყოველდღიურ გადაწყვეტილებებში შევინარჩუნო როგორც საქართველოში, ისე TBC Uzbekistan-ში, სადაც მასშტაბი და მოთხოვნები კიდევ უფრო მკაცრია.
უსაფრთხოება ჩვენთვის არ არის დამატებითი ფენა. ის თავიდანვე არქიტექტურის ნაწილია. თუ სისტემა უსაფრთხო არ არის, ესე იგი, ის უბრალოდ არ არის დასრულებული.
ინოვაცია და სიჩქარე მოდის მოდულურობითა და ავტომატიზაციით, როცა ცვლილებების შეტანა შეიძლება მცირე ნაწილებად, რისკის ლოკალიზებით. უზბეკეთის გამოცდილება გვასწავლის, რომ სწრაფი განვითარება მხოლოდ მაშინ მუშაობს, როცა არქიტექტურა წინასწარ არის მზად მასშტაბისთვის.
საბოლოოდ, მომხმარებელი ამას ვერ ხედავს ტექნიკურ დონეზე, მაგრამ გრძნობს შედეგს: სერვისი სწრაფია, სტაბილურია და არ უჩნდება ეჭვი უსაფრთხოებაზე. ჩვენი მიზანიც სწორედ ესაა – ტექნოლოგია მუშაობდეს ჩუმად, მაგრამ საიმედოდ.
[R]
