AI Sistemleri Sadece İzlemiyor: BT Operasyonlarında “Observability” Dönemi Değişiyor

Sorun Artık Veriyi Toplamak Değil

BT operasyonlarının uzun yıllar temel problemi görünürlük eksikliğiydi.

Bir sunucunun CPU kullanımı ne durumda? Ağ gecikmesi arttı mı? Bir servis cevap veriyor mu? Disk doluyor mu?

Monitoring sistemleri tam olarak bunun için geliştirildi.

Fakat modern altyapıda sorun tersine dönmüş durumda: artık veri az değil, fazla.

Uygulamalar, API'ler, mikroservisler, container'lar, network cihazları ve cloud servisleri sürekli metrics, logs, traces ve event verisi üretiyor. Integrated Research'ün How AI is Transforming Observability çalışması da modern dijital altyapının operasyon ekiplerinin insan gücüyle anlamlandırmakta zorlanacağı büyüklükte veri yarattığını vurguluyor.

Dolayısıyla yeni soru şu:

Sistemlerimiz hakkında ne kadar veri topluyoruz değil, bu veriden ne kadar hızlı anlam çıkarabiliyoruz?

Observability ile AI'ın kesiştiği yer tam olarak burası.

Monitoring ile Observability Aynı Şey Değil

Geleneksel monitoring çoğunlukla önceden tanımlanmış kurallara dayanıyor.

CPU %80'i geçtiyse alarm ver.

Latency 200 ms'yi geçtiyse alarm ver.

Disk %90 dolduysa alarm ver.

Bu yaklaşım hâlâ gerekli. Fakat modern dağıtık sistemlerde tek başına yeterli değil.

Observability ise yalnızca “ne oldu?” sorusuna değil, “neden oldu?” sorusuna cevap vermeye çalışıyor.

Bunu üç temel veri katmanı üzerinden yapıyor:

Metrics: Sistemde ne oluyor?

Logs: Hangi olaylar gerçekleşti?

Traces: Bir işlem sistem içerisinde hangi yolu izledi?

Raporun dikkat çektiği temel problem ise bu üç veri katmanının büyüklüğü. Büyük bir kurumsal uygulama tek başına her gün terabaytlarca observability verisi üretebiliyor.

Sonuç biraz ironik:

Sistemleri daha görünür hale getirdik ama ortaya çıkan veri miktarı nedeniyle onları anlamak zorlaştı.

AI Observability'yi Nasıl Değiştiriyor?

Raporda dönüşüm beş ana alanda ele alınıyor:

Intelligent Anomaly Detection → Automated Root Cause Analysis → Predictive Alerting → Natural Language Interfaces → Self-Healing Systems.

Bu sıralama aslında observability'nin geleceğine ilişkin oldukça önemli bir yol haritası sunuyor.

Çünkü sistemler yalnızca daha iyi alarm üretmeye başlamıyor.

Adım adım karar vermeye yaklaşıyorlar.

1. Statik Threshold Yerine Davranışı Öğrenmek

Geleneksel monitoring sistemlerinin temel problemi eşik değerleridir.

Örneğin:

CPU > %80 → Alarm

Fakat %80 CPU gerçekten sorun mudur?

Salı günü saat 14:00'te normal olabilirken pazar günü saat 02:00'de son derece sıra dışı olabilir.

AI tabanlı anomaly detection sistemleri bu nedenle sabit eşikler yerine sistemin normal davranış modelini öğrenmeye çalışıyor.

Saat, gün, sezon, trafik paterni ve diğer metriklerle ilişkiler hesaba katılabiliyor.

Bunun çok daha ilginç sonucu ise tek tek normal görünen metriklerin birlikte anormal bir davranış oluşturabilmesi.

Raporda unified communications üzerinden verilen örnek bunu güzel gösteriyor:

Jitter biraz yükseliyor.

Packet loss biraz artıyor.

Codec seçimlerinde alışılmadık bir değişiklik oluşuyor.

Tek tek bakıldığında hiçbir değer alarm seviyesinde değil.

Ama üçü birlikte yakında oluşacak bir network probleminin erken sinyali olabilir.

İnsan operatörün kaçırabileceği korelasyonu model yakalayabilir.

Bu observability açısından önemli bir zihniyet değişimi:

“Threshold aşıldı mı?” yerine “Sistem normal davranıyor mu?”

2. Root Cause Analysis Dakikalara, Hatta Saniyelere İniyor

Bir incident başladığında sistem yöneticilerinin yaptığı şey pek değişmedi:

loglara bak,

timestamp'leri karşılaştır,

network'ü kontrol et,

deployment var mı bak,

configuration değişmiş mi incele,

servis bağımlılıklarını araştır.

Dağıtık sistemlerde bu araştırma saatler sürebiliyor.

AI destekli observability ise metrics, logs ve traces arasındaki ilişkileri otomatik olarak inceleyerek olası nedenleri sıralayabiliyor.

Raporda geleneksel root cause investigation için 2-3 saat, AI destekli yaklaşım için ise yaklaşık bir dakika örneği veriliyor. Whitepaper bunu teorik olarak “179 kata kadar daha hızlı root cause analysis” şeklinde görselleştiriyor.

Buradaki önemli nokta yalnızca hız değil.

AI sistem içerisindeki dependency graph'ı anlayarak şu ilişkiyi kurmaya çalışıyor:

Problem → Etkilenen servis → Bağımlı servis → Önceki değişiklik → Muhtemel neden

Dolayısıyla observability sistemi artık sadece veri gösteren araç olmaktan çıkıyor.

Araştırmaya katılan bir sisteme dönüşüyor.

3. En Büyük Değişim: Alarm Vermek Değil, Problemi Tahmin Etmek

Bence observability'deki asıl kırılma burada yaşanacak.

Bugünkü monitoring mantığı:

Problem → Alarm → İnsan → Müdahale

AI destekli predictive observability ise bunu şöyle değiştirmeye çalışıyor:

Sinyal → Tahmin → Müdahale → Problem hiç oluşmuyor

Makine öğrenmesi modelleri geçmiş incident'lar öncesindeki davranışları öğrenerek benzer koşullar tekrar oluştuğunda erken uyarı verebilir.

Örneğin sistem şöyle diyebilir:

Mevcut büyüme hızına göre database connection pool yaklaşık dört saat içerisinde tükenecek.

veya:

Mevcut kapasite eğilimine göre storage üç gün içerisinde dolacak.

Rapor bu yaklaşımı operasyonların reactive'den predictive'e geçişi olarak tanımlıyor.

Bu küçük bir özellik değişikliği değil.

Monitoring'in temel amacı değişiyor.

Eskiden amaç:

Sorunu mümkün olduğunca hızlı bulmak.

Yeni amaç:

Sorunun ortaya çıkmasını engellemek.

4. Observability'nin Yeni Arayüzü Dashboard Değil, Dil Olabilir

AI'ın daha sessiz fakat belki de en büyük etkilerinden biri natural language interfaces.

Bugün observability araçlarını etkili kullanmak çoğu zaman query language, data schema ve sistem mimarisi bilgisi gerektiriyor.

Generative AI bu bariyeri azaltıyor.

Bir mühendisin sorgu yazmak yerine şunu yazdığını düşünelim:

Son bir saat içerisinde payment service'e yapılan başarısız API çağrılarını göster.

Ya da:

İstanbul ofisindeki VoIP çağrılarında saat 10:00'dan sonra packet loss neden yükseldi?

AI gerekli sorguları oluşturup logs, metrics ve traces üzerinde araştırma yapabilir.

Raporda bu dönüşümün observability verisini yalnızca uzman ekiplerin erişebildiği bir yapıdan daha geniş organizasyonun kullanabileceği bir sisteme dönüştürebileceği savunuluyor.

Bu noktada dashboard tamamen ortadan kalkmayacaktır.

Ama observability'nin ana kullanıcı arayüzü giderek konuşma olabilir.

5. Sonraki Aşama: Self-Healing Infrastructure

AI önce problemi tespit ediyor.

Sonra nedenini buluyor.

Sonra problemi tahmin ediyor.

Mantıksal sonraki adım oldukça açık:

Problemi kendisi çözmek.

Raporda automated remediation ile self-healing arasında önemli bir ayrım yapılıyor.

Automated remediation önceden tanımlanmış kurallara dayanıyor:

Disk %90 → eski logları temizle.

Service health check başarısız → container'ı restart et.

Self-healing sistem ise geçmiş müdahalelerden hangi çözümün hangi koşullarda başarılı olduğunu öğrenmeye çalışıyor.

Olgunlaşma modeli kabaca şöyle:

AI önerir → İnsan onaylar

↓

AI uygular → İnsan bilgilendirilir

↓

AI rutin incident'ları bağımsız çözer

Asıl “otonom operasyon” kavramı burada başlıyor.

Sistem Yöneticisinin Rolü Ne Olacak?

Bu dönüşüm doğal olarak şu soruyu doğuruyor:

AI operasyon ekiplerinin yaptığı işi devralacak mı?

Raporun yaklaşımı daha nüanslı.

AI'ın değiştirdiği şey öncelikle meslekler değil, görev dağılımı.

Raporda bugün IT profesyonellerinin zamanının önemli bölümünü tüketen reaktif investigation işlerinin giderek AI tarafından gerçekleştirileceği ve insanın kapasite planlama, mimari kararlar, optimizasyon ve business-technology alignment gibi alanlara kayacağı öngörülüyor.

Yeni roller de ortaya çıkıyor:

AI Observability Engineer

Data Quality Specialist

Intelligent Automation Architect

Conversational AI Administrator

Bence burada daha geniş bir dönüşüm var.

Geleceğin iyi sistem yöneticisi her logu manuel inceleyen kişi olmayabilir.

AI'ın ulaştığı sonucu sorgulayabilen, sistem ilişkilerini anlayabilen ve otomasyonun nerede durması gerektiğine karar verebilen kişi olabilir.

Fakat Bir Problem Var: AI'ın Kendisi de Observability Gerektiriyor

AI-powered observability kulağa oldukça güçlü geliyor.

Ama rapor önemli riskleri de açık biçimde sıralıyor.

Bunların başında data quality geliyor.

Eksik timestamp'ler, standart olmayan log formatları, tutarsız metric isimleri veya incomplete traces modellerin yanlış baseline oluşturmasına neden olabilir.

Klasik kural hâlâ geçerli:

Garbage in, garbage out.

Hatta AI ile birlikte bunun etkisi büyüyor.

Çünkü kötü veri artık sadece kötü dashboard üretmiyor.

Kötü otomatik karar üretebilir.

Diğer kritik problem explainability.

AI bir sistemi restart etmeyi öneriyorsa operasyon ekibinin doğal olarak bilmek isteyeceği şey:

Neden?

Bu nedenle confidence score, kararın dayandığı datapoint'ler ve alarmı tetikleyen pattern'lerin görünür olması kritik hale geliyor. Rapor da başarılı AI observability sistemlerinde explainability ve human governance ihtiyacının altını çiziyor.

Otonom Operasyon Bir Anda Gelmeyecek

Raporda önerilen yaklaşım oldukça pragmatik:

Crawl

Önce anomaly detection.

AI sistemin normal davranışını öğrensin.

Walk

Ardından automated root cause analysis ve natural language querying.

Run

Son olarak predictive alerting ve düşük riskli olaylarda automated remediation.

Bu model önemli çünkü AI observability teknolojik olduğu kadar bir güven problemi.

Bir operasyon ekibinin AI'ın önerdiği çözümü kabul etmesi başka şeydir.

AI'ın production ortamında insan onayı olmadan değişiklik yapmasına izin vermesi bambaşka şey.

2027-2028: Monitoring Araçlarının Sonraki Formu

Whitepaper, önümüzdeki birkaç yıl için oldukça iddialı beklentiler ortaya koyuyor.

Autonomous observability'nin gelişmiş özellik olmaktan çıkıp standartlaşması, natural language interfaces'ın temel interaction yöntemi haline gelmesi ve AI'ın yalnızca teknik metrikleri değil business impact'i de anlaması bekleniyor.

Multimodal AI da observability kapsamını genişletebilir.

Sistem yalnızca logs ve metrics okumayabilir.

Architecture documentation,

code changes,

audio quality,

video experience

gibi farklı veri türlerini aynı incident içerisinde değerlendirebilir.

Bu durumda observability'nin tanımı da değişmeye başlayacaktır.

Artık sadece sistemin durumunu gözlemlemekten değil,

sistemin bağlamını anlamaktan bahsediyoruz.

Dashboard'dan Karar Sistemine

Observability'nin ilk dönemi bize sistemleri görme yeteneği verdi.

İkinci dönem metrics, logs ve traces sayesinde sistemlerin davranışını anlamaya çalıştı.

AI ile başlayan üçüncü dönem ise başka bir soruya yöneliyor:

Sistem kendi davranışını ne kadar anlayabilir?

Bugün AI anomaly detection yapıyor.

Root cause analysis gerçekleştiriyor.

Incident'ları tahmin ediyor.

Natural language üzerinden sistemleri sorgulamamızı sağlıyor.

Ve giderek remediation kararlarına dahil oluyor.

Bu gelişimin doğal sonucu, observability platformlarının klasik monitoring araçlarından operasyonel karar sistemlerine dönüşmesi olabilir.

Bu durumda geleceğin Network Operations Center'ı onlarca dashboard'a bakan insanlardan oluşmayabilir.

İnsanların önünde daha az alarm olabilir.

Ama verdikleri kararların etkisi çok daha büyük olacaktır.

Belki de AI'ın IT operasyonlarındaki en önemli etkisi insanı sistemden çıkarmak değil.

İnsanı alarm takip etmekten çıkarıp karar vermeye geri döndürmek olacak.

AI Kullanım Şeffaflığı: Bu çalışmanın hazırlanması sırasında yapay zekâ; kaynak araştırmasını desteklemek, veri ve iddiaları kontrol etmek, içeriği yapılandırmak, iyileştirmek ve özetlemek amacıyla kullanılmıştır. Nihai içerik yazar tarafından gözden geçirilmiş ve düzenlenmiştir. Kaynaklar bağımsız olarak doğrulanmış olup nihai metnin sorumluluğu yazara aittir.