SLA və SLO monitorinqi

1) Şərtlər və rollar

SLA (Service Level Agreement) - müştəri qarşısında xarici müqavilə öhdəliyi (cərimə şərtləri, kreditlər).
SLO (Service Level Objective) - SLA-nın icrasını dəstəkləyən məqsədli daxili xidmət səviyyəsidir.
SLI (Service Level Indicator) - SLO/SLA tərəfindən qiymətləndirilən ölçülən göstəricidir.
Error Budget: 'Budget = 1 − SLO'.
Scope: istifadəçinin gözü ilə ölçülür (end-to-end). Mikroservislərdə - həm komponent səviyyəsində, həm də tam yol.

2) SLI seçimi: dəqiq ölçmək üçün nə

Meyar - istifadəçi təcrübəsi və biznes dəyəri ilə korrelyasiya.

• Əlçatanlıq: uğurlu sorğuların payı. 'SLI = uğurlu/hamısı'.
• Gecikmə: T. həddindən daha sürətli sorğuların payı. 'SLI = P (latency ≤ T)'.
• Keyfiyyət: düzgün cavabların payı (5xx/funksiya olmadan). səhvlər).
• Məlumatların aktuallığı: replikasiyanın gecikməsi/ETL ≤ X dəqiqə.
• Biznes prosesinin səmərəliliyi: uğurlu ödənişlərin/qeydiyyatların payı.

Anti-nümunələr: yalnız 200-ləri biznes səhvlərinə məhəl qoymadan «uğur» hesab edin; xüsusi əvəzinə test şəbəkəsində ölçmək.

3) Müşahidə formulları və pəncərələri

• `Availability = (OK_requests / All_requests) × 100%`.

• 'P95 ≤ T' → pay kimi formalaşdırmaq daha yaxşıdır: 'SLI =% T' ≤ sorğular.
• Nümunə: «Axtarış sorğularının 99% -i 28 gündə 300 ms ≤».
• Sürüşmə pəncərəsi: 28 və ya 30 gün (həssaslıq və sabitlik balansı). Hadisələr üçün - əlavə pəncərələr: 1 saat, 6 saat, 24 saat.

4) Error Budget və sürət dəyişikliyi

Hesablama: 'SLO = 99. 9% 'büdcə =' 0. 1% 'dövr ərzində səhv/əlçatmazlıq.

• Büdcə> 50%: plana uyğun olaraq buraxılışlar və təcrübələr.
• Büdcə 10-50%: yalnız aşağı riskli relizlər, kanaryaların sərtləşdirilməsi.
• Büdcə <10%: relizlərin dondurulması, kök səbəbi, etibarlılığın yaxşılaşdırılması.
• Mütərəqqi buraxılışlarla əlaqə: canary/feature-flags «yemək» büdcəsi dozalı, deqradasiya zamanı avtomatik geri dönüş ilə.

5) Alert siyasəti: eşikdən burn rate

Niyə «daupal SLO - alert qaldırın»: çox gec. Proaktivlik lazımdır.

• 'BR = (qısa pəncərədə müşahidə olunan səhv/bu pəncərədə icazə verilən səhv)'.
• Əgər 'BR> 1' - büdcə normadan daha tez xərclənir.

• Sürətli alert (səs-küy həssasdır, fəlakətləri tutur): pəncərə 5-10 dəq, BR həddi 14-20 ×.
• Yavaş alert (sürünən deqradasiyaları tutur): pəncərə 1-6 saat, BR həddi 2-4 ×.
• Kombinasiya şərtləri: sürətli və ya yavaş işlədi - on-call çağrı.
• Səviyyələr: xüsusi SLO üçün çağrı cihazı, daxili SLI boz deqradasiyalar üçün biletlər/bildirişlər.

6) Müşahidə və həqiqət mənbələri

Logi - səbəblərin diaqnostikası.
Metriklər - ədədi SLI (müvəffəqiyyət/səhv, lent, pay, sayğaclar).
Treys - keçici yollar, «isti» seqmentlərin lokalizasiyası.
Sintetika - periferiyadan (region-aware) aktiv nümunələr.
Real hadisələr - RUM/telemetriya müştərilər, biznes metrika (dönüşüm, uğurlu ödənişlər).

Tələblər: buraxılış və hadisələrin daşbordlarında vahid şəkil, «versiya/kanarya/bayraq» şərhləri.

7) SLO dizayn: addım-addım şablon

1. Kritik yolu təsvir edin (məsələn, «kartla depozit»).
2. SLI müəyyən edin: uğur/səhv, gecikmə həddi, tamlıq.
3. SLO ilə razılaşın: 28 gün + istisnalar üçün hədəf (planlaşdırılan pəncərələr).
4. SLA ilə əlaqə saxlayın: hüquqi öhdəlik ≦ faktiki SLO.
5. Sahibini təyin edin (service owner), RACI və alert kanalı.
6. Alert siyasətlərini (iki pəncərəli BR) və avtomatik geri çəkilmələri müəyyən edin.
7. Hesabat təqdim edin: həftəlik büdcə icmalları, post-insident review.
8. SLO-nu rüblük nəzərdən keçirin (yük/memarlıq dəyişikliyi).

8) SLO nümunələri (şablonlar)

• Mövcudluq: '≥ 99. 95% '(28d, elan edilmiş pəncərələr istisna olmaqla ≤ 30 dəq/ay).
• Gecikmə: '≥ 99%' cavabları '≤ 400 ms'.
• Biznes əməliyyatlarının uğuru: '≥ 98. 5% uğurlu icazələr (fraud-filterlər nəzərə alınır).

• Gizlilik: '99% ≥' sorğular '≤ 300 ms'.
• Cache aktuallığı: '≤ 5 min' 99% hallarda gecikmə.

• Çatdırılma: '99 ≥. 9% 'ərzində' ≤ 60 s '(end-to-end, retralar ilə).
• itki: '≤ 0. 01% 'mesajlar (idempotentlik/deduplikasiya daxildir).

9) Multi-region və multi-tenant

SLO «kohortlar üzrə»: ölkə, ödəniş provayderi, VIP seqmenti, cihaz.
Kənarda lokal SLO: istifadəçiyə ən yaxın nöqtələrdən metriklər (edge/PoP).
Aqreqasiya: ümumi SLO vacib kohortlarda uğursuzluqları gizlətməməlidir.
Provayderlərin dəyişdirilməsi: SLO gates səviyyəsində avtomatik fallback marşrutları.

10) Daşbordlar və hesabatlar

Reliz dashboard: versiyası, kanarya (% trafik), SLI (uğur/gecikmə), BR, bayraq izahları.
Əməliyyat dashboard: burn-down büdcə gün, top hadisələr, MTTR, problemli kohorts.
Həftəlik hesabatlar: büdcə qalığı, BR trendləri, texniki borc (dar yerlər), təkmilləşdirmə planı.

11) Proseslər: hadisələr, RCA və təkmilləşdirmə

Hadisə-menecment: alert → BR qiymətləndirilməsi → kanarya/bayraq miqyası → geri/fix.
RCA (kök səbəb): faktlar/zaman/hipotezlər/düzəlişlər/SLI təsiri yoxlama.
Öyrənilmiş dərslər: qeyri-cüzi post-mortemlər, sahibləri və şərtləri ilə məcburi action items.
Döngənin qapanması: testlərdə, fiqa bayraqlarında, limitlərdə, keşlərdə, retralarda, kvotalarda dəyişikliklər.

12) Komplayens və audit

SLO/SLI nəzarət artefaktları kimi (policy-as-code, dəyişməz log).
Tələblərə bağlama (məsələn, ödəniş əməliyyatlarının mövcudluğu).
Sübut: alert protokolları, büdcə hesabatları, buraxılış/geri dönüş jurnalları.

13) Tez-tez səhvlər və onlardan necə qaçmaq olar

“99. 99% və ya ölüm": əlçatmaz məqsədlər → daimi alert-səs. real SLO seçin.
Qlobal orta yerli uğursuzluqları gizlədir → kogorts daxil.
e2e olmayan metriklər: müştəridə faktiki deqradasiya ilə yüksək SLO → RUM/sintetika əlavə edin.
Bir eşik üçün alertlər → iki pəncərəli burn rate.
Dəyişikliklər ilə heç bir əlaqə yoxdur → buraxılışlar açıqlanmır, avtomatik geri dönüş yoxdur.

14) Mini-çek tətbiq siyahısı

• Kritik yolları və onların SLI/SLO təsvir.
• Müşahidə və istisna pəncərəsi təyin edilmişdir.
• İki pəncərəli BR-alertlər (sürətli və yavaş).
• Versiyaların/bayraqların açıqlamaları ilə relizlər və əməliyyatlar daşbordları.
• Error budget siyasəti buraxılışlara təsir edir.
• Müntəzəm büdcə icmalları və post-insident RCA.
• Sənədləşmə və göstəricilərin sahibləri.

15) Hesablama nümunəsi (konkretlik)

SLO API mövcudluğu: 99. 28 gün üçün 9% → büdcə = 0. 1%.
7 gün ərzində 0 yığılıb. Səhvlərin 06% -i → həftəlik büdcənin 60% -i xərclənib.
15 dəqiqəlik qısa pəncərədə səhvlərin 2% -i müşahidə olunur. Bu pəncərədə icazə verilir: '0. 1% × (15 dəq/40320 dəq) ≈ 0. 000037%`.
Burn Rate ≫ 1 (onlarla ×) → sürətli peycer işləyir, kanarya 1% -ə qədər yuvarlanır, «degrade-payments-UX» fiqa bayrağı işə salınır, RCA işə salınır.

16) Yekun

SLA/SLO monitorinqi yalnız hesabatdakı rəqəmlər deyil, dəyişiklik riskinin və xidmət keyfiyyətinin idarə edilməsi mexanizmidir. Düzgün SLI, real SLO, error budget, iki pəncərəli burn-rate riskləri və e2e-müşahidə metrikləri iş həllərinə çevirir: daha sürətli dəyər buraxın və istifadəçi təcrübəsini proqnozlaşdırıla bilən saxlayın.