AIOPS çözümlerinin 9 eksiği
IT Operasyonları ve sistem yönetimi için yapay zekayı kullanmak anlamına gelen AIOPS, şirketlere bir çok alanda yüksek verimin kapısını açıyor. Bu sebeple de iş dünyasının yeni trendi durumunda…
Bildiğimiz gibi kullandığımız tüm programlar, programcısı tarafından yazıldıktan sonra paket haline getirilip bir sunucuya yükleniyor ve bu sistemde çalıştırılıyor.
Bundan sonra, sistemin çalışması, programlara erşim, hızlı yada yavaş çalışmaları, yedeklenmeleri, güvenlikleri vs. sistem mühendislerinin sorumluluk alanına giriyor.
Yapılan işin, günden güne ağırlaşıp, karmaşıklaştığı oldukça açık. Zira günümüzde yönetilen sunucu sayısının, uygulama çalıştıran ve işletim sistemi içeren cihazları da dahil edersek (Akıllı Tv, Cep Telefonu, Adsl Modem, Tablet, IoT cihazları) 10 ila 30 Milyar arasında olduğu tahmin ediliyor.
“Yapay zeka sistem mühendislerinin yerini mi alacak?” yazımızda sistem mühendislerinin, gittikçe karmaşıklaşan sistemleri yönetebileceklerine olan güvenin azaldığından ve sistem yönetiminde insan faktörünü mümkün olduğunca ortadan kaldıracak tam otomasyon arayışlarına gidildiğinden bahsetmiştik.
Öyle ki Google 2008 yılında, 2015’de 100 milyon sunucu sayısına ulaşacağını ve bunun için 100 bin sistem yöneticisi istihdam etmesi gerektiğini hesapladı. Çözüm olarak, bu kadar insanı istihdam etmek yerine Borg altyapısını geliştirdi ve günümüzde Kubernetes olarak anılan bu altyapı ile tam otomasyona geçti.
Bu sayede, Google şu anda 252 milyon sunucuyu, 19000 civarı sistem mühendisi ile yönetebiliyor. Bu hesaptan hareketle, yakın gelecekte yüz milyonlarca sistem yöneticisine ihtiyacımız olacak gibi görünüyor. Google’ın kendine özel olarak geliştirdiği tam otomasyon alt yapısını sistem yönetilen her ortamda kullanabilmek mümkün olmadığı için, alternatif çözüm arayışları sürüyor.
Hayal edilen tam otomasyonu sağlamak için üretilen son teknolojiye AIOPS adı veriliyor. Ancak, ismi kulağa oldukça pratik gelse de, yapay zeka(AI) ile operasyonun (OPS), bu iki kelimeyi yanyana yazıvermek gibi basitçe birleştirilemeyeceğini düşünüyorum.
Zira, günümüzdeki IT operasyonları (Sistem Yönetimi), oldukça hantal bir şekilde ITILv1,2,3,4 Operasyon Standartları ile ITSM toolları arasına sıkışmış olarak yapılmaya çalışılıyor. Ancak sistemler o kadar hızlı yaratılıyor ve yok oluyor ki ITIL süreçleri bu konulara çözüm üretemiyor.
Oysa, yeni paradigma Dev OPS ve SRE, sunduğu hız, güvenilirlik ve süreklilik avantajlarıyla sistem yönetimi işinin yeni standardı olmuş durumda. AIOPS çözümlerine mutlaka DevOps ve SRE prensiplerinin de eklenmesi gerekiyor.
SRE prensipleri
tuzakları eleyecek otomatize yazılımlar geliştirilmelidir
Sürekli karşılaşılan tuzakları çözecek otomatize yazılımlar geliştirmeli ve müşteri ile hizmet içeriği paylaşılırken, otomasyon da hizmet içeriğine dahil edilmelidir.
yazılım mühendisliği prensipleri kullanılmalıdır
Bu, herşeyi etkileyecek çok köklü bir prensip. Çünkü, IT ile ilgili herşey, aslında altta çalışan bir yazılımı barındırıyor. Dolaysıyla, SRE (Site Reliabity Engineer) ‘ler sorunlarına çözüm üretirken, yazılım mühendisliği prensiplerini kullanmalılar.
Hedef Servis Seviyesi belirlenmelidir
Geliştirdiğiniz her servise, bir “Hedef Servis Seviyesi” belirleyin. Bu öngörüye göre, kurumunuz içersinde yaratacağınız hizmetlerin ayakta kalma sürelerini ve bunun başarılı olup olmadığını kolaylıkla ölçebilirsiniz.
Hiçbir SRE %100 ayakta kalma süresini söz vermemelidir. Yapılması gereken, her üretilen servis için bir SLO (Service Level Objectives) belirlemek ve bunun ölçülebileceği bir raporu, dashboard üzerinden izlemektir.
Gereksiz iş yükleri elimine edilmelidir
Ani ve tepeden inme iş yükleri elimine edilmelidirler. Çünkü, operasyonel sebeplerle yapacağınız manüel bir sistem müdahalesi, çok daha fazla sistemi etkileyebilecek büyük tuzakları çözmek için yapacağınız projelere ayıracağınız zamandan çalar.
DevOps prensipleri
Silolara ayrılmak yerine yerine Versatilist çalışanlar
Artık sistem yöneticisi olan birisinin, aynı zamanda hem yazılım geliştirebilmesi, hem de Storage Network konusunda değişiklik yapabilmesi gerekiyor. ITIL ile tanımlanmış “Silolara ayırma” çok ciddi anlamda zarar görmüş durumda.
Versatilist, birden çok disiplinde uzmanlık sahibi olan kişi demek ve “Çevik(Agile)” hareket edebilmek, ancak ekipler içersinde farklı disiplinlerin olması ile mümkün olabiliyor.
Her an problem çıkabilir
Diyelim ki bir sanal sunucu kuruyorsunuz ve diskleri konfigüre ediyorsunuz. Eğer LVM kullanırsanız, disklerinizi online resize edebilirsiniz. Ya da performans sorunu yaşadığınızda, işletim sistemi üzerinde disklerinizi taşıyabilirsiniz. Böylece, baştan performans sorunu ve kapasite arttırımı gibi durumları öngörmüş olursunuz. Ayrıca sunucunuzda işlem yapmak için sistemleri kapatmak zorunda olmazssınız.
Ani değişiklik yapılmamalıdır
Değişiklikler, adım adım gerçekleştirilmeli ve sürekliliği sağlanmalıdır.
Aylık büyük toplantılar yerine, süreç içinde küçük toplantılar yapmak ve kullanıcılardan geri bildirim almak, tam ihtiyacınıza göre istediğiniz sonucu almanızı sağlar.
Kurum kültürü kullanılan araçlara göre değişemez
Kullandığınız araçlar ve kurum kültürünüz birbiriye ilişkilidir. Ancak, kurum kültürünüz, araçlar değişse bile değişmemelidir. Çalışılan araçtan bağımsız olarak değişim yönetimi prensiplerinizi belirlerseniz, bunlar zaman içersinde çok az değişime uğrarlar.
Şunu unutmayalım, prensiplerimizi araçlarımıza göre değiştirirsek, araçları değiştirdiğimizde prensiplerimiz kalmaz, yeni araçlar prensiplerimiz olurlar.
Başarı ve başarısızlık ölçülmelidir
Hedeflenen servis seviyesinin(SLO), çalışanlar, departmanlar ve tüm şirket olarak ölçülmesi ve kullanıcılara mutlaka sunulması gerekir.
Resim: Emile Guillemot/www.unsplash.com