AIOps nedir?

Kelimeyi değil, yapılan işi sorgulayın

Terim, BT operasyonlarına büyük veri ve makine öğrenmesi uygulayan platformlar için kullanılan bir analist etiketi olarak doğdu. Bugün yapay zekâ kelimesi geçen hemen her operasyon aracına söyleniyor, yani tek başına pek bir şey anlatmıyor. Satıcı sunumunda "AIOps" duyduğunuzda aklınıza beş ayrı iş gelsin. Her birinin tekniği, olgunluğu ve yanlış gitme biçimi farklı.

Anormal davranışı bulmak

"800 ms üstünde alarm ver" gibi sabit bir eşik iki yönde başarısız olur. Pazartesi sabahı yoğunluğunda 750 ms olağan olabilir. Normalde 120 ms olan pazar gece üçte 500 ms görülmesi ise açıkça tuhaftır ama eşiğin altında kaldığı için kimse fark etmez.

Mevsimsel taban çizgileri her dönem için normali öğrenerek bunu çözer. Yaygın yöntem geçmişi haftanın saatlerine böler: 7 × 24 = 168 dilim. Her dilim tipik bir değer ve bir yayılım öğrenir, yeni ölçüm kendi dilimine göre puanlanır.

Herhangi bir ürünü incelerken şunları sorun:

• Uç nokta başına mı, servis başına mı? Yavaşlayan yeni bir uç nokta servis ortalamasının içinde saklanabilir.
• Yeni servislerde ne yapıyor? Geçmiş yoksa tahmin etmek yerine bunu söylemeli.
• Olay taban çizgisini kirletiyor mu? Kötü geçen bir hafta yeni normal olursa artık işaretlenmez.
• Bayramlar ve kampanyalar ne yapıyor? Türkiye'de tarihi her yıl kayan dini bayramlar haftalık bir modelin göremeyeceği düşüşler üretir. O günlerde gürültü bekleyin.
• Düşük trafiği nasıl ele alıyor? On istekten çıkan p99 anlamlı değildir, puanlama sistemi bunu bilmeli.

Anomali, etki demek de değildir. Bir toplu iş, hiçbir müşterinin görmediği bir saatte servis gecikmesini ikiye katlayabilir. Birini uyandırmak için kullanıcı etkisine bağlı SLO ve burn-rate alarmlarını kullanın, anomalileri destekleyici kanıt sayın.

Alarm gürültüsünü azaltmak

Veritabanı yavaşladığında veritabanından, onu çağıran her servisten, onların çağıranlarından ve uçtaki sentetik probdan alarm gelebilir. Tek bir sorun için onlarca bildirim çok olağan bir tablodur.

Gruplama burada topolojiye dayanır. Servis haritası A'nın B'yi, B'nin de veritabanını çağırdığını gösteriyorsa, üçünde aynı anda çıkan alarmlar büyük ihtimalle tek sorundur. Topoloji yoksa araç yalnızca zaman penceresine bakabilir ve aynı dakikada çıkan ilgisiz iki arızayı birleştirir.

Bunun için topolojinin gerçek olması gerekir. Canlı trace'lerden üretilen harita güncel kalır, elle tutulan bir CMDB zamanla gerçeklikten kopar. Trace'lerin yakalamadığı bağımlılıklar, örneğin ortak bir depolama birimi veya aynı düğümdeki gürültülü komşu, grubu şaşırtabilir. Bu yüzden servisleri altlarındaki altyapıyla da ilişkilendirin. Haritanın kaynağını dağıtık izleme nedir yazısında bulabilirsiniz.

Olası nedeni bulmak

Sıralamanın nasıl çalıştığını kurgu sayılarla görelim. Saat 14.05'te odeme servisinin p95 değeri 300 ms'den 2,1 saniyeye çıkıyor. Motor adayları şöyle sıralıyor:

Bunda derin bir zekâ yok. Sıralama zamandaki öncelik-sonralığa, bağımlılık grafiğindeki konuma ve sinyallerin birbirini desteklemesine dayanır. Veri eksikse bu yüzden başarısız olur. Sorunu çıkaran değişiklik hiçbir yerde kayıtlı değilse, örneğin elle girilmiş bir güvenlik duvarı kuralı veya veritabanı parametresi, sıralamaya giremez. Araç gördüğünü sıralar, belki de kendinden emin bir şekilde.

Bu nedenle tek bir ilan edilmiş "kök neden" yerine, tıklayıp doğrulanabilen kanıtlı adaylar sunan araçlara bakın. Gerçek olayların çoğunda birden fazla etken vardır, müdahale eden kişi akıl yürütmeyi saniyeler içinde denetleyebilmelidir.

Operasyonda dil modelleri

Dil modelleri yeni bir yetenek getirdi: dağınık bağlamı okuyup insanın anlayacağı bir açıklama yazmak.

İyi kullanımlar:

• "Dün geceki sürümden sonra hangi servisler yavaşladı?" sorusunu verinize karşı gerçek bir sorguya çevirmek
• toplantıya yeni katılan biri için uzun bir olay akışını özetlemek
• deneyimsiz bir mühendise tanımadığı ekranı veya metriği açıklamak
• kayıtlı olaylardan, insanın düzelteceği bir olay sonrası rapor taslağı çıkarmak

Kötü kullanımlar:

• yüzdelik veya burn rate hesabını modelin kafasından yaptırmak; bu sıradan kodun işidir
• veri getirmeden cevap istemek; boşluğu inandırıcı uydurmalarla doldurur
• yıkıcı eylemleri modelin kendi yargısına bırakmak

Kullanılabilir olanı riskli olandan ayıran tasarım kuralı şudur: önce getirilen gerçek veri, sonra onu açıklayan model, en sonda insanın doğrulama yolu. Model bir sorgu üretiyorsa sorguyu ve dönen sonucu görebilmelisiniz.

İkinci konu verinin kendisidir. Model loglarınızı ve trace'lerinizi okumak zorundadır, bu da eski AIOps türlerinde olmayan bir veri sorusu doğurur: istemler nereye gidiyor? Türkiye'de kişisel veri taşıyan loglar için bu soru genellikle ilk sorulardandır. Bkz. KVKK ve veri yerelliği.

Harekete geçmek

Otomatik müdahale, arıza ve çözüm iyi bilindiğinde eski ve kanıtlanmış bir yöntemdir: takılan bir tüketiciyi yeniden başlatmak, dolan geçici dizini temizlemek, kapasite eklemek. Güvenli ilerleme şöyledir:

1. Her alarmı insanın uygulayacağı bir runbook'a bağlayın.
2. Runbook'u otomatikleştirin, çalıştırmak için insan onayı isteyin.
3. Dar kapsamlı, iyi anlaşılmış, geri alınabilir ve sıklığı sınırlı eylemleri gözetimsiz çalıştırın.

Otomasyonun ne sıklıkta çalışabileceğine sınır koyun. Bellek sızıntısını tüm filo etkilenene kadar saklayan bir yeniden başlatma döngüsü, gece aranmaktan daha kötüdür.

Etiket satıldığını gösteren işaretler

Değerlendirmede şunları sorun:

• Bana yanlış bir cevap gösterin. Bunu sahada çalıştırmış üreticiler nasıl yanıldığını bilir.
• Veri eksikse ne yapıyor? "Kanıt yetersiz" sağlıklı bir cevaptır.
• Ağımdan ne çıkıyor, istemler dahil? Bunu yazılı isteyin.
• Müdahale eden kişi nedenini görebiliyor mu? Birini arayan veya üretimi değiştiren hiçbir şey kara kutu olmamalı.
• Yapay zekâ kapalıyken çalışıyor mu? Olay süreciniz tek bir modele bağlı kalmamalı.

Geçmiş olaylarınızla test yapın. Gerçek neden kaç olayda ilk adaylar arasındaydı, araç kaç kez ekibi yanlış yöne gönderdi? Bunu ölçmeden MTTR'de yüzde şu kadar düşüş iddiası sadece pazarlama cümlesidir.

Satın almadan önce düzeltilecekler

AIOps elinizdekinin kalitesi üzerine kurulur. Şunları kurtaramaz:

• tutarlı adlandırma olmayan, aynı uygulamanın üç ayrı adla göründüğü servisler
• bağımlılık grafiğinde delik bırakan eksik trace'ler
• dağıtım ve ayar değişikliği kaydının olmaması
• sahibi olmayan alarm kuralları

Bunları düzeltmek yapay zekâ ekleseniz de eklemeseniz de ekiplerinize yarar.

Wrentrix bunu nasıl yapıyor?

Wrentrix, uç noktalar ve metotlar için haftanın saatine göre taban çizgilerini kendi geçmişinden öğrenir. Problem motoru sinyalleri topolojiye göre tek bir olayda toplar. Otomatik kök neden analizi tıklanabilir kanıt zinciriyle sıralı adaylar verir, doğal dille sorular bir sorgu planına dönüşür. Dil modeli ağınızın içinde çalışır, dış modele veri gitmez ve yapay zekâ tümüyle kapatılabilir. Müdahale webhook'lar veya Ansible AWX iş şablonlarıyla, otomatik ya da onaylı yürür. Akışı canlı demoda örnek veriyle görebilirsiniz.

Sık sorulan sorular

AIOps basitçe nedir?

AIOps; metrik, log ve trace gibi operasyon verisi üzerinde istatistik, makine öğrenmesi ve dil modelleri kullanmaktır. Amaç sorunları daha erken bulmak, alarm gürültüsünü azaltmak, olası nedenleri önermek ve bazen çözümü tetiklemektir. Risk taşıyan kararlar yine insanlarda kalır.

AIOps ile gözlemlenebilirlik arasındaki fark nedir?

Gözlemlenebilirlik, sistemlerinizi anlayacak ve onlara yeni sorular soracak kadar zengin veriye sahip olmaktır. AIOps bu verinin üzerinde çalışarak tespit ve teşhisin bir kısmını otomatikleştiren analiz katmanıdır. İyi telemetri yoksa AIOps'un çalışacak malzemesi de yoktur.

AIOps SRE'lerin yerini alır mı?

Hayır. Bağlam toplama ve alarm gruplama gibi tekrar eden kısımları üstlenebilir, ama sistemleri tasarlamak, riskli kararları tartmak ve yeni arıza biçimleriyle uğraşmak insanlarda kalır. Genellikle rolü ortadan kaldırmaz, emeğin yerini değiştirir.

AIOps veriyi buluta göndermeden çalışabilir mi?

Evet, platform ve modeller kendi altyapınızda çalışıyorsa çalışır. Taban çizgisi ve topoloji analizi dış servis gerektirmez, dil modelleri de bazı kalite ödünleriyle yerelde barındırılabilir. Her üreticiye istemler ve lisans kontrolleri dahil tam olarak hangi verinin ağdan çıktığını sorun.

AIOps'un işe yaradığını nasıl ölçerim?

Gerçek olayları yeniden oynatıp gerçek nedenin ne sıklıkta ilk adaylarda olduğuna ve aracın ne sıklıkta yanılttığına bakın. Ardından birkaç ay boyunca olay başına alarm sayısını ve ilk doğru hipoteze kadar geçen süreyi izleyin. Yalnızca MTTR'ye bakarken dikkatli olun, çünkü olay karmasına göre çok oynar.