Altyapı KPI'ları ve çalışma süresi
Neden buna ihtiyacın var?
Altyapı KPI'ları, istikrarla ilgili "duyguları" ölçülebilir hedeflere dönüştürür, riski yönetir ve işe odaklanır. Doğru metrikler, teknik SLI'ları iş sonuçlarına (dönüşüm, Time-to-Wallet, LTV) bağlar ve yeniliğin geliştirilmesi, yüklenmesi ve paylaşılması ile güvenilirlik arasında plan yapmanıza olanak tanır.
Temel kavramlar: SLI, SLO, SLA ve hata bütçesi
SLI (Hizmet Seviyesi Göstergesi) - ölçülen kalite göstergesi: başarılı taleplerin oranı, p95 gecikme süresi, aralık başına çalışma süresi.
SLO (Hizmet Seviyesi Hedefi) - SLI hedefi (örneğin, "başarı ≥ 99. 30 günde %9").
SLA (Anlaşma) - cezalar/krediler ile dış vaat. Her zaman SLO'dan türetilir, ancak eşit değildir.
Hata bütçesi = '1 − SLO'. Bu, ölçüm penceresi başına izin verilen maksimum hata oranıdır. Riskli sürümler ve deneyler hakkında kararlar vermek için kullanılır.
- Kullanılabilirlik SLO 99. 30 günde %95 - hata bütçesi 0. 05% ≈ 21. Bir takvim ayında 6 dakika "başarısızlık".
Dört altın sinyal ve ek
1. Gecikme (p50/p90/p95/p99, kuyruk ortalamadan daha önemlidir).
2. Hatalar (5xx/timeout/business errors).
3. Trafik/işlem hacmi (RPS/QPS, MBps).
4. Doygunluk (CPU/RAM/IO/FD/bağlantılar/GC/kotalar).
Ek: soğuk başlangıç, kuyruklar/backlog, dağıtım süresi, SLO uyumluluğu.
Farklı hizmet türleri için SLI modeli
HTTP/API
Kullanılabilirlik: '(başarılı 2xx/3xx − mantıksal hatalar )/( tüm istekler)'
Gecikme: Başarılı sorgular için 'p95'; Sıcak yollarda hedef.
Kalite: 'Kitle/kapsam' doğru olan isteklerin oranı (authZ hataları olmadan).
Kuyruklar/eşzamansız
Mesaj işleme süresi: p95 uçtan uca ≤ N saniye
Backlog: medyan <X, kuyruk p99 <Y.
Teslimat hatası: ≤ Z ppm.
DB/Önbellek
İşlem gecikmesi: p95 get/put/commit.
Doygunluk: bağlantı havuzu kullanımı, önbellek isabet oranı.
Hatalar: zaman aşımları, kilitlenmeler, tahliye fırtınaları.
CDN/Statik
Vuruş Oranı: hedef seviye ≥; degradation - orijinde yük büyümesi.
POP kullanılabilirliği: Her neyse, arızalar komşular tarafından telafi edilir.
Ödemeler (Business SLI)
Time-to-Wallet p95, depozito/çıkış başarısı %, PSP başarısızlık oranı.
Kullanılabilirlik ve çalışma süresinin hesaplanması
Hizmet kullanılabilirliği = 'başarılı istekler/tüm istekler' (tercihen 'çalışma süresi dakikaları'değil).
Altyapı düğümleri için bir alternatif'yeşil zaman/pencere zamanı'dır.
Takvim penceresi: 28-31 gün, sürgülü pencere: son 30/90 gün.
Çalışma saatleri/kritik pencereler: arka ofisler için çalışma süresi programa göre kabul edilebilir (örneğin, 08: 00-22: 00 yerel saat).
- 'Kullanılabilirlik (A) ≈ Av (B) × Av (C) × Av (A' B, C) '- SLO'ları sınırlara yerleştirmek önemlidir.
Örnek SLO kiti (örnek)
Ağ Geçidi API'si: ≥ 99 kullanılabilir. %95/30d; 120 ms ≤ p95 gecikme; Hata ≤ 0. 2%.
Ödeme/Ödemeler: Para yatırma başarısı ≥ 98. %5/30d; Time-to-Wallet p95 ≤ 90 с; PSP zaman aşımları ≤ 0. 3%.
Veritabanı: P95 okuma ≤ 10 ms; P95 yazma ≤ 25ms; Replika lag p95 ≤ 150 мс.
Önbellek: isabet oranı ≥ %85; Tahliye fırtınaları = 0/30д.
Ödemeler: p95 işleme ≤ 5 dakika; fraud-falls-positives ≤ 0. 3%.
Hata bütçesi ve değişim yönetimi
Hata bütçesi pencerenin ortasından önce %50 + tarafından tüketilirse, özelliklerin/sürümlerin "dondurulması" tanıtılırsa, odak sabitleme üzerinedir.
Bütçe yavaş yavaş harcanırsa, deneyleri/kanaryaları hızlandırabilirsiniz.
Bütçe tüketimini 'release _ id' aracılığıyla belirli sürümlere/olaylara bağlayın.
Uyarı: boşuna "gece aramak" nasıl
Yalnızca SLO bozulması ve hayati semptomlar için uyarılar, her metrik için değil.
Çoklu pencere, çoklu yanma oranı: kısa pencere (5-15 dakika) + uzun pencere (1-6 saat).
Örnek: "Burn rate 14 × in 5 minutes AND 6 × in 1 hour".
non-P1 sinyalleri için sessiz saatler; sahiplik yönlendirmesi.
Panolar ve görselleştirme uygulamaları
SLO paneli: hizmet uyumluluğu, kalan bütçe, bağımlılık haritaları.
Gecikme paneli: p50/p90/p95/p99, rotalara/kiracılara/ülkelere/ASN'ye göre ayrışma.
Hata paneli: kodlar/nedenler, sürümler/özellik bayrakları ile korelasyon.
Kapasite paneli: CPU/RAM/IO/ağ/FD/bağlantılar, eğilimler ve tahminler.
İş Paneli: Dönüşüm, Cüzdan Zamanı, Para Yatırma/Çekme, Korumaların Etkisi (WAF/Anti-Botlar).
Olaylar, MTTR ve post-mortemler
Reaksiyon KPI:- MTTD (algılama), MTTA (kabul), MTTR/MTTC (kurtarma/muhafaza), zamanında RCA olmadan % olaylar.
- Playbooks: kim yükselir, özellik bayrakları/blokları nasıl açılır, sürüm nasıl geri alınır, işletme ile iletişim.
- Ölüm sonrası (suçsuz): gerçekler, zaman çizgisi, kök nedenler (bu/süreçler), eylemler: anında/uzun vadeli, regresyon testleri, SLO'ya etkisi.
Performans, doygunluk ve bozulma
Headroom: hedef kaynak headroom (örn. CPU <%70 p95, RAM <%75 p95).
Sıcak yollar: kritik yolları profilleme; 'P99' ortalamadan daha önemlidir.
Bozulma modları: yalnızca önbellek, salt okunur, önemsiz isteklerin düşürülmesi, "oran sınırı "/kota.
Formüller ve hesaplama örnekleri
1) İsteğe bağlı kullanılabilirlik
availability = (total_requests - error_requests) / total_requests'error _ requests' = 5xx + zaman aşımları + iş hataları (yapılandırılabilir).
2) Hata bütçesi (dakika)
error_budget_minutes = window_minutes (1 - SLO)Örnek: 30 gün (43.200 dakika), SLO 99. 95% → 21. 6 dk.
3) Yanma oranı
burn_rate = observed_error_ratio / (1 - SLO)Eğer SLO 99 ise. 9 % (bütçe 0. %1) ve hata %1 - burn_rate = × 10.
4) Bileşik kullanılabilirlik
A_total ≈ A_gw × A_auth × A_db × A_pspKüçük düşmeler çarpı genel A'ya çarpar.
Ölçüm ve istisna politikaları
Planlanmamış pencereler (olaylar) - dikkate alınır.
Planlı bakım pencereleri - sadece SLA'nın bu şekilde reçete edilmesi durumunda dikkate alınır; SLO'lar için genellikle çıkarılmaz (veya 'planned _ downtime'olarak ayrı ayrı işaretlenir).
Sentetik vs gerçek kullanıcılar: Her iki kanala da sahip olmak yararlıdır (RUM + sentetik kontroller).
Eser örnekleri
KQL/PromQL (fikirler)
SLI hatası (5xx + zaman aşımları) 5 dakika içinde:promql sum(rate(http_requests_total{status=~"5.. timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)SQL (Payment Business SLI)
sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;Bağımlılıkları ve basamakları yönetin
Takımlar arasındaki SLO sözleşmeleri: gateway↔auth↔wallet↔PSP.
Bozulma politikaları: Bağımlılık düştüğünde, hizmet "basitleştirilmiş moda" geçer.
Özellik bayrakları: kritik olmayan işlevleri devre dışı bırakma, gecikme kuyruklarını azaltmak için "gri sürüm".
Kapasite Planlama ve Tahminleri
Schomes. RPS/MBps trendlere ve etkinliklere göre tahmin yapar (turnuvalar, maçlar, promosyonlar).
"Altın yollar'ile yük testi, PSP/ödemeler için ayrı testler.
Zirvede stok: hedef faktör 1. 3 × -2. Beklenen yükün × 0'ı.
SLO/KPI uygulama kontrol listesi
1. Kritik kullanıcı yollarını belirleyin ve SLI'yi "müşterinin bakış açısından" müzakere edin.
2. SLO hedeflerini ve penceresini seçin (30/90 gün); hata bütçesini hesaplayın.
3. Ağ geçitlerine/hizmetlere metrik toplama oluşturun, kodları/nedenleri normalleştirin.
4. Yazma hızı uyarılarını (kısa + uzun pencere), yönlendirmeyi ve çağrı üzerine yapılandırın.
5. SLO uyumluluğunu görselleştirin, sürümlerle/özellik bayraklarıyla ilişkilendirin.
6. Değişim politikasına ve dondurma işlemine karşı bir bütçe oluşturun.
7. Retrospektifler ve RCAs her fazlalık, regresyon testleri.
8. Gerçek bütçe kullanımı ve iş hedefleri için SLO'ları üç ayda bir gözden geçirin.
Yaygın hatalar
Uygulama hatalarını göz ardı ederek "çalışma süresini ping ile" ölçün.
SLO'lar "yedekte'olarak ayarlanır (99. %999), ama ulaşılamaz ve hiçbir şeyi çözmez.
Kullanıcı belirtileri yerine düşük seviyeli metriklerde uyarılar.
Bağımlılık haritası yok, nerede yandığı belli değil.
SLO ve sürümler arasında bir bağlantı yoktur - bütçeyi kimin "yediği" açık değildir.
P99 kuyruklarını görmezden gelin - iyi ortalama ama kötü UX VIP kullanıcıları.
iGaming/fintech'e özel
Planlanan zirveler: maçlar/etkinlikler/promosyonlar - kapasiteyi önceden artırın, önbelleği/CDN'yi ısıtın, özel sınır profilleri içerir.
İş SLI: Time-to-Wallet, para yatırma/çekme başarısı, "ödeme hızı" p95; Panoların kökünde.
PSP/iş ortakları: Sağlayıcıya göre bireysel SLO/gösterge panoları, otomatik rota değiştirme.
Antibot/anti-dolandırıcılık: hatalar için bütçe olmamalıdır - "meşru blokları" "teknik hatalardan" ayırın.
Düzenleme: günlük depolama, SLO/SLA hesaplamalarının tekrarlanabilirliği, olay raporları.
SSS
Planlanan işi SLO'dan çıkarmam gerekiyor mu?
Genellikle hayır: SLO, kullanıcının yaşadığı deneyimi yansıtır. SLA'lar için istisnalar belirleyebilirsiniz.
Neden p95, ortalama değil?
Ortadaki kuyrukları maskeler; UX kuyrukları tanımlar (p95/p99).
Tüm ürün için bir SLO alabilir miyim?
Bir SLO ağacına ihtiyacınız var: Ürüne ve çocuklara göre kritik yollara/bileşenlere göre toplanın.
Toplam
Güçlü bir altyapı KPI sistemi, özel SLI'lar, gerçekçi SLO'lar, bir değişiklik kontrol kolu olarak hata bütçesi, akıllı uyarı ve olay disiplini ve RCA'lardır. Teknik göstergeleri iş metriklerine bağlayın, toplama ve görselleştirmeyi otomatikleştirin - altyapı öngörülebilir hale gelecek ve çalışma süresi en yoğun senaryolarda bile kontrol edilecektir.