Sorun Sistemde mi, Yoksa Görünmeyen Bir Yerde mi?
Sabah mesainin ilk saatleri…
Kullanıcılardan art arda aynı bildirimler gelmeye başlıyor:
- "Sistem çok yavaş."
- "Uygulamaya giriş yapamıyoruz."
- "Sayfalar geç açılıyor."
İlk kontroller yapılıyor. Sunucular çalışıyor, ağ bağlantıları aktif, disklerde yeterli alan var. Görünürde her şey normal. Ancak kullanıcı deneyimi bunun tam tersini söylüyor.
"Peki sorun nerede?"
Geçmişte bu sorunun cevabını bulmak saatler sürebiliyordu. Farklı sistemlerdeki log kayıtları inceleniyor, sunucular tek tek kontrol ediliyor, ekipler arasında yoğun iletişim trafiği yaşanıyordu. Dijital hizmetlerin kesintisiz sunulmasının beklendiği günümüzde ise bu yaklaşım artık sürdürülebilir değil.
Modern BT operasyonlarında önemli olan yalnızca bir sorunun varlığını tespit etmek değildir. Asıl değer; sorunun nedenini dakikalar hatta saniyeler içinde ortaya çıkarabilmek, etkisini doğru analiz edebilmek ve benzer olayların tekrar yaşanmasını önleyebilmektir.
İşte bu noktada iki temel kavram öne çıkmaktadır:
- Monitoring (İzleme)
- Observability (Gözlemlenebilirlik)
Birbirini tamamlayan bu iki yaklaşım, günümüz BT operasyonlarının temel yapı taşları hâline gelmiştir.
Monitoring ve Observability Arasındaki Fark:
Bu iki kavram çoğu zaman aynı anlamda kullanılsa da amaçları farklıdır.
Monitoring, sistemlerin belirlenen metrikler doğrultusunda sürekli izlenmesini sağlar. CPU kullanımı, bellek tüketimi, disk doluluk oranı veya servis durumu gibi önceden tanımlanmış göstergeler takip edilir ve eşik değerler aşıldığında alarm üretilir.
Observability ise çok daha kapsamlıdır. Sadece bir alarm üretmekle kalmaz; alarmın neden oluştuğunu, hangi servislerin etkilendiğini, olayın nasıl geliştiğini ve kullanıcıya olan etkisini de ortaya koyar. Kısacası;
- Monitoring, "Ne oldu?" sorusuna cevap verir.
- Observability ise; "Neden oldu ve tekrar yaşanmaması için ne yapılmalı?" sorusunu cevaplar.
Monitoring: Gösterge Paneline Bakmak Gibidir.
Monitoring'i bir otomobilin gösterge paneline benzetebiliriz.
Gösterge paneli size;
- Yakıt seviyesini,
- Motor sıcaklığını,
- Hızınızı,
- Yağ basıncını
gösterir. Ancak; Motor neden arızalandı sorusunun cevabını vermez. BT sistemlerinde de durum benzerdir.
Monitoring;
- CPU kullanımı %90'ı geçti mi?
- Bellek kritik seviyeye ulaştı mı?
- Disk alanı doluyor mu?
- Web servisi cevap veriyor mu?
- Ağ bağlantısında kesinti oluştu mu?
gibi sorulara cevap verir. Amaç, sistemde olağan dışı bir durum oluştuğunda ilgili ekipleri mümkün olan en kısa sürede haberdar etmektir.
Observability: Sistemin Davranışını Anlamak
- Monitoring size bir alarm gösterebilir.
- Observability ise o alarmın arkasındaki hikâyeyi anlatır.
Örneğin bir e-ticaret uygulamasında kullanıcı "Sepete Ekle" butonuna bastığında arka planda onlarca işlem gerçekleşebilir.
- API Gateway
- Kimlik doğrulama servisi
- Ürün servisi
- Stok servisi
- Kampanya servisi
- Ödeme servisi
- Veritabanı
- Cache sistemi
- Mesaj kuyruğu
Monitoring yalnızca yanıt süresinin arttığını gösterebilir. Observability ise;
- Hangi mikro servisin geciktiğini,
- Gecikmenin hangi sorgudan kaynaklandığını,
- Etkilenen kullanıcı sayısını,
- Zincirleme etkilenen servisleri,
- Sorunun başlangıç zamanını,
- Aynı problemin daha önce yaşanıp yaşanmadığını
ortaya çıkarabilir. Observability'nin amacı; alarm üretmek değildir. Alarmın neden oluştuğunu mümkün olan en kısa sürede ortaya çıkarmaktır.
Observability'nin Üç Temel Sütunu:
Modern gözlemlenebilirlik üç temel veri kaynağı üzerine kuruludur.
- Metrics (Metrikler)
CPU kullanımı, bellek tüketimi, disk IO, ağ trafiği, istek sayısı ve yanıt süreleri gibi sayısal veriler sistemin genel sağlık durumunu gösterir.
- Logs (Kayıtlar)
"Sistem ne yaptı?"
Uygulama kayıtları, hata mesajları, yetkilendirme bilgileri ve olay günlükleri sayesinde sistem içerisinde gerçekleşen işlemler ayrıntılı olarak incelenebilir.
- Traces (İzler)
"İşlem hangi yolu izledi?"
Özellikle mikro servis mimarilerinde büyük önem taşır. Tek bir kullanıcı isteğinin geçtiği tüm servisler adım adım izlenebilir. Böylece, darboğaz oluşturan servis veya gecikmeye neden olan işlem saniyeler içinde belirlenebilir.
Alarm Çokluğu, Başarı Göstergesi Değildir
Monitoring sistemleri kurulurken yapılan en yaygın hatalardan biri, mümkün olduğunca fazla alarm üretmeyi başarı olarak görmektir. Oysa zamanla yüzlerce hatta binlerce gereksiz alarm oluşabilir. Bu durum literatürde Alert Fatigue (Alarm Yorgunluğu) olarak adlandırılır.
Sürekli alarm alan ekipler, zamanla kritik uyarıları da sıradan bildirimler gibi algılamaya başlar. Sonuç olarak, gerçekten önemli olaylar gözden kaçabilir. Başarılı bir monitoring yaklaşımı;
- Doğru metrikleri izlemeli,
- Anlamlı eşik değerleri belirlemeli,
- Alarm tekrarlarını azaltmalı,
- Önceliklendirme yapabilmeli,
- Yanlış pozitif alarmları en aza indirmelidir.
Amaç çok alarm üretmek değil, doğru alarm üretmektir.
Modern BT Operasyonlarında Neden Vazgeçilmez?
Günümüzde tek bir kurumsal uygulama bile, onlarca farklı bileşenden oluşabilmektedir. Örneğin;
- Kubernetes
- Docker
- Mikro Servisler
- API Gateway
- Active Directory
- SQL ve NoSQL Veritabanları
- Cache Katmanları
- Load Balancer
- Bulut Servisleri
- Güvenlik Bileşenleri
Bu kadar karmaşık yapılarda manuel takip artık mümkün değildir. Merkezi bir Monitoring ve Observability platformu sayesinde;
- Tüm sistemler tek ekrandan izlenebilir.
- Olaylar ilişkilendirilebilir.
- Performans eğilimleri analiz edilebilir.
- Kapasite planlaması veriye dayalı yapılabilir.
- Kullanıcı deneyimi sürekli ölçülebilir.
- Sorunlar kullanıcılar fark etmeden önce tespit edilebilir.
SLI, SLO ve SLA Yönetiminde Kritik Rol:
Monitoring ve Observability yalnızca BT ekiplerinin kullandığı teknik araçlar değildir. Aynı zamanda kurumların hizmet kalitesini ölçebilmesinin temelini oluştururlar. Bu noktada, üç önemli kavram öne çıkar.
SLI (Service Level Indicator)
Hizmet performansını ölçen göstergelerdir. Örneğin;
- Yanıt süresi
- Başarılı istek oranı
- Uptime
SLO (Service Level Objective)
Kurumun ulaşmayı hedeflediği performans seviyesidir. Örneğin;
- Sistemin aylık %99,9 erişilebilir olması.
SLA (Service Level Agreement)
Kurum ile hizmet alan taraf arasında belirlenen hizmet seviyesidir. Monitoring ve Observability sayesinde bu hedefler sürekli ölçülür, raporlanır ve gerektiğinde iyileştirme çalışmaları başlatılır.
Kullanılan Popüler Platformlar:
Günümüzde farklı ölçeklerdeki kurumlar ihtiyaçlarına göre çeşitli çözümler kullanmaktadır. Yaygın platformlardan bazıları şunlardır:
- Zabbix
- Prometheus
- Grafana
- Elastic Stack
- OpenTelemetry
- Jaeger
- Dynatrace
- Datadog
- Splunk
- New Relic
Burada önemli olan; kullanılan ürün değil, doğru gözlemlenebilirlik yaklaşımının benimsenmesidir. İyi tasarlanmış bir mimaride bu araçlar birlikte çalışarak daha güçlü bir görünürlük sağlar.
Geleceğin BT Operasyonları: AIOps
Yapay zekâ destekli operasyon yönetimi (AIOps), Monitoring ve Observability yaklaşımını yeni bir seviyeye taşımaktadır. Artık sistemler yalnızca alarm üretmiyor. Aynı zamanda;
- Anormallikleri tespit ediyor,
- Olaylar arasındaki ilişkileri kuruyor,
- Kök nedeni tahmin ediyor,
- Kapasite ihtiyacını öngörebiliyor,
- Bazı problemlere otomatik müdahale edebiliyor.
Bu sayede; BT ekipleri sürekli yangın söndürmek yerine, stratejik iyileştirme çalışmalarına daha fazla zaman ayırabiliyor.
Sonuç:
Dijital hizmetlerin kesintisiz sunulması artık yalnızca güçlü sunuculara veya yüksek donanım kapasitesine sahip olmakla mümkün değildir.
Gerçek başarı; sistemlerin davranışını anlayabilen, anormallikleri erken tespit edebilen ve veriye dayalı kararlar alabilen BT operasyon ekipleriyle sağlanır.
Monitoring size; "Ne oldu?" sorusunun cevabını verir.
Observability ise; "Neden oldu ve tekrar yaşanmaması için ne yapmalıyız?" sorusunu ortaya koyar.
Bu nedenle; Monitoring ve Observability birbirinin alternatifi değil, birbirini tamamlayan iki temel yaklaşımdır.
Kurumlar için asıl hedef; yalnızca sistemleri çalışır durumda tutmak değil; hizmet kalitesini sürdürülebilir kılmak, kullanıcı deneyimini iyileştirmek ve operasyonel süreçleri sürekli geliştirmektir.
Verinin doğru analiz edildiği, olayların anlamlandırıldığı ve öngörüye dayalı kararların alındığı bir BT operasyon modeli; yalnızca teknik ekiplerin başarısını değil, kurumun dijital olgunluğunu ve rekabet gücünü de doğrudan artıracaktır.
Çünkü modern BT operasyonlarında başarı, sorunlara yalnızca hızlı müdahale etmek değil; sorunları oluşmadan önce görebilecek bir görünürlüğe sahip olmaktır.
Kaynaklar:
* Chat GPT
* Gemini