მონოლითებიდან მიკროსერვისებამდე: M.Video-Eldorado და MegaFon-ის გამოცდილება

25 აპრილს, Mail.ru Group-ში ჩავატარეთ კონფერენცია ღრუბლებისა და გარშემო - ფოსტა: ღრუბელი. რამდენიმე ხაზგასმა:

• Მთავარი რუსი პროვაიდერები — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center და Yandex.Cloud ისაუბრეს ჩვენი ღრუბლოვანი ბაზრის სპეციფიკასა და მათ სერვისებზე;
• Bitrix24-ის კოლეგებმა უთხრეს როგორ მოვიდა multicloud;
• საინტერესო იყო Leroy Merlin, Otkritie, Burger King და Schneider Electric ხედი ღრუბლის მომხმარებლებისგან — რა ამოცანებს უყენებს მათი ბიზნესი IT-ს და რომელ ტექნოლოგიებს, მათ შორის ღრუბლოვანს, ყველაზე პერსპექტიულად თვლიან.

თქვენ შეგიძლიათ უყუროთ ყველა ვიდეოს mailto:CLOUD კონფერენციიდან по ссылкеდა აქ შეგიძლიათ წაიკითხოთ, თუ როგორ წარიმართა დისკუსია მიკროსერვისების შესახებ. ალექსანდრე დეულინი, MegaFon ბიზნეს სისტემების კვლევისა და განვითარების ცენტრის ხელმძღვანელმა და სერგეი სერგეევმა, M.Video-Eldorado ჯგუფის საინფორმაციო ტექნოლოგიების დირექტორმა, გააზიარეს მონოლითებისგან თავის დაღწევის წარმატებული შემთხვევები. ჩვენ ასევე განვიხილეთ IT სტრატეგიის, პროცესებისა და თუნდაც HR-თან დაკავშირებული საკითხები.

პანელისტები

• სერგეი სერგეევი, ჯგუფი CIO "M.Video-Eldorado";
• ალექსანდრე დეულინი, ბიზნეს სისტემების კვლევისა და განვითარების ცენტრის ხელმძღვანელი მეგაფონი;
• მოდერატორი - დიმიტრი ლაზარენკო, PaaS მიმართულების ხელმძღვანელი Mail.ru Cloud Solutions.

ალექსანდრე დეულინის გამოსვლის შემდეგ „როგორ აფართოებს მეგაფონი თავის ბიზნესს მიკროსერვისის პლატფორმის საშუალებით“ მას უერთდება დისკუსიისთვის სერგეი სერგეევი M.Video-Eldorado-დან და დისკუსიის მოდერატორი დიმიტრი ლაზარენკო, Mail.ru Cloud Solutions.

ქვემოთ ჩვენ მოვამზადეთ თქვენთვის დისკუსიის ჩანაწერი, მაგრამ ასევე შეგიძლიათ ნახოთ ვიდეო:

მიკროსერვისებზე გადასვლა არის პასუხი ბაზრის საჭიროებებზე

დიმიტრი:

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

სერგეი:

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

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

ერთ-ერთი პირველი სერვისი, ყველაზე მძიმედ დატვირთული, იყო ფასის გაანგარიშების სერვისი. ყოველ ჯერზე, როდესაც მიდიხართ ნებისმიერ არხზე, M.Video-Eldorado-ს კომპანიების ჯგუფში, იქნება ეს ვებსაიტი თუ საცალო მაღაზია, ირჩევთ იქ პროდუქტს, ხედავთ ფასს ვებსაიტზე ან „კალათაში“, ღირებულება ავტომატურად ხდება. გამოითვლება ერთი სერვისით. რატომ არის ეს აუცილებელი: მანამდე თითოეულ სისტემას ჰქონდა საკუთარი პრინციპები აქციებთან მუშაობისთვის - ფასდაკლებით და ა.შ. ჩვენი ბექ ოფისი ამუშავებს ფასებს, ფასდაკლების ფუნქცია დანერგილია სხვა სისტემაში. ეს უნდა ყოფილიყო ცენტრალიზებული და შექმნილიყო უნიკალური, განცალკევებული სერვისი ბიზნეს პროცესის სახით, რომელიც მოგვცემდა ამის განხორციელების საშუალებას. თითქმის ასე დავიწყეთ.

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

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

როგორ გავზომოთ მიკროსერვისებში მიგრაციის წარმატება

დიმიტრი:

როგორ განისაზღვრება მიკროსერვისებში მიგრაციის წარმატება? რა იყო "ადრე" თითოეულ კომპანიაში? რა მეტრიკა გამოიყენე გადასვლის წარმატების დასადგენად და ვინ განსაზღვრა ის რეალურად?

სერგეი:

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

ალექსანდრე:

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

სერგეი:

Დიახ, ვეთანხმები. სამი წლის განმავლობაში ჩვენ უკვე გვაქვს ორასზე მეტი სერვისი და ჩამორჩენილი სამუშაო. გუნდში რესურსების საჭიროება მხოლოდ იზრდება - ყოველწლიურად 30%-ით. ეს იმიტომ ხდება, რომ ხალხი გრძნობდა: უფრო სწრაფია, განსხვავებულია, არსებობს სხვადასხვა ტექნოლოგიები, ეს ყველაფერი ვითარდება.

მოვა მიკროსერვისები, მაგრამ ბირთვი დარჩება

დიმიტრი:

ეს ჰგავს დაუსრულებელ პროცესს, სადაც ინვესტიციას აკეთებთ განვითარებაში. უკვე დასრულებულია თუ არა ბიზნესისთვის მიკროსერვისებზე გადასვლა?

სერგეი:

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

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

დიმიტრი:

ცხოვრება კარგ ფორმაშია. (იცინის)

ალექსანდრე:

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

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

როგორ გავყიდოთ მიკროსერვისები ბიზნესს

დიმიტრი:

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

სერგეი:

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

დიმიტრი:

როგორმე ჩაწერეთ პირველი ეტაპის დრო?

სერგეი:

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

შემდეგი მოდის სისტემატური მუშაობა ბიზნესის საჭიროებებზე, შესაძლებლობებზე, რესურსების ხელმისაწვდომობაზე და ყველაფერს, რაც ამჟამად მუშაობს.

დიმიტრი:

ᲙᲐᲠᲒᲘ. ალექსანდრე, რას იტყვი?

ალექსანდრე:

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

დიმიტრი:

ხდება თუ არა, რომ ბიზნესი გაძლევს გუგლის მსგავსი საქმის კეთების საშუალებას - კვირაში ერთ უფასო დღეს? გაქვთ ასეთი მიმართულება?

ალექსანდრე:

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

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

მიკროსერვისები: აჟიოტაჟი თუ აუცილებლობა?

დიმიტრი:

რიცხვები რიცხვებია. და შემოსავალი ან დაზოგილი ფული ძალიან მნიშვნელოვანია. რა მოხდება, თუ მეორე მხარეს შეხედავ? როგორც ჩანს, მიკროსერვისები არის ტენდენცია, აჟიოტაჟი და ბევრი კომპანია ბოროტად იყენებს მას? რამდენად მკაფიოდ განასხვავებთ იმას, რასაც აკეთებთ და არ თარგმნით მიკროსერვისებს? თუ მემკვიდრეობა ახლა, გექნებათ თუ არა მემკვიდრეობა 5 წელიწადში? რამდენი იქნება ინფორმაციული სისტემების ასაკი, რომლებიც მუშაობენ M.Video-Eldorado-სა და MegaFon-ში 5 წელიწადში? იქნება ათი წლის, თხუთმეტი წლის საინფორმაციო სისტემები თუ იქნება ახალი თაობა? როგორ ხედავ ამას?

სერგეი:

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

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

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

ჩვენ ვხედავთ ამ განვითარებას:

• ძირითადი საინფორმაციო სისტემები (ძირითადად back office);
• შუა ფენები მიკროსერვისების სახით აკავშირებს ბირთვს, აგროვებს, ქმნის ქეშს და ა.შ.
• წინა ხაზის სისტემები მიმართულია მომხმარებლისთვის;
• ინტეგრაციის ფენა, რომელიც ზოგადად ინტეგრირებულია ბაზრებში, სხვა სისტემებსა და ეკოსისტემებში. ეს ფენა არის რაც შეიძლება მსუბუქი, მარტივი და შეიცავს მინიმუმ ბიზნეს ლოგიკას.

მაგრამ ამავე დროს, მე ვარ მომხრე იმისა, რომ გავაგრძელოთ ძველი პრინციპების გამოყენება, თუ ისინი სათანადოდ იქნა გამოყენებული.

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

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

ალექსანდრე:

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

დიმიტრი:

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

როგორ განვავითაროთ საიმედო მიკროსერვისები

დიმიტრი:

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

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

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

ალექსანდრე:

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

ჩვენ არ გვქონია გლობალური წარუმატებლობა მიკროსერვისებთან დაკავშირებით. ჩვენ მშვიდად გვძინავს, გვაქვს 24/7 მორიგეობა, რომელიც ემსახურება მთელ BSS-ს [ბიზნესის მხარდაჭერის სისტემას].

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

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

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

მიკროსერვისები და HR

სერგეი:

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

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

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

კიდევ ერთი პრობლემა - თუმცა ეს თავისებურად კარგია - შიდა კონკურენციაა. ”ოჰ, აქ გამოჩნდნენ ახალი მოდური ბიჭები, ისინი საუბრობენ ახალ ენაზე.” ხალხი, რა თქმა უნდა, განსხვავებულია. არიან ისეთებიც, ვინც მიჩვეულია ჯავაში წერას და ისინიც, ვინც წერენ და იყენებენ Docker-სა და Kubernetes-ს. ეს სრულიად განსხვავებული ხალხია, ისინი სხვანაირად საუბრობენ, სხვადასხვა ტერმინებს იყენებენ და ზოგჯერ არ ესმით ერთმანეთის. პრაქტიკის გაზიარების უნარი ან უუნარობა, ცოდნის გაზიარება, ამ თვალსაზრისით ასევე პრობლემაა.

ისე, რესურსების მასშტაბირება. ”მშვენიერია, წავიდეთ! და ახლა ჩვენ გვინდა უფრო სწრაფად, მეტი. რა, არ შეგიძლია? წელიწადში ორჯერ მეტის მიწოდება არ შეიძლება? Და რატომ?" ასეთი მზარდი ტკივილები, ალბათ, ბევრი რამის, მრავალი მიდგომის სტანდარტია და თქვენ შეგიძლიათ იგრძნოთ ისინი.

რაც შეეხება მონიტორინგს. მეჩვენება, რომ სერვისები ან სამრეწველო მონიტორინგის ხელსაწყოები უკვე სწავლობენ ან შეუძლიათ მუშაობა Docker-თან და Kubernetes-თან განსხვავებულ, არასტანდარტულ რეჟიმში. ისე, რომ, მაგალითად, არ დასრულდეს 500 ჯავის აპარატი, რომლებშიც ეს ყველაფერი მუშაობს, კერძოდ, ის გროვდება. მაგრამ ამ პროდუქტებს ჯერ კიდევ აკლია სიმწიფე, მათ ეს უნდა გაიარონ. თემა მართლაც ახალია, განაგრძობს განვითარებას.

დიმიტრი:

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

სერგეი:

Დიახ, რა თქმა უნდა.

ალექსანდრე:

HR სვამს კითხვას: "სად არის თქვენი ვარდისფერი unicorn backend-სა და frontend-ს შორის?" HR არ ესმის რა არის მიკროსერვისი. ჩვენ ვუთხარით მათ საიდუმლო და ვუთხარით, რომ ბექენდმა ყველაფერი გააკეთა და არ არსებობს unicorn. მაგრამ HR იცვლება, სწრაფად სწავლობს და იღებს ადამიანებს, რომლებსაც აქვთ საბაზისო IT ცოდნა.

მიკროსერვისების ევოლუცია

დიმიტრი:

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

სერგეი:

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

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

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

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

განმეორებით, წელიწადში რაღაც არის ასახული ტექნოლოგიის თვალსაზრისით, რაღაც სხვა ჩამორჩენისა და საჭიროებების თვალსაზრისით. ჩვენ ერთ ნივთს ვუკავშირდებით მეორეს. გუნდი 20%-ს ხარჯავს გუნდის ტექნიკურ დავალიანებაზე და ტექნიკურ მხარდაჭერაზე, 80%-ს ბიზნეს სუბიექტზე. ჩვენ ვმოძრაობთ იმის გაგებით, თუ რატომ ვაკეთებთ ამას, რატომ ვაკეთებთ ამ ტექნოლოგიურ გაუმჯობესებას, რას გამოიწვევს ისინი. Ეგრე.

დიმიტრი:

მაგარია. რა არის მეგაფონში?

ალექსანდრე:

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

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

დიმიტრი:

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

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

მადლობა ყველა მონაწილეს, მადლობა სერგეის და ალექსანდრეს!

კითხვები აუდიტორიისგან

კითხვა აუდიტორიისგან (1):

სერგეი, როგორ შეიცვალა IT მენეჯმენტი თქვენს კომპანიაში? მე მესმის, რომ როდესაც არსებობს რამდენიმე სისტემის დიდი დასტა, მისი მართვა საკმაოდ ნათელი და ლოგიკური პროცესია. როგორ აღადგინეთ IT კომპონენტის მენეჯმენტი მას შემდეგ, რაც ძალიან დიდი რაოდენობით მიკროსერვისები იქნა ინტეგრირებული ასეთ მოკლე დროში?

სერგეი:

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

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

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

კითხვა აუდიტორიისგან (2):

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

ალექსანდრე:

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

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

და ჩვენი პრობლემა მხოლოდ მცირე გუნდშია. ერთი პირობითი პროდუქტისთვის საჭიროა ერთი ხარისხის ინჟინერი. ასე რომ, ჩვენ ვაგზავნით 5-7 მიკროსერვისის პროდუქტს, რომელთაგან 2-3 შეიძლება შემუშავდეს მესამე მხარის მიერ. მაგალითად, ჩვენ გვაქვს პროდუქტი, რომლის შემუშავებაში მონაწილეობს ჩვენი ბილინგის სისტემის გამყიდველი, Mail.ru Group და MegaFon R&D. ჩვენ უნდა დავფაროთ ეს ტესტებით წარმოებაში გაგზავნამდე. QA ინჟინერი ამ პროდუქტზე თვენახევარია მუშაობს, გუნდის დანარჩენი წევრები კი მისი მხარდაჭერის გარეშეა დარჩენილი.

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

სერგეი:

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

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

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

ალექსანდრე:

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

კითხვა აუდიტორიისგან (3):

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

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

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

ალექსანდრე:

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

სერგეი:

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

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

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

ალექსანდრე:

სერგეი, შენ ხარ პროცესის მფლობელი, არა? არის თუ არა დავალებების ჩანაწერი გაზიარებული? ვინ არის პასუხისმგებელი მის გავრცელებაზე?

სერგეი:

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

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

ვთქვათ, ბიზნესი ამბობს: „ჩვენ გვინდა ეს ფუნქცია, გვინდა შევქმნათ ახალი პროდუქტი - სესხის გადაკეთება“. ჩვენ ვპასუხობთ: "დიახ, ჩვენ ამას ხელახლა გავაკეთებთ." არქიტექტორები ამბობენ: "მოდით, დავფიქრდეთ: სად დავწერთ სესხში მიკროსერვისებს და როგორ გავაკეთებთ ამას?" შემდეგ მას ვყოფთ პროექტებად, პროდუქტებად ან ტექნოლოგიურ დასტად, ვაყენებთ გუნდებად და ვახორციელებთ. შექმენით პროდუქტი შიდა და გადაწყვიტეთ გამოიყენოთ მიკროსერვისები ამ პროდუქტში? ჩვენ ვამბობთ: „ახლა მემკვიდრეობითი სისტემები, რომლებიც გვქონდა, ან წინა ხაზის სისტემები, უნდა გადავიდნენ ამ მიკროსერვისებზე“. არქიტექტორები ამბობენ: ”ასე რომ: წინა ხაზის პროდუქტებში ტექნოლოგიურ ნარჩენებში - მიკროსერვისებზე გადასვლა. წადი". და პროდუქტის სპეციალისტებს ან ბიზნესის მფლობელებს ესმით, რამდენი სიმძლავრეა გამოყოფილი, როდის გაკეთდება და რატომ.

დისკუსიის დასასრული, მაგრამ არა ყველა

მოეწყო კონფერენცია mailto:CLOUD Mail.ru Cloud Solutions.

სხვა ღონისძიებებსაც ვაკეთებთ - მაგ. @Kubernetes Meetup, სადაც ჩვენ ყოველთვის ვეძებთ შესანიშნავ დინამიკებს:

• მიჰყევით @Kubernetes და სხვა @Meetup სიახლეებს ჩვენს Telegram არხზე t.me/k8s_mail
• გაინტერესებთ ერთ-ერთ @Meetups-ზე საუბარი? დატოვეთ მოთხოვნა mcs.mail.ru/speak

წყარო: www.habr.com