Operasyonlar ve Yönetim Denetim Metrikleri ve SLA'lar

Denetim Metrikleri ve SLA'lar

1) Neden ihtiyacınız var

Metrikler yanlışsa - kararlar yanlış olacak, SLA'lar "kağıt üzerinde" ihlal edilecek veya sorunları gizlemek için tam tersi olacaktır. Metriklerin ve SLA'ların denetlenmesi, kullanıcılara ve ortaklara verilen sözlerin karşılaştırılabilir, güvenilir ve yasal olarak güvenli olmasını sağlar.

• Tek bir "doğruluk kaynağı" (SSOT) ve tekrarlanabilir hesaplamalar sağlayın.
• Panolar/raporlar/faturalandırma arasındaki tutarsızlıkları azaltın.
• SLA'ları kanıta dayalı hale getirin.
• Ölçümlerdeki bozulmayı hizmetlerde olduğu kadar erken tespit edin.

2) Sorumluluğun temel kavramları ve sınırları

Metrik: Ölçülen miktar (RPS, p95, CR, GGR, Başarı Oranı).
KPI/OKR: Metriklerin bağlı olduğu hedefler.
SLO: hedef hizmet kalitesi (örneğin, "p99 ≤ 400 ms 99. Zamanın %9'u").
SLA: dış söz; Yasal olarak önemli, SLO'ya dayalı.
OLA: Ekipler/satıcılar arasındaki iç anlaşma, SLA'yı destekler.
SSOT: Verileri raporlama için referans olarak kabul edilen sistem/depolama.

3) Metriklerin taksonomisi (katmanlar)

1. Altyapı: CPU/Bellek/IO/Net, bölmeler/düğümler, HPA/VPA.
2. Platform: kuyruklar/akışlar (gecikme, verim), DB/önbellekler (bağlantılar, hit), API (p95/p99, 5xx).
3. İş akışları: para yatırma/çekme, bahis, oyun başlatma, yetkilendirme, KYC.
4. Ürün/pazarlama: dönüşümler, ARPPU/LTV, kampanyalar.
5. Süreçlerin kalitesi: MTTA/MTTR, Arıza Oranını Değiştir, kontrol listesi kapsamı.

Kural: Her metriğin bir katmanı, sahibi ve formülü olmalıdır.

4) Veri kaynakları ve "doğru"

Çevrimiçi telemetri: Prometheus/OTel, günlükler (ELK/ClickHouse), izler.
Olaylar ve muhasebe: Kafka/Outbox, DWH/data mart (BigQuery/ClickHouse).
El yapımı eserler: ölüm sonrası, biletler, olay kayıtları.
Dış kayıtlar: sağlayıcı raporları (PSP/KYC/stüdyolar), faturalandırma.

Uyuşmazlık çözümü: "Çevrimiçi vs DWH" tutarsızlıkları durumunda, öncelikli düzenleme geçerlidir (örneğin, SLA için - kaynak izlenebilirliği olan DWH'den agregalar).

5) Metrik denetim süreci (kontrol döngüsü)

1. Envanter: metrik kataloğu/SLO/SLA (ad, sahip, katman, formül, kaynak, hesaplama sıklığı).
2. Formül doğrulaması: SQL/promo sorgularının tanımla mutabakatı (hesaplamaların birim testleri).
3. Örnekleme ve yeniden kontrol etme: örnekleme olayı/günlük çizgileri ve manuel mutabakat.
4. Kontur haritalama: Çevrimiçi panoların ve DWH raporlarının karşılaştırılması.
5. Değişiklik kontrolü: şema/mantık sürümleri için formül incelemesi.
6. SLA denetimi: Montajların ve istisnaların doğruluğunun doğrulanması (planlı bakım, mücbir sebep).
7. Rapor ve iyileştirmeler: Tespit edilen tutarsızlıkların bir listesi ve son teslim tarihleriyle ilgili düzeltmeler.

6) Tanımlar ve formüller (örnekler)

• 'başarı = istekler - (5xx + zaman aşımları + circuit_open)'
• 'success _ rate = sucess/requests'

• SSOT, tek bir pencere tanımını (5m/1h haddeleme) ve toplama (HDR/TDigest) kaydeder.

• 'SLO _ availability _ month = (çalışma süresi - izin verilen _ istisnalar )/total _ time'

• 'SLA _ ay = 99. UTC penceresi tarafından %90 çalışma süresi, planlanan pencereler hariç (T-48 bildirimi), transit operatörlerinde kanıtlanabilir kazalar (belgeler)

7) Veri kalitesi: kontroller ve uyarılar

• Полнота (tamlık): 'received _ events/ expected_events ≥ 0. 99`.
• Zamanlama: yük gecikmesi ≤ N dakika.
• Benzersizlik: yinelenen anahtarlar olmadan (idempotency-key).
• Tutarlılık-Miktarlar/para birimi/karakterler.
• Doğrusallık - Sayaçlar "geri alınmış" değildir.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) SLA/OLA Denetimi: Metodoloji

1. Bir istisna takvimi toplayın: planlı pencereler, kararlaştırılmış bozulma, satıcıların eylemleri.
2. Çalışma süresinin hesaplanması: SSOT'ye dayalı tek bir saat dilimine göre.
3. Olaylarla uzlaşma: zaman çizelgesi, biletler, ölüm sonrası.
4. Atıf: kendi arızaları, sağlayıcı, transit, DDoS, rutin bakım.
5. SLA çevre: kullanıcı deneyimi (E2E) vs belirli bir API.
6. Raporlama: Aylık/üç aylık rapor: fiili, sapmalar, tazminatlar (varsa), düzeltici önlemler.

9) Hesaplama tekrarlanabilirliğinin kontrolü

Formül sürüm oluşturma: SQL/PromQL/dock özelliklerine sahip Git deposu.
Metriklerin birim testleri: sentetik verilerde (kenar durumları: boşluklar, kopyalar, tarih sınırları).
Veri soyu: kontrol panelinden kaynak tablolara ve olaylara.
Anlık görüntüler: Yeniden hesaplamaların karşılaştırılabilir olması için verilerin kesilmesi için dondurulması.

10) Örnekleme

Günlük: Anahtar akışlarla 10-20 olay (mevduat/oran/CCL) - izleme ↔ DWH'nin manuel olarak doğrulanması.
Haftalık: Agregalar arasında "çevrimiçi vs DWH'yi karşılaştırmak için %1 örnek.
Aylık: SLA etkisi olan olaylar kümesi - ayrıntılı yeniden yapılanma.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Gösterge tablolarının ve uyarıların denetimi

Birleşik metrik sözlüğü: sözlük sağ gösterge panosunda.
Bültenlerin/olayların ek açıklamaları: sapmaların nedenini görmek için.
Yayın öncesi/sonrası karşılaştırma: otomatik regresyon panelleri.
Kopyalar/tutarsızlıklar: "iki farklı p99'u tanımlama - formülleri/pencereleri düzenleme.
Panel kullanılabilirliği: haklar, rezerv, bağlantı/sürüm kontrolü.

12) Metrik Değişim Yönetimi

RFC Süreci - Formülü/Pencereyi/Kaynağı Değiştirin - SLA/Raporlama Etki Değerlendirmesi ile RFC aracılığıyla

Migration "genişlet> migrate> contract": Her iki sürümü de geçici olarak saklayın, karşılaştırın, sonra eskisini kapatın.
İletişim:'yeni yönteme göre "değerlerdeki değişimlerden önce ürünü/işletmeyi bilgilendirin.

13) Özellikler iGaming/fintech

Talep zirveleri: metrikler patlayıcı yüklere dayanmalıdır (toplamlar "yapışmaz").
Sağlayıcılar: SLA, OLA satıcılarına bağlıdır - raporlarını, olay durumlarını ve kotalarını saklar.
Maliyet: 'cost _ per _ 1k _ calls've' cost of success 'zorunlu panellerdir.
Antifraud/risk: gecikmelere karşı hassasiyet ve metriklerin "yanlış pozitiflikleri".

14) Denetim panoları (minimum set)

Metrikler Sağlık: tamlık/zamanlama/kopyalar, ingest-lag ошибки ETL.
SLO/SLA Kanıtı: hesaplanan SLO, gerçek SLA, istisnalar, olaylara/eylemlere referanslar.
Online vs DWH Karşılaştırma: p95/p99/Success Oranı, sapmalar ve eğilimler.
Satıcı SLA: Sağlayıcı tarafından çalışma süresi/kotalar/zaman aşımları/maliyet.
Yayın Etkisi: Hesaplamalardan sonra metriklerin gerilemesi/özelliklerin dahil edilmesi.

15) Denetim kontrol listesi (operasyonel)

• Sahipleri ve formülleri olan metrikler/SLO/SLA dizini günceldir.
• SSOT her rapor/panel için tanımlanmıştır.
• Formüllerin birim testleri yeşil, hesaplama boru hatları belgelenmiştir.
• Veri kalitesi uyarıları etkindir (tamlık/zaman çizelgesi/kopyalar).
• "Çevrimiçi vs DWH" tutarsızlık kabul edilebilir eşik ≤ (örneğin % ≤2).
• Kabul edilen SLA istisnaları belgelenir ve rapora eklenir.
• Kontrol numuneleri alındı ve sertifikalar hazırlandı.
• Tüm formül değişiklikleri RFC ve geçiş geçti.

16) Örnekler (parçalar)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-desenler

Farklı panellerde iki farklı "aynı" metrik formül.
Geçiş ve bildirim olmadan metriğin değiştirilmesi - OKR/SLA'da "atlamalar".
Yerel Excel'de "true" (yeniden üretilemez) olarak raporlar.
SLA hesaplamalarında zaman dilimlerini ve takvimleri karıştırma.
SLA istisnaları belgelenmemiştir.
Ölçümlerin kalitesi hakkında uyarı yoktur.

18) Ölçüm olgunluğu KPI

Sürüklenme Oranı Online↔DWH (hedef % ≤2).
Metrikler Sağlık Çalışma Süresi.
Düzeltme Zamanı Formülü.
SLA Anlaşmazlık Oranı.
Kapsama SLO/SLA (resmi olarak açıklanan SLO/SLA ile kritik yolların oranı).

19) Roller ve sorumluluklar

Metrik/hizmetin sahibi: formül, kaynak, gösterge tablosu, uyarılar.
Gözlemlenebilirlik/SRE: SSOT/platform, formül testleri, veri kalitesi uyarıları.
Veri/BI: DWH, rapor tekrarlanabilirliği, soy.
Avukatlar/ortak yöneticiler: SLA anlaşmaları ve istisnalar.
Olay Yöneticisi: SLA olaylarını ilişkilendirme ve bağlama.

20) Hızlı başlangıç (30 gün)

1. Hafta: Envanter Metrikleri/SLO/SLA ve Sahipleri; Bir SSOT atayın.
2. Hafta: Veri kalitesi uyarıları ve "Online vs DWH" paneli ekleyin.
3. Hafta: kontrol numuneleri yapın, p95/p99 penceresini hizalayın.
4. Hafta: Formüller için RFC sürecini resmileştirin, eklerle birlikte aylık bir SLA raporu hazırlayın.

21) SSS

S: SLA için SSOT nedir?
A: Tekrarlanabilir hesaplamalar (DWH) ve tam soy ile depolama; Çevrimiçi paneller - operasyonel kontrol için, yasal eylemler için değil.

S: "İki p99s'ile nasıl başa çıkılır?
C: Metrik dizinindeki pencere/toplama yöntemini düzeltin, panelleri geçirin, sürüklenmeye uyarı ekleyin.

S: Planlanan işler nasıl değerlendirilir?
C: Bir istisnalar takvimi tutmak ve bunları sözleşmenin kurallarına göre SLA'dan otomatik olarak düşmek; Doğrulayıcı eserler saklayın.