ძველი სერვისები თქვენს ინფრასტრუქტურაში

გამარჯობა! მე მქვია პაშა ჩერნიაკი, მე ვარ QIWI-ს წამყვანი დეველოპერი და დღეს მინდა ვისაუბრო გარდაუვალზე. Legacy-ის შესახებ.

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

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

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

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

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

დროთა განმავლობაში დაიწყო ახალი პრაქტიკის გამოყენება, მაგალითად, მიგრაცია Kubernetes-ში, ყველა სახის შემოწმების სტილი, spotbugs, ktlint, ჟურნალების არსებობა Kibana-ში, ავტო აღმოჩენის სერვისები, მისამართების პირდაპირ მითითების ნაცვლად და სხვა სასარგებლო ნივთები. და ყველგან ჩვენი მაგიდა გვაძლევდა საშუალებას შეგვენარჩუნებინა ჩვენი სერვისების აქტუალობა. ჩვენთვის ეს არის ერთგვარი საკონტროლო სია, რომელიც ამბობს, რომ ამ სერვისს შეუძლია ამის გაკეთება, მაგრამ ეს ჯერ არ არის. მაგრამ ჩვენ გადავედით, რადგან მივხვდით, რომ გვაკლია ინფორმაცია ჩვენი სერვისების შესახებ, რომლებსაც ვაკვირდებით, სად მდებარეობს სერვისის წყაროები. სად იწყება ასამბლეის ამოცანები TeamCity-ში, როგორ ხდება მათი განლაგება, სად ინახება end2end ტესტების წყაროები, ფოტოები არქიტექტურის სესიებიდან, მიღებული გადაწყვეტილებების შესახებ. იდეალურ შემთხვევაში, ვისურვებდი, რომ ეს ინფორმაცია სადმე იყოს და საჭიროების შემთხვევაში ხელთ იყოს. ამიტომ, ჩვენი ნიშანი გახდა ინფორმაციის ძიების ამოსავალი წერტილი.

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

როგორ ხდება

მაგრამ დროის გარკვეულ მომენტში აღმოვაჩენთ, რომ სერვისი წყვეტს თავისი ფუნქციის შესრულებას, რაღაც ირღვევა - რა უნდა გავაკეთოთ ასეთ სიტუაციაში? სერვისმა უბრალოდ შეწყვიტა მუშაობა. Საერთოდ. ჩვენ ამის შესახებ შევიტყვეთ, ჯერ ერთი, შემთხვევით და მეორეც, ექვსი თვის შემდეგ. Ხდება ხოლმე. ერთადერთი, რაც ვიცოდით, ის იყო, რომელ ვირტუალურ მანქანებზე განთავსდებოდა სერვისი, სად იყო მისი წყაროები და სულ ეს არის. ჩვენ ვაკეთებთ git კლონს და ჩავიძირებით იმ ადამიანის გონებაში, ვინც ეს დაწერა რამდენიმე წლის წინ, მაგრამ რას ვხედავთ? ჩვენთვის ნაცნობი არცერთი საგაზაფხულო ჩექმა, თუმცა ყველაფერს მიჩვეული ვართ, სრული სტეკი გვაქვს და ეს ყველაფერი. იქნებ არსებობს Spring Framework? Მაგრამ არა.

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

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

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

სად უნდა დაიწყოს?

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

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

რა უნდა გავაკეთოთ

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

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

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

შედეგად, მსურს შევიმუშავო გეგმა, თუ რა უნდა გავაკეთო Legacy სერვისებთან.

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

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

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

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

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

• 31.5%თავიდან ვწერ, უფრო სწორია 12

• 52.6%თითქმის იგივეა რაც შენ20

• 10.5%ჩვენ არ გვაქვს მემკვიდრეობა, ჩვენ დიდებულები ვართ4

• 5.2%დავწერ კომენტარებში 2

მისცა ხმა 38 მომხმარებელმა. 20-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com