Observability’nin Sonu Yaklaşıyor (Ve Benim İçin Sorun Değil)

• Son birkaç on yılda Observability araçlarının temel hedefi, büyük ölçekli heterojen telemetry verilerini insanların anlayabileceği hale getirmek oldu
• Yapay zeka ve LLM’lerin ortaya çıkışıyla birlikte, mevcut "dashboard+uyarı+örnekleme" odaklı paradigma değişiyor ve analiz süreci otomasyonla yer değiştiriyor
• Gerçekte, bir AI ajanı yalnızca 80 saniyede 8 araç çağrısıyla gecikme sıçramasının nedenini analiz etti; önceki demolarda yapılan işi otomatikleştirip bunu sadece 60 sent maliyetle çözdü
• Mevcut gösterişli dashboard’lar veya kullanışlı enstrümantasyon artık özel bir değer taşımıyor; LLM’ler analizi, OpenTelemetry ise enstrümantasyonu metalaştırıyor
• Geleceğin Observability yaklaşımında “hızlı geri bildirim döngüsü” ile AI+insan iş birliği iş akışları başarının anahtarı olacak ve daha fazla yazılım ile otomasyon çağını yönlendirecek

---

Observability araçlarının tarihi ve AI’ın ortaya çıkışı

• On yıllar boyunca observability araçlarının temel amacı, devasa heterojen veriyi (telemetry) insanların anlayabileceği düzeye sıkıştırmak/özetlemek oldu
• Yeni yazılım soyutlamaları (ör. Rails, AWS, Kubernetes, OpenTelemetry vb.) ortaya çıktıkça,
  bu karmaşıklığı perdelemek için izleme, ölçüm, dashboard, uyarlanabilir uyarılar, dinamik örnekleme gibi çeşitli araçlar geliştirildi ve verinin karmaşıklığı insan biliş düzeyine uygun şekilde sıkıştırılarak sunuldu

LLM = genel amaçlı fonksiyon yaklaştırıcı ve artık gerçekten kullanışlı

• LLM’ler matematiksel olarak yalnızca bir genel amaçlı fonksiyon yaklaştırıcı (universal function approximator) olsa da, pratikte observability problemlerini çözmede çok faydalı
• Örnek olarak, Honeycomb demosunda ısı haritasındaki gecikme sıçramasının AI ajanı tarafından doğal dille analiz edilmesi istendi
  • “Frontend servisinde 4 saat arayla meydana gelen gecikme sıçramalarının nedenini analiz et”
  • Hazır bir LLM (Claude Sonnet 4) ile Honeycomb’un Model Context Protocol (MCP) entegrasyonu
  • 80 saniye, 8 araç çağrısı ve 60 sent maliyetle nedenin otomatik analizi
• Ek prompt, ayrı eğitim veya rehberlik olmadan gerçek senaryoları zero-shot olarak çözebilecek seviyeye ulaşıldı
• Analizin metalaşması (commoditization):
  • LLM’ler analiz işini otomatikleştirdiğinde, mevcut observability ürünlerinin farklılaştırıcıları (güzel grafikler, kolay enstrümantasyon vb.) anlamını yitiriyor
  • OpenTelemetry enstrümantasyonu, LLM’ler ise analizi metalaştırıyor
  • Bundan sonra observability araçlarının temel değerinin yerini “hızlı geri bildirim döngüsü” alacak

İnsanın rolü ve gelecekteki değişim

• İnsanın rolü tamamen ortadan kalkmıyor
  • Bulutun ortaya çıkışı IT’nin varlığını tamamen yok etmediği gibi, AI da geliştiricilerin/operasyon ekiplerinin yerini almayacak
  • Verimlilik artışı toplam alanı genişletir ve daha fazla yazılımın ortaya çıkmasına yol açar
• Temel soru şu:
  Kod yazma/refactor/analiz maliyetinin büyük ölçüde düştüğü ve analizin sabitleştiği bir dünyada,
  Observability’nin özü nereye gidiyor?

Gerçekten önemli olan şey “hızlı geri bildirim”

• En önemli şey, geliştirme ve operasyonun tüm aşamalarında “hızlı ve sık geri bildirim döngüleri” kurmak
  • AI hız konusunda her zaman insanın önünde olacak
  • LLM’ler onlarca hipotezi hızla kurup test eder, başarısız olur ve sonunda doğru sonuca ulaşır
    (üstelik bunun maliyeti de oldukça düşüktür)
• Honeycomb’un felsefesi:
  • Hızlı geri bildirim döngüleri, iş birliğine dayalı bilgi paylaşımı, deneysel geliştirme/operasyon
  • Bundan sonra AI desteği yazılım geliştirme ve operasyonun tüm yaşam döngüsüne girecek
    • Örnekler
      • Kod yazımı ve dağıtım sırasında AI ajanlarının gerçek zamanlı geri bildirim vermesi, hata/kalite iyileştirme önerileri sunması
      • Operasyon sırasında emergent behavior tespiti/analizi/otomatik raporlama, onay sonrası otomatik iyileştirme
      • En ileri organizasyonların SRE/SWE rollerini AI+araçlarla otomatikleştirip iş hedeflerine kadar doğrudan ulaşması
• Başarılı bir observability geleceği için gerekenler
  • Ultra düşük gecikmeli sorgu performansı
  • Entegre veri deposu
  • İnsanlar ile AI arasında sorunsuz iş birliği iş akışları
• Sonuç:
  • Geleneksel dashboard, uyarı ve görselleştirme odaklı observability araçları
    AI çağında artık temel unsur değil;
    yalnızca “hızlı geri bildirim döngüleri” ve AI-insan iş birliği platformları ayakta kalacak

[redlasha]

Observability, izleme için bir son olmadığı gibi, LLM de observability için bir son olmayacaktır.
Gelişmiş izleme temeli üzerinde observability’nin geliştiği gibi, gelişmiş observability temeli üzerinde de LLM analizi gelişecektir.

[ethanhur]

LLM sayesinde Observability alanının hızla yenileneceğini düşündüğüm için heyecanlıyım ama başlık tam anlamıyla clickbait olmuş, haha

[crawler]

Kendi hizmetlerini "son yaklaşıyor" diye tanıtmaları biraz utandırıcı geliyor...

Ben şahsen vision LLM'lerin gelişip izleme işlerinde kullanılmasını bekliyorum.

Yakın zamanda, bir ebeveynin VLM'i çocuğu uyurken olağan dışı bir durum olup olmadığını kontrol etmek için kullandığını anlattığı bir yazı görmüştüm; bu bana oldukça ilginç gelmişti.

[GN⁺]

Hacker News görüşü

• Toplu olarak determinizmin değerini fazla küçümsediğimizi ve buna karşılık determinizmin olmamasının getirdiği maliyeti de azımsadığımızı düşünüyorum. Kısa süre önce benzer bir satış söylemiyle çıkan başka bir ürünü test ettim; bu ürün, olaylarımı grafikler arasında ilişkilendirerek RCE yapmaya çalışıyor. Sonuçta ortaya Spurious Correlations sayfası gibi bir şey çıkıyor; bizzat görünce hem çok açık hem de komik duruyor
  • Zaman serisi verilerinin sahte korelasyonlara gerçekten çok açık olduğu daha iyi bilinmeli. r² değeri de anlamlı değil. Daha kötüsü, grafikleri göz kararı yorumlamak; veriler zaman içinde değişiyorsa buna uygun ölçütler kullanmak gerekir
  • Belki de anlatılmak isteneni yanlış anlamışımdır ama LLM tabanlı uygulamalarda da, eğer tasarım doğruysa, gerçekten kritik anlarda deterministik bir UX uygulanabilir. Gerektiğinde LLM’in bir şey yapması için deterministik bir spesifikasyon üretip ilgili görevi ya da aksiyonu kaydedebilirsiniz. Kullanıcının istediği zaman yeniden çalıştırabileceği spesifikasyonu konuşma içeriğiyle birlikte saklayacak, spesifikasyon başarısız olduğunda da AI’ın nasıl düzeltileceğine dair öneri sunacak şekilde tasarlayabilirsiniz. AI ile kod yazma deneyimine benzer bir akış olur. Sadece spesifikasyon alanını daha dar tutmak ve başarısız spesifikasyonların nasıl toparlanacağını daha çok düşünmek gerekir. Kullanıcıya ayrıca bir spesifikasyon dili öğrenmesini şart koşmadan da bu yapılabilir
• RCA konusunda iyi biri olarak, mahcup hissetmek istemeyen ekip arkadaşlarımın %10 hatalı sonuçları büyük bir özgüvenle veren araçlara körü körüne güvenip işleri daha da kötüleştirmesinden endişe ediyorum. Gerçekten bilmedikleri durumlarda bunu açıkça söylemek zorunda kalmayacakları için araca aşırı yaslanmalarından korkuyorum. Araç bir sonuca vardıktan sonra, o yoruma ters düşen verileri de arasa ve daha güvenilir kanıt ya da belirsizliği açıkça belirtse daha az kötü olurdu diye düşünüyorum
  • Sistem prompt’u iyi yazılırsa bu taraf bir ölçüde telafi edilebilir. Nitekim, LLM’den varsayılan olarak daha titiz ve daha iyi araştırılmış yanıtlar almak için özel prompt’lar/yönergeler hazırladım ve oldukça iyi sonuç aldım. ChatGPT’de kullandığım prompt şu: "Özü, açıklığı ve derinliği öncele. Tüm öneri, tasarım ve sonuçları hipotez olarak ele al ve sertçe sorgula. Gizli varsayımları, trade-off’ları ve başarısızlık durumlarını erken ortaya çıkar. Gereksiz övgüyü, dayanağı yoksa atla. Emin değilsen bunu açıkça söyle. Her zaman alternatif bakış açıları sun. Olgusal iddiaları yalnızca alıntı ya da güçlü gerekçe varsa kesin biçimde ifade et. Muhakemeye veya eksik bilgiye dayanıyorsan bunu net şekilde belirt. Kesinlikten çok doğruluğu önemse." Bu yapı gerçekten de yanıtların kalitesini ve derinliğini ciddi biçimde artırıyor
• “New Relic Rails devriminde, Datadog AWS’nin yükselişinde, Honeycomb ise OpenTelemetry’de öne çıktı” tarzı tarih anlatısı taraflı bir yorum. OpenTelemetry (OTel), Google’ın başlattığı OpenCensus ile LightStep’in başlattığı OpenTracing’in resmen birleşmesiyle doğdu. Google, LightStep, Microsoft, Uber ve başka birçok kuruluş ilk yönetişimde yer aldı. Honeycomb’un kod, topluluk ve teknolojinin benimsenmesi tarafında büyük etkisi olduğu doğru ama “öncülük etti” demek abartı
  • Bunu yakın zamanda kullanmaya başlayan biri olarak yazıyorum: Honeycomb gerçekten inanılmaz bir araç. Özellikle otel otomatik enstrümantasyonu sayesinde birkaç saat içinde içgörü elde edebiliyorsunuz. Dashboard/sorgu özelliklerinin de derin bir Observability felsefesinden çıktığı çok belli. Ekibimizde herkes aracın olgunluk seviyesine şaşırdı. Datadog ise daha çok pazarlama ve 'observability' kontrol listesine odaklanıyormuş gibi hissettiriyor
• “Satış söylemini” bir kenara bırakırsak, bu gerçekten LLM’lerin değer kattığı uygulama alanlarından biri. Bugüne kadar izleme ve observability büyük ölçüde yalnızca büyük şirketlerdeki SRE ekiplerinin alanıydı; küçük organizasyonlar içinse giriş bariyeri çok yüksekti (yalnızca IT açısından bakarsak). Anlamlı metrikleri seçmek, heartbeat ve baseline kurmak başlı başına zaman, uzman araçlar, geniş bir geliştirme ortamı ve değişiklik doğrulama süreçleri gerektiriyordu; bu yüzden sıradan IT ekipleri buna cesaret edemiyordu. Şimdi ise en yaygın araçlar üzerinde eğitilmiş LLM’ler sayesinde, bütçesi ya da yetkinliği sınırlı IT ekipleri de açık framework/araçlar üstünde “gerçek” bir observability sistemi kurabiliyor. Artık gösterişli abonelik çözümleri şart değil. Dashboard kurmak ve pratik izleme düzenleri hazırlamak gerektiğinde LLM gerçekten nimet gibi. CIO’nun dayattığı sayısız ürün ailesini tek tek derinlemesine inceleyecek vakti olmayan ama dokümantasyon okuyup troubleshooting yapabilen IT ekipleri için kullanışlılığı çok yüksek. PagerDuty uyarılarına en azından olası neden önerileri de eklenirse, SMB/SME tarafı için bu bir observability devrimi olur
  • Anlamlı metrikleri keşfetmek LLM’lerin yapabildiği bir şey değil ama heartbeat, baseline ve geri kalan kısımlar zaten çok önceden ConvNet’lerle yeterince otomatikleştirilebilecek alanlardı. Değişiklik doğrulama ya da kararlılık kontrolü gibi deployment kaygıları ise observability araçlarının kapsamı dışındaki konular
  • Küçük SRE ekipleri için de çok büyük etki yaratmasını bekliyorum. Bizim ekipte iki kişi yüzlerce bare-metal sunucuyu yönetiyor ve arıza çıktığında nedeni adım adım daraltmak çok stresli oluyor. Hatta MCP (Master Control Program) benzeri bir aracı kendimiz yazmayı düşündüğümüz oldu. Bazı durumlarda, uzun süre gizli kalmış sorunlar bir gün hataya dönüşerek patlıyor; böyle vakalarda LLM ciddi fayda sağlayabilir
• Başlık fazla sansasyonel duruyor. Mevcut observability araçlarının işe yaramaz hale geldiği söylenemez. Sadece grafik oluşturup onları sürekli incelemeye ayırdığımız zaman azalabilir. Bu, LLM’lerin diğer alanlardaki etkisine benziyor. Zaten yapabildiğiniz işleri daha hızlı yapmanıza ya da o işleri öğrenmenize yardımcı olabilirler ama belli bir tekniğin kendisini tamamen ortadan kaldırmazlar
  • “Zaten yapabildiğiniz işleri hızlandırmak” ve “yeni işleri öğrenmenize yardım etmek” sonucunu bugün ikinci kez duyuyorum. 2 numarayla inference yapıp, 1 numaranın verimliliğini uç noktalara taşımak, önümüzdeki dönemin en üretken yönü gibi görünüyor
  • Başlık sansasyonel ama mesaj açık — giriş bariyeri, yani hendek, giderek küçülüyor
  • Buna “Charity Majors etkisi” deniyor
• Demoda “Bu yapay bir örnek değil. Demoda kullanıcıya sorduğumuz sorunun aynısını LLM ajanına sorduk ve ek prompt, eğitim ya da yönlendirme olmadan doğru cevabı buldu” deniyor ama aslında bu senaryo zaten demonun bir parçası ve çözümü de zaten bilinen bir örnek. Hatta tam tersine, yapay bir örnek kullanıp modelin eğitim verisinde birebir bulunmayan yeni durumlara ne kadar genelleyebildiğini göstermeleri gerekirdi. LLM’in gerçek yetenekleri elbette faydalı ama “observability’nin sonu” gibi uç bir iddia için aracın genelleme becerisini göstermek gerekiyor
• Bunun “observability’nin sonu” olduğunu düşünmüyorum. Yine de yazıda öne sürülen noktalar tamamen temelsiz değil. Özellikle RCA dahil SRE içinde farklı roller üstlenebilen yeni bir yapay zeka ajan katmanının ortaya çıkması gayet olası. Ancak bu gerçekleşse bile mevcut observability yığınının büyük kısmına, hatta belki tamamına, yine ihtiyaç olacak. Üstelik LLM’lerin saçmalama, güven ve kararlılık sorunları kökten çözülmedikçe, derin problem analizi için insan hâlâ gerekli olacak
• “AI ile biraz uğraşarak uzmanların yaptığı işi yapabilirsiniz” iş stratejisi gerçekten çok cazip bir strateji. Üzücü ama bugün AI girişimlerinin %80’ine bu söylemi kopyalayıp yapıştırsanız sırıtmaz
  • Bunun alay olduğunu sanıyorum ama o “işini gerçekten bilen uzmanlar” <i>inanılmaz derecede</i> pahalı kaynaklar. Bu otomasyon gerçekten gerçekleşirse, neden ortalıkta bu kadar çok özensiz AI girişimi olduğu da daha anlaşılır hale geliyor
• Bu makale sanki tamamen AI tarafından yazılmış gibi duruyor. “AI bu paradigmayı bitiriyor, zaten bitirdi, sistemleri tasarlama ve işletme biçimimizi kökten değiştirecek” — verinin bir kısmını yorumlayabilmenin nasıl olup da “observability’nin sonu” anlamına geldiği bana hiç net değil
• “Artık veriyi grafikler ve UI üzerinden görmeye gerek yok” argümanının pratikte sınırları var. LLM iyi çalıştığında çok iyi ama başarısız olduğunda bir insanın devreye girip grafiklere ve diğer görselleştirmelere bakması gerekiyor. Grafikler ve görselleştirmeler zor olabilir ama asıl veri toplama, karmaşık sorgular ve veri saklama biçimlerinin tasarımı çok daha zor. Observability ancak gerçek yapay zeka neredeyse her şeyi kusursuza yakın değerlendirebildiğinde “ortadan kalkar”. O noktada ise toplumun genel yapısının tümden değiştiği, kültürel olarak sancılı bir dönüşüm yaşanıyor olur. AI’ın observability alanını değiştirdiği kesin. Bu süreç zaten başladı ama hâlâ gidilecek yol var