Etiket Bulutu

Benchmark Convert_IMplicit Database High Availability Database Mirroring datawarehouse dimension table dmv Dynamic Data Masking Execution Execution Plans fact table Failover Cluster Node ekleme Failover Clustering FileStream generate script High Availability Implicit Instant File Initialization index Kinect Linux Live Query Statistics Log Shipping Mirroring object explorer object explorer details ODBC Driver pass performance performance tuning Plan Handle Planü Power View reporting services rol Row Level Security script sql serer 2016 sql server SQL Server 2008 SQL Server 2008 Log Shipping SQL Server 2012 SQL Server 2012 installation SQL Server 2012 Kurulumu SQL Server Backup SQL Server da Backup planı SQL Server da Maintenance Plans oluşturma SQL Server database mirroring SQL Server Disaster Recovery sql server dynamic management views SQL Server Failover Cluster SQL Server High Availability SQL Server Log Shipping SQL Server Maintenace Plans sql server performans SQLDIAG SQLDIAG Troubleshooting T24 Temenos truncate table t-sql unique index performance 1. Dünya savaşı istatistikleri 1456 451 ACID advanced analytics Advanced Data Analytics Affinity algı Alter index Alter table ALTER TABLE .. ALTER COLUMN Altın Oran Always On ALWAYSON AlwaysOnDemoTool amazon web services kinesis AMR analiz analysis service Ankara Antivirus apache kafka Arduino Article Assembly asymmetric audit Authentication Auto Growth Availability Group azure Azure Backup azure event hub partition azure event hubs azure event hubs servisi azure event hubs veri edinme Azure File Share Azure Fiyatlandırma Azure HDInsight Azure Hizmet Modelleri Azure ML Azure New Portal Azure Pricing Azure Queue azure sql database configuration azure sql database kullanımı azure sql database stream veriyi tutma azure sql database table partitioning Azure Storage azure stream analytics azure stream analytics dashboard azure stream analytics ölçeklendirilmesi azure stream analytics servisi Azure Table BA Backup backup encyrption backupset Bakım BASE bellek Best Practice BI Semantic Model Big Data Big User blocking blocking disable trigger blocking enable trigger Buffer Cache buffer pool Buffer Pool Extension bulk logged Buluta Veri Depolama Buluttaki Disk Business Analytics Conference business intelligence Büyük Veri Case Central Management Server certificate changed data capture Cloud Computing Cloud DR CLR Cluster clustered columnstore index Clustered Index Code Snippets Cold Purging collation column store column-level columnstore ColumnStore Indexes Compress ComputerNamePhysicalNetBIOS Concurrency Conditions Contained Database Contained Databases convert CONVERT_IMPLICIT Corruption Credentials cube DAC Dashboard Tasarımı data cleansing Data Compression Data Consistency Model data encryption data matching data mining Data Page data profiling data quality Data Services Data Warehouse Design Database database list Database Management Sistem database master key Database Mirroring Database Snapshot database trigger database-level Data-Ink Ratio datasets datasource DataZen date date dimension db_owner DBA DBCC dbcc dropcleanbuffers dbcc freeproccache DBMS dbo user DDL deadlock debugging DecryptByKey DecryptByPassPhrase deleted bitmap delta store Denali Denali SSAS deny database list deşifre detail index developer DIFFERENTIAL BACKUP DirectQuery Dirty Read Disaster Recovery Distribution Yapılandırma Distributor Distributor Agent dm_server_services DMF DMO DMV document db dosya bazlı şifreleme dqs dr Dynamic Management Function Dynamic Management Object Dynamic Management View ecrypt Effected Report Design Techniques Eğitim EncryptByKey EncryptByPassPhrase encryption endpoint Environment Variable error Error 5030 Error Log Estetik Raporlama Estimated Rows Eş Zamanlılkk Etkili Rapor Tasarlama Teknikleri Etkinlik ETL event Event Viewer except;intersect;sql execution Execution Plan export formats extended events Extended Stored Procedure Facets Failover Failover Cluster fast n execution plan FETCH NEXT FILELISTONLY FILLFACTOR File Table file-level FileStream Filter Pack Filtered Index First_Value Flat File fn_repl_hash_binary Focal Point foreignkey FORMAT Forwarded Record forwarded_record_count ftp task FULL BACKUP Full Recovery Full-Text Search functions Gartner Geocluster Gerçek Zamanlı Dashboard gestalt Golden Ratio görsel duyu group by Güvenlik ha Hadoop hafıza Hash HASHBYTES HEADERONLY headers footers Heap Hekaton hicri High Availability hijr Hiyerarşi Hybrid Cloud IaaS Index Index Scan In-Memory InMemory DW In-Memory DW InMemory OLTP In-Memory OLTP Internet of People Internet of Things IO IOT IoT nedir Isolation Level indeks index inmemory in-memory oltp internet of things isolation level istatistik istatistikler İş zekası İzolasyon Seviyesi Job json json support knowledge base kolon-satır bazlı kurulum küp Lag Lansman latch Lead linked server lock locking locking hints Log Backup Log Reader Agent Log Shipping login Lost-Update LQS Machine Learning Maintenance Management Studio matrix Max Text Replication Size mdx memory Memory Optimization Advisor Memory Optimized Table Memory Optimized Tables merge Merge Agent merge kullanımı Merge Publication Merge Replication merge type 1 slowly changing dimension merge type 1 slowly changing dimension örneği merge type 1 vs type 2 scd merge type 2 slowly changing dimension merge type 2 slowly changing dimension örneği merge type 3 slowly changing dimension merge type 4 slowly changing dimension message Microsoft Advanced Data Analytics Çözümleri microsoft azure Microsoft Bulut Microsoft Sanal Akademi Microsoft SQL Server Microsoft SQL Server 2014 Yenilikleri Microsoft SQL Server 2016 Mirror mirroring missing index Monitoring move Msdb multi_user multiversion concurrency control MVP MVP Roadshow MySnippet Named Pipes Natively Store Procedures Natively Stored Procedures Nesnelerin İnterneti Network Binding Order NoEngine Approaches nonclustered columnstore index Non-Repetable Read NoSQL NoSQL Approaches NoSQL Dünyası object explorer Odak Noktası ODBC Office 365 Offline OFFSET olap OLAP Backup OLE DB OLTP Online Index order attributes Otomatik Büyüme OVER PaaS PAD_INDEX page out page properties PAGE RESTORE PAGEIOLATCH paging parameters partition partitioning PASS PASS Summit PASS Summit 2014 Performance Performance Tuning performans performans tuning Phantom Read pivot Policies Policy Based Management Filtreleme Policy Management Power BI Power BI Dashboard Power BI Rest API power bi power view PowerBI PowerBI for Office 365 powerbi PowerMap PowerPivot PowerQuery powershell powershell ile sql yönetimi PowerView PowerView raporlarının web sayfalarına gömülmesi precon Primary Key primarykey Project Deployment Model Project Variable Protokol Proxy Proxy Account Publisher Purging on Independent Tables QL Server 2014 Yenilikleri Que Reader Agent Query Plan query store R Range Raporlama Raporlama Projeleri için Strateji Belirleme Raporlama Projelerine Hazırlık Read Committed Read Uncommitted RealTime Dashboard Rebuild RECONFIGURE RECONFIGURE WITH OVERRIDE Recovery model Relational Engine relationships Rename SSRS Database Repeatable Read Replication Replication Monitoring replikasyon report manager web site report parts reporting service reporting services reporting servis Resource Governor RESTORE Restore Database Restore Generate Restore Generate Script Restore transaction log rollback rs Rule of Thirds sa user SaaS sayfalama scd 3 demo scd karşılaştırma scd type 4 demo Scheduling Schema Comparison script Security segment elimination select into Self-Service BI Semantic Search Serializable Server Core SERVERPROPERTY Service services shared data sources shared datasets Shared Memory sharepoint Sharepoint 2010 ShowPlan Shrink simple recovery sing_user sliding window Slowly Changing Dimension snapshot Snapshot Agent Snapshot Publication Snapshot Replication Snippet snowflake sorting sp_configure sp_describe_first_result_set sp_server_diagnostics sp_spaceused sql SQL Agent Job SQL Azure sql bilgi yarışması SQL CLR SQL DIAG SQL DIAG Performans verisi toplama SQL endpoint SQL Login SQL Onculeri SQL Öncüleri sql script sql server SQL Server 2005 SQL Server 2008 SQL Server 2011 CTP3 SQL Server 2011 Denali SQL Server 2012 SQL Server 2012 CTP3 SQL Server 2012 RC SQL Server 2012 RC0 SQL Server 2012 ShowPlan Enhancements SQL Server 2012 T-SQL Enhancements SQL Server 2014 Sql Server 2014 Cardinality Estimator SQL Server 2014 Yenilikleri sql server 2016 SQL Server 2016 New Features SQL Server 2016 Yenilikleri sql server agent sql server assembly ekleme SQL Server Authentication sql server cast ve convert sql server clr integration sql server clr kullanımı sql server clr örnek sql server cluster SQL Server Code Name Denali SQL Server da Kullanıcı Yaratma SQL Server Database Project sql server dmv ve dmf sql server execution plan temizleme SQL Server Express Backup sql server fast n option örneği sql server fast n seçeneği SQL Server login sql server management stdio sql server merge into örnek sql server merge komutu sql server merge performnas sql server merge type 1 scd sql server merge type 2 scd sql server merge type 3 scd SQL Server Mobile Report Publisher SQL Server Network Interface SQL Server Onculeri SQL Server Öncüleri SQL Server Öncüleri Ankara SQL Server Performance sql server performans SQL Server Profiler SQL server recovery model SQL Server Reporting Services SQL Server Restore Generate Script SQL Server sa SQL Server Security SQL Server SQL DIAG sql server tarih dönüşüm işlemi sql server tarihsel veriler ile çalışma SQL Server User SQL Server yetki SQL Server yetkilendirme sql servera .net kodu ekleme SQL Serverda yetkilendirme nasıl SQL Serverda yetkilendirme nasıl yapılır sql to oracle linked server sql türkiye SQL User With Password sql yarışma SQLCMD sql'den oracle'a linked server SQLDIAG SQLDIAG Report SQLOS sqlsaturay SQLSaturday SQLSaturday #182 SQLSaturday #359 sqlsaturday #451 sqlserveronculeri ssas SSAS 2012 SSIS SSIS 2012 ssis SSMS SSMS Project SSMS Solution ssrs Stanby Database star schema STOPAT STOPBEFOREMARK STORAGE Storage Engine stored procedure stream analytics job subreports Subscriber Subscription subscriptions symmetric SYS sys.dm_db_index_physical_stats sys.dm_db_index_usage_stats sys.dm_db_missing_index_columns sys.dm_db_missing_index_details sys.dm_db_missing_index_group_stats sys.dm_db_missing_index_groups sys.server_principals sysadmin System Databases System View şifre şifreleme table table difference TableHasClustIndex TableHasIdentity TableHasPrimaryKey Tablet PC Tabular Mode Tabular Model TCP/IP TDE Tempdb time series Transaction Transactional Publication Transactional Replication Transparent Data Encryption trigger Troubleshooting TRY_CONVERT TRY_PARSE tsql t-sql T-SQL 2012 tsql mistakes Undocument union unionall Updatable ColumnStore İndex upgrade Veri ambarı veri edinme seçenekleri Veri Güvenliği Veri Hizmetleri Veri madenciliği Veri Mürekkep Oranı Veri Tabanı Yönetim Sistemleri Veri Tipi Veri Tutarlılık Modelleri Veri Yönetimi Evrimi verinin evrimi Veritabanı oluşturmak VERİTABANI YEDEKLEME STRATEJİLERİ veritabanı yedeklerinin şifrelenmesi Veritabanı Yöneticisi Veritabanı Yönetimi VeritPaq view any database Visual Studio VTYS web services Webcast Windows 7 Windows 8 Windows Authentication Windows Azure Windows Failover Clustering wmi WRITELOG xevents xp_sqlagent_enum_jobs YEDEKLEME STRATEJİLERİ Yedekli Çalışma Yetkilendirme Yiğit Aktan ysfkhvc yusuf kahveci Yüksek Erişilebilirlik Yüksek Süreklilik zip

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

Ekleyen: Mustafa Acungil Bilgeadam Kurumsal Teknoloji Yöneticisi Tarih:24.08.2011 Okunma Sayısı:2752


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ı!


yorum yaz
serdar toprak

serdar toprak


13.11.2014 12:30


Mükemmel bir yazı olmuş.Elinize Sağlık

Üye Girişi

Kullanıcı Adınız

Şifreniz

Şifremi Unuttum

Arkadaşına Tavsiye Et

Tavsiye edebilmek için siteye giriş yapmalısınız