SLO/SLA და მეტრიკა

SLO/SLA და მეტრიკა

1) ტერმინები და იერარქია

SLI (Service Level Indicator) - გაზომილი ინდიკატორი „როგორც მომხმარებელი ხედავს ჩვენს მიერ“: წარმატებული მოთხოვნების წილი, p95 ლატენტობა, მონაცემების სიახლე, წარმატებით დამუშავებული ბრძოლების წილი და ა.შ.
SLO (Service Level Objective) - SLI სამიზნე მნიშვნელობა დაკვირვების დიაპაზონში (28/30/90 დღე). მაგალითი: "99. მოთხოვნის/გადასახადის 9% დასრულებულია 400 ms".
Error budget — 1 − SLO. SLO 99-ში. 9% შეცდომის ბიუჯეტი = 0. 1% დრო/მოთხოვნა.
SLA (გაძლიერება) - იურიდიულად მნიშვნელოვანი მომსახურების დონე: მოიცავს SLO, განზომილებას, გამონაკლისს, კომპენსაციას/ჯარიმებს.

2) დიზაინის პრინციპები

სიმპტომები> შიდა მეტრიკა. SLI უნდა ასახავდეს მომხმარებლის რეალურ გამოცდილებას.
მცირე რაოდენობით ძირითადი SLI. მომსახურებაზე - 2-5 მთავარი: წარმატება, ლატენტობა, გამტარუნარიანობა/სიახლე, სისწორე.
კრიტიკული ბილიკების გაშუქება. თითოეული ბიზნეს სცენარისთვის (checkout, login, webhook, ETL დატვირთვა) - საკუთარი SLI/SLO ნაკრები.
„წარმატების“ მკაცრი სემანტიკა. არა „კოდი 200“, არამედ „მომხმარებელმა მიიღო პასუხი დროულად და შედეგი რეალურია“.
გარე და შინაგანი SLO გამიჯვნა. შინაგანი - უფრო მკაცრი; გარე SLA არის 1-2 ცხრა ქვემოთ.

3) SLI კატალოგი (რეფერენდუმი)

3. 1 API/ონლაინ მომსახურება

წარმატება: 'SLI _ success = 1 − (5xx + timeout + business _ error )/all _ requests'

ლატენტობა: p95/p99 'http _ server _ duration _ seconds' მარშრუტებზე/მეთოდები/მოიჯარეები

გამტარუნარიანობა: 'RPS '/ლიმიტები/კვოტები

სისწორე: ნამდვილი პასუხების პროპორცია (ხელმოწერები, სქემები, ინვარიანტები)

3. 2 ვებჰუკი/ასინქრონული მიწოდება

ადგილზე მიტანა: T წამში დადასტურებული მოვლენების წილი და Retrai- ის გამოცემა

მომხმარებლები: აბონენტების წილი ხანგრძლივი შეფერხების გარეშე (წინა ტენანტი)

3. 3 მონაცემები/ETL/DWH

სიახლე: 'now - last _ successful _ ingest _ ts'

სისრულე: 'ingested _ rows/expected _ rows'

სისწორე: ჩანაწერების წილი, რომლებმაც გაიარეს ხარისხის შემოწმება

Piplines: ჯობების წილი დასრულებამდე

3. 4 მობილური/კლიენტის SDK

კლიენტის წარმატება: სესიების წილი საბედისწერო შეცდომების გარეშე

ლატენტობა round-trip: p95 მოთხოვნიდან Render- მდე

ქეში ჰიტები: ქეში მომსახურე წილი (როგორც სპექტაკლის სიმპტომი)

4) ფორმულები და მიზნების მაგალითები

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% 30 დღის განმავლობაში - error budget = 0. 05% მოთხოვნა.

• `uptime = (obs_window − downtime) / obs_window`

• ' SLO _ latency = p95 (მარშრუტი = “/გადახდა“) 400 მგ' 7-დღიან სექციებზე, გარდა ქეშის გათბობისა (1%)

• ' SLO _ freshness (dataset =“ orders“) - 10 min' p99 24 საათში.

5) Error budget და ცვლილების მენეჯმენტი

ბიუჯეტი (B): 'B = 1 − SLO'.
ბიუჯეტის მოხმარება: ფაქტობრივი შეცდომების თანაფარდობა დასაშვებად.

• გადატვირთვა (burn> 1) - ფიჩფრიზი, ყურადღება გამახვილებულია საიმედოობაზე.
• მოკლე ფანჯარაში burn rate> X - ინციდენტი და ქუდი. ზომები.
• დაგეგმვა: საიმედოობის სპრინტის წილი კორელაციაშია გასული პერიოდის განმავლობაში.

6) Alerting: burn rate და მრავალ ფანჯრის წესები

იდეა: ჩვენ დაჭერით სწრაფი გაჟონვა და ნელი დრიფტი.

• კრიტიკული: „ბიუჯეტის 2% 1 საათში“ (სწრაფი ხანძარი).
• გაფრთხილება: „ბიუჯეტის 5% 6 საათში“ (მცოცავი დეგრადაცია).

• მოკლე ფანჯარა (წუთი-საათი) სწრაფი ინციდენტებისთვის.
• გრძელი ფანჯარა (6-24 საათი) ტენდენციებისთვის.
• ლატენტობა: ალერტი p99> ბარიერი - 5 წუთი, ფუფუნების ჩახშობა და კომუნიკაცია ბილიკების ნიმუშებთან.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) მრავალმხრივი (მრავალმხრივი) და სეგმენტი

SLI/SLO ითვლება მოიჯარეების/გეგმების/რეგიონების მიხედვით, წინააღმდეგ შემთხვევაში საშუალო „გაყინავს“ წარუმატებლობებს.
სტატისტიკური მნიშვნელობის მოვლენების მინიმალური რაოდენობა (guard-rails).
SLA შეიძლება განსხვავდებოდეს ტარიფებით (მაგალითად, "Pro 99. 9%, Free 99. 5%»).

8) დაკვირვებასთან და ტრეკებთან კავშირი

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

9) კონტრაქტები და SLA

• SLI/გაზომვის/ფანჯრის მეთოდის განმარტებები.
• გამონაკლისები (დაგეგმილი სამუშაოები, ფორსმაჟორი).
• ინციდენტებისა და კომუნიკაციების პროცედურა (სტატუსის გვერდი, RFO/RCA).
• კომპენსაცია (სერვისის კრედიტები) და მოთხოვნის პროცედურა.
• იურისდიქცია, მოქმედების პერიოდი, გადასინჯვის პირობები.

• არასოდეს დაგვპირდეთ საჯაროდ SLO უფრო მკაცრს, ვიდრე არქიტექტურა და ოპერაციული პრაქტიკა იძლევა.
• გამოყავით შიდა SLO და გარე SLA.

10) ღირებულება და პრიორიტეტიზაცია

გოგონების ფასი ხაზოვანი არ იზრდება. «99. 9% → 99. 99%" = არქიტექტურის სხვა კლასი (N + 1, მულტიზონი, აქტივი).
დააყენეთ SLO ყველაზე ღირებული მომხმარებლის ქმედებებზე.
აკონტროლეთ ტელემეტრიის ღირებულება: downsampling, კვოტები, შენიშვნა და შენახვა კლასებში.

11) პროცედურები და მოხსენებები

ყოველკვირეული მოხსენებები: SLO- ს შესრულება მომსახურებებზე/მოიჯარეებზე, ბიუჯეტის მოხმარებაზე, ტოპ მიზეზებზე, გაუმჯობესების გეგმებზე.
Postinsident RCA: ჩვენ ვუკავშირდებით ბიუჯეტის ნაჭრებს; ჩვენ დავალებებს ვაძლევთ ძირძველი მიზეზების აღმოფხვრას.
ფიჩფრიზი: ჩართვის/ამოღების კრიტერიუმები.

12) შაბლონები (სწრაფი დასაწყისისთვის)

12. 1 SLO ბარათი (მაგალითი)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 „SLO სიმწიფის“ ცხრილი

13) წესების მაგალითები (ფრაგმენტები)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO მონაცემთა და ML (მახასიათებლები)

SLO მონაცემების მეშვეობით: p99 სიახლე, p99 სისრულე, „გადაკეთების“ დრო გაუმართაობის შემდეგ.
მონაცემთა კონტრაქტები: მოსალოდნელი სქემები, მოცულობა, ვადები; მონაცემთა ინციდენტის დარღვევა.
ML: SLO ინვესტიციის ლატენტურობისთვის, SLA fich stor- ის ხელმისაწვდომობისთვის, დრიფტის მონიტორინგისთვის (მოდელის ხარისხი ცალკე თემაა SLA- ს გარეთ).

15) უსაფრთხოებისა და კონფიდენციალურობის ინტეგრაცია

Logs SLI გარეშე PII/საიდუმლოებები; ტოქსიკაცია/შენიღბვა.
SLO/SLA- ს ცვლილებების აუდიტი და უცვლელი ჟურნალების ანგარიშების გამოქვეყნება.
მარეგულირებელი გზებისთვის (გადახდები/PII) - ცალკეული, უფრო მკაცრი SLO.

16) ჩეკის ფურცლები

მომსახურების/ფიჩების დაწყებამდე

• განსაზღვრულია SLI „წარმატება/ლატენტობა/გამტარუნარიანობა/სიახლე“.
• მითითებულია SLO და ფანჯრები; გამოითვლება შეცდომის ბიუჯეტი.
• burn-rate ალერტები (მოკლე + გრძელი).
• დაშბორდები RED + exemplars მარშრუტები; ინციდენტების რუნიბუკები.
• მრავალსართულიანი ჭრილობები და მნიშვნელობის ბარიერები.
• ფიჩფრიზის პროცედურა და მოხსენება.

ოპერაცია

• ყოველკვირეული ანგარიში SLO/burn, გეგმები hardening.
• SLO გადაფასება არქიტექტურის/დატვირთვის შეცვლისას.
• პერიოდული „ინციდენტები-წვრთნები“ და რუნიბუკების განახლება.
• ტელემეტრიული ღირებულების კონტროლი და SLI რაოდენობა.

17) Runbook’и

Runbook: სწრაფი ზრდა p99/ანაზღაურება

1. Alert r99> ბარიერი გახსნას dashboard და გადაიტანოს ექსპლარის ბილიკზე.
2. იპოვნეთ ვიწრო CLIENT/SERVER სპანი, შეადარეთ რეგიონები/ვერსიები.
3. ჩართეთ დეგრადაცია (ქეში/ლიმიტი/ფოლბეკი), აცნობეთ დამოკიდებულების გუნდს.
4. სტაბილიზაციის შემდეგ - RCA, ოპტიმიზაციის დავალებები, SLO გაზომვების განახლება.

Runbook: ბიუჯეტის მოხმარება> 50% კვირაში

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

18) FAQ

გ: რამდენი SLO გჭირდებათ?
ო: მინიმალური კრიტიკული მომხმარებლის სცენარებისთვის: წარმატება + ლატენტობა. ყველაფერი დანარჩენი საჭიროებისამებრ არის.

გ: რა არის უკეთესი - წვდომა დროულად ან მოთხოვნით?
ო: მოთხოვნით - უფრო მომხმარებლის მეტრი. დროულად მოსახერხებელია ქსელის კომპონენტები/ინფო.

გ: რატომ p95 და არა საშუალო?
ო: შუა მალავს კუდს; მომხმარებელი გრძნობს p95/p99.

გ: როგორ არ უნდა „გამკაცრდეს თხილი“ ძალიან ძლიერი?
ო: დაიწყეთ რეალისტური მიზნებით (ისტორიული მონაცემები), შემდეგ გამკაცრდით, როგორც სიმწიფე.

• „დაკვირვება: ლოგოები, მეტრიკები, ტრეკები“
• „განაწილებული ტრეკები“
• „აუდიტი და უცვლელი ჟურნალები“
• „ვებ ჰუკების მიწოდების გარანტიები“
• „დაშიფვრა In Transit/At Rest“
• „მონაცემთა წარმოშობა (Lineage)“