ოპერაციები და Metrica- ს შესრულების მენეჯმენტი

შესრულების მეტრიკა

1) რატომ გვჭირდება შესრულების მეტრიკა?

• ინციდენტებამდე დეგრადაციის გამოვლენა,
• პროგნოზირება შესაძლებლობები და ბიუჯეტი,
• ალტერნატიული გადაწყვეტილებების შედარება (ქეში BD, gRPC vs REST),
• განთავისუფლების შემდეგ რეგრესიების მართვა.

პრინციპები: ერთი მეტრიკის ლექსიკონი, percentils- ის შეკრება (p50/p90/p95/p99), „ცხელი“ და „ცივი“ ბილიკების ცალკეული აღრიცხვა, კონტექსტი (ვერსია, რეგიონი, პროვაიდერი, მოწყობილობა).

2) მეტრიკის ტაქსონომია

2. 1 ძირითადი SRE ჩარჩო

ოთხი ოქროს სიგნალი: Latency, Traffic, Errors, Saturation.
RED (მიკრო სერვისებისთვის): Rate, Errors, Duration.
USE (რკინისთვის): Utilization, Saturation, Errors.

2. 2 დონე

ინფრასტრუქტურა: CPU, RAM, დისკი, ქსელი, კონტეინერები, კვანძები.
პლატფორმა/სერვისები: API endpoints, რიგები, ქეში, BD, ღონისძიების საბურავები.
კლიენტის გამოცდილება: ვებ ვიტალები, მობილური SDK, ნაკადი, CDN.
მონაცემთა პლატფორმა: ETL/ELT, ნაკადები, ფანჯრები, BI შეფერხებები.
ბიზნეს კრიტიკული ფლეშ: ავტორიზაცია, KYC, ანაბრები/გადახდები, თამაშის რაუნდი.

3) საკვანძო მეტრიკის და ფორმულების კატალოგი

3. 1 API და მიკრო სერვისები

RPS (Requests per second).
latency p50/p95/p99 (ms) - სასურველია „end-to-end“ და „backend-only“.
Error Rate (%) = 5xx + ვალიდირებული 4xx/ყველა მოთხოვნა.
Saturation: ვორკერების რიგის საშუალო სიგრძე, „ფრენის“ მოთხოვნა.
Cold Start Rate (FaaS- ისთვის).
Throttling/Dropped Requests.

SLO მაგალითი: p95 ლატენტობა 250 მმ RPS- ით 2k- მდე EU-East- ის რეგიონში; შეცდომები 0. 5%.

3. 2 მონაცემთა ბაზა

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (რეპლიკაცია), Checkpoint/Flush time, Autovacum lag.
Hot Keys/Skew - ტოპ N დატვირთვის გასაღებები.

ბირთვის მოთხოვნის ფორმულა: QPS/vCPU _ core _ count - შარდვის სიგნალი.

3. 3 კეში და CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 რიგები/ნაკადები

Ingress/egress msg/s, Consumer Lag (შეტყობინებები/დრო), Rebalance rate.
Processing Time p95, DLQ Rate.

3. 5 ინფრასტრუქტურა/კონტეინერები

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 ვებ კლიენტი (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency (პერცენტილი).

3. 7 მობილური კლიენტი

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline success rate (ქეშირებული ოპერაციები).

3. 8 მონაცემთა პლატფორმა და მოხსენებები

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Cost per TB processed, წვეულებებზე Skew, გვიან მოვლენები%.
BI Time-to-Render p95 ძირითადი დაშბორდებისთვის.

3. 9 დომენის კრიტიკული ფლეშ (iGaming, როგორც მაგალითი)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) ნორმალიზაცია, წინსვლა და ატრიბუტი

ჩვენ ვდგავართ საშუალოზე: ვაღიარებთ p50/p90/p95/p99 - საშუალო აურზაური პიკის ტკივილს.
განყოფილებები: პროგრამის ვერსია, რეგიონი, პროვაიდერი, ქსელის არხი (4G/Wi-Fi), მოწყობილობა.
კორელაცია: ჩვენ ვუკავშირებთ „backend-only“ და „real-user“ მეტრიკას მიზეზობრივი ჯაჭვებისთვის.
Exemplars/Traces: ჩვენ უკიდურეს წინსვლას ვუკავშირებთ ტრეკებს.

5) ბარიერები და ალერტები (სავარაუდო ბადე)

Latency p95 (core API): warning> 250 ms, critical> 400 ms ზედიზედ 5 წუთი.
Error rate: warning > 0. 5%, კრიტიკული> 2% (ენდოინტის მიხედვით, არა გლობალურად).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

ჩვენ ვიყენებთ სტატიკურ + ადაპტირებულ ბარიერებს (სეზონურობა, დღის შაბლონები), დედუპლიკაცია და ალერტების ჯგუფი სერვისების/გამოშვებების მიხედვით.

6) შესრულების ტესტირება

ტიპები: ბასელინი, სტრესი, გრძელი (soak), ქაოსი (degrade links/PSP).
დატვირთვის პროფილები: რეალურ ტრასებზე (distribution-based), „bursts“, რეგიონალური მწვერვალები.
მიზნები: SLO- ს მიღწევა მიზნობრივი RPS და mix ოპერაციებში, backpressure- ის შესაბამისობა.
პროგონის მეტრიკა: Throughput, Error%, p95 latency, GC პაუზები, CPU throttle, queue lag, cost/run.

რეგრესიების წესი: გამოშვება წარმატებულად ითვლება, თუ p95 არ გაუარესდება> 10% თანაბარი პროფილით, ხოლო მოთხოვნის ღირებულება (CPU-ms/მოთხოვნა) არ გაიზარდა> 15%.

7) კონტეინერის დაგეგმვა და ფასი/პროდუქტიულობა

Demand მოდელი: RPS საათებში × საშუალო სამუშაო/მოთხოვნა (CPU-ms, IO-ops).
Headroom: სარეზერვო 30-50% კრიტიკული ბილიკებისთვის, P95 ავტო სკალირება.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. LCP გაუმჯობესება.
ქეშირება/დენორმალიზაცია: ჩაითვალოს „cache ROI“ = (დანაზოგი CPU-ms არის ქეშის ღირებულება).
თბილი და ცივი რეგიონები: offload CDN/edge, რეპლიკაცია „მხოლოდ კითხვა“.

8) დაკვირვებისა და პროფილის პრაქტიკა

ტრეკები: განაწილებული trace-ID ყველა ჰოპის საშუალებით; ჭკვიანი ნიმუში (tail-based).
მეტრიკა: Prometheus/OpenTelemetry, სახელებისა და ეტიკეტების ერთიანი ნოტაცია.
Logs: trace/span- ის კორელაციით, budget ხმაურით, PII რედაქტირება.
პროფილაქტიკა: CPU/Heap/Alloc/Lock profiles, უწყვეტი პროფილირება (eBPF).
ნიმუშების ნიმუშები: ჩვენ ვუკავშირებთ p99 აურზაურს კონკრეტულ span/SQL/PSP კოლოფთან.

9) გამოშვებებისა და ბრძანებების მეტრიკა (სისრულისთვის)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
SPACE: კმაყოფილება, შესრულება, აქტივობა, კომუნიკაცია, ეფექტურობა.
ეს მეტრიკა არ ეხება რკინას, მაგრამ პირდაპირ გავლენას ახდენს პროდუქტიულობის სტაბილურობაზე.

10) ანტი შაბლონები

საშუალო დევნა: p95/p99 უგულებელყოფა.
„გლობალური“ ერორი: მალავს მტკივნეულ ენდოინტებს.
ვერსიების მიხედვით ატრიბუტის გარეშე: შეუძლებელია კლიენტის რეგრესიის დაჭერა.
ალერტ სპამი: ზღურბლები ჰისტერეზის გარეშე და სეზონური კორექტირება.
„ბრმა“ ოპტიმიზაცია: პროფილის და ტრეკების არარსებობა.
UX და დაბალანსებული ლატენტობის ნაზავი: არასწორი დასკვნები კლიენტის გამოცდილებაზე.

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

ერთი მეტრიკის სტანდარტი

• მეტრული ლექსიკონი ფორმულებით, ერთეულებით, მფლობელებით
• სავალდებულო p50/p90/p95/p99
• სავაჭრო კორელაცია და ლოგიკური კორელაცია
• ჭდეები: რეგიონი, ვერსია, პროვაიდერი, მოწყობილობა, ქსელის არხი
• ზღურბლები ჰისტერეზით და დედუპლიკაციით

გამოსვლამდე

• Bazline p95/p99 stage და გაყიდვა
• კანარის ტრაფიკი + მეტრული A/B შედარება
• Fich დროშა სწრაფი გამოტოვებით
• სათვალთვალო გეგმა (observability runbook)

რეგულარულად

• ყველაზე ნელი ტოპ N მოთხოვნის რეპროდუქცია/SQL
• ქეშის პოლიტიკის აუდიტი და TTL
• Freshness- ის შემოწმება და მონაცემთა ბაზის რეპლიკები
• გარე პროვაიდერების დეგრადაციის ტესტები (PSP, KYC)

12) მინი ფლეიბუკები (მაგალითი)

p95/app/payments დეგრადაცია

1. შეამოწმეთ error% და გარე Timauts PSP.
2. შეამოწმეთ კოლბეკის რიგები.
3. P99 მაგალითების სანახავად: SQL/HTTP ვიწრო ადგილი?
4. ჩართეთ საცნობარო წიგნების/ლიმიტების ქეში, შეამციროთ N + 1.
5. ბიუჯეტი: დროებით გაზარდეთ ვორკერის რესურსები 20% -ით, ჩართეთ autoscale.
6. Post-fix: ინდექსი (psp _ id, status, created _ at), retray-gitter.

RepLag ზრდა BD- ში

1. შეამოწმეთ „მძიმე“ მოთხოვნები და გრძელი გარიგებები.
2. გაზარდეთ რეპლიკაციის პარალელიზმი, გადაიტანეთ checkpoint.
3. Offload კითხულობს ქეში/შენიშვნებს მხოლოდ კითხვას.
4. პიკის ფანჯრებზე - ნაწილობრივი დენორმი + ბატჩი.

13) ფორმულების/SQL მაგალითები (გამარტივებული)

Error Rate ენდპოინტში

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Consumer Lag (დრო)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) დაშბორდები და ანგარიშგებები

KPI ბარათები: p95 latence, error%, RPS, saturation WoW/DoD ტენდენციებით.
ტოპ N „ყველაზე უარესი“ ენდოინები/SQL/რესურსები, clicabel drill-down-trace.
კლიენტის ვერსიების კორელაცია: გრაფიკი „p95 LCP/INP კონვერტაცია“.
მსოფლიო რუკა: geo-latence (CDN), PSP latence რეგიონებში.
SLO პანელი: დროის წილი SLO- ში, გამგზავრება SLO- სგან, „შეცდომების ბიუჯეტი“.

15) შედეგები

შესრულების მეტრიკა არის სისტემური დისციპლინა: ერთი ლექსიკონი, გადაჭარბებული, ატრიბუტი, კარგი დაკვირვება და მკაცრი SLO. ტექნიკური (ლატენტობა, ლატენტობა, ქეშის ჰიტები) და სასურსათო სიგნალები (KYC დრო, ანაბარი p95, LCP), თქვენ აკონტროლებთ გამოცდილების ხარისხს და მისი მიწოდების ღირებულებას - პროგნოზირებადი და მასშტაბური.