Uptime hesabatları və SLA auditi

1) Niyə rəsmi uptime hesabat prosesi lazımdır

Müştəri etimadı və müqavilə şəffaflığı - vahid ölçmə metodikası, təkrarlanan hesablamalar.
SLO və səhv büdcəsinin idarə edilməsi - buraxılışlar və hadisələrlə əlçatanlıq faktının birləşməsi.
Düzgün SLA kreditləri - obyektiv düsturlar, proqnozlaşdırıla bilən ödənişlər/kreditlər.
Hüquqi sabitlik - sübut bazası, müstəqil audit, Legal Hold.

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

SLI Availability - dövr ərzində uğurlu yoxlamalar/əməliyyatların payı.
SLO daxili hədəfdir (məsələn, 99. 28 gün ərzində 95%).
SLA - xarici öhdəlik (məsələn, 99. 9 %/ay + xidmət kreditləri).
Ölçmə pəncərəsi - təqvim ayı (SLA) və rolling pəncərələr (SLO).
Scope - hansı komponentlər hesablanır (edge, API, ödənişlər), hansıları yoxdur (admin-portal, qeyri-prod).

3) Həqiqət mənbələri (və nə zaman əsas)

1. Sintetika (blackbox/headless) - «istifadəçi gözü ilə əlçatanlığı» üçün ilkin SLI.
2. Loqlar/metriklər - uğursuzluğun miqyasını və xarakterini təsdiqləyir.
3. Biznes hadisələri - «əməliyyatın uğuru» (məsələn, ödəniş səlahiyyətli).
4. Status-səhifə - ictimai kommunikasiya; 1-3 saylı faktlarla yoxlanılır.

Uyğunsuzluqlar zamanı: ≥ 2 regiondan düzgün quorum ilə sintetikaya üstünlük verilir.

4) Əlçatanlığın hesablanması metodikası

4. 1 Əsas formul

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

4. 2 Çox regional quorum

Hadisə, Müstəqil Bölgələrin N/ASN ≥ eyni vaxtda imtinanı qeydə alırsa hesablanır.
Tövsiyə olunur: 3-dən N = 2 (EU/NA/APAC).

4. 3 SLI növləri

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Biznes SLI: uğurlu əməliyyatlar/bütün cəhdlər (müştəri uğursuzluqları istisna olmaqla).

4. 4 istisnalar (documented)

Planlı maintenance pəncərələri əvvəlcədən elan N saat və müşahidə.
SLA-dan Force majeure (məsələn, IX fəlakət provayderi) - yalnız sübut və ictimai bildiriş olduqda.
Müştəri səhvləri/məhdudiyyətləri (quota exceeded, 4xx).

5) Pəncərələrin maintenance siyasəti

Müqavilədə razılaşdırılmış müvəqqəti slotlar (məsələn, UTC + 0 üzrə 02: 00-04: 00 saatı).
Alert/panellərdə 'maintenance = true' markerləri → SLI istisna.
Bildiriş həddi: ən azı 5 iş günü (və ya müqavilədə olduğu kimi).
Pəncərədən kənarda - SLA təsiri sayılır.

6) Edge-cases və yuvarlaqlaşdırma qaydaları

Brownout (qismən pisləşmə): «0/1» deyil, uğursuzluqların payını (weighted downtime) hesablayın.
Flapping: minimum ölçü vahidi - nümunə intervalı (məsələn, 30-60 saniyə) + hysteresis (for: 2-5 dəqiqə).
Clock drift: UTC və ISO-8601 bütün vaxt; NTP sinxronizasiyası.

7) PromQL nümunələri (sintetik → 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 nümunələri (hesabat aqreqasiyası)

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) Aylıq hesabat şablonu (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 kreditləri: hesablanması və tətbiqi

Kredit cədvəli: məsələn, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% və s.
True-up: kredit növbəti hesaba kredit note kimi tətbiq olunur.
Avtomatlaşdırma: qaydası "əgər 'measured _ availability <SLA' → 'credit _ note. create()`».
Müştəri üçün vitrin: «SLA credits balance» portal kartı.

11) Audit, sübut və qanuni Hold

Audit-trail: kim/nə/nə vaxt hesablandı, metodologiyanın versiyası, nəzarət məbləğləri.
Raw-data dəyişməz (append-only); düzəlişlər - ayrı qeydlər.
Legal Hold: Data diapazonunun dondurulması (nümunələr, qeydlər, hadisə kartları, həyəcanlar).
Arxiv replikası: müstəqil saxlama (WORM/S3 Object Lock).

12) Ictimai status-səhifə ilə müqayisə

Status-səhifədəki insidentin taymline və komponentləri olmalıdır.
Zaman/miqyasda uyğunsuzluq → discrepancy-record yaradılır və RCA tərəfindən həyata keçirilir.
Hesabat «Reconciliation Notes» bölməsindən ibarətdir.

13) Insidentlər və hesabatlar

Hər bir downtime pəncərəsi INC kartına (ID, SEV, sahibi, RCA, CAPA) uyğundur.
Hesabatda: INC-ə keçid, qısa root cause, CAPA statusu.
SEV-1 üçün: qapanmadan 48 saat ≤ mövzuların postmoru.

14) Data keyfiyyətinə nəzarət

Nümunə gigiyenası:> 99% uğurlu sürüşmə agentləri, heç bir keçid> 5 dəqiqə.
Anti-səs: quorum + multi-window, debounce.
Trass/log sampling qeyd və sənədləşdirilir.
Metodika testləri: vahid hesablama testləri, tarixi məlumatlarda qızıl fayllar.

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

ingest üçün TLS/mTLS, paket imzası (HMAC).
log/hesabatlarda PII-redaktə; SLA hesabatı şəxsi məlumatları açıqlamamalıdır.
RBAC/ABAC hesabatlara; giriş izləri audit log yazılır.

16) Daşbordlar və SLO-widgets (nə göstərmək olar)

Bir ay/rübdə Overall availability xidmətləri.
severity və kanal detektor ilə Downtime windows.
Error budget burn (fast/slow) və trendlər.
Releases overlay - Hesabların şərhləri.
SLA credits forecast - cari tendensiya ilə.

17) Tətbiq planı (3 iterasiya)

1. Model və məlumatlar (2 həftə): SLI/SLO/SLA qeyd, quorum sintetikanı daxil edin, DWH-də «xammal» yığın.
2. Hesablama və hesabat (2-3 həftə): formullar, SQL/PromQL, YAML/PDF şablonları, müştəri portalı, avtomatik kreditlər.
3. Audit və avtomatlaşdırma (3-4 həftə): Legal Hold, status-səhifə ilə reconciliation, imzalanmış vebhuk, mübahisə qaydaları.

18) Hesabatın keyfiyyətinin yoxlanılması

• Scope, SLI, metodikası və ölçü pəncərəsi müəyyən edilmişdir.
• quorum və multi-window var; flapping boğulur.
• istisnalar (maintenance/force majeure) sənədləşdirilmişdir.
• Downtime hər pəncərə INC və RCA ilə bağlıdır.
• SLA kreditləri hesablanır və billinqdə əks olunur.
• Hesabat təkrar (formula/data versiyaları).
• Audit Trail və Legal Hold daxildir.
• İctimai status-səhifə razılaşdırılmışdır (reconciliation notes).

19) Mini-FAQ

Niyə sintetik əsas mənbədir?
Bu istifadəçi yolu ən yaxın və perimetri daxildir (DNS/CDN/WAF). Metriklər/loqlar - səbəbini aydınlaşdırır.

Qismən deqradasiyanı necə saymaq olar?
Balanslı downtime: uğursuzluqların payı pəncərənin uzunluğunu ×, «hər şey və ya heç nə» deyil.

«Xam» yoxlamaları saxlamaq lazımdırmı?
Bəli. Mübahisə zamanı audit və yenidən hesablama üçün - raw tələb olunur.

Yekun

Uptime-hesabatlar və SLA auditi «ayın sonunda bir rəqəm» deyil, düzgün SLI, quorum-yoxlamalar, şəffaf formullar, insidentlər və billinqlər, istisnalara nəzarət və qanuni Hold. Metodologiyanı düzəldin, hesablama və kreditləri avtomatlaşdırın, audit treylini saxlayın və SLA-larınız idarə oluna, başa düşülə və qoruna bilər.