SLA ve SLO izleme

1) Şartlar ve roller

SLA (Hizmet Seviyesi Sözleşmesi) - müşteriye karşı harici sözleşme yükümlülüğü (ceza maddeleri, krediler).
SLO (Service Level Objective - Hizmet Düzeyi Hedefi) - SLA yürütmesini destekleyen dahili hizmet düzeyini hedefler.
SLI (Hizmet Seviyesi Göstergesi) - SLO/SLA'nın değerlendirildiği temelinde ölçülen gösterge.
Hata Bütçesi - dönem için izin verilen "kullanılamazlık/hata" yüzdesi: 'Bütçe = 1 − SLO'.
Kapsam: Kullanıcının gözleriyle ölçülür (uçtan uca). Mikro hizmetlerde, hem bileşen düzeyinde hem de uçtan uca yol düzeyinde.

2) SLI seçimi: tam olarak neyin ölçüleceği

Kriter, kullanıcı deneyimi ve iş değeri ile korelasyondur.

• Kullanılabilirlik: Başarılı taleplerin yüzdesi. 'SLI = successful/all'.
• Gecikme: Isteklerin oranı T. 'SLI = P (latency ≤ T)' eşiğinden daha hızlıdır.
• Kalite: Doğru cevapların oranı (5xx/functs olmadan. Hatalar).
• Veriler güncel - Çoğaltma gecikmesi/ETL ≤ X dakika.
• İş süreci performansı: Başarılı ödemelerin/kayıtların paylaşımı.

Anti-kalıplar: iş hatalarını göz ardı ederek sadece 200'ü "başarı'olarak sayın; Kullanıcı ağı yerine test ağında ölçün.

3) Formüller ve gözlem pencereleri

• 'Kullanılabilirlik = (OK_requests/ All_requests) × %100'.

• 'P95 ≤ T'daha iyi bir hisse olarak formüle edilmiştir:' SLI = T ≤ taleplerin %'si '.
• Örnek: "Arama sorgularının %99'u 28 günde 300 ms ≤".
• Sürgülü pencere: 28 veya 30 gün (hassasiyet ve stabilite dengesi). Olaylar için - ek pencereler: 1 saat, 6 saat, 24 saat.

4) Hata Bütçesi ve değişim oranı kontrolü

Hesaplama: 'SLO = 99'da. %9 'bütçe =' 0. Dönem başına %1 'hata/kullanılamama.

• Bütçe> %50: sürümler ve plan deneyleri.
• Bütçe %10-50: Sadece düşük riskli salımlar, kanaryaları sıkılaştırır.
• Bütçe <%10: serbest bırakma donması, kök nedeni, güvenilirlik iyileştirmeleri.
• Aşamalı sürümlerle bağlantı: Kanarya/özellik bayrakları bütçeyi dozlarda "yiyin", bozulma altında otomatik geri alma ile.

5) Politikacıları uyarın: eşiklerden yanma oranına

Neden "daupal SLO - uyarı yükseltin": çok geç. Proaktivite gerekiyor.

• 'BR = (kısa bir pencerede gözlemlenen hata/bu pencerede izin verilen hata)'.
• Eğer 'BR> 1' - bütçe normalden daha hızlı tüketilir.

• Hızlı uyarı (gürültü hassastır, felaketleri yakalar): pencere 5-10 dakika, eşik BR 14-20 ×.
• Yavaş uyarı (sürünen bozulmayı yakalar): pencere 1-6 saat, eşik BR 2-4 ×.
• Koşulları birleştirin: hızlı veya yavaş çalıştı - çağrı üzerine çağrı.
• Seviyeler: Kullanıcı SLO'ları için çağrı cihazı, dahili SLI'ların gri bozulması için biletler/bildirimler.

6) Gözlemlenebilirlik ve gerçeğin kaynakları

Günlükler - nedenlerin teşhisi.
Metrikler - sayısal SLI'lar (başarı/hata, gecikme yüzdeleri, kesirler, sayaçlar).
Yollar - yollar boyunca, "sıcak" segmentlerin yerelleştirilmesi.
Sentetikler - çevreden aktif örnekler (bölge-farkında).
Gerçek olaylar - RUM/müşteri telemetrisi, iş metrikleri (dönüşüm, başarılı ödemeler).

Gereksinimler: Sürümlerin ve olayların panolarında tek bir resim, ek açıklamalar "sürüm/kanarya/bayrak".

7) SLO tasarımı: adım adım şablon

1. Kritik yolu tanımlayın (örneğin, "kartla para yatırma").
2. SLI'yi tanımlayın: başarı/hata, gecikme eşiği, bütünlük.
3. SLO'ya katılıyorum: 28 günlük hedef + istisnalar (zamanlanmış pencereler).
4. SLA'ya bağlantı: Yasal yükümlülük ≦ gerçek SLO.
5. Bir servis sahibi, RACI ve uyarı kanalı atayın.
6. Uyarı ilkelerini (iki pencereli BR) ve otomatik geri dönüşleri tanımlayın.
7. Raporlamayı uygulayın: haftalık bütçe incelemeleri, olay sonrası incelemeler.
8. SLO'ları üç ayda bir gözden geçirin (load/architecture change).

8) SLO örnekleri (şablonlar)

• Kullanılabilirlik: '≥ 99. %95 '(28d, açıklanan pencereler hariç ≤ 30 dakika/ay).
• Gecikme: '≥ %99' yanıtları '≤ 400 ms'.
• Ticari faaliyetlerin başarısı: '≥ 98. %5 'başarılı yetkiler (sahtekarlık filtreleri dikkate alınır).

• Gecikme: '≥ %99' istekleri '≤ 300 ms'.
• Önbellek alaka düzeyi: Zamanın %99'unda '≤ 5 dakika' gecikmesi.

• Teslimat: 99 ≥. '≤ 60 s' için %9 '(retras ile uçtan uca).
• Kayıp: '≤ 0. %01 'iletileri (idempotency/veri tekilleştirme etkin).

9) Çok bölgeli ve çok kiracılı

SLO "kohort tarafından": ülke, ödeme sağlayıcısı, VIP segmenti, cihaz.
Kenardaki yerel SLO'lar: kullanıcıya en yakın noktalardan gelen metrikler (edge/PoP).
Toplama: Toplam SLO, önemli kohortlardaki arızaları gizlememelidir.
Anahtarlama sağlayıcıları: SLO kapısı seviyesinde otomatik geri dönüş yolları.

10) Gösterge panoları ve raporlama

Yayın panosu: sürüm, kanarya (% trafik), SLI (başarı/gecikme), BR, bayrak ek açıklamaları.
Çalışma panosu: güne göre bütçeyi yak, en iyi olaylar, MTTR, problem kohortları.
Haftalık raporlar: bütçe dengesi, BR eğilimleri, teknik borç (darboğazlar), iyileştirme planı.

11) Süreçler: Olaylar, RCA'lar ve İyileştirmeler

Olay yönetimi: uyarı - BR değerlendirmesi - kanarya/bayrak ölçeği - geri alma/düzeltme.
RCA (kök neden): gerçekler/zaman çizelgeleri/hipotezler/düzeltmeler/etki kontrolü SLI tarafından.
Öğrenilen dersler: cezai olmayan post-mortemler, sahipli zorunlu eylem maddeleri ve son tarihler.
Döngü kapatma: testlerdeki değişiklikler, özellik bayrakları, limitler, önbellekler, retrays, kotalar.

12) Uyumluluk ve denetim

Kontrol artifaktları olarak SLO/SLI (policy-as-code, immutable logs).
Gereksinimlere bağlantı (örneğin, ödeme işlemlerinin kullanılabilirliği).
Kanıt: uyarı dakikaları, bütçe raporları, serbest bırakma/geri alma günlükleri.

13) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

“99. %99 ya da ölüm": ulaşılamaz hedefler - sürekli uyarı-gürültü. Gerçekçi SLO'ları seçin.
Küresel ortalamalar yerel düşüşleri gizler - kohortları tanıtır.
Metrikler e2e değil: istemci üzerindeki gerçek bozulma sırasında yüksek SLO'lar - RUM/sentetikler ekleyin.
Bir eşikteki uyarılar - iki pencereli yanma oranına geçin.
Değişikliklere bağlantı yoktur - sürümler açıklamalı değildir, otomatik geri alma yoktur.

14) Mini Uygulama Kontrol Listesi

• Kritik yollar ve bunların SLI/SLO'su açıklanmıştır.
• İzleme ve dışlama penceresi ayarlanır.
• İki pencereli BR uyarıları (hızlı ve yavaş) yapılandırılmıştır.
• Sürümlerin/bayrakların ek açıklamaları ile sürümlerin ve işlemlerin panoları.
• Hata bütçesi politikası sürümleri etkiler.
• Düzenli bütçe incelemeleri ve olay sonrası RCA'lar.
• Dokümantasyon ve puan kartı sahipleri.

15) Hesaplama örneği (özellikler)

API kullanılabilirliği SLO: 99. 28 günde %9 - bütçe = 0. 1%.
7 gün boyunca 0 biriktirdi. Hataların %06'sı, haftalık bütçenin %60'ını kullandı.
15 dakikalık kısa bir pencerede, hataların %2'si gözlemlenir. Bu pencerede geçerli '0'dır. 1 % × (15 dk/40320 dk) ≈ 0. 000037%`.
Yanma Oranı ≫ 1 (onlarca ×) - hızlı bir çağrı cihazı tetiklenir, kanarya %1'e geri döner, degrade-payments-UX özelliği bayrağı açılır, RCA başlar.

16) Alt satır

SLA/SLO izleme sadece rapordaki rakamlar değil, aynı zamanda değişiklik riskini ve hizmet kalitesini yönetmek için bir mekanizmadır. Doğru SLI'lar, gerçekçi SLO'lar, hata bütçesi yönetimi, iki pencereli yakma oranı uyarıları ve e2e-gözlemlenebilirlik, metrikleri çalışma çözümlerine dönüştürür: değeri daha hızlı serbest bırakır ve kullanıcı deneyimini öngörülebilir tutar.