CASE მეთოდი: ჰუმანური მონიტორინგი

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

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

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

რა არის CASE?

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

• Cონტექსტი-მძიმე (შეზღუდული კონტექსტი)
• Aქმედითუნარიანი (პრაქტიკული ღირებულება)
• Sსიმპტომებზე დაფუძნებული (ხაზგასმა სიმპტომებზე)
• Eდაფასებული (კლასი)

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

დასამახსოვრებლად გასაადვილებლად წარმოიდგინეთ, რომ გჭირდებათ CASE [ანუ საქმე, მიზეზი - მთარგმნელის შენიშვნა] ყოველი გაფრთხილების გასამართლებლად. :მზის სათვალე:

და რატომ არის ეს ყველაფერი?

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

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

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

Context-Heavy - კონტექსტის სავალდებულო

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

პრობლემებს მრავალი წყარო აქვს. განსაკუთრებით მოჩვენებები.

როგორ შემიძლია დავეხმარო მორიგეს? პირველი, რასაც მორიგე ხედავს, არის შეტყობინება, ამიტომ იგი ყველა ჰიპოთეზას აშენებს მის საფუძველზე. შემდეგ ის ათვალიერებს ინსტრუქციებსა და დაფებს, მაგრამ ყოველთვის არის მონაცემები კონკრეტულ შეტყობინებაზე და არა მხოლოდ ზოგადი ინფორმაცია? ალსპაუ გვირჩევს „დაფიქრდეთ იმაზე, თუ როგორ შეგიძლიათ ინტერპრეტაცია გაუკეთოთ ან უპასუხოთ შეტყობინებას“ (სლაიდი 29)1. კარგი შეტყობინება ფოკუსირებულია მორიგე ადამიანზე და არა მხოლოდ ზღვრით კონფიგურირებული.

ასე რომ, აქ არის რამდენიმე იდეა, თუ როგორ უნდა გავაუმჯობესოთ შეტყობინებების კონტექსტი:

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

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

ქმედითი - პრაქტიკული ღირებულება

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

ჩანაწერის ნახვა on imgur.com

Რა უნდა გავაკეთო? Რა გინდა?

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

აი, როგორ გამოიყურება პრაქტიკული მნიშვნელობის შეტყობინება:

• შეტყობინება მოითხოვს მოქმედებას და არა უბრალოდ სიახლეების მოხსენებას.
• ამ ქმედების ავტომატიზაცია რთული ან სარისკოა. თუ ქმედება შეიძლება ავტომატიზირებული იყოს, მაშინ ავტომატიზირდით, შეწყვიტეთ ხალხის შეწუხება!
• შეტყობინება შეიცავს სასწრაფო რეკომენდაციებს ფორმაში მომსახურების დონის ხელშეკრულებები (SLA) ან აღდგენის დროის სამიზნე (RTO). ამის შემდეგ მორიგე ოფიცერს შეუძლია გაააქტიუროს ორგანიზაციის ინციდენტების მართვის პროგრამა.

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

სიმპტომებზე დაფუძნებული - აქცენტი სიმპტომებზე

მოგწონთ თუ არა, თქვენ მუშაობთ განაწილებულ სისტემაში (Kavaj)2. შედეგად, თქვენ იყენებთ სხვადასხვა ტაქტიკას სერვისების იზოლირებისთვის და მარცხისგან დასაცავად (Trainor et al.)3. და მიუხედავად იმისა, რომ დაგვიანებული ნაგვის შეგროვება ან მონაცემთა ბაზის შეჩერებული მოთხოვნა მიუთითებს პრობლემებზე, არ არის საჭირო მათი გამოსწორების ჩქარობა, თუ მომხმარებლებს პრობლემები არ შეექმნებათ უახლოეს მომავალში.

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

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

სიმპტომები არც ისე ცვალებადია

რიჩარდ კუკი შეგვახსენებს, რომ რთული სისტემები სავსეა ხარვეზებით, ნაკლოვანებებით და პრობლემებით4. ყველა შესაძლო მიზეზის ჩამოთვლის მცდელობა სიზიფური ამოცანაა. თქვენ ცდილობთ აღწეროთ პრობლემები, მაგრამ ისინი მუდმივად იცვლება. სინდი შრიდჰარანი თვლის, რომ „სისტემები არ უნდა იყოს იდეალურ მდგომარეობაში ყოველ წამს“ და უმჯობესია უფრო ადამიანური მიდგომა გამოვიყენოთ ("განაწილებული სისტემების დაკვირვებადობა" („განაწილებული სისტემების მონიტორინგი“), 7)5.

მოერიდეთ შეტყობინებებს ინციდენტის შემდეგ

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

არ წამოგცდეს მიზეზის შენიშვნები. ჯობია დაფიქრდე:

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

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

მიზეზებზე დაფუძნებული შეტყობინებები ზომიერად მისაღებია

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

შეფასებული - შეფასება

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

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

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

დასკვნა

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

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

ისიამოვნეთ გაუმჯობესებული შეტყობინებებით!

წყარო: www.habr.com