Öncelikle, Akbank’ta çalışan arkadaşlarımıza geçmiş olsun diyorum. İlk duyduğum andan itibaren çok üzüldüm, bu tip durumlarda son kullanıcılar bilmez fakat emek veren insanlar çok üzülürler ve ellerinden gelenin fazlasını yapmak isterler.

Akbank’ ta hesabınız var ve şu anda ulaşamıyorsunuz. Bütün paranızı emanet ettiğiniz kurum ise sessiz, ne olduğu ile ilgili size herhangi bir bilgi vermiyor. Herkes için kabus gibi bir durum.

Kurumsal şirketlerin bu tip durumlarda takındıkları tavır, aslında ne kadar kurumsal olduklarınının göstergesidir. Ne yazık ki Türkiye’de kurumlar, yaşadıkları bu tip sorunları çok kötü yönetiyorlar, banka neredeyse bir gün sonra resmi açıklama yaptı. Tıpkı Yemek Sepeti Hacklemesinden çok sonra gelen, “ Naapalım, herkese oluyor, bize de oldu” açıklaması veya SolarWind şirketinin tüm kullanıcılarına trojan dağıdıp, bunu çok sonra kabul etmesi gibi.

Tüm bu şirketler gibi, AKBANK da ne yazık ki sınıfta kaldı.

Bu tip durumlar operasyonda çalışanlar için “Major Incident” olarak tarif edilir. Root cause bulunup problem çözülmeye çalışılır veya work around bir çözüm ile sistem tekrar çalışır hale getirilir. Work around yapılan çözüm ise sonradan ortadan kaldırılır.

Akbank’ta yaşanan problem özeti (IT sektöründe konuşulanlar)

(Banka kendisi ayrıntılı bir açıklama yapmadığı için, sektör içindeki ve bankanın eski çalışanlarından aldığımız bilgilerle bu yazıyı derledik)

Salı sabahı saat 02:00 civarı bir deployment(yazılım güncellemesi) yapılmış, sonrasında sistemlerin eskisi gibi çalışmadığı görülmüş. 3 ve 4 Temmuz günleri yine 2 saatlik çalışmalar yaptıkları görünüyor.

Bu tip durumlarda sistemlerin hiç çalışmaması en iyi durumdur; çünkü çok hızlı alternatif üretebilirsiniz.

Fakat sistemlerin çok yavaş çalışması veya bir çalışıp bir çalışmaması durumu, olabilecek en kötü durumdur. Çünkü artık aldığınız backuplardan geri dönmek veya alternatif şekilde veri tabanının çalıştırılması yöntemlerini kullanamazsınız; artık veriler değişmiştir. Aldığımız bilgiye göre, Akbank’ta sistemler şuanda çok yavaş çalışıyor. 

Bu tür yarı çalışır durumlarda disaster senaryosu çalıştırmak da ciddi riskler içerir ve Felaket Veri Merkezine (DR site) geçiş artık alternatifler arasında değildir.

Akbank, IBM Mainframe ve DB2 veri tabanı kullanıyor. Bu tip ciddi değişikliklerde Proaktif çağrı ile sistemde güncelleme yapacağınızı bildirirsiniz. Fakat sorunun veri tabanından kaynaklandığını öğrenmeleri zaman almıştır, sonrasında IBM tarafına durumu bildirip major bir durum olduğu bildirilmiştir. Çağrıyı eskale etmeleri biraz zaman almıştır, çünkü önce sorunun yapılan deployment kaynaklı olduğunu düşünüp, kendileri çözmek istemişlerdir.

Akbank gibi büyük bankalar, şirketlerinin tüm altyapısında IBM, SUN(eskiden, şimdi Oracle oldu), Oracle gibi şirketlerden hizmet alırlar. En güçlüleri IBM’dir ve bu sektörü kuran şirkettir.

Bankalar çalışanlarına veya ekiplerine bağımlı olmak yerine arkalarına IBM gibi şirketleri almak isterler. Çünkü bugünkü gibi bir sorun çıktığında IBM müdahale edip çözüm üretmek üzerine bankalara SLA ve TTR taahhüdü verir. Sorunun kaynağı IBM ise, sistemleri geri getirmedikleri her saat için kaybedilen cironun %5’ i gibi bir miktarı gelecek seneki IBM faturasından sileceklerdir.

Sistemlerin 2 gündür çalışmadığını düşünürsek, sorunun Akbank uygulamasında(yazılım) kaynaklı olduğunu öngörebiliriz, sistemde bir bug olsaydı IBM çoktan bir patch çıkarmış olurdu.

“Ana Bilgisayar”‘ da ne demek, eskiden değilmiydi o?

Bilgisayar bilimlerinde, kapasitenizi arttırmak için iki yöntem vardır. Tek bir ortam içinde kapasite arttırımı yapıyorsanız buna Monolith scaling denir. Tek bir bilgisayarınız olduğunu düşünün ve bir sürü RAM/ CPU kapasitesi olduğunu düşünün, ihtiyaç oldukça bu kapasite kullanıma alınır. 

Geçtiğimiz 10 yılda oldukça popüler olan Kubernetes veya Mikroservis çözümler ise scale (kapasite arttırımı) konusunda sistem’e dışarıdan eklenen node’lar ile RAM/CPU/Disk kapasitesini arttırılırlar. Akbank burada monolitik bir altyapı çalıştırmakta, yani tek bir sistemleri var.

Peki bu tür durumlardan nasıl kaçınılabilir?

Yukarıda saat 02:00 da sistemlerin güncellendiğini söylemiştik, bu güncellemeyi yapan yazılımcı arkadaşlar, yazılımlarını benzer ortamlarda QA veya Test/Staging sistemleri üzerinde test ederler. IBM Mainframe çok maliyetli bir donanım, kullandığınız kapasiteye göre lisanslanıyor, tahminim test yaptıkları ortamın veri tabanının ve donanım kapasitesinin çok sınırlı olduğu yönünde. Bu yüzden stres testini düzgün yapamadıklarını düşünüyorum.

Oysa IBM Mainframe yerine, mikroservisler kullansalardı. X86 sunucular üzerinde benzer testleri yapmak ve istedikleri yük senaryolarını çalıştırmak çok düşük maliyetli olacaktı. Tabii burada veri tabanı sorunu yaşandığı için DB2 üzerinden cluster bir veri tabanına geçmeleri gerekirdi. Daha fazla yük ile canlı(production) sistemlerine yakın test yapacakları için bu durumla karşılaşma ihtimalleri çok düşük olacaktı.

Uygulama Kısmı ile nasıl bir sorun olmuş olabilir?

Yaşadıkları sorun veri tabanı ile ilgili olduğu ve yazılım güncellemesi ile geldiği için söyle bir senaryo gerçekleşmiş olabilir; veri tabanında tabloların üzerindeki alanları arttırmış veya azaltmış ve bu alanlarla ilgili yeni indexler yaratmış olabilirler. Bu kadar uzun süre kapalı kalmalarını ancak çok fazla değişikliği bir anda yapmalarıyla açıklayabiliriz. Akbank web sayfasından anladığımız kadarıyla 3 ve 4 temmuz günleri 2 saatlik gece çalışmaları ile sistemlerini güncelledikleri bilgisi var. Çok ciddi bir güncelleme yaptıkları anlaşılıyor ve yaptıkları değişiklikler onları şuan bulundukları sorunlu duruma getirmiş.

Oracle, DB2, MSSQL gibi veri tabanları “commit and pray” şeklinde çalışırlar. Açık kaynak olmadıkları ve sistemlerin çalışması ile ilgili detaylı bilginiz olmadığı için, komut yazdıktan sonra sadece sorunsuz çalışması için dua edebilirsiniz. DB2 veri tabanı ile ilgili IBM dışında bilgi alabileceğiniz herhangi bir kaynak yoktur.
Peki Backup restore gibi bir yöntem ile çözüm olamaz mıydı?

DB2 veri tabanı büyüklüğünün 150-200 TB civarı olduğunu tahmin ediyorum. Söz konusu sorunlu veri tabanı ise 20-50 TB’lık bir kısmıdır diye düşünebiliriz. Böyle bir veri büyüklüğünü restore etmek, ciddi zaman alacaktır. İlk başta belirttiğim gibi semi-working (yarı çalışma) çok kötü bir durum, Yukarıda bahsettiğimiz veri tabanı güncellemelerini zaman içinde yaptılarsa ve son halini replike edemiyorlarsa (performans yüzünden) bu daha da ciddi restore sorunlarına yol açabilir.

Verilerin restore edilmesi senaryosu en son düşünülecek senaryodur, burada DR merkezinin aktive edilip edilmemesi ciddi tartışılmıştır diye düşünüyorum. DR geçişinin olmaması, problemin uygulama kaynaklı olduğunu gösteriyor.

Dış Kanyak Kullanımı Sorunu

BT sektöründeki bir diğer büyük sorun ise outsource kaynak kullanımıdır. Outsource kaynaklar, sorumluluk almak istemedikleri ve kısa vadeli düşündükleri için riski az olan çözümler üretirler ve uzun vadede şirketin faydasına olabilecek çözümler üretemezler. Outsource olarak çalışan birisi, risk alıp değişiklik yaparsa Çünkü çözüm üretirken aldıkları risk sonradan başlarına dert açabilir. Bankalarda çalışan yüzlerce kişinin içinde çok ciddi sayıda outsource çalışan vardır, kurum içindeki bilgi birikiminin yok olması bu tür uzun süreli kesintilere yol açar.

Kurumlar outsource hizmet alma konusuna, maliyet avantajından dolayı çok sıcak bakarlar. BT içersinden gelmiş bir BT yöneticisi outsource çalışan birisi ile bordrolu çalışan arasındaki farkı çok iyi bilir. Outsource kaynak kullanabilirsiniz, fakat bunu bir kota çerçevesinde uygulamanız gerekir. 200 çalışanın 100 tanesi outsource ise ciddi bir sorununuz var demektir.

Youtube Tekno Politik kanalında Sn. Füsun Nebil ile Akbank’ ta  yaşanan 43 saatlik kesintiyi konuştuk. 

youtube yayını