Error Budgets და SLO მენეჯმენტი

1) რატომ არის SLO და შეცდომების ბიუჯეტი

SLO (Service Level Objective) - მომხმარებლის მიერ აღქმული ხარისხის მიზნობრივი დონე; SLI - გაზომილი მეტრი; Error Budget - ფანჯრის გადახრების დაშვება (ჩვეულებრივ 30/90 დღე).
შეცდომების ბიუჯეტი საიმედოობას „აბსტრაქციიდან“ მართულ რესურსად აქცევს: როდესაც ბიუჯეტი სწრაფად იწვის, ჩვენ ვყინავთ ფიჩებსა და ჩინს; როდესაც ბიუჯეტი ჯანმრთელია, შეგიძლიათ დააჩქაროთ გამოშვებები.

2) SLI არჩევანი: რა არის „კარგი“

კრიტერიუმი: „წარმატებით მომხმარებლის თვალსაზრისით“.

2. 1 კლასიკური SLI

Availability: წარმატებული მოთხოვნების წილი (კლიენტის მიერ გაუქმებული გამოკითხვის გამოკლებით).
'success = http _ status' {2xx, 3xx, 404} და ტაიმუტის გარეშე '(404 შეიძლება წარმატებულად ჩაითვალოს read API- სთვის, თუ ეს მოსალოდნელი სემანტიკაა).
Latency: მოთხოვნების წილი უფრო სწრაფია, ვიდრე ბარიერი (მაგალითად, p95-300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: „მონაცემები არ აღემატება X წუთს“ (ქეში, კატალოგები, კოეფიციენტები).
Quality: შედეგის სისწორე (ბიზნესის შემსრულებლების გავლა/ეკრანული ინვარიანტები).

2. 2 საზღვრები და სეგმენტები

SLI უნდა ჩაითვალოს მნიშვნელოვან სექციებად: 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. ასე რომ, თქვენ არ „გააცნობიერებთ“ ერთი კრიტიკული კალმის წარუმატებლობას მთელ სისტემაში.

3) ფორმულები და ბიუჯეტი

3. 1 Request-based (სასურველია API- სთვის)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 დრო (ფონის სერვისებისთვის/ნაკადისთვის)

SLO_uptime = good_minutes / total_minutes

3. 3 მიზნების მაგალითი

API საერთოა: 99. ხელმისაწვდომობის 9% 30 დღეში - ბიუჯეტი = 0. 1%.
კრიტიკული გადახდის სახელურები: 99. 95%; კატალოგები/ძებნა: 99. 5%.
ლატენტობა: p95-300 ms n '/v1/payments ', p99-800 ms.

4) SLI ბრიფინგი

4. 1 პრინციპები

Logs/traces - მეტრიკა RED (Rate/Errors/Duration) აშკარა ბუკეტებით.
დარწმუნდით, რომ დააყენეთ 'tenant', 'region', 'route _ class' (PII გარეშე).
განიხილეთ ორი მეტრი: „წარმატება“ და „ყველაფერი“, ხოლო ლატენციისთვის - „სწრაფი“ და „ყველაფერი“.

4. 2 მაგალითი Prometheus (5 მ)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alerty on burn (multi window, multi-burn)

5. 1 იდეა

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

5. 2 ბარიერი პროფილები (SLO 99-ისთვის). 9%)

Paging: burn rate - 14. 4 × (ბიუჯეტის 10% 1 საათში და 5% 6 საათში).
Ticet: burn rate - 6 × (2% 6 საათში და 1% 24 საათში).

5. 3 წესების მაგალითი (Prometheus, ფსევდო)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

ანალოგიურად, ტიკეტისთვის 6h/24h.

6) ბიუჯეტის ოფისი: პროცესები

6. 1 გამოშვებული კარიბჭეები

თუ ბიუჯეტის დარჩენილი ნაწილი <25% და ტენდენცია უარყოფითია - „კოდი გაყინვა“ ფიჩებზე, პრიორიტეტი SRE/სტაბილურობა.
კანარის გამოშვებებს უნდა ჰქონდეთ ცალკეული SLO ნაჭერი ('deployment. environment="canary"`).

6. 2 ბეკლოგის პრიორიტეტი

განაწილეთ ბრძანების შესაძლებლობები წვის სიჩქარის პროპორციულად და შემოსავალზე გავლენის მოხდენით.
დაასაბუთეთ ტექნიკური დავალიანება მეტრიკებით: „ფაქსი X შეამცირებს ბურნს Y% -ით“.

6. 3 მარხვის ინციდენტი

თითოეული ინციდენტი - RCA და „ფაქსი, რომელიც არ უნდა გამოტოვოთ“, კონტროლი „დაბრუნდა SLO- ში“.

7) SLO კოდი

7. 1 SLO მანიფესტის მაგალითი (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 წესების გენერაცია

გამოიყენეთ გენერატორები (slo-generator, pyrra, sloth) წესების, დაშბორდების და მოხსენებების ავტომატური შესაქმნელად.

8) SLO დეგრადაცია და დაცვა

Load shedder: მისცეს სწრაფი პასუხები მწვერვალზე „ძვირადღირებული“ დამოკიდებულების გარეშე.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: იცავს ზურგჩანთებს; მნიშვნელოვანი მარშრუტები პრიორიტეტია.
Circuit/Timeout: სწრაფი ტაიმაუტები და „fallback“ ფილიალები.
Feature flags: ერთი ღილაკის მძიმე დარტყმის გამორთვა.

9) დაკვირვება SLO- სთვის

Dashboards: SLO actual vs target, ბიუჯეტის დარჩენილი ნაწილი, burn rate, წვლილი მარშრუტებზე/პროვაიდერებზე.
კორელაცია: SLO „ხვრელიდან“ exemplar- ში სპეციფიკური ტრეკი - ლოგოები/პროფილები.
მოხსენებები: ყოველკვირეული - ტენდენციები, ბიუჯეტის მოხმარება, დეგრადაციის ტოპ მიზეზები.

10) ანტიპატერები

ერთი „გლობალური“ SLO ყველაფრისთვის, პრობლემებს შენიღბავს. ოპჲგვპვრვ ჟვ.
«99. 99% ყველაფერზე" ფასისა და რეალობის გამოკლებით. შეარჩიეთ მიზნები მომხმარებლის გამოცდილებიდან.
CPU/heap ალერტები burn rate/SLO- ს ნაცვლად.
4xx/გრძელი რედაქციის უგულებელყოფა, რომელსაც UX აფუჭებს.
გაუმჭვირვალე ფანჯარა (rolling vs კალენდარი) - შედარება „ვაშლი ფორთოხალთან“.

11) iGaming/ფინანსების სპეციფიკა

ფულის გზები (ანაბრები/დასკვნები): ცალკეული SLO აღემატება საერთო დონეს (მაგ., 99. წვდომის 95%; p95-250 ms).
PSP/KYC პროვაიდერები: SLO თითოეული პროვაიდერისთვის + ალერტისთვის მათი წვლილისთვის; მარშრუტების ავტომატური გადართვა.
იურისდიქციები/ტენანტები: SLO და ბიუჯეტები 'region/jurisdiction/brand' ისე, რომ ადგილობრივი პრობლემა არ „დაიტბორა“ გლობალურ მეტრიკაში.
საპასუხისმგებლო თამაში: SLO ლიმიტების/თვითკმაყოფილების გამოყენების დროს (კომპლექსის ფორმულა).
აუდიტი/მარეგულირებელი: შეინახეთ SLO ანგარიშები და ინციდენტები; გამჭვირვალობა შიდა აუდიტისთვის.

12) მზადყოფნის სიის სია

• განსაზღვრულია SLIs (availability/latenty/quality/freshness) და სეგმენტები (მარშრუტი/tenant/region).
• მიზნები (SLO) რეალისტურია, შეთანხმებულია ბიზნესთან; არსებობს rolling ფანჯარა 30/90 დღის განმავლობაში.
• Alerta on burn rate მულტფილმის ფანჯრებით (padging/ticket).
• SLO, როგორც კოდი (წესების გენერატორი/დაშბორდები); ბიუჯეტის ანგარიშები.
• გამოშვებული კარიბჭეები უკავშირდება ბიუჯეტის დანარჩენ ნაწილს; კანარის ნაჭრები.
• დეგრადაციის მექანიზმები (shedder, cache stale, circuit, limites) ხორციელდება და შემოწმებულია.
• მრიცხველების კორელაცია (exemplars), მკაფიო runbooks.
• ფინანსური/იურისდიქციის გზები - ცალკეული SLO/ალერტები; PSP/KYC განუყოფელია.
• რეგულარული რეტრო ინციდენტებზე და ინვესტიციებზე დაფუძნებულ საიმედოობაში.

13) TL; DR

განსაზღვრეთ SLI მომხმარებლის ღირებულებით, დაუსვით რეალისტური SLO და მართეთ Error Budget და burn ფანჯრები მულტფილმის ფანჯრებით. ჩართეთ SLO კოდი, გამოშვებული კარიბჭეები და გეგმის მიხედვით დეგრადაცია. დაგეგმეთ მარშრუტები/ტენანტები/რეგიონები; ფულის ბილიკებისთვის შეინარჩუნეთ უფრო მკაცრი მიზნები და ცალკეული ალერტები.