SLA/OLA provayderlar bilan

1) Atamalar va chegaralar

SLI - o’lchanadigan indikator (foydalanish imkoniyati, latentlik p99, muvaffaqiyatli qayta ishlangan vebxuklar, RPO/RTO).
SLO - oʻlchash oynasi uchun SLI maqsadli qiymati (masalan, 99. 9 %/30 kun).
SLA - yuridik majburiyatli hujjat (SLO + protsedura + tovon).
OLA - SLAga rioya etilishini ta’minlaydigan ichki maqsadlar va jarayonlar.
UC (Underpinning Contract) - uchinchi shaxslar (kanallar, ma’lumotlar markazi, CDN va h.k.) bilan «substratcha».

Chegaralar: provayderning javobgarlik sohasini (bulut/WAF/CDN/toʻlov shlyuzi/KYC provayderi) oʻz hududingizdan (kod, , mijozlar sozlamalari) aniq ajrating.

2) Tanqidlik matritsasi va model tanlash

SLA chuqurligi, tekshirish hajmi va OLA/UC talablari matritsaga bog’liq.

3) O’lchash metrikasi va oynalari

Foydalanuvchanlik (Availability): ruxsat etilgan talablarni bajarish vaqti.
Latentlik: p95/p99 asosiy operatsiyalar uchun; «sekin muvaffaqiyat» hisobga olinadi.
Ma’lumotlarning ishonchliligi: RPO (ma’lumotlarning maksimal yo’qotilishi) va RTO (tiklanish vaqti).
O’tkazish qobiliyati/limitlar: kafolatlangan kvotalar (RPS/MBps).
Integratsiya sifati: yetkazib berilgan vebxuklar ulushi ≤ X min, 2xx javoblar, takrorlashlar va deduplikatsiyalar ulushi.
O’lchash oynasi: oylik/siljish 30 kun, cheklovlar bilan istisnolar (rejali ishlar).

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Bu yerda outage - nafaqat provayderning status-sahifasida, balki tashqi monitoring boʻyicha tasdiqlangan mavjud boʻlmagan holat.

4) SLA tarkibi (bo’lim shabloni)

1. Fan va soha (servislar, hududlar, API versiyalari).
2. Ta’riflar (SLI/SLO, «hodisa», «rejali ishlar», «fors-major»).
3. So’rovlar toifalari va hududlar bo’yicha servis maqsadlari (SLO).
4. Monitoring va dalillar bazasi: qanday usulda, kimning sensori bilan, qanday davriylikda.
5. Noxush hodisalar va eskalatsiyalar: kanallar, javob/yangilanish muddatlari, rollar.
6. Qoplash: kreditlar/jarimalar/bonuslar, chegaralar, formulalar.
7. Xavfsizlik va maxfiylik: DPA, shifrlash, jurnallar, qoidabuzarlik to’g "risidagi xabarnomalar.
8. Xizmatdagi oʻzgarishlar: deprekeytlar, notifikatsiya oynasi, muvofiqlik.
9. Uzluksizlik va DR: RPO/RTO, tiklanish testlari.
10. Audit va komplayens: audit, hisobot, attestatsiyaga bo’lgan huquq.
11. Exit Plan: maʼlumotlar eksporti, muddatlari, formati, migratsiya yordami.
12. Yuridik qoidalar: yurisdiksiya, fors-major, maxfiylik, amal qilish muddati.

5) Formulalar namunalari (parchalar)

5. 1 Foydalanish imkoniyati va o’lchash

"Provayder 99 ta ta’minlaydi. har bir kalendar oyda 95% foydalanish imkoniyati. Foydalanish imkoniyati Buyurtmachining ≥ 3 ta hududdan 1 daqiqadan ≤ oraliqda tashqi sintetik monitoringi bilan o’lchanadi. ≥ 2 ta hududda qayd etilgan foydalanish imkoniyati bir vaqtning o’zida SEV2 darajasi hodisasi hisoblanadi va Downtime-da hisobga olinadi"

5. 2 Asosiy API ning yashirligi

"p99 javob vaqti’POST/payments/authorize’≤ 450 ms oyning 95% kunida. So’rovlarning chegaradan oshib ketadigan ulushi uchun sabablar tahlil qilingan holda hisobot taqdim etiladi"

5. 3 Hodisalar va eskalatsiyalar

"S1: ack ≤ 15 daqiqa, updeytlar har ≤ 30 daqiqada, maqsadli tiklash ≤ 2 soat; S2: ack ≤ 30 min, apdeytlar ≤ 60 min; S3: keyingi ish kuni. Kanallar: telefon 24 × 7, chat-brij, email"

5. 4 Qoplash (kreditlar)

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

Kreditlar qo’pol beparvolik bilan zararni qoplashning boshqa usullarini istisno etmaydi.

5. 5 Deprekeytlar va muvofiqlik

"Muvofiqlikni buzadigan o’zgartirishlar uchun kamida 180 kunlik bildirishnoma. vN va vN + 1 ni parallel qo’llab-quvvatlash kamida 90 kun"

5. 6 Chiqish (Exit)

"Bekor qilingandan so’ng 30 kun mobaynida provayder ma’lumotlarning to’liq eksportini Parquet/JSON + sxemasi formatlarida bepul taqdim etadi; qo’shimcha migratsiya xizmatlari - X tarif bo’yicha. Nusxalarni yo’q qilish dalolatnoma bilan tasdiqlanadi"

6) OLA: tashqi SLA uchun ichki tayanch

• Maqsadlar: p99 gateway ≤ 200 ms, error rate ≤ 0. 3%, DR: RPO 0, RTO 30 min.
• Mas’uliyati: SRE-on-call, 24 × 7; umumiy dashbordlar va alertlar.
• Jarayonlar: relizlardagi xaos-smouk, PRdagi perf-smouk, sheyding evristikasi.
• Geytlar: SLO/xaoc-test muvaffaqiyatsizlikka uchraganda deploy bloki; runbook yangilanishi shart.

7) Monitoring va dalillar

Sintetika: tashqi namunalar (HTTP/TCP), foydalanuvchi yo’li, «sekin muvaffaqiyat».
RUM: ta’sirni tasdiqlash uchun haqiqiy foydalanuvchi monitoringi.
Korrelyatsiya:’provider’,’region’,’api _ method’,’incident _ id’belgilari.
Artefaktlar: skrinshotlar/treyslar/loglar, KPI eksporti, eskalatsiyalar xronologiyasi.

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

8) Hodisalar va o’zaro hamkorlik

1. SEV tasnifi, war-room ochilishi, IC vazifasi.

2. «Issiq kanal» orqali provayderni xabardor qilish, artefaktlarni topshirish.

3. Aylanma rejimlar/ficha-bayroqlar (stale, sheyding, rate-cap).

4. Qo’shma taymline, tiklash.

5. Postmortem + harakatlar: limitlar, kalitlar, zaxira yo’nalishlar konfigini yangilash.

6. SLA bo’yicha kreditlar tashabbusi, billingda qayd etish.

9) Xavfsizlik va DPA

DPA/maxfiylik: nazoratchi/protsessor rollari, ma’lumotlar toifalari, qonuniylik bazasi, qayta ishlash muddatlari/maqsadlari, subprosessorlar va ularning SLA.
Shifrlash: TLS1. 2+, PFS; «tinch» ma’lumotlar, kalitlarni boshqarish (KMS/HSM), rotatsiya.
Audit: kirish daftarlari, qoidabuzarliklar to’g "risidagi bildirishnomalar ≤ 72 soat, so’rov bo’yicha pentest-hisobotlar.
Mahalliylashtirish: saqlash hududi, roziligisiz olib chiqishni taqiqlash.

10) Supply Chain va muvofiqlik

SBOM/zaifliklar: CVSS-chegara siyosati va tuzatish muddatlari (tanqidiy ≤ 7 kun, yuqori ≤ 14).
API muvofiqligi: kontrakt testlari, qum qutilari va barqaror fiksturalar.
Provayderning oʻzgarishlari: erta reliz-notalar, prevyu/beta-derazalar, teskari moslik.

11) Ko’p tarmoqlilik va feylover

Active/Active: murakkabroq va qimmatroq, ammo yuqori foydalanish imkoniyati (konsistentlikni hisobga oling).
Active/Passive: sovuq/issiq zaxira, muntazam mashq DR.
Abstraksiyalar/adapterlar: yagona kontrakt, salomatlik/qiymat/uglerod omili bo’yicha yo’naltirish (agar tegishli bo’lsa).
Litsenziya/tijorat shartlari: ko’chiruvchanlik, ma’lumotlarni chiqarishni cheklash, egress qiymati.

12) Exit-reja va davriy mashqlar

Maʼlumotlar/sxemalar katalogi va hajmlari.
SDK/API moslashuvchanlik stsenariysi (minimum - second source).
Quruq chiqish testi: eksport/import, tiklash, invariantlarni tekshirish.
Yuridik saqlash/chiqarib tashlash muddatlari.

13) Kontrakt va conformance testlari

API namunalari: ijobiy/salbiy, limitlar, xatolar va retralar.
Hodisalar/vebxuklarni yetkazib berish: imzo/vaqt/dedup/takrorlash.
Perf-bazlaynlar: p99, o’tkazish qobiliyati; provayderning reliz-eslatmalari bo’yicha regress-testlar.
Kross-mintaqa: bitta mintaqaning tanazzulga uchrashi SLOni global miqyosda buzmasligi kerak.

14) Anti-patternlar

SLA «status-sahifada» tashqi o’lchovlarsiz.
Barcha mintaqalar/endpointlar uchun bir xil maqsadlar.
Audit huquqining yo’qligi va hodisalarning batafsil jurnallari.
OLA/UC → tashqi majburiyatlarni bajaradigan hech kim yo’q.
Noma’lum exit-reja → Etkazib beruvchining garovi.
«Faqat kreditlar bilan jarimalar» ni muntazam ravishda buzilganda bekor qilish huquqisiz.
O’tish oynasi bo’lmagan deprekeytlar.

15) Arxitektorning chek-varaqasi

1. Asosiy flow va mintaqalar uchun SLI/SLO aniqlanganmi?
2. Tashqi monitoring usuli va dalillar bazasi tanlanganmi?
3. SLAda noxush hodisalar, eskalatsiyalar, rejali ish oynalari va istisnolar chegarasi yozilganmi?
4. Kredit shkalasi/jarimalar va N qoidabuzarlik holatlarida bekor qilish huquqi bormi?
5. DPA/xavfsizlik: shifrlash, jurnallar, xabarnomalar, subprosessorlar, mahalliylashtirish?
6. Payplayndagi kontrakt testlari va qum qutilari?
7. Ichki OLA/UC tashqi SLOlarni bajarishni taʼminlaydimi?
8. DR: RPO/RTO e’lon qilindi, mashg’ulotlar o’tkazilmoqda, hisobotlar bormi?
9. Exit-reja: eksport formatlari, muddatlari, «quruq chiqish» amaliyoti?
10. CI/CD geytlari SLA buzilishi xavfini oshiradigan relizlarni bloklaydimi?

16) Mini-misollar (eskizlar)

16. 1 Provayder tavakkalchiligi bo’yicha «deploy-geyt» siyosati

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 «Hodisa dalillarini» eksport qilish

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 Vebxukning kontrakt 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

Xulosa

SLA/OLA - bu nafaqat «yuridik qog’oz», balki xatar va sifatni boshqarishning arxitektura mexanizmi. To’g’ri metrika va derazalar, tashqi monitoring, aniq hodisa va kompensatsiya tartib-taomillari, ichki OLA/UC, payplaynlardagi geytlar, ko’p etkazib beruvchilar va haqiqiy exit-reja provayderlarga bog’liqlikni platformaning nazorat qilinadigan, o’lchanadigan va iqtisodiy jihatdan oldindan aytib bo’ladigan qismiga aylantiradi.