AIOps ve Prediktif Bakım: Yapay Zekâ ile Incident Öncesi Sinyal Yakalamak

AIOps, operasyon verilerini (log/metric/event) analiz ederek anomali ve ilişki örüntülerini bulmaya, alarmları gruplayıp özetlemeye ve müdahale için “en olası kök neden/etki” çerçevesi sunmaya çalışır. Klasik monitoring; “eşik aşıldı/alarm” üretir. AIOps ise aynı anda çok sinyali görüp noise reduction yapar ve incident’e dönüşme ihtimali yüksek durumları öne çıkarır. Bu prediktif bakım yaklaşımı, bakım ekiplerinin yalnızca olay sonrası değil olay öncesi riskleri de görmesini sağlar.

Soru : AIOps nedir, klasik monitoring’den farkı nedir?

Cevap: Klasik monitoring genelde tek metrikte eşik aşımına alarm üretir; AIOps log/metric/event’i birlikte okuyup anomaliyi bağlama oturtur, benzer alarmları birleştirir ve “hangi sinyal önce ele alınmalı?” önceliğini çıkarır. Amaç tam otomasyon değil, ops ekibine karar desteğidir. Bu sinyallerin gerçekten işe yarayıp yaramadığını görmek için AIOps için bakım KPI’ları ile ölçüm katmanını da net kurmak gerekir.

AIOps’in yakıtı üç sinyal sınıfıdır:

• •Metric: sayısal zaman serileri (CPU, latency, error rate, queue depth)
• •Log: olay metinleri (stack trace, time-out, auth hatası)
• •Event: değişiklik kayıtları (deploy, config change, DB migration, feature flag)

En güçlü anomali tespiti; bu üç sinyali bir olay penceresinde birleştirir: “deploy oldu → p95 yükseldi → error rate arttı → belirli endpoint log’da time-out”.

Anomali tipleri (pratik sınıflandırma)

• •Seviye kayması: baseline kalıcı yükseldi (p95 latency yükseldi)
• •Spikes: kısa süreli sıçrama (error burst)
• •Trend bozulması: kademeli kötüleşme (memory leak gibi)
• •Korelasyon anomali: iki metrik birlikte sapıyor (CPU + queue)
• •Mevsimsellik: sezon/hafta içi paterni bozuldu (otel sezonu, kampanya)

Prediktif bakım, “incident olmadan önce” riskin yükseldiğini söyleyebilmektir. Bu her zaman “kesin tahmin” değildir; çoğu zaman olasılık ve uyarı üretmektir: “Bu gece CPU patlayabilir” gibi bir sinyalin değeri, doğru aksiyona bağlanmasıyla ölçülür.

Prediktif sinyal örnekleri (otel/B2B)

• •Queue birikmesi + latency trendi → yaklaşan time-out
• •Error rate küçük ama sürekli artıyor → yakında P1’e dönebilir
• •Memory leak paterni → gece trafik artınca crash
• •DB connection pool doluluk trendi → rezervasyon/ödeme akışında risk

Key Statistics / Data Point (yumuşatılmış): AIOps kullanan ekiplerde, insan gözüyle fark edilmesi zor “küçük ama kritik” anomaliler daha erken yakalanıp incident’e dönüşmeden müdahale edilebildiği görülür; özellikle yüksek log/metric hacmi olan projelerde.

Soru : Yapay zekâ log ve metric’lerden nasıl anomali tespit eder?

Cevap: Model; geçmiş baseline’ı öğrenerek sapmayı (spike/trend/shift) tespit eder, log’larda tekrar eden hata paternlerini gruplar ve event (deploy/config) ile korelasyon kurar. Sonuç; “bu sapma anlamlı mı, hangi bileşene işaret ediyor, öncelik ne?” şeklinde bir özet/alert üretmektir. Bu yaklaşım, reliability hedeflerini yalnız incident sonrası değil incident öncesi sinyallerle yönetmek isteyen ekiplerde AIOps ve error budget ilişkisi açısından da güçlü bir temel oluşturur.

AIOps’in en hızlı değer ürettiği yer; kritik akışlar ve yüksek hacimli sinyal üreten katmanlardır.

Otel senaryoları (rezervasyon/ödeme odaklı)

• •Rezervasyon arama → fiyat → ödeme adımlarında latency/error artışı
• •Kampanya/season trafiğiyle bot/CDN davranış değişimi
• •PMS/OTA entegrasyon time-out anomali tespiti
• •“Ödeme sağlayıcı yavaşlıyor” sinyaliyle proaktif fallback/limit

Mini örnek: Antalya gibi sezonda trafik artan destinasyon odaklı otel sitelerinde, CDN cache hit oranı düşerken origin load artıyorsa; AIOps bunu “yaklaşan incident” sinyali olarak işaretleyebilir. Aynı anda rezervasyon veya ödeme funnel’ında anormal bir düşüş görülüyorsa, bu sinyali incident öncesi dönüşüm sinyalleri olarak okumak mümkün hale gelir.

B2B senaryoları (API/raporlama odaklı)

• •API endpoint bazlı p95 latency sapması
• •Rapor/export job sürelerinin uzaması (pipeline anomali)
• •Login/permission hatalarında pattern artışı
• •Büyük release sonrası “sessiz yavaşlama” (CWV/INP artışı)

AIOps’in başarısı, “insan rolünü” net tanımlamaya bağlıdır. Tam otomasyon, özellikle prod müdahalede risklidir. En sağlıklı model; AI’ın triage ve özetleme yaptığı, insanın onay ve müdahale verdiği hibrit modeldir. Dağıtık ekiplerde bu uyarıların vardiyalar arasında kaybolmaması için AI assisted ops uyarılarının async takibi de operasyon tasarımının parçası olmalıdır.

İnsan-in-the-loop kural seti

• •AI: anomaliyi yakalar, gruplar, önceliklendirir, öneri üretir
• •İnsan (L1/L2): doğrular, incident açar, müdahale/rollback kararını verir
• •Model: sonuçtan öğrenir (false positive etiketi, feedback loop)

AIOps’i devreye almak, araç kurmaktan çok akış kurmaktır: veri → analiz → karar → aksiyon.

AIOps temel akış (özet)

Log/metric/event → normalize & enrich → anomaly detect → correlate → score (P1–P4) → alert → ticket → runbook → postmortem feedback

Önemli teknik not: Bot trafiği ve CDN davranışları doğru etiketlenmezse yanlış pozitif artar. Bu yüzden güvenlik ve analitik katmanla birlikte yorumlanmalıdır:

Bu sinyallerin karar verebilir hale gelmesi için log metric anomali tespiti disipliniyle düzenli dashboard ve trend analizi kurulmalıdır.

Aynı çerçeve, crawl hataları, CWV düşüşleri ve indexleme sapmaları gibi teknik SEO sinyallerinde anomali tespiti yapmak için de kullanılabilir.

Şablon seçimi: Checklist + Sprint Plan (Checklist / Sprint / Fix)

Çoğu içerik AIOps’u “hype” düzeyinde anlatır; bu rehberin farkı, otel/B2B bakım aksiyon akışına nasıl oturacağını somutlaştırmasıdır: ticketing entegrasyonu, insan-onayı, runbook bağlantısı, noise ölçümü ve pilot planı. Böylece AIOps, “demo” değil “operasyon sistemi” olur. Bakım ve Destek hizmetiyle AI assisted ops sürecinizi güçlendirin.

Kapsam, destek modeli ve operasyonel beklentiler için Bakım ve Destek hakkında sık sorulan sorular sayfasını da inceleyebilirsiniz.