Bir çalışan “sistem yavaş” dediğinde sorunun kaynağı tek bir bileşen olmayabilir. Dizüstü bilgisayarın belleği dolmuş, kablosuz ağda paket kaybı başlamış, kimlik doğrulama servisi gecikmiş veya uygulamanın bir arka uç bağımlılığı yavaşlamış olabilir. Geleneksel destek modeli, kullanıcı bildiriminden sonra bu katmanları sırayla kontrol eder. Sonuç; uzun teşhis süresi, ekipler arasında yönlendirilen kayıtlar ve aynı sorunun farklı kullanıcılarda tekrar etmesidir.
AIOps ve dijital çalışan deneyimi yaklaşımı bu akışı tersine çevirmeyi amaçlar: önce deneyimi ölçer, ilgili teknik sinyalleri ortak bağlamda toplar, olası nedeni önceliklendirir ve uygun durumlarda düzeltici işlemi kullanıcı etkilenmeden başlatmayı hedefler. Böylece destek deneyimi tepkisel bir kuyruktan ölçülebilir bir hizmet iyileştirme döngüsüne taşınır.
AIOps ve dijital çalışan deneyimi nedir?
AIOps, “Artificial Intelligence for IT Operations” ifadesinin kısaltmasıdır; Türkçede yapay zekâ destekli BT operasyonları olarak düşünülebilir. Amaç, yüksek hacimli operasyonel veriyi istatistiksel yöntemler ve makine öğrenmesiyle ilişkilendirerek anormallikleri, tekrar eden örüntüleri ve muhtemel kök nedenleri daha hızlı belirlemektir. Bu, bütün kararların yapay zekâya bırakılması anlamına gelmez.
Dijital çalışan deneyimi ise çalışanın cihaz, ağ, kimlik, sanal masaüstü ve iş uygulamaları üzerinden görevini ne kadar kesintisiz tamamlayabildiğine odaklanır. İki yaklaşım birleştiğinde teknik sağlık göstergeleri, “çalışan işini yapabiliyor mu?” sorusuna bağlanır.
Bileşen değil, kullanıcı yolculuğu ölçülmeli
Sunucunun çalışıyor olması, hizmetin iyi olduğu anlamına gelmez. Örneğin bordro uygulaması erişilebilir olabilir; ancak oturum açma 40 saniye sürüyor, rapor ekranı belirli bir şubede zaman aşımına uğruyor veya yeni yazılım sürümü eski cihazlarda çöküyor olabilir. Bu nedenle izleme kapsamı cihazın işlemci (CPU) kullanımı ya da ağ gecikmesiyle sınırlı kalmamalıdır.
Önce kritik yolculuklar tanımlanmalıdır: güne başlama ve oturum açma, sanal özel ağ (VPN) bağlantısı, görüntülü toplantıya katılma, kurumsal uygulamada işlem tamamlama gibi. Her yolculuk için teknik sinyallerin yanında başarı oranı, bekleme süresi ve etkilenen kullanıcı grubu izlenmelidir.
Sağlam temel: Ortak ve bağlamlı telemetri
Telemetri, sistemlerin çalışırken ürettiği ölçüm ve olay verileridir. OpenTelemetry; izleri, metrikleri, günlükleri ve bu sinyaller arasında bağlam taşıyan baggage bilgisini desteklenen sinyaller olarak tanımlar. Metrik belirli bir andaki ölçümü, günlük bir olayı, iz ise bir isteğin bileşenler arasındaki yolunu gösterir. Uç nokta sağlığı, Wi-Fi kalitesi, kimlik olayları ve değişiklik kayıtları da aynı zaman çizelgesine eklendiğinde parçalı ekranlar yerine uçtan uca görünürlük oluşur.
Verinin değeri hacminden değil bağlamından gelir. Cihaz, kullanıcı grubu, lokasyon, uygulama sürümü, hizmet sahibi ve son değişiklik bilgisi ortak bir varlık modeliyle ilişkilendirilmelidir. Toplama katmanı üreticiye bağımlılığı azaltacak biçimde tasarlanmalı; gereksiz kişisel veri alınmamalı, saklama süreleri ve erişim yetkileri açıkça belirlenmelidir.
Gürültüden kök nedene nasıl gidilir?
Bir kesinti sırasında yüzlerce eşik alarmı oluşabilir; fakat bunların çoğu aynı olayın belirtisidir. AIOps katmanı zaman yakınlığı, ortak bağımlılık, değişiklik geçmişi ve etkilenen kullanıcı kümesini birlikte değerlendirerek alarmları tek bir olay kaydında toplar. Böylece ekip “hangi alarmı kapatmalıyım?” yerine “hangi değişiklik hangi yolculuğu bozdu?” sorusuna yönelir.
Sabit eşikler tek başına yeterli değildir. Pazartesi sabahı oturum açma yoğunluğu ile gece vardiyasının normali farklıdır. Mevsimsellik ve lokasyon bazlı taban çizgileri kullanılmalı; yine de model çıktısı kanıt olarak değil, araştırılacak hipotez olarak ele alınmalıdır. Kök neden önerisi; ilişkili iz, günlük, sürüm ve değişiklik kaydıyla açıklanabiliyorsa operasyon ekibi için güvenilir hâle gelir.
Otomasyonun sınırı ve insan gözetimi
Düşük riskli ve geri alınabilir işlemler uygun başlangıç adaylarıdır: önbelleği temizlemek, başarısız bir servisi yeniden başlatmak, diskteki güvenle kaldırılabilen geçici dosyaları temizlemek veya kullanıcıya doğrulanmış bir kendi kendine çözüm adımı sunmak. Her otomasyon için tetik koşulu, kapsam, başarı ölçütü, zaman aşımı ve geri dönüş planı yazılı olmalıdır.
Kimlik politikası değiştirmek, çok sayıda cihazdan yazılım kaldırmak ya da üretim trafiğini yönlendirmek gibi yüksek etkili işlemler onay kapısından geçmelidir. NIST AI Risk Management Framework, yapay zekâ sistemlerinde sürekli izleme ile insan gözetiminin rollerinin tanımlanmasını vurgular. Modelin olmayan bir sorunu var göstermesi (yanlış pozitif) veya gerçek sorunu kaçırması (yanlış negatif) düzenli ölçülmeli; sapma görüldüğünde otomasyon durdurulabilmelidir.
Sık yapılan hatalar
İlk hata, kullanım senaryosu belirlemeden bütün veriyi tek platforma taşımaktır; sonuç çoğu zaman pahalı bir “veri gölü” ve daha fazla alarm olur. İkincisi, başarıyı yalnızca kapanan destek kaydı sayısıyla ölçmektir. Destek kayıtları azalırken kullanıcı deneyimi kötüleşebilir; yolculuk başarı oranı, etkilenen kullanıcı sayısı, tespit ve düzeltme süresi birlikte izlenmelidir.
Diğer hatalar; her lokasyona aynı taban çizgisini uygulamak, varlık envanterini güncel tutmamak, model kararını açıklayamamak ve geri dönüşsüz otomasyon çalıştırmaktır. Çalışan telemetrisi gözetim aracına dönüştürülmemeli; amaç, kişiyi değerlendirmek değil hizmet kalitesini ölçmek olmalıdır.
Sektörel kullanım örnekleri
Üretimde vardiya başlangıcındaki ortak terminal ve kablosuz el cihazı sorunları, üretim uygulamasına etkisiyle birlikte izlenebilir. Perakendede mağaza ağı, satış noktası (POS) ve stok terminali sinyalleri lokasyon bazında ilişkilendirilerek bölgesel arıza erken görülebilir. Lojistikte el terminallerinin dolaşım ve Wi-Fi geçiş sorunları teslimat sürecine bağlanabilir.
Finans kuruluşlarında şube cihazı, güvenli erişim ve temel iş uygulaması tek yolculuk olarak ölçülebilir. Sağlıkta klinik iş istasyonlarında oturum açma ve uygulama yanıt süresi izlenirken mahremiyet ve erişim ilkeleri özellikle sıkı tutulmalıdır. Ortak nokta, teknik metriğin doğrudan iş adımına bağlanmasıdır.
Aşamalı uygulama yol haritası
İlk aşamada en fazla üç kritik çalışan yolculuğu seçilir; mevcut destek kayıtlarıyla başlangıç ölçümü çıkarılır. İkinci aşamada uç nokta, ağ, kimlik ve uygulama telemetrisi ortak zaman ve varlık modeliyle birleştirilir. Veri kalitesi doğrulanmadan modelleme yapılmaz.
Üçüncü aşamada alarm birleştirme ve kök neden önerileri “insan onaylı” pilot olarak işletilir. Dördüncü aşamada yalnızca sık tekrarlanan, düşük riskli ve geri alınabilir iki veya üç işlem otomatikleştirilir. Son aşamada kapsam yeni yolculuklara açılır; model doğruluğu, kullanıcı etkisi, maliyet ve mahremiyet kontrolleri yönetişim kurulunda düzenli gözden geçirilir.
Nereden başlamalı? Kısa kontrol listesi
· En kritik üç çalışan yolculuğu ve hizmet sahibi belli mi?
· Uç nokta, ağ, kimlik ve uygulama verisi ortak zaman damgası ve varlık kimliğiyle ilişkilendirilebiliyor mu?
· Başarı ölçütleri yalnızca destek kaydı sayısını değil kullanıcı etkisini de gösteriyor mu?
· Otomatik işlemlerin kapsamı, onay eşiği ve geri dönüş planı tanımlı mı?
· Toplanan verinin amacı, erişimi ve saklama süresi çalışanlara ve yöneticilere açık mı?
Kaynaklar
· OpenTelemetry — Signals (https://opentelemetry.io/docs/concepts/signals/)
· OpenTelemetry — Collector (https://opentelemetry.io/docs/collector/)
· NIST SP 800-137 — Information Security Continuous Monitoring (https://csrc.nist.gov/pubs/sp/800/137/final)
· NIST — Artificial Intelligence Risk Management Framework 1.0 (https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10)
· CISA — Use Logging on Business Systems (https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/use-logging-on-business-systems)
