Observability · Self-Healing · Disaster Recovery
Sistem “Ayakta” Demek,
“Sağlıklı” Demek Değildir.
Günde 10 milyon mesaj işleyen bir entegrasyon platformunu 5 yıl boyunca izlerken öğrendiklerimiz, 50+ müşteri deneyiminden çıkardığımız dersler ve MIP HealthCheck’i neden sıfırdan geliştirdiğimizin hikayesi.
Standart izleme araçları “sunucu açık mı?” sorusuna cevap verir. Entegrasyon platformlarında asıl sorun bu değil: bileşenler ayakta olsa bile birbirleriyle konuşamadığında ortaya çıkan sessiz arızalardır.
MIP HealthCheck, uçtan uca veri akışını test eden çift katmanlı izleme, dinamik sağlık skoru, otomatik yedekleme/restore, self-healing log yönetimi ve akıllı alarmlarla kesintiyi oluşmadan önce önler.
Bir gece saat 03:47. Müşterinin EDI entegrasyon akışı durmuş. Support ekibi arıyor. Sunucular açık, loglarda hata yok, dashboard yeşil. Ama mesajlar akmıyor.
Bir saat sonra anladık: ActiveMQ sunucusu ayaktaydı, ping yanıtlıyordu. Ancak Backend pod’u ActiveMQ’ya TCP connection açmaya çalıştığında stale connection’a düşüyor, 30 saniye bekleyip timeout oluyordu. Sunucu “çalışıyor” gözüküyor, iletişim ise ölüydü. Müşteri için tek anlamı vardı: sistem çalışmıyor.
Bu, sektörde “silent failure” (sessiz arıza) olarak bilinir. Ve MIP gibi günde 10 milyon mesaj işleyen, 50+ müşteriye hizmet veren bir entegrasyon platformunda, sessiz arıza sadece “zaman zaman olan” bir problem değil — sistemik bir risk kategorisidir.
- ActiveMQ ayakta gözükür ama Backend’den mesaj alamaz (stale TCP connection)
- DB yanıt verir ama connection pool %95 doludur — yeni istekler saniyeler içinde birikecektir
- Disk yazılabilir durumdadır ama 3 gün sonra log birikiminden kilitlenecektir
- Latency 200ms’den 1200ms’ye çıkmış ama kimse fark etmemiştir — müşteri SLA’sı sessizce kırılıyordur
- Redis yanıt veriyor ama hit rate %90’dan %40’a düşmüş — hafıza dolduğu için eviction başlamış
Çözüm basitti ama uygulaması zordu: ya her müşteri kendi ekibini 7/24 nöbete dikecekti, ya da platform kendi kendini izleyip proaktif uyarı verecekti. Biz ikincisini seçtik. İşte MIP HealthCheck böyle doğdu.
Bu Özelliği Neden Geliştirdik?
5+ yıllık MIP operasyonunda biriken support ticket’larını geriye dönük analiz ettiğimizde çarpıcı bir desen gördük: kritik seviyeli incident’ların yaklaşık %70’i, olaydan saatler önce gözlemlenebilir sinyallere sahipti.
DB connection pool sessizce doluyordu — ama kimse pool doluluğuna bakmıyordu. RAM 3 gün boyunca saatte %1 artıyordu — ama anlık grafiğe bakıldığında normal görünüyordu. Disk doluluğu eşiği geçiyordu — ama sistem henüz “çökmediği” için ticket açılmıyordu.
Geleneksel monitoring araçları (Grafana, Prometheus vb.) ham metriklere odaklanır. Oysa bize gereken şey ham metrikler değil; olası arızaları oluşmadan önce anlamlandırabilen bir domain-aware izleme katmanıydı. Piyasadaki genel çözümlerin hiçbiri MIP’in özel mimarisine — Backend pod’ları, Camel flow’ları, splitter’lar, ActiveMQ queue’ları, Redis session’ları — spesifik olamıyordu. Bu yüzden kendi çözümümüzü geliştirdik.
3 Temel Tasarım Prensibi
MIP HealthCheck Nedir?
MIP HealthCheck, sistemin sadece “çalışıyor” olmasını değil, “sağlıklı” kalmasını garanti altına alan proaktif bir izleme, otomasyon ve felaket kurtarma çözümüdür.
Sunucu kaynaklarını (CPU, RAM, Disk) anlık takip ederken; Backend ile Redis, Veritabanı, ActiveMQ ve Frontend arasındaki veri akışını uçtan uca test eder. Olası darboğazları, bağlantı kopukluklarını ve biriken logları — kriz anına dönüşmeden önce — tespit eder, ilgili ekipleri uyarır ve gerektiğinde otomatik aksiyon alır. Bu yazının geri kalanında HealthCheck’in 9 temel yeteneğini, tasarım kararlarımızı ve saha öğrenimlerimizi paylaşacağız.
01 / 09
Tek Bakışta Sistem Nabzı
Redis, Database, Backend, Frontend, ActiveMQ… Her biri için ayrı ekran açmak, ayrı log okumak artık tarih oluyor. MIP HealthCheck tüm kritik bileşenleri tek merkezi dashboard‘da birleştirir. Renk kodlu durum göstergeleri (Yeşil / Sarı / Kırmızı) ve sadeleştirilmiş grafikler sayesinde, teknik uzmanlığa gerek kalmadan sistemin genel sağlığı anlaşılır.
Tasarım kararı: Dashboard’a bakan kişi SRE olmak zorunda değil. Proje yöneticisi de, support lideri de, müşteri temsilcisi de ilk 3 saniyede “sistem iyi mi?” sorusuna cevap bulmalı. Renk ve sade sayılar, teknik jargonun önüne geçer.
02 / 09
Çift Katmanlı İzleme: Direct + Deep Check
Bu, HealthCheck’in en kritik mimari kararıydı. Standart izleme araçları sunucunun “açık” olup olmadığına bakar. Biz iki katmanlı bir yaklaşım kurguladık:
- Direct Check: HealthCheck servisi doğrudan Redis, ActiveMQ, Veritabanı, Backend ve Frontend’e bağlanır. Her biri ayakta mı? TCP connection açılıyor mu? Yanıt süresi kabul edilebilir mi? (diyagramda siyah oklar)
- Deep Check: Asıl fark burada. Backend pod’ları içinden Redis’e, DB’ye, ActiveMQ’ya uygulama seviyesinde istek gönderilir. Yani “benim pod’um bu component’e gerçekten ulaşabiliyor mu?” sorusunun yanıtı aranır. (diyagramda mavi oklar)
Neden iki katman? Çünkü ActiveMQ sunucusu ayakta olup ping yanıtlıyor olsa bile, Backend ile arasında bir network policy, stale connection veya pod-level DNS cache sorunu varsa, iş hâlâ durmuş demektir. Tek katmanlı kontrol bunu göremez. Asıl sorun “bileşen” değil, “bileşenler arası iletişim”dir.
Saha gözlemimiz: Geçen 12 ayda yakaladığımız kritik incident’ların ~%40’ı yalnızca Deep Check sayesinde tespit edilebildi. Direct Check yeşil, Deep Check kırmızı — bu kombinasyon altın değerindedir.
03 / 09
Geçmişe Dönük Latency Hafızası
“Saat 08:30’da sistem yavaşladı” — support dünyasının en kronik cümlesi. Anlık dashboard’lara bakıp “şu an iyi gözüküyor” demek, o anı kaçırmak demektir. HealthCheck, tüm bileşenler arası istek/yanıt sürelerini milisaniye bazında sürekli kaydeder. Böylece geçmişe dönük “zaman yolculuğu” yaparak darboğazın tam olarak ağın hangi noktasında başladığını nokta atışı tespit edebilirsiniz.
Bir örnek: Müşteri “her gün 10:00 civarında yavaşlama yaşıyoruz” diyor. Normal monitoring bu bilgiyle size sınırlı şey söyler. HealthCheck’in latency hafızasıyla o aralığı açar, her bileşen çiftine ait yanıt sürelerini görürsünüz. Sonuç: 10:00’da Backend → Postgres arasındaki latency 2ms’den 80ms’ye sıçrıyor. Bu, bir SQL query regression veya rakip bir CRON job’un işareti olabilir. Sorunu 3 dakikada lokalize edersiniz.
Öğrendik ki: Ham loglar “ne oldu?” sorusuna cevap verir. Zaman serisi latency verisi ise “neden oldu?” sorusuna cevap verir. İkincisi çok daha değerlidir.
04 / 09
Geçmişe Dönük Performans Analizi
CPU, RAM ve disk kullanımını sadece anlık değil, saatlere yayılmış grafiklerle gösterir. “Her gün 08:50 civarında RAM neden fırlıyor?” sorusunun cevabı tek bakışta görünür hale gelir. Üstelik bu veriler bileşen bazında ayrılmıştır: Backend pod’u mu, ActiveMQ mı, Postgres mi? Her biri için ayrı grafik.
Bu pattern’i bulmak, sorunu tekrar etmeden önce çözmenin en ucuz yoludur. Bir CRON job veya tetikleyici entegrasyon keşfedildiğinde, çözüm genellikle 10 dakikalık bir iş. Ama o pattern’i bilmeden reaktif çalışırsanız, her sabah 08:50’yi beklersiniz.
05 / 09
Akıllı Sağlık Skoru
CPU, RAM, Disk ve Latency gibi 4 farklı metriği tek bir System Health % değerine dönüştürür. Neden? Çünkü bir yöneticinin haftalık raporda görmek istediği şey 47 farklı grafik değil — tek bir sayı: “Sistem bu hafta ne durumda?”
Bu skor yalnızca bir görselleştirme trick’i değil. Skorun altında yatan algoritma, peak değerleri de (ani sıçramaları) ortalama değerleri de (kronik problemleri) hesaba katar. Böylece kısa süreli ama kritik bir pik’i, günlük ortalamada “düşük” gözükmesine rağmen skora yansıtır.
Yönetici perspektifi: Her iki sayıyı da yan yana gösterdiğimiz anda — “Peak RAM: %97.6, Average RAM: %83.2” — kapasite planlama toplantısı “daha fazla veri isteyin” moduna değil, “kaynak artırma kararı” moduna geçiyor.
06 / 09
İleri Seviye Veritabanı Yönetimi (DBA Modülü)
DBA modülü, HealthCheck’in “sanal DBA” iddiasını somutlaştıran parçadır. Kapsam:
- Connection Pool doluluğu — DB tarafı ve Backend tarafı ayrı ayrı. Çünkü birinin yeşil olup diğerinin kırmızı olması mümkündür.
- Active Transactions — uzun süredir açık kalan transaction’ları yakalar
- En büyük 10 tablonun boyut analizi — hangi tablonun anormal büyüdüğünü gösterir
- Otomatik yedekleme — periyodik full backup, zip arşiv
- Tek tuşla restore — geçmiş yedeklerden seçerek geri dönüş
Restore özelliğini eklerken en çok tartıştığımız konu “ne kadar kolay olmalı?” sorusuydu. Çok kolay olursa yanlış tetikleme riski var, çok zor olursa felaket anında işe yaramaz. Sonunda “tek tuş + onay ekranı + restore başlarken otomatik snapshot” kombinasyonunda karar kıldık — restore kendisi geri alınabilir bir işlem olsun istedik.
İş değeri perspektifi: Business continuity kağıt üstünde tutulan bir plan değil, denenmiş bir süreçtir. HealthCheck’in restore özelliği sayesinde müşteriler yıllık DR tatbikatlarını artık saatlerce süren operasyonlar yerine 10 dakikalık bir prosedüre indirgeyebiliyor.
07 / 09
Otonom Bakım ve Log Yönetimi (Self-Healing)
Disk doluluğu, susarak gelen en büyük tehditlerden biridir. Ne alarm verir ne de görünür bir “hata” üretir — bir sabah sistem açılmaz ve logları bile okuyamazsınız çünkü disk dolduğu için log yazamıyordur. HealthCheck bu tehdide 4 adımda cevap verir:
- Veritabanı ve disk üzerinde eskimiş log kayıtlarını tespit eder (konfigüre edilebilir retention period)
- Ekibe “3 saat sonra otomatik temizlik başlayacak” uyarı maili gönderir — inceleme/müdahale fırsatı tanır
- Eşik süresi geçtiğinde tanımlı kurallarla otomatik temizlik yapar
- “Log Cleanup Completed Successfully” maili ile sonuç raporunu paylaşır (kaç kayıt temizlendi, öncesi/sonrası)
Self-healing kulağa korkutucu gelir — “sistem kendi başına karar veriyor” imajı verir. Bu korkuyu aşmak için kuralı şöyle kurduk: Her otonom aksiyon öncesinde önbildirim, sonrasında sonuç raporu. Böylece ekip “ne olmuş?” sorusuna her zaman cevap bulur, sistem şeffaflığını kaybetmez.
İstatistik: Bu modül canlıya aldıktan sonraki 6 ayda disk-dolu kaynaklı incident sayımız sıfıra indi. Toplam 14 olası freeze vakası, sessiz sedasız HealthCheck tarafından temizlendi.
08 / 09
Akıllı Alarm Mekanizması
Tüm eşikler (CPU %86, RAM %89, Response Time 1000ms gibi) projeye göre dinamik olarak yapılandırılabilir. Bir müşterinin “agresif” dediği eşik, başkasının “normal”i olabilir. Bu yüzden default değerler değil, tunable policy’ler tasarladık.
Alarm tasarımında en büyük düşmanımız “alert fatigue”‘di. Gereksiz alarm gönderen sistem, gerçek alarmı görünmez kılar. Bu yüzden debouncing, flapping detection ve eşik kombinasyonları ekledik — aynı bileşen 60 saniyede iki kez up/down olursa tek bir alarm birleştirilir.
09 / 09
Anomaliler ve Pik Noktalar
Sistemin normal rutinini öğrenerek sapmaları otomatik tespit eder. Bu, alarm sistemden farklıdır: alarm eşik tabanlıdır (“CPU %90’ı geçti”), anomali tespiti ise davranış tabanlıdır (“bu saatte CPU hiç bu kadar yükselmezdi”). İkisi birbirini tamamlar.
CPU, RAM, Disk veya Latency’deki olağan dışı davranışlar; tarih, bileşen ve kritiklik seviyesine göre filtrelenebilir bir tabloda toplanır. Binlerce log satırı arasında kaybolmadan, sistemin ne zaman ve nerede sınırları zorladığını saniyeler içinde görürsünüz.
Bu tablo post-mortem kültürünü değiştiren araçtır. Bir incident sonrası “geçen hafta boyunca bu bileşende kaç pik olmuş?” diye bakarsınız — sorunun kökeninin ani mi yoksa kronik mi olduğunu anlamak için paha biçilmez.
Saha’dan Bir Hikaye
HealthCheck Öncesi vs. Sonrası: Bir Incident
Aynı problem, iki farklı sonuç. Aradaki fark sadece “izleme” değil — problemi oluşmadan görebilen bir mimariye sahip olmaktı.
İş Değerİ
Neden Önemli?
| Önce | MIP HealthCheck ile |
|---|---|
| Müşteri “sistem çalışmıyor” diye arar | HealthCheck 15-45 dakika önce uyarır |
| Log birikiminden disk dolar, freeze olur | Otomatik temizlik disk’i yönetir |
| DB connection pool sessizce dolar | %75 eşiğinde proaktif alarm |
| “Hangi bileşen yavaşladı?” saatlerce araştırılır | Latency tablosu nokta atışı gösterir |
| Felaket anında manuel yedekten dönüş | Tek tuşla restore |
| “Geçen ay kaç incident’imiz olmuştu?” bilinmez | Anomali tablosu tam trendi gösterir |
Sonuç: Ortalama müdahale süresi (MTTR) dramatik şekilde düşer, sistem sürekliliği (uptime) artar, operasyon ekibinin yükü otomasyonla hafifler, müşteri memnuniyeti (NPS) yukarı taşınır.
Öğrendİklerİmİz
Bu Süreçte Aldığımız 4 Büyük Ders
Yol Harİtası
Sıradaki Adımlar
HealthCheck’i bir ürün olarak görüyoruz — bitmiş bir özellik değil. Önümüzdeki 12 ay içinde hedeflediklerimiz:
- ML-tabanlı anomali tespiti: Sabit eşikler yerine, sistemin kendi “normali”ni öğrenen modeller
- Incident Response entegrasyonu: PagerDuty, Opsgenie, Slack bağlantıları — alarmı doğru kişiye doğru kanaldan iletmek
- Multi-tenant sağlık görünümü: Bir ekranda tüm müşterilerin sağlık skorunu görmek
- Forecast modülü: “Disk 14 gün içinde dolacak” tahmini — kapasite planlaması için
- Flow-level health: Sistem bileşeni seviyesinden akış seviyesine inmek — “X entegrasyonu son 6 saatte kaç mesaj kaybetti?”
Kapanış
Entegrasyon platformunun kalitesi,
toparlanma hızıyla ölçülür.
MIP HealthCheck bu toparlanmayı mümkün olan en erken ana çeker: sorun ortaya çıkmadan önce. “Sistem ayakta mı?” sorusu bizi buraya kadar getirdi. Bundan sonraki sefer, doğru soru şu olacak: “Sistem sağlıklı mı?”
Siz de kendi entegrasyon platformunuzda silent failure’larla savaşıyor musunuz? Yorumlarda deneyimlerinizi paylaşmaktan çekinmeyin — özellikle “bizi tam olarak şu incident yıktı” hikayelerine bayılırız.
