SLA/OLA provayderləri ilə

1) Terminlər və sərhədlər

SLI - ölçülə bilən göstərici (əlçatanlıq, gecikmə p99, uğurla işlənmiş vebhuk, RPO/RTO).
SLO - ölçmə pəncərəsi üçün SLI hədəf dəyəri (məsələn, 99. 9 %/30 gün).
SLA - hüquqi cəhətdən məcburi sənəd (SLO + prosedurlar + kompensasiya).
OLA - SLA-ya riayət edən daxili məqsədlər və proseslərdir.
UC (Underpinning Contract) - üçüncü şəxslərlə (kanallar, məlumat mərkəzi, CDN və s.) «substratdır».

Sərhədlər: Provayderin məsuliyyət sahəsini (bulud/WAF/CDN/ödəniş şluzu/KYC provayderi) zonanızdan (kod, , müştəri parametrləri) dəqiq ayırın.

2) Kritik matris və model seçimi

SLA dərinliyi, yoxlama həcmi və OLA/UC tələbləri matrisdən asılıdır.

3) Metrik və pəncərə ölçmə

Mövcudluq (Availability): Xidmətin tələblərə uyğun olaraq sorğuları yerinə yetirdiyi vaxtın bir hissəsi.
Gecikmə: əsas əməliyyatlar üçün p95/p99; «yavaş uğur» nəzərə alınır.
Məlumatların etibarlılığı: RPO (maksimum icazə verilən məlumat itkisi) və RTO (bərpa vaxtı).
Bant genişliyi/limitləri: zəmanətli kvotalar (RPS/MBps).
İnteqrasiya keyfiyyəti: çatdırılan vebhukların payı ≤ X min, 2xx cavabların, təkrarların və duplikasiyanın payı.
Ölçmə pəncərəsi: aylıq/sürüşmə 30 gün, məhdudiyyətlərlə istisnalar (planlı işlər).

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Burada outage - yalnız provayderin status səhifəsində deyil, xarici monitorinqdə təsdiqlənmiş əlçatmaz vəziyyət.

4) SLA məzmunu (bölmə şablonu)

1. Mövzu və sahə (xidmətlər, regionlar, API versiyaları).
2. Təriflər (SLI/SLO, «insident», «planlı işlər», «fors-major»).
3. Xidmətin məqsədləri (SLO) sorğu kateqoriyaları və regionlar üzrə.
4. Monitorinq və sübut bazası: hansı üsulla, kimin sensorları ilə, hansı tezliklə.
5. Hadisələr və eskalasiyalar: kanallar, cavab/yeniləmə vaxtı, rollar.
6. Kompensasiya: kreditlər/cərimələr/bonuslar, hədlər, düsturlar.
7. Təhlükəsizlik və məxfilik: DPA, şifrələmə, jurnallar, pozuntular barədə bildirişlər.
8. Xidmət dəyişiklikləri: deprekeyt, notifikasiya pəncərəsi, uyğunluq.
9. Davamlılıq və DR: RPO/RTO, bərpa testləri.
10. Audit və komplayens: audit, hesabat, attestasiya hüququ.
11. Exit Plan: məlumat ixrac, vaxt, format, miqrasiya yardım.
12. Hüquqi müddəalar: yurisdiksiya, fors-major, məxfilik, etibarlılıq müddəti.

5) Formasiya nümunələri (fraqmentlər)

5. 1 Mövcudluq və ölçü

"Provayder 99 təmin edir. Hər təqvim ayında 95% mövcudluğu. Əlçatanlıq Müştərinin ≥ 3 regiondan 1 dəqiqəyə ≤ xarici sintetik monitorinqi ilə ölçülür. ≥ 2 regionda qeydə alınan əlçatmazlıq eyni zamanda SEV2 səviyyəli hadisə hesab olunur və Downtime-də sayılır"

5. 2 Açar API-nin gecikməsi

"p99 cavab vaxtı 'POST/payments/authorize' ≤ 450 ms ayın 95% günü. Həddi aşan sorğuların payı üçün səbəbləri təhlil edən hesabat təqdim olunur"

5. 3 Hadisələr və eskalasiyalar

"S1: ack ≤ 15 dəq, yeniləmə hər ≤ 30 dəq, hədəf bərpa ≤ 2 saat; S2: ack ≤ 30 dəq, yenilənmə ≤ 60 dəq; S3: növbəti iş günü. Kanallar: telefon 24 × 7, çat bric, email"

5. 4 Kompensasiya (kreditlər)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

Kreditlər kobud səhlənkarlıq zamanı dəymiş ziyanın ödənilməsinin digər üsullarını istisna etmir.

5. 5 Deprekeyt və uyğunluq

"Uyğunluğu pozan dəyişikliklər üçün ən azı 180 gün bildiriş. Paralel dəstək vN və vN + 1 ən azı 90 gün"

5. 6 Çıxış (Exit)

"Ləğv edildikdən sonra 30 gün ərzində provayder Parquet/JSON + sxem formatlarında tam məlumat ixracını pulsuz təmin edir; əlavə miqrasiya xidmətləri - tariflə X. Nüsxələrin məhv edilməsi akt ilə təsdiq edilir"

6) OLA: xarici SLA üçün daxili dayaq

• Məqsədlər: p99 gateway ≤ 200 ms, error rate ≤ 0. 3%, DR: RPO 0, RTO 30 dəq.
• Məsuliyyət: SRE-on-call, 24 × 7; ümumi daşbordlar və alertlər.
• Proseslər: buraxılışlarda xaos-smouk, PR-da perf-smouk, sheiding evristics.
• Geytalar: SLO/xaoc-testin uğursuzluğu zamanı deploi bloku; runbook məcburi yeniləmə.

7) Monitorinq və sübut

Sintetika: xarici nümunələr (HTTP/TCP), istifadəçi yolu, «yavaş uğur».
RUM: təsiri təsdiqləmək üçün real istifadəçi monitorinqi.
Korrelyasiya: 'provider', 'region', 'api _ method', 'incident _ id' etiketləri.
Artefaktlar: ekran görüntüləri/treys/log, KPI ixracı, eskalasiya xronologiyası.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Hadisələr və qarşılıqlı əlaqə

1. SEV təsnifatı, war-room açılışı, IC təyinatı.

2. «Qaynar kanal» vasitəsilə provayderə bildiriş, artefaktların ötürülməsi.

3. Yan rejimlər/fiça bayraqları (stale, shading, rate-cap).

4. Birgə time line, bərpa.

5. Postmortem + fəaliyyət: limitlər, açarlar, ehtiyat marşrutlar konfiqinin yenilənməsi.

6. SLA kreditlərinin təşəbbüsü, billinqdə fiksasiya.

9) Təhlükəsizlik və DPA

DPA/privacy: controller/prosessor rolları, verilənlər kateqoriyaları, legitimlik bazası, emal şərtləri/məqsədləri, alt prosessorlar və onların SLA.
Şifrələmə: TLS1. 2+, PFS; dinc məlumat, açar idarəetmə (KMS/HSM), rotasiya.
Audit: giriş qeydləri, pozuntular barədə bildirişlər ≤ 72 saat, pentest hesabatları.
Lokalizasiya: saxlama bölgəsi, razılıq olmadan ixracın qadağan edilməsi.

10) Supply Chain və uyğunluq

SBOM/boşluqlar: CVSS həddi siyasəti və düzəliş şərtləri (tənqid ≤ 7 gün, yüksək ≤ 14).
API uyğunluğu: müqavilə testləri, «qum qutuları» və sabit fikstürlər.
Provayder dəyişiklikləri: erkən buraxılış notları, preview/beta pəncərələri, əks uyğunluq.

11) Çoxşaxəli və feylover

Active/Active: Daha mürəkkəb və daha bahalı, lakin daha yüksək mövcudluq (tutarlılığı nəzərə alın).
Active/Passive: soyuq/isti ehtiyat, müntəzəm DR təlim.
Abstraksiyalar/adapterlər: vahid müqavilə, sağlamlıq/dəyər/karbon faktoru marşrutu (müvafiq olarsa).
Lisenziya/kommersiya şərtləri: dözümlülük, məlumat çıxışı məhdudiyyəti, egress dəyəri.

12) Exit-plan və dövri məşqlər

Verilənlər/sxemlər və həcmlər kataloqu.
SDK/API dözümlülük ssenarisi (minimum - second source).
«Quru çıxış» testi: ixrac/idxal, bərpa, invariantların yoxlanılması.
Qanuni saxlama/aradan qaldırılması müddətləri.

13) Müqavilə testləri və conformance

API nümunələri: müsbət/mənfi, limitlər, səhvlər və retralar.
Hadisələrin/vebhukların çatdırılması: imza/vaxt/dedup/təkrar.
Perf Bazline: p99, bant genişliyi; provayderin buraxılış qeydlərinə görə reqres testləri.
Cross Region: Bir bölgənin deqradasiyası SLO-nu qlobal şəkildə pozmamalıdır.

14) Anti-nümunələr

SLA «status-səhifədə» xarici ölçmələr olmadan.
Bütün bölgələr/son nöqtələr üçün eyni hədəflər.
Audit hüquqlarının və hadisələrin ətraflı jurnallarının olmaması.
OLA/UC → xarici öhdəlikləri yerinə yetirən yoxdur.
Qeyri-müəyyən exit planı → təchizatçı girov.
«Yalnız kreditlərlə cərimələr» sistematik pozuntular zamanı ləğv etmək hüququ olmadan.
Keçid pəncərəsi olmayan deprekeytlər.

15) Memarın yoxlama siyahısı

1. əsas flow və regionlar üçün SLI/SLO müəyyən?
2. Xarici monitorinq üsulu və sübut bazası seçildi?
3. SLA-da insidentlər, eskalasiyalar, planlı iş pəncərələri və istisnalar limiti var?
4. N pozuntularda kredit şkalası/cərimələr və xitam hüququ varmı?
5. DPA/təhlükəsizlik: şifrələmə, jurnallar, bildirişlər, alt prosessorlar, lokalizasiya?
6. Payplaynda müqavilə testləri və qum qutuları?
7. Daxili OLA/UC xarici SLO-ların yerinə yetirilməsini təmin edirmi?
8. DR: RPO/RTO elan edilir, təlimlər keçirilir, hesabatlar var?
9. Exit planı: ixrac formatları, şərtlər, «quru çıxış» təcrübəsi?
10. CI/CD geytləri SLA pozulması riskini artıran buraxılışları bloklayırmı?

16) Mini nümunələr (eskizlər)

16. 1 Provayder riskinə görə «deploy-gate» siyasəti

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 «Hadisə sübutları» ixracı

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Webhook müqavilə testi (psevdokod)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

Nəticə

SLA/OLA yalnız «hüquqi kağız» deyil, risk və keyfiyyətin idarə edilməsi üçün memarlıq mexanizmidir. Düzgün metriklər və pəncərələr, xarici monitorinq, aydın insident və kompensasiya prosedurları, daxili OLA/UC, paylaynlarda geytalar, çox təchizatçılar və real exit planı provayderlərdən asılılığı platformanızın idarə olunan, ölçülən və iqtisadi cəhətdən proqnozlaşdırıla bilən hissəsinə çevirir.