Watson AIOps Hikayenizi Oluşturun!
Merhaba, AIOps ve Watson AIOps çözümü ile ilgili Türkçe kaynak oluşturmaya çalıştığım şu günlerde, AIOps yaklaşımını ve kurumların bir olay yönetimine (Incident Management) ve olay analizlerine (Incident Analysis) nasıl çözüm ürettiklerini ve buna karşılık Watson AIOps’un getirdiği faydalar ve çözümler nelerdir bu yazıda bunlara değineceğim.
Öncelikle AIOps’u anlamak için şu anda kurumların AIOps olmadan nasıl olay yönetimi yaptıklarını iyi anlamamız gerekiyor. Bu nedenle ilk olarak AIOps olmadan önceki hikayeyi anlatacağım daha sonra ise AIOps ile birlikte olan kısma bakacağız.
Bir Olay Yönetim Zaman Cizelgesi üzerinde hikayeyi anlatacağım.
Bir sorunun ortaya çıkacağına dair ilk sinyal genellikle loglardan bulunabilir. Ne yazık ki, bu erkenden oluşan sinyaller genellikle bir olay meydana geldikten sonra geriye dönüp bakılan ve teşhis için kullanılır.
Loglarlar ilgili bir diğer sorun ise, çok sayıda farklı teknolojiler üzerinden loglar toplanmakta ve hangilerinin neyi temsil ettiğini, hangi logun doğru-hangisinin yanlış bir durumu temsil ettiğini anlamak için log toplama çözümlerini yapılandırmak için önemli bir çaba gerekmektedir. Logların ayrıştırılması ve analizlerinin yapılması genellikle manuel bir süreç ile yürütülür.
Logları inceledikten sonra halen sorunun teşhisi ile ilgili net bir durum söz konusu değil ise, bir sonraki sinyale bakılır. İzleme sitemlerinden toplanan çeşitli metrik dataları bulunmaktadır. Metrikleri inceleyerek sorunu tespit edebiliriz fakat buradaki sorun ise, çoğu işletmede bir çok katman üzerinde (altyapılar,uygulamalar,sanallaştırma,işletim sistemleri vb.) uygulama performansına yönelik monitoring çözümlerine sahiptir. Her seviyede toplanan çok büyük miktarda toplanan metrik datalarının kombinasyonunu yapmak zordur. Çoğu zaman o kadar çok metrik datası toplanır ki, bir sorun olduğunda analiz edilmesi ve ekiplerin doğru izleri bulması çok fazla zaman alabilir. Günümüzde, metrikler sorunların oluşmasını önlemek için değil, sorun meydana geldikten sonra sorunu tespit etmek için kullanılmaktadır.
Loglar ve Metrikler bir sorun olduğunda en güçlü sinyalleri toplayacağımız noktalar. Buralardan da sorunu tespit edemediğimiz zaman topoloji değişikliklerinin içeren datalar bakarız. IT içerisinde topoloji datası toplayan bir çok araç vardır ancak yine bunların çoğu belirli bir düzeyde bilgi sağlar. Dağıtık bir mimarideki topoloji datasının tümü ile göremeyiz.
Topoloji dataları ile sorunu tespit edemediğimiz gibi, tüm sistemin/uygulamaya ait bileşenlerin uçtan uca topolojisini takip etmek için büyük bir çaba ve zaman harcamak gerekir.
Bu üç farklı kategorideki veriler izlenen hizmet/uygulamanın “Gözlemlenebilirliğini” sağlar. Toplanan loglar, metrikler, topoloji metrikleri ile uygulama içerisinde neler olup bittiğini, neden sorun olduğunu, zayıf noktaların nerede olduğunu anlayabiliriz. Bu nedenle “Observability” çözümleri bizler için çok önemlidir.
Teoride bu şekilde başarılı olunabilir fakat gerçek hayatta farklı veri domainlerinden verileri toplamak, bunları ayrıştırmak,gruplandırmak ve analiz etmek çok da kolay bir iş değildir.
Gözlemlenebilirlik, bizlere toplanan farklı kategorilerdeki verilere göre hizmetin içerisinde neler olduğunu göstermektedir. Diğer bir kritik konu ise Availability (Erişilebilirlik). Erişilebilirlik ise bizlere hangi uygulama/hizmetlerin etkilendiğini ve son kullanıcıların nasıl etkilendiği hakkında bilgiler içerir..
T-o zaman diliminde bir sorun oluştuğunda, bir bildirim veya uyarı oluşturulur ve ilk müdahale ekiplerinin ekranına düşer. Çok sayıda potansiyel veri kaynağı (loglar,metrikler,topoloji) olduğundan dolayı bir olay hakkında bir çok uyarı yada alarm üretilecektir. Aslında aynı sorunun farklı verilere bakarak oluşturulan olay bilgileri diye düşünebiliriz. Tabi bu event,alertleri incelemek zaman alır ve bir sonuç çıkarmakta mümkün olmayabilir.
Devamında ise sorun ile ilgili event/uyarılardan bir ticket-case oluşturulur. Sorunun ne olduğunu ve onu çözmek için hangi ekibin sorumlu olduğunu belgeler. Yani problemin ait ilk işaretleri T-2'de ortaya çıkarken, problemi aslında T-0'da ortaya çıktığını anlıyoruz ve T1 ile T2 zaman dilimi arasında bir yerde çözmeye başlıyoruz. Tabii halen sorunun ne kadar büyük bir alana etki ettiği bilinmediği için ilgili ekipler sorunun farkında olmayabilir.
T3 zaman dilimine geldiğimizde ise, destek mühendisi nihayet sorunu araştırmaya başlıyor ve sorunu teşhis etmek için sırasıyla topoloji, metrik ve log çözümlerine başvuruyor. Problemin karmaşıklığına bağlı olarak daha fazla uzmanlığa sahip kişileri bilgilendirmesi veya gözlemlenebilirlik çözümlerine ihtiyaç duyar.
Evet buraya kadar, geleneksel bir olay yönetiminin zaman dilimlerinde nasıl yönetildiğini anlatmaya çalıştım. Yukarıda bahsettiğim zorlukları yönetmenin daha iyi bir yolu var aslında..
Buradan sonra AIOps ile olay yönetimin nasıl yapılacağını bakacağız. Yukardaki zaman dilimlerinde bir olay meydana geldikten sonra ilk müdahale çalışanlar tarafından yapılmaktadır. Çalışanlar bu süreçte sadece olayları geç farkına varmıyorlar, problemlerin tespit sürecinde de uzun zamanlar harcayabiliyorlar.
Watson AIOps, T-3'den başlayarak tüm verileri toplar, sorunu daha erkenden tespit eder ve mühendislerin dahil olduklarında ihtiyaç duydukları bilgi-senaryolara hazır bir şekilde sahip olur.
Watson AIOps, olabilecek tüm farklı kaynaklardan verileri toplar, bunları bir araya getirir ve bizlerin anlayacağı hale getirir. Watson AIOps, anomalileri erken tespit eden yapay zeka modellerini kullanarak gelecekteki olası sorunlarına karşı sinyalleri sorun olmadan daha önce bulabilir. Watson AIOps, T-1 ve T-2 log mesajlarından önce sorunlarına ait sinyalleri yakalayabilir.
Watson AIOps, potansiyel bir sorunu tespit ettikten sonra, geçmiş olay bilgilerinden yararlanarak sorunu çözmek için kullanılabilecek otomatik bir runbook veya script’i çalıştırarak olası sorunun gerçekleşmeden ilk aşamadan çözecektir.
Eğer runbook yok ise, Watson AIOps, sorunun gerçekleşmemesi için Next Best Action önerilerinde bulunabilir.
Watson AIOps, sistemlerin ürettiği çok sayıda veriden anlam çıkarmak için yapay zeka modellerini de kullanır. Ayrıca farklı log türlerinin manuel olarak ayrıştırılmasına gerek yoktur. Watson AIOps, servis hatalarının bildiren logları otomatik olarak tanımlamak için bir dize machine learning modeli kullanır. Yeni sorunları tespit ettiğinde, kime bildireceği ve bir sonraki aksiyonun neler olduğu konusunda otomatik runbooklar hakkında öneriler sunmaktadır.
Watson AIOps, potansiyel bir sorun hakkında daha fazla sinyal tespiti yapıyor ve daha fazla insgiht elde etmek için daha fazla AI modeli kullanıyor.
Bunun yanı sıra çok değişkenli analiz,birden çok bileşendeki davranış standartlarını bulur ve aksi bir durumda bizleri uyarmaktadır. Watson AIOps, davranışsal temelleri sürekli olarak oluşturmakta ve güncellemekedir. Bir bileşen temel çalışmanın dışına çıktığında ise otomatik olarak bir uyarı üretir.
Watson AIOps, AI modellerine ortamın uçtan uca topolojisini dahil ederek olayı etki alanını haritalayabilir. Bu farklı bileşenlerdeki farklı problemler arasında öncelik belirlemek veya farklı olaylar arasında nasıl bir etkileşim olduğunu anlamak için geniş bir analize yardımcı olur.
Bu nokta Watson AIOps, sadece bir sorun var demekle kalmıyor, bu sorunun nerede olduğunu ve neyin etkilendiğini tam olarak gösteriyor.
Sorun gerçekten ilk defa olmuş ise ve Watson AIOps, hizmeti etkilemeden önce sorunu çözemezse, izleme çözümlerinde alarmlar üretmeye başlar. Watson AIOps yalnızca tüm olayları yönetilebilir bir kümede toplamak ve gruplamakla kalmaz, aynı zamanda stardantları algılayarak bunlardan bir anlam çıkarmaya yardımcı olur.
Yine sorunun tespitini, ve nelerin etkilendiğine ait kayıtları tutar ve sorunun nasıl çözüleceğine ait bir dizi öneriler sunabilir.
Yeni bir olay oldu ve yeni bir ticketin açılmasıyla sonuçlandığında, Watson AIOps sorunun çözümüne ilişkin önerileri geliştirmeye devam etmek için geçmiş olay bilgileri hakkında referans verir. Ticket ilk sistem mühendisine atanırken,Watson AIOps sürekli olarak olaya ait izlemeye devam eder, daha fazla insanı bilgilendirerek dahil eder.
Bu noktada Watson AIOps, daha önce de belirttiğim gibi bir sorun olmadan T-3'ten itibaren tüm sinyalleri ve işaretleri toplar ve ekiplerin sorunu çözmek için birlikte iş birliği yaptığı T3'e kadar tüm süreci inşa etmiş olur.
Burada runbooklar oluşturmak ve hazırlamak önemli, çünkü olay tespitinden sonra eğer olay ile ilgili bir runbook var ise direk onu çalıştırabilir ve sonrasıda bizi bilgilendirir. Eğer bir runbook yok ise yada olay ilk defa gerçekleşmiş ise sorunu çözmeye yardımcı olmak için önerilerde bulunabilir.
Özet:
Olay yönetim zaman çizelgesindeki T3 noktasına ulaşana kadar bunların hiçbiri sorunu çözmemiş olsa bile, Watson AIOps, ekiplerin ihtiyaç duyabileceği tüm bilgileri zaten toplamış, bir araya getirmiş ve önemli içgörüleri ortaya çıkarmıştır. Watson AIOps, sorunu çözmenin çok daha kolay bir yolunu geliştirmiştir.
IBM Cloud Pak for Watson AIOps, sorunları daha erken tespit eder, sorunları daha erkenden çözmeye çalışır, insanları daha önceden bilgilendir, mevcut verileri toplayarak inshightlar oluştur, geçmiş bilgiler ile cross referenslar sağlar. Tüm bunları basit ve kolay bir şekilde sunar. Ekipler logları,metrikleri anlamlandırmaya çalışmak yerine problemleri çözmeye konsantre olur.
Watson AIOps ile ilgili bazı ekran görüntülerini aşağıda görebilirsiniz.
IBM Blog;
