Kullanıcıların Bildirdiği Hataları İzleyen ve Önceliklendiren Yapay Zeka Ajanı

Üretimdeki bir hata hiçbir zaman doğru zamanda kendini göstermez. Kimsenin gerçek zamanlı izlemediği bir log akışında kaybolan bir hata olarak ya da teknik nedenini bilmeden belirtiyi tarif eden bir müşterinin açtığı bir destek ticket'ı olarak ortaya çıkar. İkisi arasında genellikle otomatik hiçbir bağlantı yoktur: mühendislik ekibi sorunu, destek ekibi sonunda yükselttiğinde, bazen ilk kullanıcıların onunla karşılaşmasından saatler sonra keşfeder. Her iki akışı aynı anda izleyen otonom bir yapay zeka ajanı, bu farkı kapatır.

Sorun

Geliştiricilerin yeni kod yazmak yerine hata düzeltmeye ayırdığı zaman, yazılım mühendisliğinin en iyi belgelenmiş verimlilik kayıplarından biri olmaya devam ediyor. Rollbar'ın (Propeller Insights aracılığıyla) 950 geliştiriciyle yaptığı küresel bir araştırma, geliştiricilerin %32'sinin haftada 10 saate kadarını kod yazmak yerine hata düzeltmeye ayırdığını ve %38'inin bunun için toplam çalışma süresinin dörtte birine kadarını harcadığını gösteriyordu (kaynak). Bu araştırma 2021 tarihli olup güncel bir ölçüm yerine bir büyüklük mertebesi olarak okunmayı hak ediyor, ancak belgelediği gözlem, mühendislik zamanının önemli bir kısmının inşa etmek yerine düzeltmeye harcanması, daha yakın tarihli geliştirici verimliliği araştırmalarında da düzenli olarak tekrarlanıyor.

Asıl mesele yalnızca düzeltme süresi değil, bir sorunun ortaya çıkışı ile tespiti arasındaki gecikmedir. DORA State of DevOps 2024 raporu bu konuda net referans noktaları belirliyor: en yüksek performanslı ekipler bozulmuş bir hizmeti bir saatten kısa sürede geri getiriyor, yüksek performanslı ekipler bir günden kısa sürede, orta düzey ekipler bir gün ile bir hafta arasında, en düşük performanslı ekipler ise bir hafta ile bir ay arasında sürebiliyor (kaynak). Bu ölçeğin üst ve alt ucu arasındaki fark bu nedenle saatlerle değil haftalarla ölçülüyor ve bu süre, bir anomalinin daha düzeltilmeden önce ne kadar hızlı tespit edilip doğru şekilde önceliklendirildiğine doğrudan bağlı.

Bu gecikme, sorun üretimi etkilediğinde doğrudan bir maliyete dönüşüyor. Kasım 2023 ile Mart 2024 arasında dünya genelinde 1.000'den fazla şirketle yürütülen ITIC 2024 araştırması, orta ve büyük ölçekli şirketlerin %90'ından fazlası için bir saatlik kullanılamama süresinin ortalama maliyetinin 300.000 doları aştığını ve büyük şirketlerin %41'inin bu saatlik maliyeti 1 ila 5 milyon dolar arasında değerlendirdiğini gösteriyor (kaynak). Bu rakamlar büyük kesintilerle ilgilidir ve her tekil hataya uygulanmaz, ama erken tespit edilebilecek bir sorunun kimsenin sürekli izlemediği bir log akışında boğularak çok uzun süre görünmez kalmasının bedelinin büyüklük mertebesini gösteriyor.

Birbirine yakın iki kullanımı karıştırmamak için bir noktayı netleştirmekte fayda var. Bir dağıtım üretime ulaşmadan önceki derleme ve test hatalarıyla ilgili olan CI takibi, burada ele alınandan farklı bir sorundur. Bu sayfa dağıtım sonrası izlemeyi kapsar: kullanıcılarda gerçekten meydana gelen hatalar ve bunları tarif etmek için açtıkları destek ticket'ları; genellikle aynı olayı anlatan ama hiçbir zaman otomatik olarak birbirine bağlanmayan iki akış.

Bu bağlantı eksikliğinin önceliklendirme üzerinde somut bir etkisi var. Loglarda beş ayrı teknik hata üreten ama yirmi aynı destek ticket'ına neden olan bir hata acil bir işlem gerektirirken, yüz teknik hata üreten ama tek bir müşterinin bile şikayet etmediği bir hata çoğunlukla bir sonraki döngüyü bekleyebilir. İki kaynak birbiriyle ilişkilendirilmeden, bir mühendislik ekibi yalnızca teknik hacme dayanarak kör bir şekilde önceliklendirme yapar; bu da kullanıcıların gerçekte yaşadığı etkiyi her zaman yansıtmaz.

Ajan Ne Yapıyor, Adım Adım

Ajan, klasik bir izleme aracıyla aynı ham veriyi, yani üretim hata akışlarını, gecikme metriklerini ve uygulama loglarını sürekli izler. Fark bir sonraki adımda başlar: bir stack trace yerine sıradan bir dille bir teknik anomaliyi tarif eden bildirimleri tespit etmek için, kullanıcıların açtığı destek ticket'larını paralel olarak izler. Ardından, ham bir uyarı sisteminin yapacağı gibi her olayı tek tek ele almak yerine, aynı sorunu tarif eden hataları ve ticket'ları gruplar. Bu gruplamadan yola çıkarak, anomalinin sıklığını, tahmini kullanıcı etkisini ve kritikliğini değerlendirir. GitHub veya Linear'da; sorunun açıklaması, stack trace, bir etki tahmini ve zaten belirlenmiş bir öncelik düzeyiyle yapılandırılmış bir issue oluşturur. İlgili ekibi, zaten bir araya getirilmiş bu bağlamla Slack üzerinden bilgilendirir ve yalnızca önceden tanımlanan kritiklik eşikleri aşılırsa nöbetçi ekibe yükseltir.

Kullanılan Entegrasyonlar

Tespit, Datadog üzerine ya da hata ve stack trace takibinde uzmanlaşmış bir araç tercih eden ekipler için Sentry üzerine kuruludur. Kullanıcı deneyimiyle ilişkilendirme, izleme tarafında tespit edilen teknik hataları açılan ticket'larla karşılaştırmak için Intercom üzerinden ya da kullanılan destek aracına göre Zendesk üzerinden gerçekleşir. Issue oluşturma, ekibin takip aracına göre GitHub veya Linear üzerinde, açıklama, stack trace ve öncelik düzeyi zaten doldurulmuş olarak yapılır. Slack ekip bildirimlerini taşır ve kritikliği belirlenen eşiği aşan olaylar için PagerDuty'ye bir yükseltme tetiklenebilir.

İnsana Kalanlar

Mühendislik ekibi, ajanı yapılandırırken kritiklik eşiklerini ve yükseltme kurallarını tanımlar; bu başlangıç çerçevesi daha sonra neyin nöbetçiye bir uyarı tetikleyip tetiklemeyeceğini belirler. Stack trace ve tahmini etki dahil olmak üzere zaten elenmiş ve bağlamlandırılmış issue'lar alır ve ham loglardan bağlamı yeniden kurmak yerine yalnızca düzeltmeyi yazmakla ilgilenir. Ürün geliştikçe önceliklendirme kurallarını ayarlar; yeni bir modül veya yeni bir entegrasyon, belirli bir anda neyin kritik sayıldığını kaçınılmaz olarak değiştirir. Düzeltmenin kendisi, acil bir hotfix mi yoksa planlanmış bir düzeltme mi hak ettiğine karar vermek, tamamen insana ait bir karar olarak kalır.

Ölçülebilir Sonuç

En doğrudan fayda, bir sorunun üretimde ortaya çıkışı ile bir log akışında kaybolmak veya aynı belirtiyi tarif eden ama birbirine bağlanmamış birden fazla destek ticket'ına dağılmak yerine kullanılabilir bir issue olarak bildirilmesi arasındaki sürenin kısalmasıdır. DORA raporunun belgelediği, en yüksek performanslı ekipler için bir saatten kısa sürede hizmet geri getirme ile orta düzey ekipler için birkaç gün arasındaki fark göz önüne alındığında, tespit ve eleme süresini kısaltmak, bir ekibin ortalamada takılı kalmak yerine bu ölçeğin üst ucuna yaklaşma kapasitesini doğrudan etkiler. İkinci fayda, nöbetçi için daha az gürültüdür: yalnızca önceden tanımlanmış bir eşiği aşan kritiklikteki anomalileri bildirerek, ajan önemsiz hatalar için gereksiz kesintileri azaltır; bu, genişletilmiş bir nöbet rotasyonu olmayan ve her gece yarısı uyanmanın ertesi günün erişilebilirliğini ve odaklanmasını doğrudan etkilediği küçük ekipler için özellikle önemli bir noktadır; gürültü iyi filtrelenmezse birkaç hafta boyunca birikimli bir etki yaratır.