Anomali Tespiti — Operasyonel Verilerden Aykırılığı Yakalamak
Anomali tespiti, normal davranış kalıplarından sapan veri noktalarını otomatik olarak fark etme disiplinidir. Modern bir hosting ve yazılım operasyonunda anomali tespiti yalnızca güvenlik için değil — performans dejenerasyonu, kapasite planlaması, müşteri davranış değişiklikleri ve finansal kayıp önleme için de hayati. AIOR olarak hem kendi altyapımızda hem müşteri projelerinde anomali tespitini birinci sınıf bir izleme katmanı olarak kuruyoruz; bu yazı 2026 perspektifinden pratik mimari kararlarını ve karşılaştığımız tuzakları paylaşıyor.
Neden Eşik-Tabanlı Alarm Yetmiyor
Geleneksel izleme sistemlerinde "CPU %90'ı aşarsa alarm at" gibi statik eşikler kullanılır. Bu yaklaşım pazartesi sabahı pik trafiğinde sürekli yanlış pozitif üretirken, gece yarısı normalin yarısına düşen aktivite yüzünden bir saldırıyı kaçırabilir. Anomali tespiti zamansal bağlamı dikkate alır: "şu an" beklenen değerin neresinde duruyor? Bu sorunun cevabı sabit bir sayı değil, geçmişte aynı saat, aynı gün, aynı sezon için tahmin edilen bir aralıktır.
Algoritmik Yaklaşımlar
Pratikte AIOR'un kullandığı yöntemler basitten karmaşığa şu sırayı izler:
- Hareketli ortalama + standart sapma: son N noktanın ortalamasının üç sigma dışında kalanlar şüpheli. Hızlı, hafif, gürültüsüz veride iyi çalışır.
- EWMA (Exponentially Weighted Moving Average): yeni noktalara daha çok ağırlık verir; trafik kalıbı kayan sistemlerde basit hareketli ortalamadan iyi.
- Mevsimsel ayrıştırma (STL): trend, mevsimsel pattern ve artığı ayrı bileşenler olarak çıkarır; anomali yalnız artık üzerinde aranır.
- Isolation Forest: ağaç tabanlı denetimsiz model; çoklu boyutta aykırılığı tek seferde yakalar.
- Autoencoder tabanlı yeniden yapılandırma hatası: derin öğrenme modeli; karmaşık zaman serileri için en güçlü, fakat eğitim ve operasyonel maliyeti yüksek.
Hangisini Ne Zaman Kullanmalı?
"En karmaşık model en iyi sonuç verir" ön yargısı sıklıkla yanlıştır. Hosting metriklerinin %80'i için EWMA + STL kombinasyonu yeterlidir ve istasyon başına bir CPU çekirdeğinden daha az tüketir. Derin öğrenme modelleri yalnız çok boyutlu, açıkça gürültülü ve yüksek değerli verilerde devreye alınır — örneğin ödeme akışındaki dolandırıcılık tespiti veya bot trafiği ayrıştırması gibi.
AIOR Altyapısında Anomali Tespiti
Tüm AIOR sunucularında Prometheus üzerinden toplanan metrikler, ayrı bir anomali tespit servisine akıyor. Bu servis Python-tabanlı, GO+Rust hibrit bir backbone üzerinde çalışıyor ve şu sinyalleri üretiyor:
- Hesap bazlı CPU/IO tüketiminde ani yükseliş
- HTTP 5xx oranında saatlik trend kırılması
- E-posta kuyruğunda bekleyen mesaj sayısının normalden sapması
- SSH başarısız giriş denemelerinin coğrafi kalıbındaki değişim
- Disk doluluk oranının haftalık projeksiyonu
Üretilen her sinyal, doğrudan PagerDuty/Slack'e gitmek yerine önce bir "smart deduplicate" katmanından geçer; gürültü bastırılır ve operasyon ekibi yalnız anlamlı uyarıları görür.
Yanlış Pozitif Yönetimi
Anomali tespit sistemlerinin uzun vadeli başarısı yanlış pozitif oranını düşük tutmaya bağlıdır. Operasyon ekibi sahte alarmlardan kanıksadıkça gerçek alarmlar da kaybolur. AIOR pratiği: her yanlış pozitif belgeli; düzenli "kalibrasyon haftası" — son 30 günde tetiklenen alarmlar gözden geçirilir, gereksiz olanlar için eşikler veya model parametreleri ayarlanır. Bu döngü olmadan en iyi model bile zamanla işe yaramaz hâle gelir.
Müşteri Projelerinde Uygulama
AIOR yazılım projelerinde anomali tespiti birkaç tipik kullanım üzerinden tasarlanır: e-ticaret sitesinin satış hızında ani düşüş (ödeme akışı bozuldu mu?), API endpoint'inin yanıt süresinde aniden artış (DB indeksi mi gerekti?), kullanıcı kayıt akışında bot kaynaklı patlama. Bu kullanımlarda işletme kuralı ile birleşen anomali tespiti, sırf teknik metriklerden çok daha fazla değer üretir.
Mahremiyet ve Düzenleyici Uyum
Müşteri verisi üzerinde anomali tespiti yaparken AIOR olarak iki katmanlı yaklaşım uyguluyoruz: hassas alanlar (kimlik, kart, sağlık) hash'lenmiş ya da maskelenmiş olarak modele giriyor; modelin ürettiği sinyal kimliği kişiselleştiren değil davranış kalıbını anlatan biçimde saklanıyor. Bu yaklaşım hem yasal düzenlemelere uyum sağlar hem de model eğitimi sırasında ortaya çıkabilecek veri sızıntısı risklerini azaltır.
Olay Sonrası İnceleme ve Öğrenme
Her ciddi anomali olayı sonrasında AIOR'da yapılandırılmış bir post-mortem yapıyoruz: ne oldu, ne zaman fark edildi, ne kadar sürdü, kim etkilendi, ne öğrendik. Bu inceleme suçlama kültürü değil "blameless" çerçevede yapılır; amaç sistemin daha dirençli hâle gelmesidir. Her post-mortem'den çıkan eylem maddeleri (yeni alarm kuralı, eşik ayarı, runbook güncellemesi, eğitim) takip listesinde tutulur ve tamamlanma oranı izlenir.
Müşterinin Anomali Tespit Olgunluğunu Yükseltmek
AIOR olarak müşteri projelerinde anomali tespitini bir defada tam kuran değil, kademeli olgunlaştıran bir program olarak ele alıyoruz. İlk aşamada temel HTTP/DB metriklerine basit istatistiksel alarmlar; ikinci aşamada iş metrikleri (sipariş hızı, ödeme başarı oranı) için EWMA + STL; üçüncü aşamada birden çok metriği birlikte değerlendiren çok değişkenli modeller. Bu kademeli yaklaşım hem ekibin öğrenmesini destekler hem de yanlış pozitif yağmurunu önler.
Sonuç
Anomali tespiti, modern operasyonun olmazsa olmaz katmanlarından biri. AIOR olarak sade istatistiksel modellerle başlayıp gerçek ihtiyaç ortaya çıktığında derin öğrenme katmanlarına yükseliyoruz. Sade ile karmaşık arasındaki dengeyi sağlamak, yanlış pozitifleri kontrol altında tutmak, post-mortem disiplini ile sürekli öğrenmek ve operasyon ekibinin güvenini kazanmak — sürdürülebilir bir anomali tespit programının dört temel kuralı. Doğru uygulandığında anomali tespit katmanı yalnız sorunları erken yakalamaz; aynı zamanda işletmenin kendi davranışını daha net anlamasını ve kararlarını veriye dayandırmasını da sağlar.
Anomaly Detection — Catching Outliers in Operational Data
Anomaly detection is the discipline of automatically flagging data points that deviate from the normal behaviour pattern. In modern hosting and software operations it is critical not only for security but also for performance degradation, capacity planning, customer behaviour change, and financial loss prevention. At AIOR we treat anomaly detection as a first-class observability layer in both our own infrastructure and in customer projects; this article shares practical architecture decisions and the pitfalls we have learned to avoid.
Why Threshold Alarms Aren't Enough
Traditional monitoring uses static thresholds like "alarm if CPU exceeds 90%". This approach fires false positives during Monday morning peaks and misses attacks at 3 AM when activity is half of normal. Anomaly detection adds temporal context: where does "now" sit inside the predicted range for this hour, day, and season — that range is not a single number but a forecast band derived from history.
Algorithmic Approaches
From simple to complex, the methods AIOR uses in practice:
- Moving average + standard deviation: points outside three sigma of the recent N-point mean are suspicious. Fast, lightweight, works well on quiet signals.
- EWMA (Exponentially Weighted Moving Average): weights recent points more; outperforms vanilla MA when the traffic pattern shifts.
- Seasonal decomposition (STL): splits the series into trend, seasonality, residual; anomalies live in the residual.
- Isolation Forest: unsupervised tree-based model; flags multivariate outliers in one pass.
- Autoencoder reconstruction error: a deep learning model; strongest for complex time series, but the training and operating cost are high.
When to Use Which
The bias that "the most complex model wins" is often wrong. For 80% of hosting metrics, EWMA + STL is sufficient and runs on less than one CPU core per station. Deep models earn their keep only on multidimensional, noisy, high-value data — fraud detection in the payment flow, bot-traffic separation, and similar.
Anomaly Detection on AIOR Infrastructure
All AIOR servers' metrics, collected via Prometheus, flow into a dedicated anomaly service. The service is Python-driven on a Go+Rust hybrid backbone and produces signals such as:
- Per-account CPU/IO sudden spikes
- Hourly trend breaks in HTTP 5xx rate
- Email queue length deviation from norm
- Geographic shift in failed SSH attempts
- Weekly disk-fill projection drift
Each signal first goes through a "smart deduplicate" layer rather than going directly to PagerDuty/Slack; noise is suppressed and the operations team sees only meaningful alerts.
False Positive Management
Long-term success in anomaly detection lives or dies on keeping the false-positive rate low. Once the on-call team gets used to fake alarms, real alarms disappear into the noise. The AIOR rule: every false positive is documented; we run a "calibration week" on a cadence — alerts from the last 30 days are reviewed and thresholds or model parameters tuned for the unneeded ones. Without that loop, even the best model degrades into uselessness.
Customer Project Applications
In AIOR software projects, anomaly detection is designed around a few typical use cases: an e-commerce site's sales velocity dipping sharply (is the payment flow broken?); an API endpoint's response time spiking (does the DB need a new index?); a bot-driven surge on the signup flow. In these cases, anomaly detection combined with business rules produces far more value than raw technical metrics alone.
Privacy and Regulatory Compliance
When performing anomaly detection over customer data, AIOR applies a two-layer approach: sensitive fields (national ID, card, health) feed the model hashed or masked; the signals the model produces describe behaviour patterns rather than re-identifiable individuals. This keeps regulatory compliance achievable and reduces leakage risks during model training.
Post-Incident Review and Learning
After every serious anomaly event AIOR runs a structured post-mortem: what happened, when it was detected, how long it lasted, who was affected, what we learned. The review is blameless — the goal is a more resilient system. Action items (new alarm rule, threshold adjustment, runbook update, training) go into a tracked list with measured completion rate.
Raising the Customer's Anomaly-Detection Maturity
On customer projects we treat anomaly detection as a programme that grows, not a single-shot install. Phase one: basic statistical alerts on HTTP/DB metrics. Phase two: EWMA + STL on business metrics (order velocity, payment success rate). Phase three: multivariate models that consider several metrics together. The phased path supports learning and prevents false-positive storms.
Conclusion
Anomaly detection is one of modern operations' must-have layers. At AIOR we start with simple statistical models and move into deep learning only when the actual need appears. Balancing simple vs. complex, keeping false positives bounded, learning from post-mortems, and earning the operations team's trust — those are the four rules of a sustainable anomaly detection programme.