Uptime hisobotlari va SLA auditi

1) Nima uchun rasmiy uptime-hisobot jarayoni kerak?

Mijozlarning ishonchi va kontrakt shaffofligi - o’lchashlarning yagona metodikasi, takroriy hisob-kitoblar.
SLO va xatolar byudjetini boshqarish - relizlar va hodisalar bilan foydalanish imkoniyati bilan bog’liq.
To’g "ri SLA kreditlari - ob’ektiv formulalar, oldindan aytib bo’ladigan to’lovlar/hisobga olishlar.
Yuridik barqarorlik - dalillar bazasi, mustaqil audit, Legal Hold.

2) Atamalar va chegaralar

SLI Availability - davr mobaynida muvaffaqiyatli tekshirishlar/tranzaksiyalar ulushi.
SLO - ichki maqsad (masalan, 99. 28 kunda 95%).
SLA - tashqi majburiyat (masalan, 99. 9 %/oy + servis-kreditlar).
Oʻlchash oynasi - kalendar oy (SLA) va rolling-derazalar (SLO).
Scope - qaysi komponentlar hisob-kitobga kiritiladi (edge, API, to’lovlar), qaysi komponentlar kiritilmaydi (admin-portal, non-prod).

3) Haqiqat manbalari (va qachon bosh)

1. Sintetika (blackbox/headless) - «foydalanuvchi ko’zi bilan foydalanish» uchun birlamchi SLI.
2. Logi/metriklar - rad etishning ko’lami va xususiyatini tasdiqlaydi.
3. Biznes tadbirlari - «operatsiya muvaffaqiyati» (masalan, to’lov vakolatli).
4. Maqom-sahifa - ommaviy kommunikatsiya; 1-3-sonli faktlar bilan solishtiriladi.

Kelishmovchiliklar bo’lganda: ≥ 2 ta hududdan to’g "ri quorum bilan sintetikadan ustuvorlik.

4) Foydalanish imkoniyatini hisoblash metodikasi

4. 1 Bazaviy formula

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Koʻp mintaqaviy quorum

Agar N. mustaqil mintaqalar/ASN ≥ bir vaqtning o’zida rad etishni qayd etsa, hodisa hisobga olinadi.
Tavsiya etiladi: 3 dan N = 2 (EU/NA/APAC).

4. 3 SLI turlari

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Biznes SLI: muvaffaqiyatli tranzaksiyalar/barcha urinishlar (mijozlarning rad etishlari bundan mustasno).

4. 4 Istisnolar (documented)

Rejali maintenance oynalar, oldindan e’lon qilingan N soat va rioya qilingan.
SLA dan Force majeure (masalan, IX-falokat provayderi) - faqat dalillar va ommaviy bildirishnoma mavjud bo’lganda.
Mijoz xatolari/cheklovlari (quota exceeded, 4xx).

5) Derazalarning maintenance siyosati

Kontraktda kelishilgan vaqtinchalik slotlar (masalan, UTC + 0 bo’yicha 02: 00-04: 00 dan boshlab).
Alert/panellardagi’maintenance = true’markerlari → SLIdan istisno.
Xabarnoma chegarasi: kamida 5 ish kuni oldin (yoki shartnomada bo’lgani kabi).
Derazadan tashqarida - SLA ta’siri hisoblanadi.

6) Edge-keyslar va yaxlitlash qoidalari

Brownout (qisman yomonlashuv): «0/1» emas, balki muvaffaqiyatsizliklar ulushini (weighted downtime) hisoblash.
Flapping: minimal hisobga olish birligi - sinov oralig’i (masalan, 30-60 sek) + hysteresis (for: 2-5 min).
Clock drift: UTC va ISO-8601’dagi barcha vaqtlar; NTP sinxronlash.

7) PromQL misollari (sintetika → aptaym)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) SQL namunalari (hisobot agregatsiyasi)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Oylik hisobot namunasi (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) SLA-kreditlar: hisob-kitob va qo’llash

Kreditlar jadvali: masalan, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% va boshqalar

True-up: kredit keyingi hisobvaraqqa credit note sifatida qo’llaniladi.
Avtomatlashtirish: qoidasi "agar’measured _ availability <SLA’→’credit _ note. create()`».
Mijoz uchun vitrin: «SLA credits balance» portal kartochkasi.

11) Audit, dalillar va Legal Hold

Audit-trail: kim/nima/qachon hisoblagan, metodika versiyasi, nazorat summalari.
Raw-ma’lumotlar o’zgarmas (append-only); tuzatishlar kiritish - alohida yozuvlar bilan amalga oshiriladi.
Legal Hold: ma’lumotlar diapazonini muzlatish (namunalar, loglar, hodisa kartochkalari, alertlar).
Arxiv nusxasi: mustaqil saqlash (Object Lock WORM/S3).

12) Ommaviy maqom-sahifa bilan solishtirish

Status-sahifadagi hodisa taymline va komponentlarga ega boʻlishi shart.
Vaqt/masshtab nomuvofiqligi → discrepancy-record yaratiladi va RCA tomonidan amalga oshiriladi.
Hisobot yakuni «Reconciliation Notes» bo’limini o’z ichiga oladi.

13) Hodisalar va hisobot

Induntaymning har bir oynasida INC-kartochka (ID, SEV, egasi, RCA, CAPA) mos keladi.
Hisobotda: INC ga havola, qisqacha root cause, CAPA maqomi.
SEV-1 uchun: yopilishidan 48 soat ≤ mavzularda postmor.

14) Ma’lumotlar sifatini nazorat qilish

Namunalar gigiyenasi:> 99% muvaffaqiyatli agentlar skriplari, yo’llanmalar yo’qligi> 5 daqiqa.
Shovqinga qarshi: quorum + multi-window, debounce.
Trassalar/loglarni samplash qayd etiladi va hujjatlashtiriladi.
Metodika testlari: hisob-kitoblarning yunit-testlari, tarixiy ma’lumotlar bo’yicha golden-fayllar.

15) Xavfsizlik va maxfiylik

ingest uchun TLS/mTLS, paketlar imzosi (HMAC).
PII - loglarda/hisobotlarda tahririyat; SLA-hisobot shaxsiy ma’lumotlarni oshkor qilmasligi kerak.
hisobotlar uchun RBAC/ABAC; kirish izlari audit-jurnalga yoziladi.

16) Dashbordlar va SLO-vidjetlar (nimani ko’rsatish kerak)

Bir oy/chorak uchun servislar bo’yicha Overall availability.
severity va detektor kanali bilan Downtime windows.
Error budget burn (fast/slow) va trendlar.
Releases overlay - hisob izohlari.
SLA credits forecast - joriy tendentsiyada.

17) Joriy etish rejasi (3 ta iteratsiya)

1. Model va ma’lumotlar (2 hafta): SLI/SLO/SLA ni tuzatish, quorum-sintetikani yoqish, DWHda «xomashyo» ni yig’ish.
2. Hisob-kitob va hisobot (2-3 hafta): formulalar, SQL/PromQL, YAML/PDF shablonlari, mijoz portali, avto-kreditlar.
3. Audit va avtomatlashtirish (3-4 hafta): Legal Hold, status-sahifali reconciliation, imzolangan vebxuklar, munozaralar reglamentlari.

18) Hisobot sifatining chek-varaqasi

• Aniqlangan skope, SLI, metodika va o’lchash oynasi.
• quorum va multi-window mavjud; flapping bostirilmoqda.
• Istisnolar (maintenance/force majeure) hujjatlashtirilgan.
• Har bir oyna INC va RCA bilan bog’liq.
• SLA kreditlari hisoblab chiqilgan va billingda aks ettirilgan.
• Hisobot takrorlanadi (formula/ma’lumotlar versiyasi).
• Audit-trail va Legal Hold kiritilgan.
• Ommaviy maqom sahifasi kelishilgan (reconciliation notes).

19) Mini-FAQ

Nega sintetika asosiy manbadir?
U foydalanuvchi yoʻliga eng yaqin va perimetrni (DNS/CDN/WAF) oʻz ichiga oladi. Metrika/loglar - sababini aniqlashtiradi.

Qisman tanazzulni qanday hisoblash mumkin?
Muvozanatli pastlik: «hamma narsa yoki hech narsa» emas, balki oynaning uzunligi ×.

Xom tekshiruvlarni saqlash kerakmi?
Ha. Nizoda audit va qayta hisob-kitob qilish uchun raw talab qilinadi.

Jami

Uptime-hisobotlar va SLA auditi - bu «oy oxiridagi raqam» emas, balki o’lchovlar, qoidalar va dalillarning takrorlanadigan tizimi: to’g’ri SLI, quorum-tekshirishlar, shaffof formulalar, hodisalar va billing bilan bog’lanish, istisnolarni nazorat qilish va Legal Hold. Metodikani tuzating, hisob-kitob va kreditlarni avtomatlashtiring, audit treylini saqlang - va sizning SLAlaringiz boshqariladigan, tushunarli va himoyalangan bo’ladi.