Çalışma Süresinden Deneyime: Modern Gözlemlenebilirlikte AI Destekli Dönüşüm

2001 yılında IBM, otonom bir BT manifestosu kaleme aldı. Autonomic Computing’in Vizyonu öz-yönetimi dört sütuna ayırdı: öz-optimizasyon, öz-iyileşme, öz-yapılandırma ve öz-koruma. IBM bu BT vizyonunu ortaya koyduğunda Microsoft’ta çalışıyordum. Otonom veri merkezi gibi teknoloji fikirleri önererek yanıt verdik, ancak sonuçta bu, zamanının çok önünde bir hayaldi. Bu vizyonu gerçeğe dönüştürmenin pratik bir yolu yoktu.

Microsoft’taki günlerimde, Clippy’nin arkasındaki ekibin bir parçasıydım. Animasyonlu kağıt ataş asistanı ünlü derecede rahatsız edici olsa da, ardındaki fikir sağlamdı: bilgisayarlar insanlara işlerini aktif olarak yapmalarında yardımcı olmalı. Ancak bunu mümkün kılacak hesaplama gücüne ve AI’ye sahip değildik. 25 yıl sonra nihayet bunu başardık.

Hizmet Seviyesinden Deneyim Seviyesine

Gözlemlenebilirlik kavramı BT’de ortaya çıkmadı. 1960 yılında, Macar‑Amerikalı mühendis ve matematikçi Rudolf E. Kálmán kavramı ortaya koydu “observability” terimini, bir sistemin çıktılarıyla ne kadar iyi ölçülebileceğini tanımlamak için. Ardından, 2013’te Twitter terimi benimsedi bir dizi blog gönderisinde, eski moda izleme yöntemlerinin, mevcut ticari hazır araçlarla, farklı bir teknoloji çağına yönelik tasarlandığını ve mikroservis ölçeğindeki mimarilerde işe yaramadığını etkili bir şekilde belirtti.

Bunu bir doktorun hastasını muayene etmesi gibi düşünün. Nabzını kontrol edebilir, kan basıncını ölçebilir ve diğer dış özellikleri gözlemleyerek hastanın iç sağlığını dolaylı olarak değerlendirebilir. BT’de de aynı şeyi yapmamız gerekir. Hastanın nabzında bir titreme olduğunda, bunun böbrekte mi yoksa karaciğerde mi bir sorun anlamına geldiğini bilmemiz gerekir. Twitter’ın 20 yıl önce (şirket sadece gerçek zamanlı tweet ve akışlarla 100 milyon kullanıcıya hizmet veriyordu) karşılaştığı ölçek ve operasyon karmaşıklığında, gözlemlenebilirlik farklı bir araç ve izleme yaklaşımı gerektiriyordu.

Günümüz sistemleri, içerik dağıtım ağları, önbellekleme ve bitmap, font, JavaScript dosyalarının dağıtımı gibi bağımlılıklarla birlikte, dünya çapında daha da büyük ve karmaşık hâle geldi. Gerçek dünya uygulamalarının performansını tam olarak anlamak kolay bir iş değildir.

IT ekibi sabah 4’te bir uyarı aldığında, birinin yataktan kalkıp sorunun sabit diskteki hatalı bir sektör mü yoksa altyapıya sızıp zarar vermeye çalışan kötü niyetli bir aktör mü olduğunu belirlemesi gerekir. Hangi durum olduğu aslında önemli değil: günün sonunda görevleri tüm sistemleri çalışır durumda tutmaktır. Neyse ki, bugün uygulama sağlığını değerlendirmek için tüm mevcut telemetrileri alabiliyoruz: her ağ cihazı, her uygulama, binlerce hazır entegrasyon, JIRA veya Atlassian üzerinden bilet akışı ve daha birçok sinyal.

İşte Experience Level Objectives (XLO’lar) burada devreye giriyor. Muhtemelen Service Level Agreements (SLA’lar) ve Service Level Objectives (SLO’lar) hakkında duymuşsunuzdur, ancak XLO’lar bir sonraki adımı atarak müşterilerinizin ve çalışanlarınızın istedikleri deneyim seviyesini elde edip etmediğini ölçer. Bu sadece çalışma süresi değil, kaliteyle ilgilidir. Teknik açıdan, XLO’lara ulaşmanın tek yolu NIC’ten uç‑kullanıcı cihazına kadar görünürlük sağlamaktır.

Geçen Ekim ayında, AWS US‑EAST‑1 çöktü. Catchpoint, Amazon’un kamuoyuna duyurmasından 16 dakika önce sorunu tespit etti. Bu görünürlüğe sahip müşteriler, kullanıcılarının kesintinin etkilerini hissetmeden önce müdahale edebildi.

Gözlemlenebilirliğin vaadi, Smokey Bear gibi olmak: yangın çıkmadan önce dumanın nerede olduğunu tespit etmek. Doğru yapıldığında, gözlemlenebilirlik bir çayır yangınını, Kaliforniya’daki Palisades’i yok edecek bir alev fırtınasına dönüşmeden söndürebilir. Smokey, dumanın nereden geldiğine bakılmaksızın (AWS sorunu, Oracle sorunu, GCP sorunu, Microsoft Azure sorunu ya da altyapınızdaki bir bozukluk) bu küçük duman izlerini algılayabilen erken uyarı sistemidir.

AI Güvenlik Sistemlerini Ölçeklendiriyor

Bugünün altyapı sistemlerini hiçbir insan operatör takip edemez. Sistemleri ölçekli bir şekilde, günde petabaytlarca günlük verisi ve trilyonlarca metriği işleyerek izlemenin tek yolu AI kullanmaktır.

Örneğin, bir diskin okuma/yazma performansını ya da ağ ortamınızdaki giriş/çıkış ya da paket tampon aşımını izlemek istediğinizi varsayalım. Normalin nasıl göründüğünü tanımlamak için dinamik bir eşik kullanabilir ya da geçen hafta, ay, yıl ya da istediğiniz herhangi bir zaman dilimindeki zaman serisi verilerine deterministik bir şekilde bakarak normal performans eşiklerini oluşturabilirsiniz. Bu istatistiksel analizi elde ettikten sonra, ortalamadan iki standart sapma seviyeleri belirleyebilir ve bu aralığın dışına bir şey geldiğinde performansın potansiyel olarak anormal olduğunu belirten bir uyarı alırsınız.

Ancak, son derece karmaşık sistemler günde binlerce uyarı alabilir. Panolar yanıp sönmeye başlar ve insanlar uyarı alır. Bu uyarıların tümünü ayıklamak insanların zamanını iyi kullanmaz. Gerçekten de, Vectra tahmin ediyor ki organizasyonlar günde ortalama 2.992 güvenlik uyarısı alıyor ve bunların %63’ü yanıtlanmadan kalıyor.

AI araçları, bu binlerce uyarıyı günde sadece birkaç düzineye indirebilir. Tek bir makinedeki tek bir NIC üzerindeki tek bir sorunun 2.000 alt uyarıya neden olduğu bir olayı hatırlıyorum. AI sayesinde, müşteri uyarı korelasyonu yapabildi ve çok daha hızlı bir kök neden analizi gerçekleştirdi; bu da bir anda tek bir sorunun şirketin tüm panosunun kırmızıya dönmesine yol açtığını ortaya koydu.

AI, BT’yi Yeniden Heyecanlı Kılıyor

Cisco’nun 2023’te Splunk’ı satın almasının ardından bir süre ara verdim. Sonraki iki yıl boyunca, arkadaşlarım ve eski meslektaşlarımın, beş yıl önce bile mümkün olmayan şekillerde AI kullanmak için şirketler kurduğunu izledim. (Unutmayın, ChatGPT bir insan çocuğu olsaydı, üç yaşında olurdu).

BT ekiplerinin alarm çalmadan önce dumanı tespit etmelerine yardımcı olacak bir şeye ihtiyacı var, daha fazla panoya bakmak yerine. Onlar. Bir bakıma, bu IBM, Twitter ve hatta Microsoft’un Clippy’iyle birlikte çözmeye çalıştığı aynı sorun.

Bu, tekrar devreye girmeye karar vermemin nedeni. Teknoloji nihayet, gözlemlenebilirlik ve özerk BT’nin orijinal vaadini yerine getirebileceğimiz bir noktaya ulaştı.