GH GambleHub

SLA და SLO მონიტორინგი

1) ტერმინები და როლები

SLA (Service Level Agreement) - კლიენტის გარე სახელშეკრულებო ვალდებულება (ჯარიმები, სესხები).
SLO (Service Level Objective) არის სერვისის სამიზნე შიდა დონე, რომელიც მხარს უჭერს SLA- ს განხორციელებას.
SLI (Service Level Indicator) არის გაზომილი ინდიკატორი, რომლის საფუძველზეც შეფასებულია SLO/SLA.
Error Budget - „მიუწვდომლობის/შეცდომების“ დასაშვები წილი პერიოდისთვის: „Budget = 1 − SLO“.
სკოპი: იზომება მომხმარებლის თვალით. მიკრო სერვისებში - როგორც კომპონენტის დონეზე, ასევე ბილიკის გავლით.

2) SLI არჩევანი: რა უნდა გაზომოთ

კრიტერიუმი არის კორელაცია მომხმარებლის გამოცდილებასთან და ბიზნეს ღირებულებასთან.

ტიპიური SLI:
  • ხელმისაწვდომობა: წარმატებული მოთხოვნების წილი. 'SLI = წარმატებული/ყველა'.
  • ლატენტობა: მოთხოვნების წილი უფრო სწრაფია, ვიდრე T. 'SLI = P (latency - T)'.
  • ხარისხი: სწორი პასუხების პროპორცია (5xx/funz- ის გარეშე). შეცდომები).
  • მონაცემების აქტუალობა: რეპლიკაციის შეფერხება/ETL - X წუთი.
  • ბიზნეს პროცესის ეფექტურობა: წარმატებული გადახდების/რეგისტრაციის წილი.

ანტი-შაბლონები: განიხილოს მხოლოდ 200-ქი, როგორც „წარმატება“, უგულებელყოფს ბიზნეს შეცდომებს; გაზომეთ სატესტო ქსელში მომხმარებლის ნაცვლად.

3) ფორმულები და სათვალთვალო ფანჯრები

ფანჯარასთან წვდომა:
  • `Availability = (OK_requests / All_requests) × 100%`.
SLO ლატენტური:
  • 'P95' T 'უმჯობესია ჩამოაყალიბოთ, როგორც წილი:' SLI =% მოთხოვნა T '.
  • მაგალითი: „ძიების მოთხოვნის 99% 28 დღეში 300 ms“.
მოცურების ფანჯარა: 28 ან 30 დღე (მგრძნობელობისა და სტაბილურობის ბალანსი). ინციდენტებისთვის - დამატებითი. ფანჯრები: 1 საათი, 6 საათი, 24:
  • 4) Error Budget და ცვლილების სიჩქარის კონტროლი

გაანგარიშება: 'SLO = 99. 9% 'ბიუჯეტი =' 0. 1% 'შეცდომები/მიუწვდომლობა პერიოდისთვის.

პოლიტიკა:
  • ბიუჯეტი> 50%: გამოშვებები და ექსპერიმენტები გეგმის მიხედვით.
  • ბიუჯეტი 10-50%: მხოლოდ დაბალი კორუფციის გამოშვებები, კანარის გამკაცრება.
  • ბიუჯეტი <10%: გამოშვებების გაყინვა, ფესვის მიზეზი, საიმედოობის გაუმჯობესება.
  • კომუნიკაცია პროგრესულ გამოშვებებთან: კანარი/მომავალი-ფლაგები „ჭამენ“ ბიუჯეტს დოზირებით, დეგრადაციის დროს მანქანით დაბრუნებით.

5) ალერტ პოლიტიკოსები: ბარიერებიდან დაწყებული

რატომ არ „მისცა SLO - country alert“: ძალიან გვიან. საჭიროა პროაქტიულობა.

Burn Rate (BR) - ბიუჯეტის დაწვის სიჩქარე:
  • 'BR = (მოკლე ფანჯრის დაფიქსირებული შეცდომა/ამ ფანჯრის დასაშვები შეცდომა)'.
  • თუ „BR> 1“ - ბიუჯეტი იხარჯება უფრო სწრაფად, ვიდრე ნორმალური.
SRE best practice:
  • სწრაფი ალერტი (ხმაური მგრძნობიარეა, იჭერს კატასტროფებს): ფანჯარა 5-10 წუთი, BR ბარიერი 14-20 ×.
  • ნელი ალერტი (მცოცავი დეგრადაციის დაჭერა): ფანჯარა 1-6 საათი, BR ბარიერი 2-4 ×.
  • შერწყმის პირობები: სწრაფი ან ნელი მუშაობდა - პეიჯინგი on-call.
  • დონე: პეიჯერი მომხმარებლის SLO- სთვის, თიკეტები/შეტყობინებები შინაგანი SLI- ს ნაცრისფერი დეგრადაციებისთვის.

6) დაკვირვება და ჭეშმარიტების წყაროები

ლოგიკა არის მიზეზების დიაგნოზი.
მეტრიკი - რიცხვითი SLI (წარმატება/შეცდომა, ლატენტობა, აქციები, მრიცხველები).
ბილიკები - ბილიკების გავლა, „ცხელი“ სეგმენტების ლოკალიზაცია.
სინთეზური აქტიური ნიმუშებია პერიფერიიდან (რეგულირების რეჟიმში).
რეალური მოვლენებია RUM/მომხმარებელთა ტელემეტრია, ბიზნეს მეტრიკა (კონვერტაცია, წარმატებული გადახდები).

მოთხოვნები: გამოშვებებისა და ინციდენტების დაშლის ერთიანი სურათი, „ვერსია/კანარი/დროშა“.

7) SLO დიზაინი: ეტაპის შაბლონი

1. აღწერეთ კრიტიკული გზა (მაგალითად, „ბარათის ანაბარი“).
2. განსაზღვრეთ SLI: წარმატება/შეცდომა, ლატენტობის ბარიერი, სისრულე.
3. კოორდინირებული SLO: მიზანი 28 დღის განმავლობაში + გამონაკლისი (დაგეგმილი ფანჯრები).
4. დააკავშირეთ SLA- სთან: იურიდიული ვალდებულება - ფაქტობრივი SLO.
5. დანიშნეთ მფლობელი (მომსახურება owner), RACI და ალერტის არხი.
6. დაადგინეთ ალერტის პოლიტიკა (ორსართულიანი BR) და მანქანის გამოტოვება.
7. გააცნობიერეთ მოხსენებები: ყოველკვირეული ბიუჯეტის მიმოხილვები, შურისძიება.
8. გადახედეთ SLO კვარტალურად (დატვირთვის/არქიტექტურის ცვლილება).

8) SLO მაგალითები (შაბლონები)

API გადახდები:
  • წვდომა: '99. 95% '(28d, გამოცხადებული ფანჯრების გამოკლებით - 30 წთ/თვე).
  • ლატენტობა: '99%' პასუხები '400 ms'.
  • ბიზნეს ოპერაციების წარმატება: '98. 5% 'წარმატებული ავტორიზაციისთვის (გათვალისწინებულია fraud ფილტრები).
თამაშის/შინაარსის ძებნა:
  • ლატენტობა: '99%' მოთხოვნა '300 ms'.
  • ქეშის აქტუალობა: '5 წუთი' ჩამორჩენა შემთხვევების 99% -ში.
სტრიმინგის მოვლენები (KYC/AML):
  • ადგილზე მიტანა: '99. 9% '60 დღის განმავლობაში' (end-end, ჭაობებით).
  • ზარალი: '0. 01% 'შეტყობინებები (შედის იდემპოტენტობა/დედუპლიკაცია).

9) მულტფილმის რეგიონი და მულტფილმის ტენანტი

SLO „კოჰორტებზე“: ქვეყანა, გადახდის პროვაიდერი, VIP სეგმენტი, მოწყობილობა.
ადგილობრივი SLO ზღვარზე: მეტრიკა მომხმარებლის უახლოესი წერტილებიდან (edge/PoP).
შეჯამება: საერთო SLO არ უნდა მალავდეს მნიშვნელოვან კოჰორტებს.
პროვაიდერების გადართვა: ავტომატური fallback მარშრუტები SLO კარიბჭეების დონეზე.

10) დაშბორდი და მოხსენებები

გამოშვებული დაშბორდი: ვერსია, კანარი (% ტრაფიკი), SLI (წარმატება/ლატენტობა), BR, დროშის სურათები.
ოპერაციული დაშბორდი: დღეების ბიუჯეტი, ტოპ ინციდენტები, MTTR, პრობლემური კოჰორტები.
ყოველკვირეული მოხსენებები: ბიუჯეტის ბალანსი, BR ტენდენციები, ტექნიკური დავალიანება (ვიწრო ადგილები), გაუმჯობესების გეგმა.

11) პროცესები: ინციდენტები, RCA და გაუმჯობესება

ინციდენტის მენეჯმენტი: ალერტი - BR შეფასება - კანარის/დროშების მასშტაბები, გამოტოვება/ფიქსი.
RCA (ფესვის მიზეზი): ფაქტები/დრო/ჰიპოთეზა/კორექტირება/SLI ეფექტის შემოწმება.
მიღებული გაკვეთილები: არასაკმარისი პოსტ-mortems, სავალდებულო მოქმედება items მფლობელებთან და ვადებთან.
ციკლის დახურვა: ცვლილებები ტესტებში, ფერფლის დროშებში, ლიმიტებში, ქეშებში, გამოსვლებში, კვოტებში.

12) შესაბამისობა და აუდიტი

SLO/SLI, როგორც კონტროლის არტეფაქტები (პოლიცია-as-code, უცვლელი ლოგოები).
მოთხოვნებთან დაკავშირებული (მაგალითად, გადახდის ოპერაციების ხელმისაწვდომობა).
მტკიცებულებები: ალერტის ოქმები, მოხსენებები ბიუჯეტის შესახებ, გამოცემების/გამოტოვების ჟურნალები.

13) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

“99. 99% ან სიკვდილი": მიუწვდომელი მიზნები - მუდმივი ალერტული ხმაური. აირჩიე რეალისტური SLO.
გლობალური საშუალო მალავს ადგილობრივ წარუმატებლობას და შემოიღებს კოჰორტებს.
მეტრიკა არ არის e2e: მაღალი SLO, როდესაც კლიენტზე ფაქტობრივი დეგრადაციაა, შეგიძლიათ დაამატოთ RUM/სინთეტიკა.
ალერტამ ერთ ზღურბლზე უნდა გადავიდეს ორსართულიანი ბარიერი.
არ არის დაკავშირებული ცვლილებებთან - გამოშვებები არ არის დანერგილი, არ არის მანქანების გამოტოვება.

14) მინი ჩეკის განხორციელების სია

  • აღწერილია კრიტიკული გზები და მათი SLI/SLO.
  • მოცემულია დაკვირვების ფანჯარა და გამონაკლისი.
  • ორსართულიანი BR ალერტები (სწრაფი და ნელი) განლაგებულია.
  • Dashbords გამოშვებებისა და ოპერაციების ვერსიების/დროშების პრეზენტაციებით.
  • error budget პოლიტიკა გავლენას ახდენს გამოშვებებზე.
  • რეგულარული ბიუჯეტის მიმოხილვები და პოსტ-ინციდენტები RCA.
  • დოკუმენტები და ინდიკატორების მფლობელები.

15) გაანგარიშების მაგალითი (სპეციფიკა)

SLO ხელმისაწვდომი API: 99. 9% 28 დღეში - ბიუჯეტი = 0. 1%.
7 დღეში 0 დაგროვდა. შეცდომების 06% დახარჯა ყოველკვირეული ბიუჯეტის 60%.
მოკლე ფანჯარაში 15 წუთის განმავლობაში, შეცდომების 2% შეინიშნება. დასაშვებია ამ ფანჯარაში: '0. 1% × (15 წთ/40320 წთ) - 0. 000037%`.
Burn Rate - 1 (ათეულობით ×) - სწრაფი პეიჯერი მუშაობს, კანარი ბრუნავს 1% -მდე, ჩართულია „degrade-payments-UX“ - ის ფიკა-დროშა, იწყება RCA.

16) შედეგი

SLA/SLO- ს მონიტორინგი არა მხოლოდ მოხსენებაში მოცემულია ციფრები, არამედ ცვლილებების რისკის მართვის მექანიზმი და მომსახურების ხარისხი. რეგულარული SLI, რეალისტური SLO, error budget მენეჯმენტი, ორმაგი ფანჯრის დამაკავშირებელი ალერტები და e2e დაკვირვება მეტრიკებს სამუშაო გადაწყვეტილებად აქცევს: უფრო სწრაფად გამოიმუშავეთ ღირებულება და შეინარჩუნეთ მომხმარებლის გამოცდილება პროგნოზირებადი.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

Telegram
@Gamble_GC
ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.