Anomaly Detection Pipeline Anatomisi: Ingestion'dan Alarm'a Uçtan Uca 7 Katman

7 Katmanlı Anomaly Detection Pipeline#

1. INGESTION
   ↓ (raw events / metrics / logs)
2. FEATURE ENGINEERING
   ↓ (modele beslenecek vektör)
3. SCORING (MODEL)
   ↓ (sürekli skor)
4. THRESHOLDING
   ↓ (binary karar veya seviye)
5. ALERTING & ROUTING
   ↓ (alarmı doğru kişiye)
6. FEEDBACK LOOP
   ↓ (analist kararı geri model'e)
7. MONITORING
   ↓ (model & data drift)

1️⃣ Katman 1 — Ingestion#

Batch ingestion#

Streaming ingestion#

Karar matrisi#

1. Schema kontrolü — gelen veride beklenmedik alanlar var mı? (drift'in ilk sinyali burada)
2. Replay capability — anomali yakalanan kayıtları yeniden işlemek için raw veri saklamak şart
3. Ordering guarantee — collective anomaly için doğru sıra önemli (Kafka partition strategy)
4. Late data handling — gecikmiş kayıtlar gelirse modeline ne anlatacaksın

2️⃣ Katman 2 — Feature Engineering#

Tipik feature aileleri#

Feature store kullan#

• Aynı feature offline (training) ve online (inference) farklı hesaplanır (training-serving skew)
• Re-engineering eski capstone'da iki haftan gider

• Open source: Feast, Hopsworks, Tecton OSS
• Managed: Databricks Feature Store, Vertex AI Feature Store

Feature engineering'in 3 altın kuralı#

1. Online çıkarılabilir mi? — bir feature offline (eğitim) hesaplanabilir ama online (gerçek zaman) hesaplanamıyorsa, kullanılamaz
2. Latency bütçen var mı? — bir velocity feature için 100ms aralık lookback gerekiyorsa, redis cache şart
3. Versioning — feature tanımı değişirse model retraining gerekir; feature_v1 ve feature_v2 yan yana yaşamalı

3️⃣ Katman 3 — Scoring (Model)#

Single model vs Ensemble#

Score_final = α * Score_iForest + β * Score_AE + γ * Score_classifier

Tipik production model türleri#

Serving infrastructure#

4️⃣ Katman 4 — Thresholding#

Threshold seçim yaklaşımları#

Tek vs çok seviyeli karar#

Score < 0.3:   GREEN — geç
Score 0.3-0.7: YELLOW — ek inceleme (challenge, soft check)
Score > 0.7:   RED   — blok / alarm

5️⃣ Katman 5 — Alerting & Routing#

Alarm anatomi şablonu#

alert:
  id: <uniq_id>
  severity: P1 | P2 | P3 | P4
  source: <model_id>
  context:
    entity_id: <transaction_id / sensor_id / user_id>
    score: <0.0 - 1.0>
    threshold_breached: <eşik>
  explanation:
    top_features: [feature1, feature2, ...]
    similar_past_cases: [case_id1, case_id2, ...]
  action:
    suggested: "block_transaction" | "manual_review" | "escalate"
    runbook_url: <URL>
  routing:
    primary: @analyst-team / @sre-oncall
    fallback: @manager / @secondary-on-call

Alarm yorgunluğu (alert fatigue)#

• Günlük 500+ alarm
• %85'i false positive
• Analist sadece P1'lere bakar
• Gerçek P3 anomali kaçar

1. Dedup — aynı entity için ardışık alarmları birleştir (deduplikasyon)
2. Grouping — ilişkili alarmları tek incident olarak topla
3. Intelligent silencing — bilinen "noise" pattern'leri otomatik sustur
4. Suppression windows — bakım pencerelerinde alarm üretme
5. Severity-based routing — sadece P1-P2 gerçek alarma yol açar

Alarm araçları#

• Open source: Alertmanager (Prometheus), VictoriaMetrics alerting
• SaaS: PagerDuty, Opsgenie, Squadcast
• Chat: Slack webhook, Microsoft Teams, Discord webhook
• Türkiye: Çoğu ekip Slack + Telegram bot hibrit kullanır

6️⃣ Katman 6 — Feedback Loop#

• Adversarial aktörler pattern'i öğrenir, model'i atlatır
• Müşteri davranışı zamanla değişir (drift)
• Yeni anomali tipleri gelir (novelty)

Feedback türleri#

Feedback nasıl uygulanır?#

Pratik mimari#

[Alert] → [Analyst Decision] → [Feedback Queue (Kafka)]
                                     ↓
                              [Label Store (Postgres)]
                                     ↓
                              [Retraining DAG (Airflow)]
                                     ↓
                              [Model Registry (MLflow)]
                                     ↓
                              [Canary Deploy]

7️⃣ Katman 7 — Monitoring#

7.1 — Operational metrics#

• Latency p50, p95, p99
• Throughput (req/sec)
• Error rate
• Memory/CPU usage

7.2 — Data quality#

• Schema değişiklikleri
• Eksik feature oranı
• Outlier rate (girişte)
• Null/NaN oranı

7.3 — Model performance proxies#

• Anomaly score dağılımı (zamanla)
• Alarm rate (zamanla)
• Action rate (gerçekten kaç alarm aksiyona dönüşüyor)
• Calibration drift

7.4 — Drift detection#

• Input drift (Kolmogorov-Smirnov, PSI, MMD)
• Output drift (anomaly score dağılımı)
• Concept drift (label dağılımı zamanla)
• Prediction drift (model davranışı zamanla)

Önerilen stack#

7 Anti-Pattern: Bu Hataları Yapma#

Anti-pattern 1: Model'i offline geliştir, online'a 'kopyala'#

Anti-pattern 2: Tek bir global threshold#

Anti-pattern 3: Alarm = log message#

Anti-pattern 4: Retraining yok#

Anti-pattern 5: Hyperparameter mağarası#

Anti-pattern 6: Manual deployment#

Anti-pattern 7: Feedback yok#

Gerçek Pipeline Örneği: Stripe Radar#

[Card transaction request]
     ↓
[Feature service]
   ├─ Velocity (15 sn pencerede tx sayısı)
   ├─ Cross-merchant pattern
   ├─ Device fingerprint
   ├─ Card BIN risk
   └─ ~1500 toplam feature
     ↓
[ML Scoring]
   ├─ XGBoost (supervised, etiketli geçmiş)
   ├─ Sparse Mixture of Experts (low-volume merchant'lar)
   └─ Multi-stage neural network
     ↓
[Threshold + Action Engine]
   ├─ Block (high risk)
   ├─ 3D Secure challenge (med risk)
   └─ Allow (low risk)
     ↓
[Feedback]
   ├─ Chargeback signal (60-90 gün gecikme)
   ├─ Merchant report
   └─ Active learning queue
     ↓
[Retraining]
   └─ Haftalık model güncellemesi
     ↓
[Monitoring]
   ├─ Real-time drift detection
   ├─ Per-merchant performance
   └─ Adversarial pattern detection

Bu Katmanlar Hangi Modüllerde İşlenecek?#