SLO/SLA və metrika

SLO/SLA və metrika

1) Terminlər və iyerarxiya

SLI (Service Level Indicator) - ölçülə bilən göstərici «istifadəçinin bizi gördüyü kimi»: uğurlu sorğuların payı, p95 gecikmə, məlumatların təravəti, uğurla işlənmiş batchların payı və s.
SLO (Service Level Objective) - müşahidə intervalında (28/30/90 gün) SLI hədəf dəyəri. Nümunə: "99. 9% sorğu/pay ≤ 400 ms" tamamlanır.
Error budget — 1 − SLO. SLO 99 ilə. 9% büdcə səhvləri = 0. 1% vaxt/sorğu.
SLA (Agreement) - hüquqi əhəmiyyətli xidmət səviyyəsi: SLO, ölçmə, istisnalar, kompensasiya/cərimələr daxildir.

2) Dizayn prinsipləri

Simptomlar> daxili metriklər. SLI real istifadəçi təcrübəsini əks etdirməlidir.
Kiçik sayda açar SLI. Xidmət üçün - 2-5 əsas: müvəffəqiyyət, gizlilik, tutum/təravət, düzgünlük.
Kritik yolların əhatə dairəsi. Hər bir iş ssenarisi üçün (checkout, login, webhook, ETL-download) - SLI/SLO seti.
"Uğur 'un ciddi semantikası. «Kod 200» deyil, «istifadəçi vaxtında cavab aldı və nəticə validen».
Xarici və daxili SLO-ların ayrılması. Daxili - daha sərt; aşağıda 1-2 doqquz xarici SLA ≤.

3) SLI kataloqu (istinad)

3. 1 API/onlayn xidmətlər

Uğur: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Gizlilik: p95/p99 'http _ server _ duration _ seconds' marşrutlar/metodlar/kirayəçilər üzrə

Bant genişliyi: 'RPS '/limitlər/kvotalar

Düzgünlük: etibarlı cavabların payı (işarələr, sxemlər, invariantlar)

3. 2 Webhook/Asenxron çatdırılma

Çatdırılma: T saniyə və ≤ N retrains təsdiqlənmiş hadisələr payı

Müştərilər: uzun gecikmədən abunəçilərin payı (per-tenant)

3. 3 Data/ETL/DWH

Təravət (freshness): 'now − last_successful_ingest_ts'

Doluluq: 'ingested _ rows/ expected_rows'

Düzgünlük: keyfiyyət yoxlamasından keçmiş qeydlərin payı

Payplayns: son tarixə qədər tamamlanmış job payı

3. 4 Mobil/müştəri SDK

Müştəri uğuru: ölümcül səhvlər olmadan seansların payı

Round-trip latentliyi: render üçün sorğudan p95

Cash Hits: Cache xidmət payı (performans simptom kimi)

4) Formullar və hədəf nümunələri

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% '30 gün → error budget = 0. 05% sorğu.

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

• ' SLO _ latency = p95 (route = »/pay») ≤ 400 ms' 7 günlük kəsiklərdə, cache istiləşmələri istisna olmaqla (1%)

• ' SLO _ freshness (dataset =» orders») ≤ 10 min' p99 24 saat ərzində.

5) Error budget və dəyişiklik idarə

Büdcə (B): 'B = 1 − SLO'.
Büdcə xərcləri (burn): faktiki səhvlərin icazə verilənlərə nisbəti.

• Artıq istehlak (burn> 1) → fichfriz, etibarlılığa diqqət.
• burn rate> X qısa pəncərədə - hadisə və kapitan. tədbirlər.
• Planlaşdırma: Sprintin etibarlılıq payı ötən dövr üçün burn ilə əlaqələndirilir.

6) Alerting: burn rate və çox pəncərəli qaydalar

Fikir: sürətli sızmalar və yavaş sürüklənmə.

• Kritik: «1 saat ərzində büdcənin 2% -i» (sürətli yanğın).
• Xəbərdarlıq: «6 saat ərzində büdcənin 5% -i» (sürünən deqradasiya).

• Sürətli hadisələr üçün qısa pəncərə (dəqiqə-saat).
• trendlər üçün uzun pəncərə (6-24 saat).
• Gecikmə: p99> astanası 5 dəq, flapping və trass ilə əlaqə.

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) Multi-tenant və seqmentasiya

SLI/SLO icarədarlar/planlar/regionlar üzrə hesab olunur, əks halda media uğursuzluqları «örtəcək».
Statistik əhəmiyyət üçün minimum hadisə sayı (guard-rails).
SLA tarifləri (məsələn, "Pro 99. 9%, Free 99. 5%»).

8) Müşahidə və izləmə ilə əlaqə

SLI metrikası - exemplars ilə histoqramlardan/sayğaclardan → «pis» treyslərə keçid.
Loglar səbəblərin mənbəyidir: taymautlar, biznes səhv kodları, limitlər.
Məlumatlar üçün - lineage ilə bir dəstə: «hansı coba təravət metrikasını gecikdirdi».

9) Müqavilələr və SLA

• SLI/ölçü metodu/pəncərə tərifləri.
• İstisnalar (planlı işlər, fors-major).
• Hadisə və kommunikasiya proseduru (status-səhifə, RFO/RCA).
• Kompensasiya (service credits) və sorğu proseduru.
• Yurisdiksiya, fəaliyyət müddəti, yenidən baxılma şərtləri.

• Heç vaxt açıq şəkildə SLO-ya memarlıq və əməliyyat təcrübələrindən daha sərt söz verməyin.
• Daxili SLO və xarici SLA-ları ayırın.

10) Qiymət və prioritetləşdirmə

Doqquzların qiyməti xətti artmır. «99. 9% → 99. 99%" = fərqli bir memarlıq sinfi (N + 1, multizon, aktiv-aktiv).
SLO-ları ən dəyərli istifadəçi hərəkətlərinə qoyun.
Telemetriyanın qiymətinə nəzarət edin: downsampling, kvotalar, replika və siniflər üzrə saxlama.

11) Prosedurlar və hesabatlar

Həftəlik hesabatlar: xidmətlər/kirayəçilər üzrə SLO-nun icrası, büdcə xərcləri, top səbəblər, təkmilləşdirmə planları.
Post-insident RCA: büdcə parçaları ilə əlaqələndirmək; əsas səbəbləri aradan qaldırmaq üçün vəzifələr qoyuruq.
Fichfries: daxil/çıxarılma meyarları.

12) Şablonlar (sürətli başlanğıc üçün)

12. 1 SLO kartı (nümunə)

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 yetkinlik» cədvəli

13) Qaydaların nümunələri (fraqmentlər)

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) Məlumat və ML üçün SLO (xüsusiyyətləri)

Keçən SLO məlumatları: p99 təzəliyi, p99 tamlığı, uğursuzluqdan sonra «yenidən işləmə» vaxtı.
Məlumat müqavilələri: gözlənilən sxemlər, həcmlər, müddətlər; pozulması → insident məlumat.
ML: SLA, SLA, SLA xaricində (model keyfiyyəti - ayrı mövzu).

15) Təhlükəsizlik və məxfilik ilə inteqrasiya

PII/sirləri olmadan SLI log; tokenizasiya/maskalama.
SLO/SLA dəyişikliklərinin auditi və dəyişməz jurnallarda hesabatların dərc edilməsi.
Tənzimləyici yollar üçün (ödənişlər/PII) - ayrı, daha sərt SLO.

16) Çek vərəqləri

Service/Fich başlamazdan əvvəl

• müəyyən SLI «uğur/gizli/bant genişliyi/təravət».
• SLO və pəncərələr təyin; hesablanmış səhv büdcəsi.
• Özelleştirilmiş burn-rate alert (qısa + uzun).
• Dashboard RED + exemplars → trek; Runibuki hadisələr.
• Multi-icarə kəsilmələri və əhəmiyyət həddi.
• Fiçfriz və hesabat proseduru.

Əməliyyat

• SLO/burn həftəlik hesabat, hardening planları.
• Arxitektura/yük dəyişdikdə SLO yenidən qiymətləndirilməsi.
• Dövri «insident-təlimlər» və Runibook yeniləmə.
• Telemetriya dəyəri və SLI miqdarı nəzarət.

17) Runbook’и

Runbook: sürətli böyümə p99/pay

1. Alert p99> eşik → dashboard açmaq → exemplar trace.
2. Dar CLIENT/SERVER-span tapın, regionları/versiyaları müqayisə edin.
3. Deqradasiyanı (cache/limit/follbek) işə salın, asılılıq komandasını xəbərdar edin.
4. Sabitləşmədən sonra - RCA, optimallaşdırma vəzifələri, SLO ölçmələrinin yenilənməsi.

Runbook: büdcə xərcləri> həftədə 50%

1. Fiçləri dondurun, etibarlılıq prioritetini artırın.
2. Səhvlərin klasterləşdirilməsi: marşrutlar/kirayəçilər/asılılıqlar üzrə.
3. Düzəlişlər → trendin bərpasını təsdiqləyin.
4. Retrospektiv və alert/eşik düzəlişləri.

18) FAQ

S: Nə qədər SLO lazımdır?
A: Kritik istifadəçi ssenarilərində minimum: uğur + gecikmə. Qalan hər şey zəruridir.

S: Hansı daha yaxşıdır - vaxt və ya sorğu ilə əlçatanlıq?
A: Tələblərə görə - daha çox istifadəçi metrikası. Zaman şəbəkə komponentləri/infra üçün əlverişlidir.

S: Niyə orta deyil, p95?
A: Orta quyruğu gizlədir; istifadəçi p95/p99 hiss edir.

S: «qoz-fındıq» çox güclü necə deyil?
A: Real məqsədlərlə başlayın (tarixi məlumatlar), sonra yetkinlik yaşına çatdıqda sərtləşdirin.

• «Müşahidə: loqlar, metriklər, izlər»
• «Paylanmış izlər»
• «Audit və dəyişməz jurnallar»
• «Webhook çatdırılma zəmanətləri»
• «Transit/At Rest şifrələmə»
• «Məlumatların mənşəyi (Lineage)»