Felaketten Dönebilmek ya da Orada Kalmak. İşte Bütün Mesele Bu!


Sevgili dostum Kadir Çamoğlu, Türk MVP’leriyle bu sene bir MVP kitabı düzenliyor. Ben de iki yazıyla bu çalışmaya katkıda bulunacağım.

İlk yazıyı daha önce burada yayınlamıştım.

İkinci yazım, IT alanında yaşanan felaketler ve felaket dönüşleri üzerine çok yapısal olmayan bir tarzda, hayli serbest bir dille yazıldı. Bu yazının ilk şeklini aşağıda bulabilirsiniz. Henüz düzeltme çalışması yapmadığım için ufak tefek imla hataları, hatta anlam hataları olabilir; kusura bakmayın. Bir de tabii kitap yayın aşamasına geldiğinde, bu yazıyı kaldırmam gerekebilir. Şimdilik buyrun, keyifle okuyun:

Felaketten Dönebilmek ya da Orada Kalmak. İşte Bütün Mesele Bu!

Bu yazıyı tam da olmaması gerektiği gibi yazacağım. Bir nehir yazı olacak. Okumak için ayırabileceğiniz blok bir zamanda değilseniz, şimdilik pas geçin isterseniz. Çünkü geri döndüğünüzde devam edebilmek için kullanacağınız ara başlıklar olmayacak.

Neden mi böyle bir taktik izliyorum? Çünkü “disaster recovery” ya da felaketten dönüş üzerine deneyimleri acı, tatlı, biraz hikaye modunda, askerlik anısı anlatır gibi yazacağım. Çünkü hayalle gerçek birbirine karışacak. Gerçekleri biraz kurgulaştırarak anlatacağım. Kurguları biraz gerçekleştirerek anlatacağım. Bu yazıda geçen olaylar ve karakterler tamamen hayal ürünü olacak ama bir anda kendinizi ya da bir arkadaşınızı ya da her an başınıza gelebilecek bir şeyi bulacaksınız sayfaların arasında.

Bu yazıyı okumak için ayırabileceğiniz rahat bir zamanda değilseniz, okumaya devam etmeyin. Çünkü bu yazıyı okurken gülebilmelisiniz. Güleriz ağlanacak halimize deyip yeri geldiğinde de dövünebilmelisiniz. Tadına varmak için bu yazının, rahat bir zamanınızda okuyun.

Felaketten dönebilmek için önce felakete gitmek gerekli. Ya da felaket size gelmeli. “Bana çıkmaz demeyin”, çıkar. Sayısal lotoda tutturmak ya da piyango biletiyle ikramiyeye konmak gibi düşük bir olasılıktan bahsetmiyoruz.

IT uzmanıysanız, şöyle bir kendi geçmişinizi düşünün. Bu alanda yeniyseniz tanıdığınız daha tecrübeli kişilerden biraz soruşturun. İddia ediyorum Türkiye’de IT alanında 3-4 yıl çalışan herkes felaket yaşamıştır.

Zaten IT alanında felaket yaşamamak pek olası değil. O yüzden de uluslararası arenada bile bu işin adı “disaster prevention” yani felaket önleme değil, “disaster recovery” yani felaketten normale geri dönme. Benim anlatacağım konuların bir kısmı, yaşayabileceğiniz felaketler, bir kısmı felaket yaşamamak için yapılabilecek şeyler, bir kısmı da felaketten hızlı ve az zararla geri dönmek için yapılabilecek şeylerle ilgili olacak.

Kendi uzmanlığım gereği ağırlıklı olarak veritabanı üzerinde duracağım ama uygulama geliştirme ve diğer bazı sunucular üzerine de anlatımlar bulabilirsiniz.

Çok uzun bir giriş oldu hadi bir örnekle başlayalım, ne dersiniz?

Olmaz olmaz demeyin, olmaz olmaz dedirten bir örnek düşünelim mesela. Diyelim ki yazılım geliştirmeyle ilgili bir sorumluluğunuz var. Çok büyük bir proje değil, tek başına yapabileceğiniz ölçekte. İyi bir okuldan mezun olmuşsunuz, zeki hissediyorsunuz. Bu işleri ‘kıvırabileceğinizi’ düşünüyorsunuz. Üstelik gidip eğitimini de ayrıca almışsınız.

Başlıyorsunuz yazmaya… Yazıyorsunuz, yazıyorsunuz, yazıyorsunuz. Eğitimi bitirdikten sonra 2-3 ay kadar uğraşıyorsunuz. Ama hiç derlemiyorsunuz bu arada. Ne de olsa zekisiniz ve üstelik de eğitimini de aldınız. Sonra proje teslimine bir hafta falan kala her şeyi derliyorsunuz.

Yazılımla biraz uğraşanlar bilir, 2 ay birikmiş bir kodu derlemek olası değildir. Kodun sık sık derlenmesi, testlerinin yapılması vs vs gerekir. Bunu proje üzerinde öğrenmek ne kötü olurdu değil mi?

Böyle bir durumu gözlerimle görmüş olmasam, sanırım hayal edemezdim. Olmaz olmaz demeyin!

Yine yeni bir üniversite mezunu olarak ve kabiliyetli de bir gencin bir uygulama geliştirmeye başlayıp “ya bunun verilerini de bir yerde saklamak gerekli” diye veritabanı tasarlamaya başlamasına ne demeli? Hayli zeki bir arkadaş, ne yazık ki eğitim ortamının garipliğiyle hiç veritabanı diye bir kavram duymadan ama programcılık hakkında eğitim almış olarak mezun olunca bu tür durumlar oluşabiliyor. Ama belki de ben atıyorumdur, bu bir şehir efsanesidir.

Kıssadan hisse: Teorik bildiğiniz ya da bir yanını bildiğiniz bir işe girişirken, bu işi daha önce yapmış olanlara fikir danışın. Belki beş dakikalık bir görüşme, aylarınıza mal olacak bir zarardan kurtulmanızı sağlayabilir.

Klasik tanımlamalara pek uymasa da yukarıdaki durumların da ‘birer felaket’ olduğunu düşündüğüm için bir fasıl geçtim üzerlerinden.

Biraz da Raid 5 ya da benzeri disk veri güvenliği uygulamalarından bahsedelim mi?

Duymuşsunuzdur, kullanmışsınızdır. Raid 5 bir disk sisteminiz olduğunu varsayalım. Bir veritabanı sunucunuz ya da eposta sunucunuzda olabilir. Bakım için ya da taşıma için bir sebeple sunucuyu kapatmış olun. Hazır kapatmışken diskleri yuvalarından şöyle bir çıkarıp tipine, modeline falan bakmak istemiş olun. Elinizin altında zaten. Öyle kasanın içinde gömülü vidalı falan bir disk de değil. Basıyorsunuz mandallarına çekip çıkarıyorsunuz. Zaten çalışıyorken bile bozulma durumunda basıp mandalına çıkarıp yerine yenisini takabiliyorsunuz.

Şimdi zaten çalışmıyor sistem. Risk de yok değil mi? Bu cümlelere dikkat edin. ŞİMDİ ZATEN ÇALIŞMIYOR, RİSK DE YOK!

Disklerden birine bakıp yerine taktınız ya, ikinci bir tanesine de bakmak isteyebilirsiniz. Nasılsa sistem şu an çalışmıyor, üstelik birinciyi yerine koydunuz. Onu da çıkardınız, baktınız, yerine koydunuz.

Sonra da sistemi açtınız. O da ne, bir aksilik var. Bir atın nalındaki bir çivinin düşmesinin orduyu nasıl mağlup olmaya sürüklediği ile ilgili klasik bir hikaye vardır. Hani bir de fıkra vardır. Adamın biri bir topluluk görmüş. Birisi bir numara söylüyor herkes katıla katıla gülüyor. Diğer bir kişi bir numara söylüyor, kimsenin güldüğü falan yok. Noluyor burada diye sorunca öğreniyor ki, bu arkadaşlar uzun süredir bir arada olduklarından artık herkesin fıkralarını herkes ezberleşim, fıkralara birer de numara vermişler. Fıkra anlatmak yerine artık numarasını söylüyorlarmış. Birisi bir numara söyleyince herkes gülüyor da diğerine niye kimse gülmüyor diye sormuş. Biri iyi anlatıyor, öbürü anlatamıyor demişler.

Ben de şimdi uzun uzun atın nalındaki çividen orduya kadar anlatmayayım hikayeyi. Bir bilene sorup dinlersiniz isterseniz. Çividen mandala gelecek olursak, mandallar bazen yerlerine iyi otururlar bazen de oturmazlar. Raid 5 bir sistemde iki diski yerinden alıp tekrar yerine koyar ama tam oturmasını sağlayamazsanız, sonra bir de sistemi açarsanız, tamamen sağlam diskler olduğu halde elinizde Raid sistemi iki diski yok görür ve kendisini “öldü” ilan eder.

Bu noktada hemen yedeklere koşabilirsiniz ama koşmadan önce kıssadan hisselerimize bakalım, sonra koşmaya devam edersiniz.

Kıssadan Hisse: Sunucu odasının ve kritik amaçlı uygulamaların ya da sistemlerin şakası olmaz. Çalışmıyorlarken bile onlara nasıl davrandığınıza dikkat etmelisiniz.

Kıssadan Hisse: Çok sıradan gibi gözüken IT yönetim işlerinde bile bir prosedürünüz olup o prosedüre göre hareket ediyor olmanız bazen hayat kurtarabilir.

Yedeklere koşmak alarm zilleri çaldıran bir davranış şekli. Lütfen koşmayın. Alarm zilleri çaldıran, yedeklere gereksinim duymanız değil, onlara koşarak gidecek durumda olmanız da değil! Alarm verici olan onlara koşarak gidiyor olmanız!

Ameliyat olmak için kendinizi o ameliyatı ilk kez yapan bir kişinin eline teslim etmek ister misiniz? Henüz acemi olan bir şoförün kullandığı şehirler arası bir otobüste olmak ister misiniz? Bir pilotun ilk uçuşunda üstelik kaptan pilot olarak uçağınızı uçurmasını ister misiniz?

Siz bunları istemezseniz, kimse de ilk kez krizden veri kurtaracak bir IT sorumlusunun elinde olmak istemez. Ama her şeyin bir ilki vardır, değil mi? Bir şekilde ilk kez krizden döndüğünüz bir zaman olacak. Neden bu ilk kriz, bir tatbikat olmasın. Gerçek bir kriz değil de varsayılan bir krizden dönmek, hatta sonra bir kere daha varsayılan bir krizden dönmek ve bir kere daha… iyi olmaz mı? Gerçek bir veri kaybı riskiyle karşılaştığınız anda bu durumda ne yapılacağına ilişkin en az birkaç kere tatbikat yapmış olsanız hoş olmaz mı?

O durumda mesela şunları düşünebilirsiniz:

Sadece veritabanı değil, işletim sistemi toptan gittiğine göre, yedekten dönmek işimi kurtarmıyor. İmajdan geri dönmem lazım. Ya da imajım yoksa kurulum kaynak kodlarıyla önce sistemi kurulu hale getirmem gerekiyor. Kurulum kaynak kodlarını CD, DVD ya da hangi formatta tutuyorsanız o formatta belirli bir yerde tutmalı ve kriz durumunda bunlara, bunların seri numarası gibi gerekli diğer bilgilerine en kısa zamanda ulaşabilmelisiniz.

Üretime ara verilen ve ayrılan sürede iş bitirilemezse bu aranın uzaması yüzünden önemli bir zarar yazılacak bir konumdayken kurulum CD’si aramak zorunda kalmak hoş olmaz değil mi? Olmaz mı diyorsunuz? Benim başıma gelmez mi diyorsunuz? Bir daha düşünün.

Şimdi şu iki sahneyi bir karşılaştırın bakalım:

Koşarak yedeklerin tutulduğu harici diskin olduğu dolaba gidiyorsunuz. Bir an önce yedekten dönmeniz gerekli. Kalkarken masadaki telefonunuz çalmaya başlamıştı bile, ama bakmaya vaktiniz olmadı. Siz dolaba yaklaşırken sustu telefon. Zaten belinizde de aynı numaraya bağlı hareketli telefon takılı. Dolap kapısını anahtarla eliniz karışa dolaşa açmaya çalışırken belinizdeki telefon çalmaya başladı. Eş zamanlı olarak şirket hatlı cep telefonunuz da çalmaya başladı. Anahtarı dördüncü kere deliğe sokamamaya başardıktan sonra telefon seslerine iyice sinir olup birini bir kulağınıza birini bir kulağınıza götürdünüz. Hala çalma seslerini duyunca açma tuşlarına basmadığınızı fark ettiniz. Her ikisine birden basıp ikisini birden açtınız. Önce biriyle konuşuyorsunuz ve enseye tokat modunda çalıştığınız arkadaşlarınızdan biri bağır çağır bilgilerini soruyor, ne zaman sisteme ayağa falan derken biraz da azarlar gibi “olum zaten uğraşıyoruz bir bıraksanız” diyorsunuz. Tam aynı tarzda diğer telefonu da cevaplayıp onu da kapatacakken hem ilk telefon tekrar çalmaya başlıyor hem de ikinci telefondakinin genel müdür yardımcısı olduğunu fark ediyorsunuz. Sıkı bir zılgıt yerken artık çalan diğer telefonun sesini fark etmiyorsunuz bile ama o sinirle elinizdeki anahtar yere düşüyor. Telefonu kapatıp yerde anahtarı aramak için eğilirken daha harici diski bile dolaptan çıkaramadığınızı fark ederek içinizden bir küfür sallayıp başınızı şöyle bir savuruyorsunuz ve bir parça dışarıda kalmış metal çekmecelerden birinin köşesi kulak tozunuzda bomba gibi patlıyor.

Acıyla kapaklandığınız yerde neyse ki anahtarla burun buruna geliyorsunuz. Hızla kalkıp dolabı açıyorsunuz, yedeklerin bulunduğu disk yerli yerinde duruyor. “Şükür, bir de iyi bir şey olsun!” diye diski alıp yine koşarak sistem odasının kapısına gidip hızla içeri dalıyorsunuz. Veritabanı yedeğini taktığınız diskten geriye dönmek için yönetim aracına bağlanmaya çalıştığınız veritabanı servisinin kapalı olduğunu fark ediyorsunuz. Yeniden başlat diyorsunuz ama sona doğru takılıp kalıyor ve sistem cevap veremez hale geliyor. “Şaka gibi” diye inleyerek sunucuyu resetliyorsunuz. Ta ta… “Non-system disk or disk error”.

“İşletim sistemini de yeniden kurmak lazım şimdi. Hay bin… *%*?-^#”

İşletim sistemi kaynak CD’lerini evde kaçak bir kurulum yapmak için iki gün önce götürmüş ve henüz getirmemiş olduğunuzu hatırladığınızda dizlerinizin bağı çözülüveriyor. Sonrasını hatırlamıyorsunuz zaten…

İkinci senaryo ise şöyle:

Veritabanının hizmet veremez duruma geldiğini anladığınızda ilk olarak 2-3 dakikalık hızlı bir önkontrolle durumun ne olduğunu anlamaya çalışıyorsunuz. Bu arada çalan telefonlara bakmıyorsunuz. Servisin başlatılamaz durumda olduğunu anlayınca ve daha yeniden başlatmayı bile denemeden bunun bir “felaket” anı olduğuna karar verdiğinizde ilk iş olarak bu iş için önceden kalıp olarak taslaklar kısmına kaydedilmiş epostalardan duruma en uygun olanı açıp zaten hazır olan listedeki kişilere gönderiyorsunuz. Epostanın içeriğinde hem durumla ilgili tahmin ve geri dönüş süresiyle ilgili öngörüler var, hem de sizin şu an konunun üzerinde olduğunuz ve gereksiz telefonların geri dönüşü çok geciktirebileceği uyarısı var. Telefon sesleri bir anda kesiliyor. Dolaba doğru yürürken yedeklerin de kaynak kodların da seri numaralarının da yerini kafanızdan şöyle bir geçiriyorsunuz. Neler yapacağınız konusunda hiç kuşkunuz yok, çünkü 9 ay önce ve sonra da 3 ay önce rutin felaketten geri dönüş tatbikatlarında bu senaryoyu da uygulamıştınız.

Hangisini tercih edeceğinizi sormama gerek yok sanırım.

Kıssadan Hisse: Felaket anları, en sakin davranılması gereken anlardır.

Kıssadan Hisse: Daha önceden geri dönmediğiniz bir felaketten geri biraz zor dönersiniz.

Kıssadan Hisse: Felaket anında teorik bilgi hiçbir işe yaramaz. Senaryoyu daha önce uygulamış olmanız hayati öneme sahiptir.

Kıssadan Hisse: Hiçbir felaket en kötüsü değildir. Yetkin bir şekilde müdahale edemezseniz durumu kendi ellerinizle daha kötü hale getirebilirsiniz.

Şu ürünler durup durdukları yerde öyle kalsalar, işler ne kadar kolay olurdu. Oysa kullandığınız yazılımların, sunucuların, yardımcı programların hiçbiri şişede ya da rafta durduğu gibi durmaz.
Onlarla değeri milyarları bulan bilgiler işlendiği / korunduğu / sunulduğu için, saldıranları da çoktur. Ufak tefek kusurlarının haricinde zaman zaman güvenlikle ilgili açık oluşturan kusurları da sahipleri, dostları ya da düşmanları tarafından bulunabilir. Kim bulursa bulsun, bu kusurla ilgili bilgi giderek yaygınlaşır ve bazen kısa sürede bazen uzun sürede sizin kullandığınız kopyaya yönelik bir saldırı da gerçekleşebilir.

Bu saldırılara karşı sisteminizi korunaklı tutabilmek için, ilgili ürünün yamalarını çıkaran ürün sahibiyle iletişim halinde olmanız gerekir. Neyse ki, önde gelen yazılım üreticileri bunu otomatik olarak yapmanıza imkan tanıyor. Otomasyona sonra döneceğim.

Özellikle güvenlik riski içeren güncelleştirmeleri zamanında yapmamanın bedeli zaman zaman ağır olarak ödenir. Çok tipik bir örnek 25 Ocak 2003’te yaşandı. SQL Server’daki bir “buffer overflow” hatasından yararlanan SQL Slammer atağı tüm interneti önemli ölçüde yavaşlattı, pek çok ağın çökmesine yol açtı. Atağın erken aşamalarında 8,5 saniyede bir etkilediği makine sayısını ikiye katladığı bulunmuş. Etkilenen makinelerin yüzde 90’ının ilk 10 dakikada kurban olması da bu hızın bir diğer sonucu. Yayılma hızının yavaşlaması da atağın oluşturduğu “Servis verememe” (Denial of Service) durumları sayesinde olmuş.

En ilginç noktaya gelecek olursak: SQL Slammer’ın kullandığı açık bu atağın gerçekleşmesinden 6 ay önce Microsoft tarafından yaması yayımlanmış olan bir açık. Üstelik yanlış hatırlamıyorsam, bu yamanın yayınlanması ile atağın gerçekleşmesi arasında bir servis paketi de (service pack) yayınlandı.

SQL Server gibi çok önemli bir ürünün bir kritik yamasını, hele hele servis paketini uygulamayan bir sistem yöneticisi başının belasını arıyor demektir. Dünya çapında bu kadar çok başının belasını arayan insan olması, bu atağın da bu kadar etkin olmasına yol açtı.
Kıssadan Hisse: Yazılım ürünleri raftan çıktığı gibi kullanılmaya devam edilmez. Bu ürünlerin ürün sahipleri tarafından çıkarılan yamalarının ve servis paketlerinin mümkün olduğunca otomatik bir şekilde takip edilip uygulanması gerekir. Siz takip etmezseniz, kötü niyetli kişiler siz takip etmiyorsunuz diye takibi bırakmaz hatta daha istekli takip ederler. Evinizdeki kapı kilidinin açılabilmesini sağlayabilecek bir hatası sonradan ortaya çıksa, gerekli tamiratı yaptırmak için vakit kaybeder misiniz?

Neyse ki bu yamaların otomatik uygulanması mümkün! Bağlayalım otomasyona, indirsin indirsin kursun! .. da diyemezsiniz!

Yamalar test edilirler ama olası her ortam için değil. Bazen yamaların önceden bilinemeyen sonuçları olabilir. Ya da önceden bilinen ama kurulum tabanının çok küçük bir bölümünü etkileyecek bir soruna rağmen yama yayınlanabilir. O önceden test edilmemiş aksiliği siz yaşarsanız ya da olumsuz sonuç verdiği çok küçük azınlık içinde yer alıyorsanız vay halinize.
Zaten tüm yazılım üreticileri yayınladıkları yamaların ortamınıza birebir benzeyen bir test ortamında tarafınızdan denetlenmesinin ardından gerçek sisteme uygulanması gerektiği konusunda uyarılarda bulunurlar.

Peki diyelim ki test etmeden yamaları uyguluyorsunuz; ne olabilir?

Mesela şu olabilir: Sadece bir donanım üreticisinin sadece bir seri çıkardığı sunucularla yayınlanan bu yamanın bir problemi vardır. Problem de şöyledir ki, yamayı kurup sistemi yama istediğiniz için yeniden başlattığınızda, sunucu açılmaz. Tamamen tepkisiz durumdadır. Olmaz olmaz demeyin, olmaz olmaz. Az önce söylediğim şeyin gerçek olduğuna ya da gerçek olabilecek kadar gerçeğe yakın olduğuna kişisel olarak şahidim.

İşin kötüsü, böyle bir durumda günümüzde –en azından Türkiye’de- kullanılan test sistemlerinin çoğu da beş para etmez. Çünkü yüksek alternatif maliyetler yüzünden test sistemleri çoğunlukla sanal sunucu ve bilgisayarlarda kurulurlar. Bu sanal kurulumlar gerçek ortamdaki yazılımları, onların yamalarını, sürümlerini vb birebir taklit ediyor olsa bile, donanımın kendisinden kaynaklanabilecek bir yama hatasını tespit edemezler. Yukarıda bahsettiğim gibi bir yama hatasını yakalayabilmek için donanımızın birebir aynısı bir sistemi yazılım olarak da (sürümler, yamalar vb dahil) birebir aynı olarak test ortamında yaşatıyor olmanız gerekir. Oysa bu bir hayli maliyetlidir.

Kıssadan Hisse: Bazı değneklerin iki ucu da okludur. Ne yana gideceği belli olmaz. Test ortamı için yapabileceğinizin en iyisini yapsanız bile, yüzde yüz bir test ortamı oluşturamadığınız için yamalardaki bazı hatalar sizi vurabilir. Hayli düşük bir olasılık olduğu için sanal ortamlarda test sistemleri yaşatmaya devam etmek bu riske rağmen daha mantıklı olabilir. Tabii yaşattığınız gerçek sistemin ne kadar kritik olduğunu değerlendirip hangi seviyede riski kabul edeceğiniz ve bu riskin gerçekleşmesi durumu için ne gibi alternatif planlar üreteceğiniz size kalmış.

Hala içiniz kararmadan bu felaket yazısını buralara kadar okuduysanız durun ve direksiyonda uyuyan bir sürücüyü düşünün. Umarım siz böyle bir deneyim yaşamamışsınızdır, ama yaşadıysanız birinci elden en sıcak deneyim olarak kendinizi düşünebilirsiniz.

Bir kamyon şoförü, bir yolcu otobüsü kaptanı, ya da uçak pilotu… Bunların çeşitli örneklerini zaman zaman yaşadık. Kontrollerin başında gerçekten uyuyanlar ya da gözleri ve bilinçleri açık olduğu halde yaptıkları işin gerektirdiği zihin yoğunlaşmasının altında kalıp yarı uyuyanlar!
Acı bedelleri olduğunu, olacağını biliyoruz.

IT yöneticileri ya da IT ortamlarının kullanıcıları da zaman zaman direksiyon başında uyuyabilirler.

Bir veritabanı yöneticisinin tabloları silme hakkı da vardır. Böyle bir hakkı kullanması gereken zamanlar da olur. Yanlışlıkla oluşturulmuş bir tabloyu, artık kullanılmayan bir tabloyu, yerine yenisi yapılmış bir tabloyu silebilir. Ya bu silme yetkisini yanlışlıkla en önemli tablolardan birisi üzerinde kullanırsa?

Hızla olaya müdahale edip güncel bir yedekten geri dönmesi gerekebilir. Tabii veritabanı sistemi bunu destekliyorsa, DROP TABLE için bir trigger yazmış ve işlemi otomatik olarak geriye alıyor olabilir. Ya da bir snapshot’ı vardır, buradan yedeğe gerek olmadan tabloyu yeniden oluşturup verisini doldurabilir. Ama kaç DBA bu tür tedbirleri sürekli olarak hazırda tutuyor ki? İşin kötüsü Database Mirroring gibi teknolojilerin bile böyle bir hataya karşı korumaması!

Olabilir mi? Olmaz olmaz demeyin, birkaç kere olmuş olduğunu şahsen bile duymuşluğum var.

Ya da biraz daha olası bir şey düşünelim. Fiyat değişiklikleri yapmak için tasarladığınız bir ekranınız var. Yetkili kullanıcılar bu ekranda filtre değerlerini giriyor, fiyatı değişecek ürünleri görüyor ve yeni fiyatı girip sistemi güncelliyorlar.

Diyelim ki bir kullanıcı böyle bir ekranda filtreleri girerken bir koşulu yanlış girdi ve değiştirmek istediği kayıtlardan çok daha fazlasını etkileyecek bir girişimde bulundu. Etkilenecek kayıtlar ekranında görüntülendi ama tek ekrana sığmadığı için ve ilk ekrandaki kayıtlar da doğru göründüğü için sonraki onlarca ekrana bakmadı. Bu ekranların sayısını sayfalama bağlantısında görüyor olduğu halde o an o kadar çok sayfa olması garibine gitmedi. 50 sayfayı bir anlığına, 50 ürün etkilenecekmiş gibi düşündü. Oysa her sayfada 40 üründen 50 sayfa 2000 ürün anlamına geliyordu! Bu 2000 ürünün fiyatını 38 YTL gibi sabit bir değere değiştirdi. 2000 adet ürünün fiyatı başarıyla değiştirildi mesajını görür görmez ne yaptığını anladı ama artık iş işten geçmişti!
Kıssadan Hisse: Yetkiler bazen kullanılmamak içindir. Bazen de kullanımlarının son derece titizlikle kontrol edilmesi gerekir. Yetkileri her zaman asla yanlış kullanılamayacak şekilde planlayabilmeniz mümkün olmayacaktır. O zaman bu yetkilere sahip kişilerin ters gidebilecek konular hakkında eğitilmeleri, olası hatalar ve çok olası olmasa da maliyeti yüksek hatalar konusunda uygulamalı olarak bilinçlendirilmeleri gerekir.

Sadece sistemde bir değişiklik yapmak değil, bir bilgiyi okumak bile takip edilmesi gereken bir yetki kullanımı olabilir. Sadece belirli kişiler tarafından görülebilmek üzere tasarlanmış birtakım bilgileri başka kişilerin görmesi uygun olmayacaktır. Hatta bazı bilgiler belki de ancak bir sorun olduğunda kullanılmak üzere tutuluyor olabilir. (Mahkeme talebiyle istenmesi durumunda kullanılmak üzere tutulan web sitesi ziyareti IP adres logları gibi.) Bu bilgilerin kimin tarafından ne zaman okunduğunun kayıtlarının tutulması önemlidir.

Yoksa bakarsınız toplum önünde yer alan önemli kişilerin mal varlıklarıyla ilgili her hangi kişiler sorgu çalıştırmaya başlamışlar! Ya da kişisel sağlık durumu gibi hassas kayıtlar rastgele kişiler tarafından görülmeye başlamış.

Kıssadan Hisse: Veriyi korumak, sadece kullanılabilir halde olmasını sağlamak değildir. Gizli kalması gereken bir bilgi açık hale gelirse, bu da felaket olarak yorumlanabilir.

Felaketlerden geri dönebilmenin en önemli yöntemlerinden birisi ‘yedekli’ gitmektir. İngilizce metinlerde bu konudan bahsedilirken ‘redundant’ kelimesini görürsünüz. Fazladan demektir.
Hiçbir şeyi tek bulundurmak istemezsiniz.

Mesela bir rooter üzerinden hizmet veren bir veritabanı olduğunu düşünün. Kullanıcıların bu veritabanına erişiminde bu rooter bozulursa sorun çıkacaktır. Veritabanınız ayakta olsa da fark etmez, kullanıcılarınız erişemez durumdaysa bu felakettir. Felaketten geri dönmek için rooter’ın tamir edilmesini beklemeniz gerekiyorsa vay sizin halinize! Nolacak peki? Rooter’ın yedeği olacak. Network kartınızın da yedeği olacak. İnternet üzerinden bir hizmet veriyorsanız ve ADSL kullanıyorsanız, ADSL kesintiye uğradığında devreye girecek yedek bir internet erişiminiz de olacak.

Herşeyin yedeği olacak yani. Eşeğini sağlam kazığa bağlayacaksın, e ki bir şey olursa diye yanına bir kazık daha çakıp bir de ona bağlayacaksın.

Kıssadan Hisse: Verinize ulaşım yolunda bulunan aktif cihazların, hatların ve varsa internet erişimlerinin yedeği olsun.

Yok öyle! Bu kıssadan hisse ucuz oldu. Sadece veriye ulaşım yolunun yedeğini almakla olur mu? Veritabanınıza bir şey olursa diye her zaman veri yedeklerinizi alıyor olmanız da gerekli.

Başka her ne önlem alırsanız alın, veri sisteminizin an gelip ölebileceğini düşünmelisiniz: Game over, kaput! Bu durumda elinizde yakın zamanda alınmış bir yedeğiniz olmalıdır.

Veritabanları için yedek almak gerekliliğini konuşmak ve yazmak günümüzde pek anlamlı değil, ya da en azından öyle umuyorum. Her veritabanı yöneticisi –kendisine böyle diyor ve saygı da duymak istiyorsa- yedek almak zorunda olduğunu bilir.

Ne sıklıkla yedek alınmalıdır? Durun, bunu düşünmeyin. Eğer veritabanı yedekleme ile ilgili bir sorumluluğunuz varsa, şu an ne sıklıkta yedek alıyor olduğunuzu düşünün. Çünkü –bu nasıl oluyor pek anlamıyorum ama- çok kritik bir rolü olan veritabanlarında bile yedek alınma sıklığının günlüğe kadar açılabildiğini görmek çok olası! Sebebi, veritabanı yöneticilerinin durup bunu düşünmüyor olmaları!

Sadece her akşam veritabanı yedeği almak, gün içinde oluşan işlemlerin tamamını kaybetmeye razı olmak demektir!

Bir veritabanında ne sıklıkta yedek almanız gerektiğine karar vermek için şu basit soruyla yola çıkılmalı: “Ne kadar sürelik bilgiyi tamamen kaybetmeye tahammülümüz var?”

Bu soruyu işin sahiplerine sorduğunuzda büyük olasılıkla “Hiç!” diye bir cevap alacaksınız. Hiç veri kaybı yaşamamanın yolu yedekleme değildir. Veri yedeği almak tek başına sıfır veri kaybını garantilemez. Sıkı bir yedekleme politikasının yanı sıra yüksek uygunluk (high availability) çözümleri de tasarlamanız gerekir. Aynalama (mirroring), donanımsal aynalama (hardware mirroring), kümeleme (clustering) gibi çözümlerin her birinin belirli yatırım ve operasyon maliyetleri vardır. Hiç cevabını aldığınızda bu çözümleri ve yaklaşık maliyetlerini çıkarın ve hiç veri kaybı olmamasını sağlamak için nasıl bir bütçeye, kaynağa, zamana, eğitime, danışmanlığa ihtiyaç duyduğunuzu anlatın. Bunları sağlamadan hiç veri kaybı sağlamanın mümkün olmadığını da anlatın. Eğer gerçekten kritik bir sistemse, iş sahipleri isteklerinize –belki biraz tırpanlayarak- razı olacaklardır. Eğer o kadar da kritik bir durum yoksa sizin isteklerinizi tamamen yok edip kendi isteklerini de tırpanlayabilirler. Yani size 10 dakika, 15 dakika, yarım saat gibi kabul edebilecekleri bir veri kaybı aralığı söyleyeceklerdir. Bu durumda iki yedeğiniz arasında bu belirtilen süreden daha uzun bir süre asla geçmemesini sağlamanız, iş isterlerini karşılar.

Kıssadan Hisse: Veritabanı için yedekleme aralığınızı belirlerken şu soruyu sormayı ihmal etmeyin: “Ne kadar sürelik veri kaybetmeye tahammülümüz var?” Bu soruyu kendi kendinize sorup geçiştirmeyin. İş isterlerinizi belirleme yetkisine sahip olan kişiye sorun.

Kıssadan Hisse: Sizden istenen her iş isterini tartışılmaz bir gerçek olarak kabullenmeyin. Bu isterin gerçekleşebilmesi için gerekli olan yatırımları, çabaları, kaynakları belirleyip iş isterinin sahibiyle uygun bir lisanla bunları paylaşın. Muhtemelen isterlerinizde onları daha makul seviyelere çeken değişimler olacaktır.

Yedekleme ile ilgili söyleyeceklerim bitti sanıyorsanız yanılıyorsunuz. Yedeği alınması gereken bir şey daha var: İnsan.

Bilişim alanında sistem yönetimi, yazılım desteği, proje yönetimi veya benzer bir sorumluluğunuz varsa, şu sahneyi yaşadığınızı canlandırın… Bu koşullardan biri size uymuyorsa da, böyle bir sorumluluğu olan bir kişinin bu sahneyi yaşadığını düşünün:

Bir Cuma akşamı yaklaşıyor ve siz yine çok yorgunsunuz. Servisin kalkacağı saati yakalayabileceğiniz ender günlerden biri ve toparlanmaya başladınız. Aniden telefonunuz çalıyor. Açıyorsunuz ve karşınızda yöneticiniz. Hal hatır soruyor size önce bir. Şaşırıyorsunuz, pek öyle konuşmayı dolandıran birisi değildir. Üstelik bu saatte aradığına göre kesin bir isteği olmalı. Bu isteğin büyük olasılıkla bir saat daha iş yerinde kalıp üstelik de servisi yine kaçırmanıza sebep olacak bir şey olması çok yüksek olasılık. Yine de aslında sadece bir soru sorup cevabını aldığı zamanlar da olur ve şu an durumun böyle olması için nerdeyse yalvaracaksınız. Oysa hal hatır sormakla servise yetişmeniz için kalmış az sayıda dakikalardan birini daha harcıyor.

Size çok uzun bir peşrevin ardından son zamanlarda çok çalıştığınızı çok yorulduğunuzu bildiğini sayıp dökmeye başlıyor ve içinizi bir korku kaplıyor. Böyle alttan alır bir havada olduğuna göre bir saat falan değil, pizzacının aranacağı gecelerden biri olacak gibi duruyor!

Sonra aniden, servis saati de yaklaştı deyip sizi daha fazla tutmak istemediğini söylüyor. Pazartesi dahil şöyle bir üç gün dinlenmenizi hatta isterseniz belki şehir dışı bir yerlere kaçmanızı öneriyor ve böyle sürpriz bir kafa izni alınca teşekkür bile edemeyecek hale gelmenizle ilgili bir espri yapıp telefonu kapatıveriyor.

Başınızda şapka olsan çıkarıp havaya savuracaksınız ama zaten tavan da çok yüksek değil hani. Hayatınızda hiç tırnak yemediğiniz halde sevinçten elinizi yumruk yapıp parmaklarınızın ikinci boğumlarını ısırıyorsunuz. Neyse ki bunu yaptınız çünkü çok kısa bir süre sonra çılgın bir sevinç çığlığı atmadığınıza şükredeceksiniz.

Acaba bu kafa izni için servise gitmeden yanıma almak istediğim fazladan bir şey olur mu diye etrafınıza bakınırken gerçekler bir anda kafanıza dank etmeye başlıyor. Jetonlar birer üçer beşer düşmeye başlıyor.

Tatile gidemezsiniz.

İyi niyetli bir çalışan olduğunuzu varsayalım:

  • Pazartesi günü çok önemli bir teslimat var. Gelen cihazların tam olarak doğru geldiğini tespit etmek, kağıt işlerini yapmak, her şeyin yolunda gitmesini sağlamak sizden başka pek kimsenin harcı değil.
  • Hafta başları alınan kritik performans raporlarında sürekli aksamalar çıkıyor ve her haftanın ilk iki gününde toplam 3-5 saat bunlardaki aksaklıklara ve yeni isteklere ilişkin destek veriyorsunuz. Sorunları gidermek için vakit ayırıp raporlardan doğru düzgün çalışmasını bir gün sağlayacaksınız. Ama henüz vakit ayırmanız mümkün olmadı.
  • Çarşamba günü lisan ve donanım sayımı var. Bilişimle ilgili sorumlu olduğunuz ürünler şirketin her köşesine ve bölümüne artık o kadar yayılmış durumda ki, siz olmadan tüm portfolyoyu toparlayabilecek kimse çıkmaz.

Şimdi de kötü niyetli bir çalışan olduğunuzu varsayalım:

  • Pazartesi günü çok önemli bir teslimat var. Gelen cihazların tam olarak doğru geldiğini tespit etmek, kağıt işlerini yapmak, her şeyin yolunda gitmesini sağlamak sizden başka pek kimsenin harcı değil. Üstelik tedarikçiyle yaptığınız özel anlaşma sayesinde kağıt üzerindekinden fazla yapılan komisyona karşılık bazı parçaların uygun bir şekilde ortadan kaldırılması gerekiyor. Sevk irsaliyesinin biraz farklı iki kopyasının uygun şekilde yer değiştirilmesi ise cabası. Kesin işte olmalısınız.
  • Hafta başları alınan kritik performans raporlarında sürekli aksamalar çıkıyor ve her haftanın ilk iki gününde toplam 3-5 saat bunlardaki aksaklıklara ve yeni isteklere ilişkin destek veriyorsunuz. Sorunları gidermek için vakit ayırıp raporlardan doğru düzgün çalışmasını bir gün sağlayacaksınız. Ama henüz vakit ayırmanız mümkün olmadı. Çünkü zaten bu sorunlar henüz çok taze. Uygun bir şekilde onları planlamak için az vakit harcamadınız. Bu sorunlar sayesinde size duydukları ihtiyacı iyce hissediyorlar. Bir başkası sizin yokluğunuzda konunun derinine inerse, bazı sorunların ne kadar yüzeysel olduğu fark edilebilir.
  • Çarşamba günü lisan ve donanım sayımı var. Bilişimle ilgili sorumlu olduğunuz ürünler şirketin her köşesine ve bölümüne artık o kadar yayılmış durumda ki, siz olmadan tüm portfolyoyu toparlayabilecek kimse çıkmaz. Üstelik kayırdığınız kişilere ve bölümlere daha çok imkan sağlamayı gelenekselleştirmiş olduğunuzu da fark edenler çıkabilir. Burada daha kazanılacak çok para var. Foyanız meydana çıkmamalı.

Bazı kurumsallaşmış yapılarda bu tür ani tatile göndermeler insanların yeterince yedekli olup olmadığını anlamak için ya da kişisel ve pek de ‘dürüst’ olmayan birtakım hesapların güdülmediğinin anlaşılması için kullanılabiliyor.

Şaşar beşer demişler, insan kötü yola düşebilen bir varlık. Ama bir kötülük yapmak için tek kişinin gerekmesiyle birkaç kişinin anlaşmalı olarak bir şeyler yapması gerekmesinin arasında büyük fark var. Kişileri ani ve önceden hazırlık yapmadan birkaç günlük tatile göndermek tek kişilik ‘düzenlerin’ ortaya çıkması ya da engellenmesi için faydalı olabilir.

Ama daha önemlisi, sisteminizin sağlıklı yürümesi için her şeyin yedekli olması gerektiği gibi insanların da yedekli olması gereklidir. Çok çalışkan, her şeyle ilgilenen, her şeyi bilen, sorunları hızla halledebilen bir IT çalışanınız olması ilk bakışta hoş gibi geliyor. İyi de bu kişi o gün işe gelirken biraz ağır bir kaza geçirirse ya da aniden yataktan bir hafta başını kaldıramayacak kadar ağır bir gribe yakalanırsa ne olacak?

Yetişmiş insan bulmanın zorluğundan ve olası maliyetlerden dolayı yedeksiz insan kaynaklarıyla çalışmayı alışkanlık edinmiş pek çok firma var. Hatta ülkemizde bu yaklaşım neredeyse standart hale gelmiş durumda.

Oysa insan kaynaklarının yetişmesinin önündeki en büyük engel de belki yedeksiz çalışma! Kapasitenin üzerinde yükleme yapmak yerine normal kapasitede çalıştırılan bir IT elemanları kadrosu olsa, bu kadro içinde yeni elemanlar da yetiştirilebilir.

Öte yandan kısıtlı kadrolarla çalışarak maliyetten tasarruf edildiği varsayılırken hesaba katılması gereken bir şey daha var: Felaketlerin ya da felaketlerden en uygun şekilde dönememenin şirket üzerine yüklediği hesap edilebilir, hesap edilebilir olduğu halde hesap edilememiş ve hesap edilemez maliyetler toplamı!

Kıssadan Hisse: Felaketleri azaltabilmek ve felaketlerden en uygun şekilde dönebilmek için kullanılabilecek pek çok teknik, araç, tasarım var. Ancak gerçek farkı sağlayacak olan, bunları tasarlayacak ya da kullanacak olan insanların varlığı ve bu insanların bu konuda yetişmişlikleridir. Tabii bir de bu insanların da yedekli olmaları!

Mustafa Acungil

Bu yazı KırkAmbar içinde yayınlandı ve , olarak etiketlendi. Kalıcı bağlantıyı yer imlerinize ekleyin.

1 Response to Felaketten Dönebilmek ya da Orada Kalmak. İşte Bütün Mesele Bu!

  1. Geri bildirim: Felaketten dönebilmek ya da orada kalmak, işte bütün mesele bu! | Veri Yönetimi Departmanından Haberler

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s