Olay araştırma

Bu kanonik araştırma akışıdır. Bir kez ezberleyin. Orbtrace ömrünüzün çoğunu bu döngüde geçireceksiniz.

1. 1

   Bildirimden onaylayın

   Bildirim (Slack mesajı, PagerDuty alarmı, e-posta) doğrudan olay detayına derin bağlantı içerir. Tıklayın. Sayfa, zaman seçici olayın penceresine ayarlı açılır.

   Üstteki Onayla butonuna basın. MTTA durur.

2. 2

   RCA panelini okuyun — eylemden önce doğrulayın

   Olayın üstündeki Sebep RCA paneli yapay zekânın hipotezini içerir. Okuyun. Sonra en az bir kaynaklanan span'e tıklayın — AI'nın uydurma cevap vermediğini doğrulayın. Span ID'leri tıklanabilirdir.

   RCA doğru görünüyorsa → 5. adıma atlayın. Yanlış görünüyorsa → devam edin, araştırmayı elle yapacaksınız.

3. 3

   Etkilenen servislere bakın

   "Etkilenen servisler"e kaydırın. En kötüye tıklayın — servis detayı açılır.

   Dört grafiği şu sırayla okuyun: RPS, sonra gecikme, sonra hata oranı, sonra doygunluk.

   • RPS değişmedi + gecikme arttı + hatalar arttı → downstream sebep.
   • RPS değişmedi + gecikme arttı + hatalar düz → kaynak tükenmesi (CPU/GC/kilit).
   • RPS düştü + hatalar arttı → servis iş kabul edemiyor; upstream'i kontrol edin.
   • RPS arttı + gecikme arttı + hatalar düz → trafik sıçraması, ya gerçek ya retry döngüsü.
4. 4

   Şüpheliye inin

   İki yol — ne gördüğünüze bağlı:

   Yol A — yavaş downstream şüphesi. Servis detayında "Operasyonlar" tablosuna kaydırın. p99'a göre azalan sıralayın. İlk satır şüpheli endpoint. Tıklayın → operasyon detayı → "Downstream çağrıları" paneline kaydırın → ilk satır suçlu downstream. Tıklayın. Onun servis detayı açılır. Tekrar edin.

   Yol B — kaynak tükenmesi şüphesi. Servis detayında doygunluk grafiğine bakın. CPU %100'de takılıysa, son deploy'lara bakın — yeni deploy'lar genelde sıcak döngü getirir. Bellek toparlanmadan tırmanıyorsa sızıntınız var. Loglara dönün: service:<ad> AND level:ERROR'u olay penceresinde süzün. Desen kümeleme görünümü "NEW" şablonları çıkarır — bunlar genelde yeni deploy'un işlemediği yollar.

5. 5

   Bir trace ile doğrulayın

   Cevabı bildiğinizi sansanız bile gerçek yavaş bir trace açın. Trace şelalesi üründeki en doğru artefakttır — bir gerçek isteğin ne yaptığını gösterir.

   Bakın: en uzun çubuk (zaman nereye gitti), status=ERROR çubuğu (nerede bozuldu), kesikli çizgiler (asenkron bağların bağlandığı yer). Şelalenin şekli isteğin hikâyesidir.

6. 6

   Mitigation kararı verin

   Mitigation kanamayı durdurmaktır, sebebi çözmek değil. Yaygın olanlar:

   • Şüpheli deploy'u geri al. Servis detayındaki deploy çipi → "CI'da aç" → geri al.
   • Şüpheli servisi ölçeklendir. Doygunluk sebepse daha fazla pod yardım eder.
   • Feature flag'i kapat. Yeni kod yolu gated ise flag'i çevirin.
   • Bozulmuş node'u boşalt. Bir Kubernetes node'u sıcaksa cordon-drain.

   Yaptığınızı olayın Notlar alanına yazın. Gelecekteki sizin buna ihtiyacı olacak.

7. 7

   İyileşmeyi izleyin

   Servis detayını açıp dört grafiği gerçek zamanlı izleyin. Zaman seçiciyi "Son 15 dk" yapın, 30 sn otomatik yenileme.

   Bozduğunuz metrik — genelde p99 ya da hata oranı — SLO içine dönüp en az bir gözlem penceresi kalınca olayı mitigating → resolved yapabilirsiniz.

8. 8

   Post-mortem'i dışa aktarın

   Olayın Post-mortem dışa aktar'ına basın. Zaman çizelgesi, RCA, notlar, ekli grafiklerle Markdown belge alırsınız. Post-mortem aracınıza atın. İsteğe bağlı ama güçlü — bir de Time-Travel Replay çalıştırıp ("ya deploy yapmasaydık?") sonucu ekleyin.

9. 9

   Zor olanı ayarlayın

   Toz çöktükten sonra Alarmlar → Analitik sayfasına bakın. Doğru alarm yandı mı? Çok geç mi? Çok erken mi? Eşiği ayarlayın. Eksik bir alarm mı keşfettiniz? Şimdi yaratın — gelecek çeyrek değil.

   RCA yanlışsa "Geri bildirimle RCA'yı yeniden çalıştır" deyip AI'ya neyi kaçırdığını söyleyin. Düzeltme embedding deposu üzerinden gelecek RCA'ları örtük olarak eğitir.

AI'nın RCA'sı şüpheli görünüyorsa

İki kırmızı bayrak:

• Span kaynağı yok — RCA her iddiayı kanıta bağlamak zorunda. Özette tıklanabilir ID yoksa istem yeterli bağlam toplayamamış.
• Güven %60 altı — Orbtrace bunu kendiliğinden "Düşük güven — eylemden önce doğrulayın" banner'ıyla işaretler. Düşük güvenli RCA'ya bağımsız doğrulama olmadan eyleme dökmeyin.

İki durumda da yukarıdaki manuel araştırma adımlarına (3-5) düşün.

Araştırma türüne göre çözüm süresi ortalamaları

Bunlar beta dağıtımlarından gözlenen sayılardır — sizinki değişir:

• RCA doğruyken işaretçiyi takip → medyan 6 dakika.
• Sistemi iyi tanıyorken manuel araştırma → medyan 14 dakika.
• 3 aydan az takımdaysanız manuel araştırma → medyan 38 dakika.

Son iki arasındaki fark genelde nereye tıklayacağını bilmek. Bu sayfa bu farkı kısaltmak için var.

Sırada: SLO tanımlayıp alarmları kurmak.