SLA, SLO და KPI საიმედოობა

1) ტერმინები და განსხვავებები

SLI (Service Level Indicator) - გაზომილი ხარისხის ინდიკატორი (მაგალითად, წარმატებული მოთხოვნების წილი, p95 ლატენტობა).
SLO (Service Level Objective) - SLI- ს მიზნობრივი მნიშვნელობა დროის ფანჯრისთვის (მაგალითად, „წარმატება“ 99). 9% 28 დღეში").
ბიუჯეტის შეცდომა (Error Budget) არის SLO შეუსრულებლობის დასაშვები წილი: '1 − SLO'.
SLA (Service Level Agreement) - სახელშეკრულებო ვალდებულებები ჯარიმებით/სესხებით (გარე).
KPI საიმედოობა - პროცესის ოპერაციული მეტრიკა (MTTD/MTTA/MTTR/MTBF, ავტომატური მიტიგიტების%, ალერტების დაფარვა და ა.შ.).

2) როგორ ავირჩიოთ SLI (Golden Signals- ის საფუძველზე)

1. Latency - p95/p99 ძირითადი endpoints.
2. Traffic - RPS/RPM/შეტყობინებების ნაკადი.
3. Errors არის 5xx/ბიზნეს შეცდომების წილი (მაგალითად, გამორიცხეთ გადახდის „decline PSP“).
4. სატურნა - რესურსების გაჯერება (CPU/RAM/IO/lag).

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

3) ფორმულები და მაგალითები

3. 1 წვდომა (წვდომა)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

მაგალითი: SLO 99. 9% 30 დღეში - შეცდომების ბიუჯეტი = 0. 1%, რაც ექვივალენტურია 43 წთ 12 წამი მიუწვდომლობა.

3. 2 ლატენტობა

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 გადახდა (ბიზნესის დონე)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) მცდარი ბიუჯეტი და ბურნი

ბიუჯეტის შეცდომა არის თქვენი „საწვავის ავზი“ ინოვაციებისთვის (გამოშვებები, ექსპერიმენტები).

• სწრაფი არხი (დეტაჟი 1 საათში),
• ნელი არხი (ტენდენცია 6-12 სთ/24 სთ).

• თუ burn-rate> 14. 4 საათში 1 საათში - SEV-1 (ჩვენ ვჭამთ დღის ბიუჯეტს 100 წუთში).
• თუ burn-rate> 6 საათში - SEV-2 (სწრაფი დეგრადაცია).

5) Alerting on SLO (multi window, multi-burn)

შეცდომების ინდიკატორი: 5xx წილი ან ლატენტობის დარღვევა.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLI/SLO დომენების მაგალითები

6. 1 API კარიბჭე/Edge

SLI-Errors: პასუხების წილი 5xx <0. 1% (28d).
SLI-Latency: p95-250 ms (დღე).
SLO: Availability ≥ 99. 95% (კვარტალი).

6. 2 გადახდა

SLI-Success: წარმატებული გადახდა (კლიენტის უარის თქმის გამოკლებით) 99 ევრო. 8% (28d).
SLI-Latency: ავტორიზაცია - 2 წამი 99% (დღე).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 მონაცემთა ბაზა (PostgreSQL)

SLI-Lag: რეპლიკაციის ლაგი p95-1 წამი (დღე).
SLI-Errors: მოთხოვნის შეცდომების წილი 0. 05% (28d).
SLO: კლასტერის ხელმისაწვდომობა 99. 95%.

6. 4 ფაზა/ნაკადი (კაფკა)

SLI-Lag: სამომხმარებლო lag p95-N შეტყობინებები (საათი).
SLI-Durability: ჩაწერის დადასტურება 99. 99% (28d).
SLO: ბროკერების ხელმისაწვდომობა 99. 9%.

7) KPI საიმედოობის პროცესი

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

ინციდენტების% ავტომატური მიტინგით

SLO/Alerts დაფარვა ტრაფიკის საუკეთესო მარშრუტებით (სამიზნე 95%)

კანარის ეტაპის გამოშვებების წილი

არასწორი ბიუჯეტის მოხმარება გუნდებისთვის/ფინიკისთვის

8) როგორ დავაყენოთ SLO რეალისტური

1. გაზომეთ მიმდინარე ძირითადი საიმედოობა (3-4 კვირა).
2. განსაზღვრეთ „მგრძნობიარე“ მომხმარებლის გზები (ლოგინი, ანაბარი, თამაში).
3. გაითვალისწინეთ თითოეული დევიზის ღირებულება (დრო, ფული, რეპუტაცია).
4. შეარჩიეთ ამბიციური, მაგრამ მიღწეული მიზანი (საბაზო 10-30% -ით გაუმჯობესება).
5. გადახედეთ კვარტალურად.

• დაუყოვნებლივ „ხუთი გოგონა“ დასაბუთების გარეშე.
• SLO მეტრიკებში, რომლებიც მომხმარებლისთვის არ ჩანს (მაგალითად, CPU UX- სთან კავშირის გარეშე).
• ძალიან ბევრი SLO არის ფოკუსის სპრეი.

9) ანგარიშები SLO და ბიუჯეტებზე

• თითოეული SLO- ს შესრულება: მიზანი, ტენდენციები, კონფიგურაცია.
• შეცდომების მოხმარების შეჯამება: რამდენი ბიუჯეტი „დაიწვა“, ვიდრე ვინ (გამოშვება/ინციდენტი).
• დეგრადაციის ხუთი მიზეზი, CAPA გეგმა და დავალებების სტატუსი.
• გავლენა ბიზნესზე: კონვერტაცია, ND, გამართვა, LTV.

10) კომუნიკაცია გამოქვეყნებულ პოლიტიკასთან

შეცდომის ბიუჯეტი <50% - უფასო გამოშვებები.
50-80% არის „ფრთხილი რეჟიმი“: მხოლოდ დაბალი დონის/კანარის გამოთვლები.

11) SLA (სახელშეკრულებო) - პუნქტის შაბლონები

ხელმისაწვდომობის ვალდებულება: მაგალითად, 99. 9 %/თვე.
გამონაკლისები (Force Majeure): DDoS გონივრული კონტროლის მიღმა, მესამე მხარის პროვაიდერები.
გაზომვის ფანჯარა და პასუხისმგებლობის სფერო: მეტრიკის წყაროები, გაანგარიშების მეთოდი.
სესხები/ჯარიმები: დონის ცხრილი (მაგალითად, მიუწვდომლობა 60-120 წუთი - სესხი X%).
ესკალაციისა და შეტყობინებების პროცედურები: ვადები, არხები.
მონაცემები და კონფიდენციალურობა: შენიღბვა, შენახვა, იურიდიული ჰოლდი.
გამეორების პრევენციის სამუშაო გეგმა (CAPA) დარღვევის შემთხვევაში.

12) გაზომვის ინსტრუმენტები

პასიური მეტრიკა: Prometheus/Mimir/Thanos, ექსპორტიორები.
Loki/ELK ბიზნესის დონეზე წარმატების/შეცდომების გამოსათვლელად.
სინთეზური: აქტიური ნიმუშები (ლოგინი/ანაბარი/თამაში) cron.
ტრეკი: Tempo/Jaeger p99 „ვიწრო ადგილებისთვის“.
გადახდა/ფინანსები: გადახდის SLI გზავნილის წყაროები.

13) შეკითხვის მაგალითები (შაბლონები)

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

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps და საიმედოობა

Cost per 9: „ცხრა“ დამატების ღირებულება ექსპონენტურად იზრდება.
სარგებლის მრუდი: ოპტიმალური, სადაც შემოსავლის ზრდა/ზარალის შემცირება დამატებითი „9“ ღირებულებაა.
SLO პორტფელი: სხვადასხვა დონის სხვადასხვა გზა (კრიტიკული გადახდები „უფრო ძვირია“, ანგარიშები „იაფია“).

15) SLO/ალერტის ხარისხი - ჩეკის სია

• SLI კორელაციას უწევს UX და ბიზნეს მეტრებს.
• ფანჯარა და დანერგვა შეთანხმებულია (rolling 28d/კვარტალი).
• Alerty multi window, flapping გარეშე, როლური მარშრუტიზაციით.
• დოკუმენტაცია: მფლობელი, ფორმულა, წყაროები, runbook.
• SLO დემო პანელი მცდარი ბიუჯეტით და ბურნის ინდიკატორებით.
• მიზნების რეგულარული განხილვა (კვარტალურად).
• სინთეზის ტესტები მთავარი სცენარების მიხედვით.

16) განხორციელების გეგმა (4 გამეორება)

1. კვირა 1: მომხმარებლის ბილიკების ინვენტარიზაცია, SLI მონახაზები, ძირითადი დაშბორდები.
2. კვირა 2: SLO ფორმალიზაცია, ბიუჯეტის გაანგარიშება, ალერტები (სწრაფი/ნელი ბურნი).
3. კვირა 3: ინციდენტების/გამოშვების პროცესთან ინტეგრაცია, უფასო წესები.
4. კვირა 4 +: სახელშეკრულებო SLA, კვარტალური შურისძიება, „cost per 9“ - ის ფინჯანი მოდელი.

17) მინი-FAQ

გჭირდებათ ერთი SLO მომსახურებაზე?
უკეთესია 2-3 ძირითადი (წარმატება + ლატენტობა) ათეულობით მეორეხარისხოვანი ნაცვლად.

რა უნდა გავაკეთოთ, თუ ბიუჯეტი ამოწურულია?
გამოშვების გაყინვა, სტაბილიზაციის ფოკუსირება და CAPA, ექსპერიმენტული ფიგურების ამოღება.

როგორ ავიცილოთ კონფლიქტი გათავისუფლების სიჩქარესა და საიმედოობას შორის?
დაგეგმეთ „ბიუჯეტის შესახებ“ გამოშვებები, შემოიღეთ კანარის გამოთვლები და feature-flags.

შედეგი

საიმედოობას აკონტროლებს არა მიმოფანტული მეტრიკის ერთობლიობა, არამედ სისტემა: SLI - SLO - ბიუჯეტის შეცდომა - burn-alerting, ინციდენტების პროცესი - CAPA - SLA. სტანდარტიზებული განმარტებები, მონაცემთა წყაროები და ანგარიშგებები, მიიპყროთ მიზნები მომხმარებლის გამოცდილებასა და ეკონომიკაში და რეგულარულად გადახედეთ „გოგონების“ დონეს, დამოკიდებულია რეალურ ROI- ზე.