Sistemlerde işlenen veri miktarı arttıkça, yapay zeka tabanlı uygulamalarla destek çözümler aranıyor.
Çeyrek yüzyıldır sistem yönetimi işi, “yazılımları doğru şekilde yönetip, kesintisiz ve verimli olarak çalışmasını sağlamak” olarak tanımlanıyor. Ancak bu kısa tanım, sistem yöneticilerinin gerçekte yaptığı işi açıklamakta oldukça yetersiz. Çünkü pratikte, bir yazılımı doğru şekilde yönetebilmek, oldukça sofistike bir iş. Bunun için, bir sistem mühendisinin, sayısız parametrenin akışkan yapısını çok iyi bilmesi, çoğu zaman spontan gelişen değişiklikleri önceden kestirebilmesi ve oluşabilecek sorunlara karşı en uygun ve pratik çözümü üretebilme becerisine sahip olması gerekiyor.
Birkaç yıl öncesine kadar, tutkulu sistem yöneticileri bu son derece komplike ve stresli işi, insan üstü bir çabayla yürütebiliyordu. Son yıllarda ise, yazılımların sayısındaki artış, sistemlerde işlenen veri büyüklüğünün de artmasına neden oldu ve her geçen gün daha da karmaşıklaşan bu işin, salt insan zekasıyla yürütülebileceğine olan güveni azalttı. Böylece, mümkün olabildiğince insan faktörünü ortadan kaldırmak için, sistem yöneticilerinin yerini alabilecek(?) yapay zeka (AI) tabanlı uygulamalar ile destek çözümler aranmaya başlandı.
Her ne kadar “Yapay Zeka” kavramı kulağa heyecan verici, fütüristik ve biraz da tekinsiz gelse de, “Bir sistem yöneticisini bir robot ile değiştirmek mümkün müdür ?” diye sormadan önce günümüzde en çok kullanılan yapay zeka (AI) tabanlı uygulama olan ‘Otonom Sürüşte’ işlenmesi gereken verinin büyüklüğüne ve kısaca yapılan işe değinelim.
Bir otomobilin sürücüsüz kullanılabilmesi için işlenmesi gereken veri miktarı sizce ne kadardır ?
Bir otomobilin, tam otomasyon ile (manüel herhangi bir arayüz olmadan tamamen araç sürüyor) hareket edebilmesi için, sürüş esnasında toplanan analog verinin işlenmesi gerekiyor.
Verinin işlenmesi derken, veriyi bilgiye dönüştürmek kastediliyor. Bunun için, öncelikle analog elde edilmiş veriler, dijital veriye dönüştürülüyor, sonra kameralar, radarlar ve Lidar gibi daha sofistike cihazlar ile ortaya çıkmış olan büyük veri (Big Data) yapısal ve ilişkisel olarak organize ediliyor. Son olarak da dijital halde organize edilmiş veriler, merkezi işlem biriminde ilişkisel olarak bilgiye dönüştürülüyor. Bu üç basamaklı işlem için kullanılan tüm teknolojiler ise merkezi işleme ünitelerinde Reliability Engineering prensipleri ile çalışıyor. Ayrıca, yedekli ve çok katmanlı alt sistemler ile de destekleniyor.
Bu demektir ki, üç saatlik otonom sürüş için işlemeniz gereken veri miktarı 50 TB civarında. Aynı miktar verinin dakikalar içinde oluştuğu uçaklarda ise, durum daha da karmaşık ve işlenecek veri miktarı daha da fazla. Sonuç olarak, tam otomasyon ile sürüş çok ciddi paralel işlem yapabilen işlemciler ve ciddi büyüklükte disk kapasiteleri gerektiriyor.
Sistem Mühendisleri yerine Yapay Zeka
Öyleyse, bir sistem yöneticisinin işini yapabilmek için günlük olarak ne kadar verinin işlenmesi gerekiyor? Öncelikle, sistem yöneticisinin uğraştığı tüm verinin dijital olduğunu hatırlayalım. Yani, verinin anlanması ve çevrilmesi gibi bir işlem söz konusu değil. Bu durumda, sunucular için oluşabilecek en büyük veri büyüklüğünün 1-5 GB arasında, çok büyük(Hibrit, Cluster..) platformlarda ise işlenecek veri büyüklüğünün 100GB civarında olduğu söylenebilir. Yani, otonom araçlara kıyasla çok daha küçük bir veri büyüklüğünden bahsediyoruz. Öyleyse, bu durum işleri kolaylaştırıyor mu? Günümüzde kullanılan en popüler sistem yönetim metodları, sistemlerimizi tam otomasyonda sorunsuz bir şekilde çalıştırabiliyor mu? Bu metodlara göz atalım
Otomasyon
2000 lerin başından itibaren, herşeyin otomasyon üzerinden yapılacağına ve sistem yöneticilerine eskisi kadar ihtiyaç duyulmayacağına inanılıyordu. Eğer kendi sistemlerinizi yönetiyorsanız bu doğrudur. Google, AWS veya Facebook gibi tüm sunucularınızda aynı işletim sistemi ve benzer donanımlar kullanılıyorsanız, yapmanız çok da zor değil. Ancak, standart dışına ne kadar çok çıkarsanız, o kadar çok benzersiz ortam yaratırsınız. Bu benzersiz ortamlar, benzersiz sorunlar doğurur ve bunları çözmek için hep yandan kapılar açmanız gerekir.
Yönettiğiniz sistemlerde otomasyon kullanıyorsanız, herbir sunucuyu teker teker yönetebilme kuralının dışına çıkmış olursunuz. Çünkü, çok basit bir parametre değişikliği bile, sistemi otomasyon tarafından yönetilemeyecek kadar komplike hale getirebilir. Pratikte, sistem mühendisi parametre değişikliğini, sunucuda manuel olarak planlı değişiklik zamanında yapar. Kontrollü bir şekilde veritabanı servisini kapatıp açar, sonrasında ise değiştirilmiş parametreyi sanki otomasyon bu değişikliği yapmış gibi otomasyona tanıtır. Sonuç olarak karmaşıklığı çok daha fazla artmıştır ve artık sürekli güncellemek gereken bir otomasyon veritabanı vardır.
Geliştirdiğiniz belli PHP Otomasyon Manifest rutinlerinin, yeni işletim sisteminde düzgün çalışmadığını düşünün. Rutinlerin yeniden yazılması gerekir. (Problemin hızlı ve geçici çözümü, yeni işletim sisteminizi downgrade etmeniz ve eski paketleri kullanmanız olabilir. Fakat müşteriniz bu durumu kabul etmeyebilir.) Ancak Otomasyon ve sürüm yönetimi ile her müşteri için farklı sürümlere sahip otomasyon rutinleri geliştiremezsiniz. Bu durumda her müşterinize özel platform yaratmış olursunuz. Otomasyonun temel amacı, standardize etmek iken, siz, olabildiğine farklı sürümlere sahip benzersiz yapılar yaratırsınız.
Müşterilerinizin kullandığı teknolojiler, yeni özellikleri kullanmanızı gerektiriyorsa güncelleme yapmanız gerekir. Eğer çalışan bir otomasyon sisteminde sadece kendiniz için geliştirdiğiniz rutinler ve özelleştirmeleriniz varsa, güncelleme halinde bunlardan kaynaklanan problemlerle karşılaşılabilmeniz olasıdır.
Herşey Bulutta stratejisi
Günümüzde en yaygın kullanılan ilk üç bulut platformu AWS, Azure ve GCP. Bu platformlara geçiş hızla devam ediyor ve bu şekilde devam edecek gibi de görünüyor. Bunun zaman içinde başarılı sonuçlar üretip üretmeyeceğini zaman gösterecek.
Microservisler (Kubernetis veya Openshift)
Son günlerde sistem altyapısının bulut platformundan bağımsız (Agnostic) olarak çalışması için mutlaka mikrosunucular üzerinde çalıştırılması gerekiyormuş gibi bir algı var. Ancak bu, kullandığınız tüm servisleri mikroservis haline getirmeniz mümkün olmadığından ve monolit çalışan (tek servis-tek sunucu) servislerin sistem yönetimi için çok daha avantajlı olduğundan, doğru değil. Eğer sisteminizde, yüzlerce servis, entegre bir şekilde çalışmak zorunda değilse, kesinlikle mikroservisler size göre bir çözüm değildir. Yeni servisler ve sunucular için, 12-Faktör geliştirme prensibine göre uygulama geliştirmeniz durumunda mikroservisleri kullanabilirsiniz.
Sonuç
Görüldüğü gibi tüm çözümler kendi içlerinde birçok handikap barındırıyor. Bunları aşabilmek için, sistem yöneticilerinin Google’dan bulduğu yöntemler sistemleri daha da kırılgan hale getirmeye devam ediyor. Çünkü esasen, yönetilecek her sistem, özelleştirilmiş bir sistem yönetimini gerektiriyor. Bunu, sistem mühendislerini devre dışı bırakarak, günümüzün otomasyon çözümlerinden herhangi biriyle (Otomasyon, Bulut, Microservice) yapabilmek ise yakın gelecekte pek mümkün görünmüyor.
Resim: Jacqueline McCray/www.unsplash.com