SLO ve Hata Bütçesi — Ne Kadar Bozuk Olmaya İzin Var?

Telefon faturan sana her ay belli bir internet kotası verir. Kotanın tamamını kullanmak bir hata değildir; aşmak ise bir karar gerektirir. Bir servisin güvenilirliği de tam olarak böyle yönetilir.

Ölçmek ve hedeflemek

SLI?Terimin tanımını açSLIService level indicator: servisin ölçülen güvenilirlik sayısı. Örneğin başarılı isteklerin toplam isteğe oranı ya da belli bir süreden hızlı dönenlerin oranı.Sözlükte gör → ölçtüğün şeydir: başarılı isteklerin oranı ya da belli bir süreden hızlı dönen isteklerin oranı. SLO?Terimin tanımını açSLOService level objective: bir SLI'ya konan hedef, örneğin 30 günde yüzde 99.9 başarılı istek. Müşteriye verilen SLA'dan sıkı tutulur.Sözlükte gör → o ölçüye koyduğun hedeftir: “ayın yüzde 99.9’unda başarılı”.

Hedefin tamamlayıcısı hata bütçesi?Terimin tanımını açerror budgetSLO'nun dışında kalan, servisin bozuk olabileceği pay. Kaldıkça risk alınır; bitince yeni özellik yerine güvenilirlik öne geçer.Sözlükte gör →dir. Yüzde 99.9 hedefi, geri kalan yüzde 0.1’in bozuk olmasına izin verir.

Bütçe ne kadar?

Yüzde 99 bir ayda 432 dakika, yüzde 99.99 ise 4.32 dakika demektir. Her ek dokuz bütçeyi on kat küçültür ve onu tutturmanın bedeli büyür.

Bu yüzden hedef “olabildiğince yüksek” değil, kullanıcının gerçekten ihtiyaç duyduğu kadardır. Kullanıcının fark etmediği güvenilirlik, harcanmış emektir.

Bütçe bir karar aracıdır

Bütçe kalmışsa ekip risk alabilir: yeni özellik çıkarır, deney yapar. Bütçe bitmişse yeni özellik deploy’ları durur ve ekip güvenilirliğe döner.

Bu kural, “hız mı, güvenilirlik mi” tartışmasını bir sayıya bağlar. Deploy riskini canary gibi bir yolla küçültmek, bütçeyi korumanın çoğu zaman en ucuz yoludur.

Kendin gör

1. Varsayılanla oynat. Yüzde 99.9 hedefinde ay, bütçeyi 1.8 dakika aştı.
2. Deploy’ları canary ile yap. Hatalı deploy 0.75 dakikaya indi; ay bütçe içinde bitti.
3. Hedefi yüzde 99.99 yap. Bütçe daha ilk olayda bitti.
4. Hedefi yüzde 99 yap. Aynı ay, bütçenin yalnızca onda birine yakın.

Tuzaklar

Sunucuyu ölçmek, kullanıcıyı değil. CPU yüzde 40 ve pod’lar ayakta, ama havalelerin yarısı başarısızsa kullanıcı için servis bozuktur. SLI, kullanıcının gördüğünü ölçmeli.

Ortalama gecikme. Ortalama 200 ms iken her yüz istekten biri 8 saniye sürebilir. Gecikme hedefi p95 ya da p99 üzerinden konur.

Bağımlılığından yüksek hedef. Kart ağı yüzde 99.9 ise, ona her istekte bağımlı bir servis daha yüksek bir hedefi tutturamaz.

Aşağıdaki örnek bir bankanın ödeme API’sinden: SLI’yi ölçen metrikler, SLO hedefi ve bütçe bitince deploy’u durduran bir kapı.

1
@Component
2
class TransferMetrics {
3

4
    private final MeterRegistry registry;
5

6
    TransferMetrics(MeterRegistry registry) {
7
        this.registry = registry;
8
    }
9

10
    // SLI = good / total over the window. "good" means the customer got an answer:
11
    // a business rejection (insufficient funds) is good, a 5xx or a timeout is not.
12
    void record(TransferOutcome outcome) {
13
        registry.counter("transfers.requests", "result", outcome.isServiceFailure() ? "bad" : "good").increment();
14
    }
15
}

1
service: payments-api
2
sli: transfers.requests{result="good"} / transfers.requests
3
objective: 99.9          # percent of requests
4
window: 30d              # 43 200 minutes -> 43.2 minutes of budget
5
policy:
6
  budget_exhausted: freeze-feature-deploys   # fixes and rollbacks still ship
7
  owner: payments-team

1
// Runs in CI before a deploy. A feature release waits while the budget is
2
// spent; a fix or a rollback is always allowed.
3
record BudgetGate(double objective) {
4

5
    boolean allows(Release release, double goodRatio) {
6
        if (release.isFixOrRollback()) return true;
7
        double budget = 1 - objective / 100;
8
        double spent = 1 - goodRatio;
9
        return spent < budget;
10
    }
11
}

Kendini sına