KPI ინფრასტრუქტურა და აფთიაქი

რატომ გჭირდებათ ეს

KPI ინფრასტრუქტურა სტაბილურობის შესახებ „გრძნობებს“ აქცევს გაზომილ მიზნებად, აკონტროლებს რისკს და მუშაობის ფოკუსს. სწორი მეტრიკა ტექნიკურ SLI- ს აკავშირებს ბიზნეს შედეგებთან (კონვერტაცია, Time-to-Wallet, LTV) და საშუალებას გაძლევთ დაგეგმოთ საიმედოობის ინოვაციების განვითარება, დატვირთვა და წილი.

ძირითადი ცნებები: SLI, SLO, SLA და შეცდომების ბიუჯეტი

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

მაგალითი:

SLO წვდომა 99. 95% 30 დღეში შეცდომების ბიუჯეტი 0. 05% ≈ 21. 6 წუთი „გადაუდებელი“ კალენდარული თვის განმავლობაში.

ოთხი „ოქროს“ სიგნალი და დამატებითი

1. ლატენტობა (p50/p90/p95/p99, tail უფრო მნიშვნელოვანია, ვიდრე საშუალო).
2. შეცდომები (5xx/timeout/ბიზნეს შეცდომები).
3. ტრაფიკი/გამშვები (RPS/QPS, MBps).
4. გაჯერება (CPU/RAM/IO/FD/კავშირი/GC/კვოტები).
გარდა ამისა: ცივი დასაწყისი, რიგები/ბეკლოგი, დეპლოკაციის დრო, SLO შესაბამისობა.

SLI მოდელი სხვადასხვა ტიპის მომსახურებისთვის

HTTP/API

ხელმისაწვდომობა: '(წარმატებული 2xx/3xx - ლოგიკური შეცდომები )/( ყველა მოთხოვნა)'

ლატენტობა: 'p95' წარმატებული მოთხოვნებისთვის; ცხელი მარშრუტების მიზანი.
ხარისხი: მოთხოვნის წილი 'audience/scope' არის სწორი (authZ შეცდომების გარეშე).

რიგები/ასინქრონი

შეტყობინებების დამუშავების დრო: p95 end-end - N წამი.
Backlog: საშუალო <X, კუდი p99 <Y.
მიწოდების შეცდომა: Z ppm.

BD/ქეში

ოპერაციების ლატენტობა: p95 get/put/commit.
გაჯერება: შეკრების აუზი, hit-ratio ქეში.
შეცდომები: Timeouts, deadlocks, eviction storms.

CDN/სტატიკა

Hit Ratio: მიზნობრივი დონე; დეგრადაცია - დატვირთვის ზრდა ორიგინზე.
POP- ის ხელმისაწვდომობა: Anycast განლაგება, უარის თქმას ანაზღაურებენ მეზობლები.

გადახდა (ბიზნეს SLI)

Time-to-Wallet p95, ანაბრის/% -ის წარმატების წარმატება, PSP- ის მარცხი.

ხელმისაწვდომობისა და „აფთიაქის“ გაანგარიშება

მომსახურების ხელმისაწვდომობა = 'წარმატებული მოთხოვნები/ყველა მოთხოვნა "(სასურველია და არა" აფთიაქის წუთი ").
ინფრასტრუქტურული კვანძების ალტერნატივა: „დრო“ მწვანე „/ფანჯრის დრო “.
კალენდარული ფანჯარა: 28-31 დღე, მოცურების ფანჯარა: ბოლო 30/90 დღე.
სამუშაო საათები/კრიტიკული ფანჯრები: backoffice- სთვის, აფთიაქი შეიძლება ჩაითვალოს გრაფიკით (მაგალითად, ადგილობრივი დროით 08: 00-22: 00).

დამოკიდებულების შემადგენლობა (გამარტივებული): თუ სერვისი A დამოკიდებულია B და C- ზე, დამოუკიდებელი უარი:

'Availability (A) - Av (B) × Av (C) × Av (A' B, C) '- მნიშვნელოვანია SLO- ს დაყენება საზღვრებში.

SLO ნაკრების მაგალითი (ნიმუში)

API Gateway: წვდომა 99 ევრო. 95 %/30d; p95 latency - 120 ms; შეცდომა 0. 2%.
Checkout/Payments: ანაბრის წარმატება 98. 5 %/30d; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
მონაცემთა ბაზა: p95 read - 10 ms; p95 write - 25 ms; replica lag p95 ≤ 150 мс.
კეში: hit ratio - 85%; eviction storms = 0/30д.
გადახდები: p95 დამუშავება 5 წუთი; frode falls პოზიტივები 0. 3%.

შეცდომების ბიუჯეტი და ცვლილების მენეჯმენტი

თუ შეცდომების ბიუჯეტი ამოწურულია 50% + -ით ადრე, ვიდრე ფანჯრის შუაში - შემოღებულია fich/გამოშვებების გაყინვა, სტაბილიზაციის ყურადღება გამახვილებულია.
თუ ბიუჯეტი ნელა იხარჯება, შეგიძლიათ დააჩქაროთ ექსპერიმენტები/კანარები.
ბიუჯეტის მოხმარება დაკავშირებულია კონკრეტულ გამოშვებებთან/ინციდენტებთან 'release _ id' საშუალებით.

ალერტინგი: როგორ არ „დარეკოთ ღამით“ უშედეგოდ

ალერტები მხოლოდ SLO დეგრადაციისა და სასიცოცხლო სიმპტომების მიხედვით, და არა ყველა მეტრიკისთვის.
Multi window, multi-burn: მოკლე ფანჯარა (5-15 წთ) + გრძელი (1-6 საათი).
მაგალითი: „Burn rate 14 5 წუთში და 6 × 1 საათში“ - გვერდი on-call.
მშვიდი საათი არა-P1 სიგნალისთვის; პასუხისმგებლობის მარშრუტიზაცია (ownership).

დაშბორდები და ვიზუალიზაციის პრაქტიკა

SLO პანელი: შესაბამისობა სერვისებზე, დარჩენილი ბიუჯეტი, დამოკიდებულების ბარათები.
Latency პანელი: p50/p90/p95/p99, დაშლა მარშრუტებზე/ტენანტებზე/ქვეყნებში/ASN.
Error პანელი: კოდი/მიზეზები, კორელაცია გამოშვებებთან/ფიჩფლაგებთან.
Capacity პანელი: CPU/RAM/IO/network/FD/კონექტორები, ტენდენციები და პროგნოზები.
ბიზნეს პანელი: კონვერტაცია, დრო-ვალეტი, ანაბრები/დასკვნები, დაცვის გავლენა (WAF/ანტიბოტი).

ინციდენტები, MTTR და პოსტმორტემები

KPI რეაქციები:

MTTD (აღმოჩენა), MTTA (აკეპტი), MTTR/MTTC (აღდგენა/შეკავება), RCA- ს გარეშე ინციდენტების%.
ფლეიბუკი: ვინ ესკალაციას ახდენს, თუ როგორ უნდა ჩართოთ ფიჩფლაგები/ბლოკები, როგორ გადააგდოთ გამოშვება, კომუნიკაცია ბიზნესთან.
პოსტმორტემი: ფაქტები, დროის ხაზი, ძირითადი მიზეზები (ეს/პროცესები), მოქმედებები: დაუყოვნებელი/გრძელვადიანი, რეგრესიის ტესტები, გავლენა SLO- ზე.

შესრულება, გაჯერება და დეგრადაცია

Headroom: რესურსების მიზნობრივი მიწოდება (მაგალითად, CPU <70% p95, RAM <75% p95).
Hot paths: კრიტიკული მარშრუტების პროფილირება; 'p99' საშუალოზე უფრო მნიშვნელოვანია.
Degradation modes: მხოლოდ ქეში, read-only, ცუდი მოთხოვნების გაპრიალება, „განაკვეთების შეზღუდვა „/კვოტები.

ფორმულები და გამოთვლების მაგალითები

1) ხელმისაწვდომობა მოთხოვნით


availability = (total_requests - error_requests) / total_requests

სადაც 'error _ requests' = 5xx + timeouts + ბიზნეს შეცდომები (კონფიგურაცია).

2) შეცდომების ბიუჯეტი (წუთი)


error_budget_minutes = window_minutes (1 - SLO)

მაგალითი: 30 დღე (43.200 წთ), SLO 99. 95% → 21. 6 წთ

3) Burn rate


burn_rate = observed_error_ratio / (1 - SLO)

თუ SLO 99. 9% (ბიუჯეტი 0. 1%), ხოლო შეცდომა 1% -ში არის burn _ rate = 10 ×.

4) მნიშვნელოვანი წვდომა


A_total ≈ A_gw × A_auth × A_db × A_psp

მცირე დაცემები მულტიპლიკაციურად სცემეს A.

გაზომვისა და გამონაკლისის პოლიტიკა

მხედველობაში მიიღება დაუგეგმავი ფანჯრები (ინციდენტები).
დაგეგმილი მომსახურების ფანჯრები გათვალისწინებულია მხოლოდ იმ შემთხვევაში, თუ SLA ასე არის რეგისტრირებული; SLO- სთვის, ისინი ხშირად არ იკლებენ (ან ცალკე აღინიშნება, როგორც 'planned _ downtime').
სინთეზური vs რეალური მომხმარებლები: სასარგებლოა ორივე არხის არსებობა (RUM + სინთეზური შემოწმება).

არტეფაქტების მაგალითები

KQL/PromQL (იდეები)

SLI შეცდომა (5xx + timeouts) 5 წუთში:

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

p95 latency по route:

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Burn rate 5m/1h:

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (ბიზნეს SLI გადახდაზე)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

დამოკიდებულებისა და კასკადების მართვა

SLO კონტრაქტები გუნდებს შორის: gateway - auth - wallet - PSP.
Degradation policies: დამოკიდებულების ვარდნისას, მომსახურება გადადის „გამარტივებულ რეჟიმში“.
Feature flags: არაკრიტიკული ფუნქციების გამორთვა, „ნაცრისფერი გამოშვება“ ლატენტობის კუდის შესამცირებლად.

Capacity Planning და პროგნოზები

შჩომესი. RPS/MBps- ის პროგნოზი ტენდენციებისა და მოვლენების შესახებ (ტურნირები, მატჩები, აქციები).
Load ტესტირება „ოქროს ბილიკებზე“, ცალკეული ტესტები PSP/გადახდებისთვის.
რეზერვი მწვერვალზე: სამიზნე კოეფიციენტი 1. 3×–2. 0 × მოსალოდნელი დატვირთვიდან.

SLO/KPI განხორციელების შემოწმების სია

1. განსაზღვრეთ კრიტიკული მომხმარებლის გზები და შეთანხმდით SLI- ზე „კლიენტის თვალსაზრისით“.
2. შეარჩიეთ SLO და ფანჯარა (30/90 დღე); შეცდომების ბიუჯეტის დათვლა.
3. ჩასვით მეტრიკის შეგროვება კარიბჭეებში/სერვისებში, კოდების/მიზეზების ნორმალიზება.
4. Burn-rate- ის ალერტას კონფიგურაცია (მოკლე + გრძელი ფანჯარა), მარშრუტიზაცია და on-call.
5. ვიზუალიზაცია SLO შესაბამისობასთან, დაკავშირება გამოშვებებთან/ფიჩფლაგებთან.
6. დაიწყეთ „ბიუჯეტის წინააღმდეგ ცვლილებების“ პოლიტიკა და გაყინვის პროცესი.
7. რეტროსპექტივები და RCA თითოეული გადამეტებისთვის, რეგრესიის ტესტები.
8. კვარტალურად გადაამოწმეთ SLO ბიუჯეტის და ბიზნეს მიზნების ფაქტობრივი გამოყენების შესახებ.

ტიპიური შეცდომები

ისინი იზომება „Ping Aptime“, განაცხადის შეცდომების უგულებელყოფით.
SLO გამოიფინა „რეზერვზე“ (99. 999%), მაგრამ მიუწვდომელი და არ წყვეტს არაფერს.
ალერტები დაბალი დონის მეტრებში, მომხმარებლის სიმპტომების ნაცვლად.
არ არსებობს დამოკიდებულების რუკა, უცნობია სად იწვის.
არ არსებობს კავშირი SLO- ს გამოშვებებთან - უცნობია ვინ „შეჭამა“ ბიუჯეტი.
P99 კუდის უგულებელყოფა არის კარგი საშუალო, მაგრამ ცუდი UX VIP მომხმარებლები.

სპეციფიკა iGaming/fintech

გრაფიკის მწვერვალები: მატჩები/ტირიფები/მოქმედებები - წინასწარ გაზარდეთ capacity, გაათბეთ ქეში/CDN, ჩართეთ სპეციალური ლიმიტის პროფილები.
Business SLI: Time-to-Wallet, ანაბრის/გამოსვლის წარმატება, p95 „გადახდის სიჩქარე“; Dashbords- ის ძირში.
PSP/პარტნიორები: ინდივიდუალური SLO/დაშბორდები პროვაიდერების გასწვრივ, მარშრუტების ავტომატური გადართვა.
ანტიბოტი/ანტიფროდი: შეცდომების ბიუჯეტი არ უნდა ჭამოს - გამოყავით „იურიდიული ბლოკები“ „ტექნიკური შეცდომებისგან“.
მარეგულირებელი: ჟურნალების შენახვა, SLO/SLA გამოთვლების რეპროდუქცია, ინციდენტების შესახებ მოხსენებები.

FAQ

საჭიროა თუ არა SLO- სგან დაგეგმილი სამუშაოების გამოკლება?
ჩვეულებრივ, არა: SLO ასახავს მომხმარებლის გამოცდილებას. SLA- სთვის, გამონაკლისების დადგენა შეგიძლიათ.

რატომ p95 და არა საშუალო?
შუა შენიღბავს კუდებს; UX განსაზღვრავს კუდებს (p95/p99).

შესაძლებელია თუ არა ერთი SLO მთლიანი პროდუქტისთვის?
ჩვენ გვჭირდება SLO ხე: პროდუქტის აგრეგატი და შვილობილი კომპანია კრიტიკულ მარშრუტებში/კომპონენტებში.

შედეგი

KPI ინფრასტრუქტურის ძლიერი სისტემაა მომხმარებლის SLI, რეალისტური SLO, შეცდომების ბიუჯეტი, როგორც ბერკეტი, ჭკვიანი ალერტინგი და ინციდენტების დისციპლინა და RCA. დააკავშირეთ ტექნიკური ინდიკატორები ბიზნეს მეტრებთან, ავტომატურად შეაგროვეთ და ვიზუალიზაცია - და ინფრასტრუქტურა გახდება პროგნოზირებადი, ხოლო აფთიაქი კონტროლდება პიკის სცენარებშიც კი.