En basit anlatımıyla sorun: Mainframe (Ana Bilgisayar) ve DB2 veri tabanından kaynaklı.
İlk olarak hem ana bilgisayarların çalışma mantığını son olarak da bu ana bilgisayara göre Akbank erişim problemini açıklamaya çalışalım. Ki sorunu, neler olduğunu ve de gelecekte başka kurumlarda da neler olabileceğini masaya yatıralım.
Mainframe sistemleri, en özet haliyle söylersek, yüksek performans ve kapasiteye sahip bilgisayar sistemleri olarak bilinir.
Büyük kurumların veri merkezlerinde, merkezi yapıda konumlandırılıp çok yüksek sayıda işlemin tutarlı ve hızlı bir şekilde tamamlanabilmesi için kullanılırlar.
İlk Mainframe 1964 yılında üretilmiş. Yıllar içerisinde farklı marka ve modelleri piyasaya çıkmış olsa da günümüzde en çok kullanılan modelleri IBM Z sunucuları ya da kısaca Z olarak isimlendiriliyor.
IBM mainframe makinalarındaki "Z" harfinin anlamı Zero Downtime. Yani asla çökmez…
IBM bu ürünü yaklaşık olarak iki senelik döngülerle bir büyük, bir küçük Z modelini üretip piyasaya sürerek pazarda en büyük oyuncu olmayı sürdürüyor.
Ancak burada dikkat edilmesi gereken bir nokta var. Yeni modellere geçmek, yazılım güncellemelerini hayata geçirmek kullanıcı kurumun sorumluluğunda.
Yine normal şartlarda Mainframe'ler donanım olarak açıldıktan sonra emekli edilene kadar hiç kapatılmamak üzerine tasarlanıyor. Yazılım güncellemeleri ve arıza durumunda, parça değişiklikleri sırasında makine tüm işlemleri kesintisiz yapabiliyor. Sadece çok istisnai durumlarda donanım kapatıldığında ya da ilk kurulum sırasında Mainframe'in açılması söz konusu oluyor. Yani bunların dışında sistem hiç kapanmıyor.
Mainframe makinaların yeniden çalışma süreleri yaklaşık 15-30 dakika arasında. Bu kadar uzun sürmesinin sebebi ise makinenin "Kapandıysam, kesin olağanüstü bir durum vardır, uçtan uca tüm parçalarımı kontrollere tabi tutmalıyım" pimpirikliliğinden geliyor.
Bunun haricinde işletim sistemi seviyesinde problem, bakım çalışması veya yazılım güncellemeleri sırasında kapatılan Mainframe'in kendisi değil, üzerinde bulunan sanal sunucular. Donanım asla kapatılmaz. Bu işlemlerin açılış süresi de manuel yapılan kontrolleri saymazsak dakikalar mertebesindedir. Bu sürede genelde yedek makine veya sanal sunucu hizmet vermeye kesintisiz devam eder. Tabi ki ciddi bir problem olması, veri kurtarma gerektiren bir durumun yaşanması, ciddi değişiklikler sonrası kayıtların detaylı incelenmesi gerektiği durumlar süreyi uzatabilir.
Bugün birçok Mainframe kullanan kurum disk olarak IBM veya başka firmaların tamamen flash olan disklerini kullanıyor. Yani klasik disk kullanımı yok denecek kadar az. Daha da önemlisi bu disklerde terebaytlar seviyesinde önbellek bulunuyor.
Mainframe ortamlarında tüm parçalar çok sayıda yedekli bulunduğu, hemen her konuda kurtarma (recovery) mekanizmaları olduğu, veriler için çeşit çeşit yedek (backup) alındığı hallerde diğer birçok IT sisteminden daha az sayıda olsa da yine de problemler olabiliyor. Kimi zaman insan hatasından, kimi zaman öngörülemeyen istisnai durumlardan vs. Bu problemlerin birçoğu bu kurtarma mekanizmaları sayesinde müşterilere hiçbir yansıması olmadan çözülebilse de bazen bir problem eş zamanlı tüm yedekli sistemleri etkileyebilmekte, yedekler de kullanılamaz hale gelebilmektedir.
Akbank erişim problemine gelirsek;
Tüm bankaların veya önemli kurumların "Disaster Recovery" adını verdikleri "olağanüstü durumlarda veri kurtarma" merkezleri var.
Akbank yönetimi bu veri merkezini İzmir'de kurmuştu. Ancak Şubat 2021'de yaşanan sel afetinden sonra bu veri merkezinin faaliyetlerini Gebze'ye taşımaya karar verdiler. İşte tam da bu geçişler esnasında sistemlere erişim sağlanamadı.
Akbank uzmanları hem yazılımsal hem de donanımsal olarak ana makineyi ayağa kaldırmaya çalışırken (insan hatası veya diğer sebeplerden dolayı) disklere de erişemedi.
IT sistemlerinde yaşanan her bir problemin kendi içerisinde belirli bir seviyesi vardır. Sorunların büyüklüğüne veya önemine göre bu problemleri kurum kendi içerisinde çözebilir. Ya da anlaşmalı olduğu diğer kurumlardan destek alabilir. Bunun yanı sıra her bankanın veya önemli büyük kurumun mainframe üreticisi ile arasında SLA adı verilen "Servis Seviye Anlaşmaları" vardır.
Akbank da mainframe üreticisi IBM olduğu için IBM Türkiye'den destek istedi. O dönemde sorunu çözmek adına IBM Almanya'dan sorumlu bir ekip Türkiye'ye getirildi. Ve ancak bir gün sonra disklere erişim sağlanabildi.
Bu noktada şu soru devreye giriyor; bu kadar çok yedek, veri merkezleri vs olmasına karşın sistem neden kapandı ve erişim sağlanamadı?
Basit bir betimleme yaparsak: Şimdi bir tepsi üzerinde içi su dolu sürahi ve içinde su olan bir bardak olduğunu düşünün. Tepsiyi bankanın uygulamalarını çalıştıran platform olarak hayal edin. İçi su dolu sürahi ise bankanın veri tabanı su dolu bardak da bankanın uygulamaları olsun.
Şimdi bu hikâyedeki sürahiyi kaybedersek tepside halen içi su dolu bardak olduğu için bardağı yani uygulamayı kullanabiliriz. Tabi içindeki su bitene kadar! Suyumuz bittiğinde sürahiyi kaybettiğimiz için bardağa su doldurup içemeyiz. Konuya bağlarsak güncel verilere ulaşma imkanı durur.
İlk başta Akbank'ın mobil bankacılık veya internet bankacılığını kullanan müşterileri sisteme giriş yapabildi. Ancak para gönder-al, fatura öde, hisse satın al vb işlemleri durdu. Ya da müşteri verilerini görebildi ama işlem yapamadı. Çünkü bardaktaki su o kadardı. Su bitince sürahiden dolum yapılmadığı için yeni verilere erişemediler.
Buna üç bacaklı uygulama mimarisi adı veriliyor.
Birçok banka ve kurumda bu betimlemeden çok sayıda yaşanıyor aslında. Onların fazla gündeme gelmemesinin mantığı da şu şekilde açıklanabilir; onların tepside birkaç sürahisi var diye düşünün. Yani tepsideki su bardağını birden fazla sürahi dolduruyor. Sürahiler bitene kadar sistem devreye giriyor.
Bu sebepten dolayı Akbank'ta da diğer sürahiler doluydu. Yaşanan problem o tek sürahiden kaynaklandı.
Peki bu noktada şunu sorabiliriz: Ya tepsi komple düşerse ne olur?
Tepsiyi düşürürsek tüm uygulamalar, veritabanı vs kısaca her şey kırılır. İşte bu nedenden dolayı bunlardan çok fazla yedekler mevcut.
Şimdi diyeceksiniz ki 'bu Akbank nasıl olur da bu sürahiyi kaybeder? Pek akla mantığa sığmıyor' …
Teknik olarak şöyle açıklanabilir: Akbank bu mainframe'e bir güncelleme yapıyor. Örneklemede olduğu üzere sürahiyi tutmak için kulp yaptıklarını düşünün. Tabi bu sürahiden çok fazla adette var. Hepsine tek tek kulp yapmak yerine diyorlar ki biz bu kulpu ana makineye yapalım diğer sürahilere de otomatik olarak kopyalansın. Teknolojide bu işleme modül yazma adı veriliyor.
Hem teknoloji geliştikçe hem de bankalar kendilerini geliştirip yeni teknolojilerini müşterilerine sunmak istediklerinde bu sürahiye yani veri tabanına sürekli eklemeler yapıyorlar. Yani damacanadan sürahiye su dolduruyorlar. Bu süreç sürahi dolduğunda bir sürahi daha, o dolduğunda bir sürahi daha şeklinde devam ediyor.
Ve bu veri tabanı zamanla çok karışık bir sistem halini alıyor. Buna da spagetti kasesi adı veriliyor.
Ana makinada yapılan ve otomatik kopyalanan bu modülden kaynaklı veritabanına erişim problemleri yaşanıyor.
İşte IBM her iki senede bir sistemin bir büyük, bir küçük modelini piyasaya sürerek söz konusu spagetti kaselerinin dağılmasını önlemeye çalışıyor.
1990'lı yılların başında Akbank o dönemin en yeni teknolojisi olan Mainframe sisteme geçiş yaptı, 2000'li yıllarda sistemini güncelledi, 2010 yılında IBM Z800 adı verilen sisteme güncelleme yaptı. Ancak 2010 yılından sonra Akbank bu Mainframe'i güncellemedi. (Temmuz ayında bu hadise yaşandığında Akbank 2010 model IBM Z800 mainframe kullanıyordu )
Bu model Mainframe'in en önemli özelliği: Veritabanı ve uygulamalar yani sürahiler ve bardakların hepsi tek bir ana makinanın içinde (monolit bir yapıda) çalışıyor olması. Bu da uygulamadaki hızı maksimum seviyeye çıkartıyor. Tüm veri işlemeleri anında gerçekleşiyor. Şimdilerde bunun için zaten Mainframe'ler var. Tabi bu Z800 2010 yılında çok iyi bir teknolojiydi.
Şimdi haliyle IBM bu eski model Mainframe makinalarına güncelleme yapıyor. Bununla birlikte IBM Akbank'ın da yeni ürünü olan Z15 teknolojisine geçiş yapmasını da zorluyor.
Banka açısından olayı ele alacak olursak; eğer 2010 yılında bu yana eski teknoloji kullanıyor ve zamanında geç kalıp yeni sisteme geçmedikleri için 11 yıl sonra yeni modernize edilmiş Mainframe makineye geçmek ciddi bir dert oluyor.
En önemli problem ise sistem değiştirmek. Çünkü Z800 modeller COBOL ile çalıştığı için COBOL'un tamamının JAVA'ya değiştirilmesi gerekiyor. Bu işlem çok zaman alan ve bir o kadar da meşakkatli bir iş.
Bu arada bir Mainframe'in modernize edilmesini de en basitleştirilmiş haliyle 5 adımda anlatmaya çalışalım.
İlk adım cobol'dan java yazılımına geçmek.
İkinci adım 'ulaşmak istenilen hedefi hayal et ona göre yürü' süreci.
Üçüncü adımda bağlı olan tüm sistemleri betimlemede yaptığım spagetti kasesini ayrıştırmak. Ve hangi verinin nereden alındığını ayrıştırarak ayırmak gerekiyor.
Dördüncü adım teker teker, parça parça modernizasyona başlanıyor.
Beşinci adım bu dört adımı yaptıktan sonra geriye dönüştürülebilir mi bunların herbiri nereye doğru gidiyor her bir adımı tek tek yazmak lazım zaten Akbank'ın başına gelen problemlerin en büyüğü buydu. Yapması gereken 2010 yılında bunlarla hiç uğraşmadan daha fazla veri birikmeden yeni yeni teknolojiler birikmeden son teknolojiye geçmesi gerekirdi.
Şu an IBM üretmiş olduğu en yeni sistem Z15. Ancak bununla birlikte IBM 2009 yılında satın aldığı RedHat markası üzerinden BC12 adı ile çok farklı bir sistemi de bu yıl tanıttı. Ve o sistemi de devreye almaya başladı.
Sözün özü Akbank'ın kullanmış olduğu Mainframe teknolojisi 4 nesil önceki teknoloji. Ve halen onu kullanmaya devam ediyorlar. Bunu yapan diğer kurum ve kuruluşlar da zaman içinde değişim süreçlerinde benzer sıkıntıları yaşayabilir. Bu nedenle biz de yeni testiler kırılmadan önce en yalın haliyle konuyu anlatmaya çalıştık.
Sağlıklı bir hafta dileğiyle
Not: Bu konularda adeta bir guru olan ve kendi çapında beyaz hacker sayılan arkadaşımız Taygun Delioğlu'na teşekkürlerimizi borç biliriz.
