Çalışma Süresi Raporları ve SLA Denetimleri

1) Neden resmi bir çalışma süresi raporlama sürecine ihtiyacımız var?

Müşteri güveni ve sözleşme şeffaflığı - tek bir ölçüm tekniği, tekrarlanabilir hesaplamalar.
SLO ve hata bütçesi yönetimi - kullanılabilirlik gerçeğini sürümler ve olaylarla ilişkilendirir.
Doğru SLA kredileri objektif formüller, öngörülebilir ödemeler/ofsetlerdir.
Yasal sürdürülebilirlik - kanıt tabanı, bağımsız denetim, Yasal Tutma.

2) Şartlar ve sınırlar

SLI Kullanılabilirliği - dönem başına başarılı onayların/işlemlerin yüzdesi.
SLO - dahili hedef (örn. 99. 28 günde %95).
SLA - dış taahhüt (örn. 99. %9/ay + hizmet kredileri).
Ölçüm penceresi - takvim ayı (SLA) ve yuvarlanma penceresi (SLO).
Kapsam - hangi bileşenlerin hesaplamaya dahil edildiği (kenar, API, ödemeler) ve hangilerinin dahil olmadığı (yönetici portalı, non-prod).

3) Gerçeğin kaynakları (ve hangisinin sorumlu olduğu)

1. Sentetikler (blackbox/headless) "kullanıcı gözü erişilebilirliği" için birincil SLI'dir.
2. Günlükler/metrikler - başarısızlığın ölçeğini ve doğasını onaylayın.
3. Ticari etkinlikler "işlem başarısı'dır (örneğin, ödeme yetkisi).
4. Durum sayfası - kamu iletişimi; 1-3 numaralı maddeye göre kontrol edilir.

Tutarsızlıklar durumunda: ≥2 bölgelerden doğru çoğunluk ile sentetiklere öncelik verilir.

4) Kullanılabilirlik hesaplama metodolojisi

4. 1 Temel formül

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

4. 2 Çok bölgeli çoğunluk

≥N bağımsız bölge/ASN aynı anda bir arıza kaydederse bir olay sayılır.
Önerilen: N = 2/3 (EU/NA/APAC).

4. 3 SLI türü

HTTP SLI: код 2xx/3xx, T ≤ gecikme süresi

DNS/TLS SLI: NXDOMAIN/SERVFAIL/son kullanma tarihi.
SLI işi: başarılı işlemler/tüm girişimler (müşteri başarısızlıkları hariç).

4. 4 İstisnalar (belgelenmiş)

Zamanlanmış bakım pencereleri önceden N saat ilan ve gözlendi.
SLA'dan mücbir sebep (örneğin, IX felaket sağlayıcısı) - yalnızca kanıt ve kamu bildirimi varsa.
İstemci hataları/kısıtlamaları (kota aşıldı, 4xx).

5) Pencere bakım politikası

Sözleşmede kararlaştırılan zaman dilimleri (örn. Güneş 02: 00-04: 00 UTC + 0).
Uyarı/panellerdeki 'Bakım = true' işaretçileri - SLI'dan hariç tutma.
Bildirim eşiği: En az 5 iş günü (veya sözleşmede olduğu gibi).
Pencereden - SLA etkisi dikkate alınır.

6) Kenar durumları ve yuvarlama kuralları

Brownout (kısmi bozulma): "0/1'değil, başarısızlık yüzdesini (ağırlıklı kesinti süresi) sayın.
Kanat çırpma: minimum hesap birimi - örnek aralığı (örneğin, 30-60 saniye) + histerezis (için: 2-5 dakika).
Saat sürüklenme: UTC ve ISO-8601 tüm zamanlar; NTP senkronizasyonu.

7) PromQL örnekleri (sentetikler - çalışma süresi)

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 örnekleri (rapor toplama)

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ık rapor şablonu (Müşteri dostu)

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 kredileri: hesaplama ve uygulama

Kredi tablosu: Örneğin, 99. 0–99. %5 - %5 MRR; 98. 0–99. %0 - %10, vb.
Gerçek: Kredi, bir sonraki hesaba kredi notu olarak uygulanır.

Otomasyon: "If 'measured _ availability 'credit _ note rule. create ()'"

Müşteri için vitrin: portal kart "SLA kredi bakiyesi".

11) Denetim, Kanıt ve Yasal Bekletme

Denetim izi: kim/ne/hesaplandığında, metodolojinin versiyonu, sağlama toplamları.
Ham veriler değişmezdir (yalnızca append-only); Ayarlamalar - ayrı kayıtlarla.
Yasal Saklama: Veri aralığının dondurulması (örnekler, günlükler, olay kartları, uyarılar).
Çoğaltma arşivleri - WORM/S3 Nesne Kilidi.

12) Kamu durumu sayfası ile uzlaşma

Durum sayfasındaki bir olayın bir zaman çizelgesi ve bileşenleri olmalıdır.
Zaman/ölçek uyumsuzluğu, tutarsızlık kaydı tarafından oluşturulur ve RCA tarafından gönderilir.
Raporun özeti Uzlaşma Notları bölümünü içermektedir.

13) Olaylar ve Raporlama

Her kesinti penceresi bir INC kartına (ID, SEV, sahibi, RCA, CAPA) karşılık gelir.
Raporda: INC bağlantısı, kısa kök nedeni, CAPA durumu.
SEV-1 için: Daha sonraki konular ≤ kapanıştan 48 saat sonra.

14) Veri kalite kontrolü

Örneklerin hijyeni:> Başarılı ajan artıklarının %99'u, boşluk olmaması> 5 dakika.
Anti-gürültü: çekirdek + çoklu pencere, debounce.
Trace/log örneklemesi kaydedilir ve belgelenir.
Yöntem testleri: hesaplamaların birim testleri, geçmiş verilere dayanan altın dosyalar.

15) Güvenlik ve gizlilik

Alım, paket imzası (HMAC) için TLS/mTLS.
Günlüklerde/raporlarda PII sürümü; SLA raporu kişisel verileri ifşa etmemelidir.
Raporlarda RBAC/ABAC; Erişim izleri denetim günlüğüne yazılır.

16) Panolar ve SLO widget'ları (ne gösterilecek)

Ay/çeyrek için hizmete göre genel kullanılabilirlik.
Önem derecesi ve algılama kanalına sahip kesinti pencereleri.
Hata bütçe yanması (hızlı/yavaş) ve eğilimler.
Releases overlay - hesaplamaların ek açıklamaları.
SLA kredileri tahmini - mevcut eğilimde.

17) Uygulama planı (3 yineleme)

1. Model ve veriler (2 hafta): SLI/SLO/SLA'yı düzeltin, quorum sentetikleri dahil edin, DWH'de "hammadde" toplayın.
2. Hesaplama ve rapor (2-3 hafta): formüller, SQL/PromQL, YAML/PDF şablonları, müşteri portalı, otomatik krediler.
3. Denetim ve otomasyon (3-4 hafta): Yasal Bekletme, durum sayfası ile uzlaşma, imzalı web kitapları, anlaşmazlık düzenlemeleri.

18) Rapor kalitesi kontrol listesi

• Kapsam, SLI, yöntem ve ölçüm penceresi tanımlanmıştır.
• Yeterli çoğunluk ve çoklu pencere vardır; Çırpma bastırılır.
• İstisnalar (bakım/mücbir sebepler) belgelenmiştir.
• Her kesinti penceresi INC ve RCA ile ilişkilidir.
• Hesaplanan SLA kredileri ve faturalandırmaya yansıtıldı.
• Tekrarlanabilir rapor (formül/veri sürümleri).
• Denetim izi ve Yasal Bekletme dahildir.
• Genel durum sayfası uzlaştırıldı.

19) Mini-SSS

Sentetikler neden ana kaynaktır?
Kullanıcı yoluna en yakın olanıdır ve bir çevre (DNS/CDN/WAF) içerir. Metrikler/günlükler - nedenini netleştirin.

Kısmi bozulma nasıl sayılır?
Ağırlıklı kesinti süresi: Hataların oranı pencerenin süresini × ve "hepsi ya da hiçbiri'değil.

"Ham" çekleri saklamam gerekiyor mu?
Evet. Bir anlaşmazlıkta denetim ve yeniden hesaplama için - ham gereklidir.

Sonuç

Çalışma süresi raporları ve SLA denetimleri bir "ayın sonundaki rakam'değil, tekrarlanabilir bir ölçüm, kural ve kanıt sistemidir: doğru SLI'lar, nisap kontrolleri, şeffaf formüller, olaylarla bağlantı kurma ve faturalandırma, istisna kontrolü ve Yasal Bekletme. Metodolojiyi kaydedin, hesaplama ve kredileri otomatikleştirin, denetim izini tutun - ve SLA'larınız yönetilebilir, anlaşılabilir ve güvenli hale gelecektir.