Oncall Bot ve frontend izleme

Sorun

NFC kontrolleri gibi üçüncü taraflara geçiş sırasında yaşanan sessiz kayıplar, günler sonra müşteri desteği aracılığıyla fark ediliyordu. Uyarılarımız sabit eşiklere dayanıyordu ve çok gürültülüydü; herkes onları görmezden gelmeye alışmıştı.

Yaklaşım

• Sabit eşikler yerine göreli referanslar. Uyarı servisi ClickHouse üzerinde SQL çalıştırır ve her metriği geçen haftanın aynı saatiyle karşılaştırır. Dönüşümdeki %20’lik bir düşüş Tokyo’da gece 3’te ve Berlin’de öğlen farklı anlamlara gelir; küresel trafik dalgalanmaları artık yanlış alarm üretmez.
• Bağlamıyla gelen bir uyarı. Bir uyarı tetiklendiğinde şirket içi sohbet platformuna bir olay kartı gönderir. Ardından arka planda çalışan bir işlem ClickHouse’tan son frontend hata yığın izlerini, yapılandırma servisinden etkin yapılandırma sürümünü ve Kubernetes dağıtım loglarını toplar ve bunları yapılandırılmış bir istem olarak kurumsal bir LLM API’sine gönderir.
• Dizinin içinde bir özet. Bot olası bir kök nedenle yanıt verir; örneğin: Japonya’da 3. adımdaki dönüşüm %32 düştü, NFC köprüsü sarmalayıcısında bir null pointer hatası var, 15 dakika önce bir yapılandırma değişikliği dağıtıldı ve backend’de bir tedarikçi ağ geçidi zaman aşımına uğruyor.

Sonuç

Tespit süresi saatler ya da günlerden 5 dakikanın altına indi, etkiyi azaltma süresi %65 ve yanlış alarmlar %80 azaldı. Uyarıların sinyal-gürültü oranı (gerçek olaylara karşılık gelen uyarıların payı) ve frontend modülleri için arızalar arası ortalama süre de takip edildi.

Neden böyle

Sıradan bir uyarı yalnızca bir şeyin bozulduğunu söyler. Veriyi otomatik olarak toplayıp özetlemek, bir metrik ile onu anlayan bir insan arasındaki boşluğu kapatır; müdahale süresinin çoğu da tam olarak orada harcanıyordu.