SLO + alarmlar

Bu iş akışı "checkout bazen yavaş" durumunu ölçülebilir bir söze ve onu koruyan alarmlara çevirir. Süre: SLO başına ~15 dakika.

1. Adım — Neyi ölçeceğinize karar verin

Servis başına kullanıcıya görünür tek bir sinyal seçin. Yaygın seçimler:

Servis başına birden çok SLO olabilir ama her türden en fazla biri. Bir HTTP servisine "erişilebilirlik" + "gecikme" eklemek normaldir; aynı servise üç farklı gecikme SLO'su mühendislik yutmacasıdır.

2. Adım — Hedef seçin

%100 seçmeyin. Ölçemeyeceğiniz bir şey seçmeyin.

Kullanıcıya dönük HTTP API için ortak başlangıç:

• Erişilebilirlik: %99,9 başarı, 30 günlük pencere. Hata bütçesi: ayda 43 dk.
• Gecikme: isteklerin %99'u 500 ms altında, 30 günlük pencere. Hata bütçesi: ayda 7 sa 12 dk.

Dahili API'ler için %99 / %99,5 daha dürüst. SLO'nun amacı takım hedefi neredeyse hep tutar olmaktır; sürekli çağrı yiyorsa hedef yanlıştır, takım değil.

3. Adım — Orbtrace'te SLO yaratın

1. 1

   Yönetim → SLO'lar

   Kenar menü → Yönetim → SLO'lar. + SLO ekle.

2. 2

   Servisi seçin

   Açılır liste. checkout-api.

3. 3

   Türü seçin

   Gecikme p99 ya da Başarı oranı.

4. 4

   Hedef ve pencere

   Gecikme: < 500 ms. Pencere: 30 gün.

   Sayfa, bu SLO son 30 gün boyunca geçerli olsaydı hata bütçenizin ne olacağına dair canlı önizleme gösterir. Hedefi sağlamak için kullanın — geçen ay bütçenin 12×'i yanmış olacaktıysa hedef çok dar.

5. 5

   Kaydet

   SLO listede belirir. Bundan sonra:

   • Servis detayı KPI kutucuklarının rengi.
   • Trace şelalesi span rengi.
   • 4. adımda kuracağınız SLO yanma alarmları.

4. Adım — Dört pencereli yanma alarmlarını bağlayın

Yanma alarmları "bütçemi ne kadar hızlı yiyorum?" sorusunu yanıtlar. Dört pencere dört tür olayı yakalar:

1. 1

   Alarmlar → Yeni

   Kenar menü → Alarmlar → + Yeni kural.

2. 2

   SLO modunu seçin

   Üstte Eşik | SLO yanma oranı anahtarı. SLO yanma oranı'na geçin.

3. 3

   SLO'yu seçin

   Açılır liste tanımladığınız SLO'ları gösterir. 3. adımda yarattığınızı seçin.

4. 4

   Dört pencereyi onaylayın

   Varsayılanlar iyidir. Her pencerenin önemi sırasıyla P0 / P1 / P2 / P3 ön ayarlıdır. Gerekirse değiştirin.

5. 5

   Etiketleri ayarlayın

   En azından: team=payments (ya da hangi takımsa), service=checkout-api. Yönlendirme doğru kanalı bunlardan bulur.

6. 6

   Açıklamaları ayarlayın

   summary: "Checkout-api gecikme SLO'sunu yakıyor". runbook_url: takım runbook bağlantınız. Bu değerler her Slack/PagerDuty bildirisinde görünür.

7. 7

   Kaydet

   Kural Alarmlar → Kurallar'ta her pencere için bir satır olarak görünür. Her pencere bağımsız susturulabilir.

5. Adım — İnsana ulaşabildiğinden emin olun

Bir kez. Şu an. Kanallar → takım Slack kanalınız → Test mesajı gönder. Mesajın geldiğini doğrulayın.

P0/P1'de çağrı yapacaksanız PagerDuty için tekrarlayın.

Sonra Yönlendirme → "Yönlendirmeyi test et" → team=payments severity=P1 etiketleri girin → beklediğiniz kanallara çıktığını onaylayın.

6. Adım — Bir hafta izleyip ayarlayın

Bir hafta sonra için kendinize hatırlatıcı ayarlayın. Sonra Alarmlar → Analitik'i açın. Yeni SLO için:

• Kaç kez yandı?
• Kaçı gerçek olaydı?
• Kaçı susturulup unutuldu?

Cevap "5'ten fazla gürültü çağrısı"ysa eşiği ya da süreyi genişletin. "Hiç yanmadı"ysa iyimser tarafta abartmış olabilirsiniz.

Yaygın hatalar

• Hareket ettiremediğiniz metrikte SLO. "Toplam hata" SLO değil; "hata oranı" SLO. Takımın çevirecek bir düğmesi olmalı.
• Pencere çok kısa. 30 gün standart. 1 saatlik pencere alarm spam üretir.
• Tek serviste birden fazla gecikme hedefi. Bir tane seçin. Bileşik SLO'lar nöbeti kafaya karıştırır.
• Etiket yok. Etiketsiz yönlendirme her şeyi varsayılan kanala atar. Her kuralı team ve service ile etiketleyin.

Sırada: Time-Travel Replay çalıştırın.