მართვადი სერვისები
ნახეთ ყველაფერი, მიიღეთ შეტყობინება მხოლოდ მნიშვნელოვანზე
სრული მონიტორინგი და დაკვირვებადობა მეტრიკის, ლოგებისა და ტრეისების გასწვრივ — რომ პრობლემები გამოვავლინოთ და გავასწოროთ, სანამ ისინი თქვენს მომხმარებლებამდე მიაღწევენ.
დაგვიკავშირდითვერ გაასწორებთ იმას, რასაც ვერ ხედავთ
როდესაც სისტემები ნელდება ან ჯდება, პირველი კითხვა ყოველთვის ერთი და იგივეა: რა შეიცვალა და სად? სათანადო მონიტორინგის გარეშე გუნდები იძულებულნი არიან გამოიცნონ — გადატვირთონ სერვერები, ხელით დაათვალიერონ ლოგები და ავარიები მხოლოდ მაშინ აღმოაჩინონ, როდესაც გაღიზიანებული მომხმარებელი იტყობინება. ამ დროისთვის ნდობასა და შემოსავალზე მიყენებული ზიანი უკვე ფაქტია, ხოლო ძირეული მიზეზი ხშირად უკვე გამქრალია მტკიცებულებებიდან. ფარული ფასი არ არის მხოლოდ თვით გათიშვა, არამედ ის საათები, რომელთაც ძვირადღირებული საინჟინრო გუნდი წვავს სიმპტომებზე ბრმად რეაგირებაში ფაქტებზე მოქმედების ნაცვლად.
Techies ქმნის დაკვირვებადობას თქვენს გარემოში ისე, რომ პასუხები უკვე გელოდებათ მაშინ, როცა გჭირდებათ. ჩვენ ვაღჭურვავთ თქვენს ინფრასტრუქტურასა და აპლიკაციებს სამი საყრდენის გასწვრივ — მეტრიკა, ლოგები და ტრეისები — გამოგვაქვს ისინი მკაფიო დაფებზე და ვაწყობთ შეტყობინებებს ისე, რომ სწორმა ადამიანებმა სწორ პრობლემებზე ადრე გაიგონ. მიზანი მარტივია: პრობლემების პროაქტიული გამოვლენა, გადაჭრის დროის შემცირება და SLA-ების დადასტურება რეალური მონაცემებით და არა ანეგდოტითა და იმედით.
მონიტორინგსა და დაკვირვებადობას შორის არსებითი განსხვავებაა და მას მნიშვნელობა აქვს. მონიტორინგი გეუბნებათ, ჯანმრთელია თუ არა ის, რასაც უკვე გადაწყვიტეთ, რომ დააკვირდით. დაკვირვებადობა საშუალებას გაძლევთ ახალი კითხვები დაუსვათ სისტემას, რომელიც აქამდე ასე ქცეული არ გინახავთ — გამოიძიოთ ახალი პრობლემა ახალი კოდის გაშვების გარეშე, რომ გაიგოთ, რა ხდება. ჩვენ მეორესთვის ვაშენებთ, რადგან ყველაზე მტკივნეული ინციდენტები თითქმის ყოველთვის ისეთებია, რომელთაც ვერავინ იწინასწარმეტყველა და რომელთათვისაც ვერავის ჰქონდა დაფა.
სამი საყრდენი, ერთად მომუშავე
მეტრიკა თქვენი სისტემების რიცხვითი გულისცემაა — CPU, მეხსიერება, მოთხოვნების სიხშირე, შეცდომების სიხშირე, დაყოვნების პროცენტილები, რიგების სიღრმე — უწყვეტად შერჩეული და მასშტაბურად იაფი შესანახად. ისინი შესანიშნავად გეუბნებიან, რომ რაღაც არასწორადაა და ამჩნევენ ტენდენციებს, სანამ ისინი ინციდენტებად იქცევა, რის გამოც მეტრიკა მართავს უმეტეს შეტყობინებას. მაგრამ მეტრიკა იშვიათად გეუბნებათ, რატომ; შეცდომების სიხშირის ნახტომი არის გამოსაძიებელი სიგნალი და არა ახსნა. ჩვენ ვაღჭურვავთ მეტრიკას, რომელიც თქვენს რეალურ მომხმარებლის გამოცდილებასა და ბიზნეს შედეგებს ასახავს და არა მხოლოდ უმი მანქანის სტატისტიკას, რომელზეც ვერავინ მოქმედებს.
ლოგები არის დეტალური, დროით აღნიშნული ჩანაწერი იმისა, რაც ნამდვილად მოხდა — კონკრეტული შეცდომა, ჩავარდნილი მოთხოვნა, ხარვეზამდე მიმავალი მოვლენების ზუსტი თანმიმდევრობა. სადაც მეტრიკა ამბობს, რომ შეცდომების სიხშირე 14:05-ზე გაიზარდა, ლოგები გეუბნებათ ზუსტად, რომელი ოპერაცია ჩავარდა და რატომ. ჩვენ ვაცენტრალებთ ლოგებს, რომ ისინი ერთ ადგილას მოსაძებნი იყოს და არა სერვერებზე გაფანტული, ვასტრუქტურებთ მათ, რომ მათი მოთხოვნა იყოს შესაძლებელი ხელით grep-ის ნაცვლად, და ვინახავთ საკმარისად ხანგრძლივად, რომ გამოვიძიოთ საკითხები, რომლებიც მხოლოდ დროთა განმავლობაში ვლინდება.
ტრეისები მიჰყვებიან ერთ მოთხოვნას, როცა ის გადის განაწილებულ სისტემაზე — ჭიშკარზე, რამდენიმე სერვისზე, რიგსა და მონაცემთა ბაზაზე — და აჩვენებენ ზუსტად, სად დაიხარჯა დრო და სად ჩავარდა. თანამედროვე არქიტექტურებში, სადაც მომხმარებლის ერთი ქმედება მრავალ სერვისს ეხება, ტრეისები ის არის, რაც შეუძლებელ „სადღაც ნელია“-ს ზუსტ „ამ დამოკიდებულებაზე ეს გამოძახება არის ბოსტლენქი“-დ აქცევს. მეტრიკის, ლოგებისა და ტრეისების ერთად დაკავშირება საშუალებას გვაძლევს გადავიდეთ სიმპტომიდან ძირეულ მიზეზამდე წუთებში და არა მთელი შუადღის გამოცნობაში გატარებით.
შეტყობინებები, რომლებიც სიგნალია და არა ხმაური
მონიტორინგის უსარგებლოდ ქცევის ყველაზე სწრაფი გზა ყველაფერზე შეტყობინების გაგზავნაა. როდესაც ყოველი მცირე ხარვეზი ინჟინერს აფრთხილებს, შეტყობინებები ჩუმდება, იგნორირდება ან ფილტრდება საქაღალდეში, რომელსაც ვერავინ კითხულობს — და ერთი შეტყობინება, რომელსაც ნამდვილად ჰქონდა მნიშვნელობა, წყალდიდობაში იკარგება. ეს „შეტყობინებებით გადაღლა“ არ არის თქვენი გუნდის დისციპლინის პრობლემა; ეს შეტყობინებების დიზაინის პრობლემაა და ის სრულად გამოსასწორებელია. კარგი შეტყობინება დაუნდობელია სიგნალის მიმართ: ის ადამიანს მხოლოდ მაშინ აფრთხილებს, როცა ადამიანს ნამდვილად სჭირდება მოქმედება.
ჩვენ ვაწყობთ შეტყობინებებს ქმედითად. ზღვრები დაყენებულია მნიშვნელოვან პირობებზე და არა თვითნებურ რიცხვებზე, დაკავშირებული შეტყობინებები დაჯგუფებულია ისე, რომ ერთმა ფუნდამენტურმა ხარვეზმა ორმოცდაათი შეტყობინება არ წარმოშვას, ხოლო ანომალიების აღმოჩენა იჭერს უჩვეულო ნიმუშებს, რომელთაც ფიქსირებული ზღვრები გამოტოვებენ. რაც კრიტიკულია, ჩვენ განვასხვავებთ იმას, რაც საკმარისად გადაუდებელია ვინმეს 3 საათზე გასაღვიძებლად, იმისგან, რასაც სამუშაო საათებამდე ლოდინი შეუძლია — ვაფრთხილებთ მომხმარებლისთვის ხილულ სიმპტომებსა და მოახლოებულ რისკზე და არა ყოველ გარდამავალ შიდა რყევაზე, რომელიც თავისთავად მოგვარდება.
შეტყობინებებს ასევე სჭირდებათ მკაფიო დანიშნულება და მკაფიო შემდეგი ნაბიჯი. ჩვენ ვამისამართებთ ყოველ შეტყობინებას სწორ მორიგე ინჟინერთან იმ კონტექსტით, რომელიც სჭირდება დიაგნოსტიკის დაუყოვნებლივ დასაწყებად — რომელი სისტემა, რა შეიცვალა, ბმულები შესაბამის დაფებსა და ტრეისებზე — ასე რომ რეაგირება იწყება გამოძიებით და არა იმის გასარკვევად ფაცაფუცით, საერთოდ რა გაფუჭდა. დროთა განმავლობაში ვაანალიზებთ, რომელი შეტყობინებები ამოქმედდა, რომელი იყო სასარგებლო და რომელი — ხმაური, და ვამკაცრებთ კონფიგურაციას, ასე რომ სისტემა სულ უფრო ბასრი ხდება.
რას გვთავაზობს ჩვენი მონიტორინგი
ერთიანი დაფები
სისტემის მდგომარეობის ერთიანი, მკაფიო ხედი ღრუბლის, ქსელის, სერვერებისა და აპლიკაციების გასწვრივ, რომ თქვენ და ჩვენ ყოველთვის ერთსა და იმავე სიმართლის წყაროს ვუყურებდეთ. დაფები აგებულია იმის გარშემო, რასაც რეალურად აქვს მნიშვნელობა თქვენი ბიზნესისა და მომხმარებლებისთვის და არა ნაგულისხმევი გრაფიკების კედლის გარშემო, რომელსაც ვერავინ კითხულობს, და მორგებული ხედები ემსახურება როგორც ინჟინრებს, ისე ხელმძღვანელობას.
მეტრიკა, ლოგები და ტრეისები
სრული დაკვირვებადობა, რომელიც აკავშირებს CPU-სა და დაყოვნების მეტრიკას დეტალურ ლოგებთან და განაწილებულ ტრეისებთან, რაც გვაძლევს საშუალებას სწრაფად მივყვეთ პრობლემას სიმპტომიდან ძირეულ მიზეზამდე. სამივეს კორელაცია ის არის, რაც ბუნდოვან „ნელია“-ს ზუსტ დიაგნოზად აქცევს და რაც აქამდე-არ-ნანახი ინციდენტის გამოძიებას ახალი კოდის გაშვების გარეშე შესაძლებელს ხდის.
ჭკვიანი შეტყობინებები
ზღვრები და ანომალიების აღმოჩენა მორგებულია ხმაურის შესამცირებლად, დაკავშირებული შეტყობინებების დასაჯგუფებლად და მათ სწორ მორიგე ინჟინერთან კონტექსტით მისამართად. ვაფრთხილებთ მომხმარებლისთვის ხილულ სიმპტომებსა და მოახლოებულ რისკზე და არა ყოველ გარდამავალ ხარვეზზე, რათა თავიდან ავიცილოთ შეტყობინებებით გადაღლა, რომელიც ჩუმად აიძულებს გუნდებს უგულებელყონ ერთი შეტყობინება, რომელსაც მნიშვნელობა ჰქონდა.
პრობლემების პროაქტიული აღმოჩენა
ვადევნებთ თვალს ადრეულ გამაფრთხილებელ ნიშნებს — სიმძლავრის ტენდენციებს, შეცდომების სიხშირის ზრდას, დამოკიდებულებების გაუარესებას, ვადაგასვლის ზღვართან მიახლოებულ სერტიფიკატებს — და ვმოქმედებთ, სანამ ისინი მომხმარებლისთვის ხილულ ავარიებად გადაიქცევა. ჩავარდნისკენ ნელი დრიფტის დაჭერა ის არის, რაც წყნარ სამოვლო დავალებას 2 საათის გადაუდებელი სიტუაციისა და საჯარო ინციდენტისგან განასხვავებს.
განაწილებული ტრეისინგი
თავიდან ბოლომდე ტრეისინგი მიჰყვება ყოველ მოთხოვნას სერვისების, რიგებისა და მონაცემთა ბაზების გასწვრივ, ზუსტად მიუთითებს, სად გროვდება დაყოვნება ან სად ჩავარდება გამოძახება. მიკროსერვისულ და მრავალსერვისულ არქიტექტურებში ეს ერთადერთი პრაქტიკული გზაა რეალური ბოსტლენქის მოსაძებნად, ნაცვლად იმისა, რომ რაღაცები გადავტვირთოთ და იმედი ვიქონიოთ, რომ პრობლემა გადაინაცვლებს.
სიმძლავრისა და წარმადობის ტენდენციები
გრძელვადიანი ტენდენციების ანალიზი მონიტორინგს დაგეგმვად აქცევს. იმის დაკვირვებით, თუ როგორ იზრდება დატვირთვა, შენახვა და რესურსების გამოყენება დროთა განმავლობაში, ჩვენ ვაპროგნოზებთ, როდის მიაღწევთ ლიმიტს და ვურჩევთ მასშტაბირებას მანამ, სანამ ის გიკბენთ — ასე რომ სიმძლავრის გადაწყვეტილებები მიიღება განზრახ, წინასწარ, და არა რეაქტიულად, გათიშვის დროს.
SLA-სა და ხელმისაწვდომობის ანგარიშები
რეგულარული, გამჭვირვალე ანგარიშები ხელმისაწვდომობაზე, რეაგირების დროსა და ინციდენტებზე აჩვენებს, რომ თქვენი SLA-ები სრულდება და სად ღირს შემდეგი ინვესტიცია. რეალური მონაცემები ანაცვლებს ანეგდოტს, რაც გაძლევთ მტკიცებულებას მომხმარებლებისა და დაინტერესებული მხარეებისთვის და მკაფიო სურათს იმისა, გარემოს რომელ ნაწილს სჭირდება ყურადღება ყველაზე მეტად.
ინციდენტებზე რეაგირების მხარდაჭერა
როდესაც რაიმე მართლა გაფუჭდება, დაკვირვებადობა უკვე ადგილზეა სწრაფი რეაგირებისთვის — დაფები ტრიაჟისთვის, ტრეისები ლოკალიზაციისთვის და ლოგები მიზეზის დასადასტურებლად. ჩვენ ვეხმარებით გადაჭრის საშუალო დროის შემცირებაში და, ფაქტის შემდეგ, ვიყენებთ აღბეჭდილ მონაცემებს, რომ იგივე ინციდენტის განმეორება თავიდან ავიცილოთ.
ხშირად დასმული კითხვები
- რა არის დაკვირვებადობის სამი საყრდენი?
- მეტრიკა გეუბნებათ, რომ რაღაც არასწორადაა და ავლენს ტენდენციებს; ლოგები გეუბნებათ დეტალურად, რა მოხდა, კონკრეტულ შეცდომამდე ჩათვლით; ხოლო ტრეისები გაჩვენებთ, განაწილებულ სისტემაში სად მოხდა პრობლემა, მოთხოვნის სერვისებზე გავლის თვალყურის დევნებით. თითოეული პასუხობს განსხვავებულ კითხვას და ერთად ისინი გვაძლევენ საშუალებას სიმპტომიდან დადასტურებულ ძირეულ მიზეზამდე სწრაფად გადავიდეთ, გამოცნობის ნაცვლად.
- რა განსხვავებაა მონიტორინგსა და დაკვირვებადობას შორის?
- მონიტორინგი გეუბნებათ, ჯანმრთელია თუ არა ის, რასაც უკვე გადაწყვიტეთ, რომ დააკვირდით — ის ცნობილ კითხვებს პასუხობს. დაკვირვებადობა საშუალებას გაძლევთ ახალი კითხვები დაუსვათ თქვენს სისტემას, რომ გამოიძიოთ პრობლემა, რომელიც აქამდე არ გინახავთ, ახალი კოდის გაშვების გარეშე იმის გასაგებად, რა ხდება. ყველაზე მტკივნეული ინციდენტები ჩვეულებრივ გაუთვალისწინებელია, რის გამოც სწორედ დაკვირვებადობისთვის ვაშენებთ და არა მხოლოდ მონიტორინგისთვის.
- იმუშავებს ეს ჩვენს არსებულ მონიტორინგის ხელსაწყოებთან?
- დიახ. ვმუშაობთ იმ სტეკთან, რომელსაც უკვე იყენებთ, და დამატებებს მხოლოდ მაშინ ვირჩევთ, როცა რეალურ ხილვადობის ხარვეზს ავსებენ, ნაცვლად სრული ჩანაცვლების თავსმოხვევისა. თუ ჯერ რეალური მონიტორინგი არ გაქვთ, ვაყენებთ თანმიმდევრულ, კარგად აღჭურვილ პლატფორმას თავიდანვე, ასე რომ არ კერავთ ერთმანეთთან გათიშულ ხელსაწყოებს, რომელთაგან თითოეული სურათის ნახევარს აჩვენებს.
- როგორ აჩერებთ შეტყობინებებით გადაღლას?
- ხმაურიან შეტყობინებებს გამოსასწორებელ დიზაინის ხარვეზად მივიჩნევთ და არა ცხოვრების ფაქტად. ვაწყობთ ზღვრებს მნიშვნელოვან პირობებზე, ვაჯგუფებთ დაკავშირებულ შეტყობინებებს, რომ ერთმა ხარვეზმა ორმოცდაათი შეტყობინება არ ამოქმედოს, ვიყენებთ ანომალიების აღმოჩენას, რომ დავიჭიროთ ის, რასაც ფიქსირებული ზღვრები გამოტოვებენ, და ადამიანებს მხოლოდ იმაზე ვაფრთხილებთ, რასაც ნამდვილად სჭირდება ადამიანის მოქმედება. შედეგი არის მაღალსიგნალიანი, ქმედითი შეტყობინებები, რომელთაც მორიგე ინჟინრები ენდობიან და არ ჩუმდებიან.
- მივიღებთ თუ არა ჩვენ თვითონ წვდომას დაფებზე?
- რა თქმა უნდა. იღებთ წაკითხვის წვდომას იმავე დაფებზე, რომლებსაც ჩვენ ვიყენებთ, პლუს გრაფიკულ ანგარიშებს, ასე რომ ყოველთვის გაქვთ ხილვადობა თქვენი გარემოს მდგომარეობაზე და არ ხართ ჩვენზე დამოკიდებული სტატუსის განახლებისთვის. ასევე ვაშენებთ ხედებს, მორგებულს სხვადასხვა აუდიტორიაზე — ღრმა ტექნიკურ დაფებს ინჟინრებისთვის და მკაფიო შემაჯამებელ ხედებს ხელმძღვანელობისთვის.
- შეუძლია მონიტორინგს ზრდის დაგეგმვაში დაგვეხმაროს?
- დიახ, და ეს მისი ერთ-ერთი ყველაზე ღირებული გამოყენებაა. დატვირთვის, შენახვისა და რესურსების მოხმარების გრძელვადიანი ტენდენციების გაანალიზებით შეგვიძლია ვიწინასწარმეტყველოთ, როდის მიაღწევთ სიმძლავრის ლიმიტს და ვურჩიოთ მასშტაბირება წინასწარ. ეს სიმძლავრის დაგეგმვას აქცევს განზრახ, დროზე ადრე მიღებულ გადაწყვეტილებად და არა გადაუდებელ სიტუაციად, რომელიც აღმოჩენილია, როცა სისტემა დატვირთვის ქვეშ ეცემა.
- როგორ ამცირებს მონიტორინგი გათიშვის დროს?
- ორი გზით. პროაქტიულად, ის იჭერს ადრეულ გამაფრთხილებელ ნიშნებს — შეცდომების სიხშირის ზრდას, სიმძლავრის ტენდენციებს, გაუარესებულ დამოკიდებულებებს — ასე რომ საკითხები სწორდება, სანამ ისინი ავარიებად იქცევა. რეაქტიულად, როცა რაიმე მართლა გაფუჭდება, უკვე ადგილზე არსებული დაფები, ტრეისები და ცენტრალიზებული ლოგები მკვეთრად ამცირებს მიზეზის მოძებნისა და გასწორების დროს, რაც გრძელ, ბრმა გათიშვას სწრაფ, მიზანმიმართულ აღდგენად აქცევს.
- კონკრეტულად რას აკვირდებით?
- ვაკვირდებით სრულ სტეკს — ღრუბლის რესურსებს, ქსელებს, სერვერებს, მონაცემთა ბაზებსა და თვით აპლიკაციებს — ფოკუსირებულნი იმ სიგნალებზე, რომლებიც რეალურ მომხმარებლის გამოცდილებასა და ბიზნეს შედეგებს ასახავს და არა უმ მანქანის სტატისტიკაზე, რომელზეც ვერავინ მოქმედებს. ზუსტი მასშტაბი თქვენთან თანხმდება, ასე რომ ის, რასაც ვაკვირდებით, ასახავს იმას, რასაც რეალურად აქვს მნიშვნელობა თქვენი ოპერაციისთვის.
- ვინ რეაგირებს, როცა შეტყობინება ამოქმედდება?
- შეტყობინებები მისამართდება სწორ მორიგე ინჟინერთან იმ კონტექსტით, რომელიც სჭირდება დიაგნოსტიკის დაუყოვნებლივ დასაწყებად — დაზარალებული სისტემა, ბოლოდროინდელი ცვლილებები და ბმულები შესაბამის დაფებსა და ტრეისებზე. როგორც თქვენი მართვადი პარტნიორი, შეგვიძლია ეს რეაგირება შეთანხმებული დაფარვის ფარგლებში თავად ვმართოთ, ან თქვენს გუნდთან ერთად ვიმუშაოთ, ასე რომ 2 საათის შეტყობინება სწრაფ, ინფორმირებულ რეაქციას იწვევს და არა დაბნეულობას.
შეწყვიტეთ ავარიების შესახებ მომხმარებლებისგან გაგება
გვითხარით, რას იყენებთ დღეს და ჩვენ შევადგენთ მონიტორინგისა და დაკვირვებადობის გეგმას იმ დაფებით, შეტყობინებებითა და SLA ანგარიშებით, რომლებიც თქვენს ბიზნესს სჭირდება.
დაიწყეთ