ჩვენ ვაკვირდებით Sportmaster-ს - როგორ და რით

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

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

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

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

პლატფორმა, რომელზეც ჩვენი ონლაინ მაღაზიები ფუნქციონირებს, ასე გამოიყურება:

• წინა
• შუა ოფისი
• უკან ოფისში

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

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

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

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

სისტემის სტრუქტურა და დასტა

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

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

ამიტომ გადაწყვიტეს სპილო ნაწილ-ნაწილ ეჭამათ.

ჩვენი სისტემა შედგება:

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

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

ასე რომ, სტეკის შესახებ.

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

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

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

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

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

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

გუნდის ახალი სტრუქტურა ნიშნავს, რომ განაცხადის ყველა აქტივობა შემოიფარგლება პროდუქტის გუნდებით, ამიტომ ჩვენ შევწყვიტეთ სუფთა ტესტირების გაკეთება. ამის ნაცვლად, ჩვენ გავაკეთეთ UI მონიტორინგი ტესტებიდან, რომლებიც დაწერილი იყო Java, Selenium და Jenkins-ში (გამოიყენებოდა როგორც სისტემა ანგარიშების გაშვებისა და გენერირებისთვის).

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

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

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

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

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

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

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

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

პერსპექტივები

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

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

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

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

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

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

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

ჩვენი კოლეგა შეიძლება მოვიდეს და მოითხოვოს რაიმე მეტრიკის დამატება, რომელიც სასარგებლო იქნება როგორც ჩვენთვის, ასევე გუნდისთვის. ან, მაგალითად, გუნდს შეიძლება არ ჰქონდეს საკმარისი ძირითადი მეტრიკა, რაც ჩვენ გვაქვს; მათ უნდა აკონტროლონ რამდენიმე კონკრეტული. Grafana-ში ჩვენ ვქმნით სივრცეს თითოეული გუნდისთვის და ვაძლევთ ადმინისტრაციის უფლებებს. ასევე, თუ გუნდს სჭირდება დაფები, მაგრამ მათ თავად არ შეუძლიათ/არ იციან ამის გაკეთება, ჩვენ ვეხმარებით.

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

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

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

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

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

წყარო: www.habr.com