PagerDuty, ან რატომ არ შეუძლია ოპერაციების დეპარტამენტს ღამით ძილი

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

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

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

რა არის PagerDuty?

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

მოკლედ, PagerDuty არის ინციდენტების დამუშავების პლატფორმა, რომელსაც შეუძლია შემომავალი ინციდენტების დამუშავება სხვადასხვა ინტეგრაციის გზით, დააყენოს მოვალეობის შეკვეთები და შემდეგ გააფრთხილოს მორიგე ინჟინერი ინციდენტის დონის მიხედვით (მაღალ დონეზე - ზარი, დაბალ დონეზე - ბიძგი აპლიკაციიდან / SMS) .

ვინ არის მორიგე?

ეს არის ალბათ პირველი ადგილი, სადაც დაიწყება PD-ის დაყენება.

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

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

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

ახლა ვნახოთ, საიდან შეიძლება მოხდეს ინციდენტები.

რა ინტეგრაციებს ვიყენებთ?

PD იღებს სხვადასხვა ინციდენტს სხვადასხვა სერვისისგან. ამჟამად გვაქვს დაახლოებით 25 ასეთი სერვისი და მათ დასამუშავებლად ვიყენებთ მზა ინტეგრაციას.

• პრომეთე

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

• Email

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

• Slack

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

Ჩვენ ვაკეთებთ:

Ჩვენ ვხედავთ:

• API

HTTP ინტეგრაცია. სინამდვილეში, აქ არაფერია განსაკუთრებით საინტერესო, უბრალოდ POST მოთხოვნა სხეულის JSON ფორმატში. მაგალითად, რაღაც საინტერესო: ჩვენ ვიყენებთ მას გარე მონიტორინგისთვის https://www.statuscake.com/. ეს სერვისი ამოწმებს ჩვენი საიტების ხელმისაწვდომობას მსოფლიოს სხვადასხვა კუთხიდან. იმ შემთხვევაში, როდესაც მივიღებთ მიუღებელ საპასუხო კოდს (მაგალითად, 502), იქმნება ინციდენტი და შემდეგ ყველაფერი მიჰყვება ზემოთ აღწერილ ჯაჭვს. თავად StatusCake-ს აქვს შიდა URL-ების, SSL სერთიფიკატის ან დომენის ვადის გასვლის მონიტორინგის შესაძლებლობა.

• LibreNMS

ეს არის კიდევ ერთი მონიტორინგის სისტემა, რომლის შესახებ მეტი შეგიძლიათ წაიკითხოთ მათ ვებსაიტზე https://www.librenms.org/. მისი დახმარებით ჩვენ ვაკვირდებით ქსელის ინტერფეისებს და iDRAC-ს სერვერებიდან.

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

ვიზუალიზაცია

ინციდენტის მოხსენების მთავარი სისტემა არის Slack. PD-ში მოსული ყველა ინციდენტი იწერება სპეციალურ ჩატში და თუ მათი სტატუსი შეიცვლება, ეს ასევე ნაჩვენებია ჩატში.

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

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

მის დასაწერად, თქვენ მხოლოდ უნდა მიიღოთ გასაღები PD-დან მხოლოდ წაკითხვის უფლებებით.
და ეს არის ის, რაც მივიღეთ:

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

იხილეთ ამ განხორციელების წყაროები აქ.

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

წყარო: www.habr.com