Video: Clonera | Felaket Kurtarma ve İş Sürekliliği Çözümü Demosu (Kasım 2024)
BT altyapınız için olağanüstü durum kurtarma stratejisini uygulayabilmeniz için resmi bir plan oluşturmanız gerekir. Bu kritik belge, kuruluşunuzda makul olarak düşebilecek, kritik öneme sahip uygulamaları ve sistemleri tam olarak belirleyebilecek her olası acil durumu detaylandırmalı ve yürütme yönetimi, insan kaynakları ve tesis yönetiminden sorumlu olanlar da dahil olmak üzere kuruluşunuzdaki tüm kilit rakamlarla imzalanmalıdır. Bu makale, bu planı oluşturmak için size bir taslak sağlayacaktır.
Kilit paydaşlarla bir araya geldikten ve organizasyonu durdurabilecek (ve muhtemel bir ölüm) kritik uygulamaların ve verilerin kaybı gibi potansiyel afet senaryolarını belirledikten sonra planınızın belgelenmesi gerekir. Personele dağıtmak için kısa ve özlü bir plana sahip olmak önemlidir, böylece felaket durumunda ne yapılması gerektiğine dair karanlıkta kimse kalmaz. Planı oluşturmada size rehberlik etmek için, etkili bir planın neler içermesi gerektiği ile ilgili bir kontrol listesi.
Kontrol Listesi
• Kritik uygulamalar, sistemler ve platformlar belirleyin
Bir felaket anında hangi altyapının hangi bileşenlerinin mutlaka bulunması gerektiğini belirlerken eti yağdan kesmeniz gerekir. Bu, donanım ve yazılımın güncel bir envanter değerlendirmesinin önemini vurgulamaktadır. Sanallaştırılmış herhangi bir şey dahil olmak üzere altyapıda çalışan tüm yazılım veya donanım parçalarını öğrenin. Yalnızca iyi bir varlık yönetimi çözümüne yatırım yapmakla kalmaz, aynı zamanda tüm yazılım ve güncellemelerle ilgili bir günlük dosyası tutmayı da öder. Bu şekilde, yalnızca bir felaketten dolayı kayıp olması durumunda tüm BT envanterinin ne olduğunu bilmezsiniz, ancak bir liste derleyip kriz sırasında hangi sistemlerin hangi operasyonel kalması gerektiğini ve geçici olarak yaşayamayacağınızı kontrol edebilirsiniz.
Bir felakette neyin feda edilebileceği hakkında kasıtlı olun. Örneğin, satış potansiyelini takip etmek için kullanılan bir veritabanı bir felaket için çok önemli olmayabilir, ancak bir sağlık tesisi için mevcut tüm hastaları listeleyen bir veritabanıdır. Özellikle çalışanlar tesis dışında kalmak zorunda kaldıklarında, personel durum güncellemeleri ve prosedürleriyle iletişim kurmak için e-posta gerekebilir. Hangi bileşenlerin önemli olduğu işin doğasına bağlıdır, ancak ne olursa olsun, listelenmeli ve plana dahil edilmelidir.
• Değerlendirme ve Uygulama
Burası uygulama hakkında düşünmeye başlamanız gereken yer. Güvenlikten veya kurumsal uygunluktan ödün vermeden saha dışında hangi verilere erişilebilir? Bir kuruluş hiçbir iş sürecini bir bulut bilişim modeline kaydırmamışsa, bunu düşünmek için iyi bir zaman olabilir. İş kolu uygulamaları daha fazla planlama gerektirse de, buluta kolayca taşınabilmeleri için karmaşık olabilirler, e-posta ve depolama, buluta geçiş için iyi adaylardır.
Bulut Tabanlı Posta ve Depolama
Bulut tabanlı e-posta hizmetleri, yalnızca mevcut e-posta sistemlerini yansıtmakla kalmayıp, aynı zamanda gerektiğinde HIPAA ve diğer e-posta düzenlemelerine de uymak için kullanılabilir. Bu e-posta sağlayıcılarının birçoğu, belirli bir iletişimi gizli veya çok hassas olarak işaretlemesi gerekebilecek veya yalnızca belirli personel üyelerinin belirli e-posta iletişimlerini almasını sağlaması gerekebilecek bir hukuk firması gibi bir işletme için e-posta iletişimi üzerinden veri yönetişimi uygulayabilir.
Bulut depolama, tüketicilerle birlikte hızla büyüyen bir trenddir ve işletmeler bir felaket planının parçası olarak bulut depolama avantajından da yararlanabilirler. Çok fazla sayıda organizasyon hala yerel olarak kurulmuş, yedekleme ve teyp ya da RDX ortamlarına yedeklenmiş veri çözümleri kullanıyor. Yedeklenen veriler genellikle saha dışına gönderilir ve düzenli olarak döndürülür, böylece sistem verilerinin ya da felaket durumunda bir kuruluşun verilerinin hazır bir kopyası hazır olur.
Ancak, bu verilerin bir bulut depolama sağlayıcısına çoğaltılması, bu verileri fiziksel, site dışı bir konumdan almak ve ardından sunuculara el ile geri yüklemek için harcanacak zamandan tasarruf sağlayabilir. Bir bulut çözümü ile, çalışanların İnternet bağlantısı varsa, neredeyse gerçek zamanlı olarak kritik verilere erişilebilir. Depolanan verilerin Sarbanes-Oxley (SOX) gibi kurumsal uyumluluğa uymasını sağlayabilen bulut depolama sağlayıcıları da vardır.
Uygulamalar, Sunucular ve Sanallaştırma
Bir felaket kurtarma planının ana hatlarını çizerken, yalnızca buluta taşınan veriler hakkında değil, taşınabilecek tüm uygulamalar hakkında düşünmek de faydalı olur. Bir işletme, Amazon, Rackspace ve Google gibi sağlayıcılarla, acil bir durumda erişilebilmesi için uygulamaları ve veritabanlarını buluta geçirebilir.
Bir işletmenin buluta veriyi tamamen yedekleyemediği veya en azından yalnızca hibrit bir çözüm uygulayabildiği durumlar vardır - bazı veriler yedeklenir ve diğer veriler yerel kalır. Nedenler arasında güvenlik endişeleri veya maliyet yasakları olabilir. Bir DP planı oluştururken, bir altyapının nasıl modernleştirilebileceğini belirlemek için iyi bir zamandır.
Acil bir durumda, daha fazla donanıma ne kadar ayrı bir yazılım dağıtılırsa, durumun sistemlerin geri yüklenmesiyle ilgili yaygın hasar ve süre o kadar olasıdır. Sanallaştırma bu tür bir sorun için güçlü bir çözüm olabilir. Fiziksel sunucuları sanal makinelerde birleştirmek, BT'nin sunucu örneklerinin düzenli anlık görüntülerini oluşturabileceği ve bir felaketten sonra bu sunucuları kolayca geri yükleyebileceği anlamına gelir. Canlı geçiş gibi özellikler sunan sanallaştırma çözümleri sayesinde, kritik altyapı sistemlerini eski haline getirmek için uzun bir süre durmaya gerek yok.
Hala çoğu sistemi ve verileri yerinde barındırması gereken kuruluşlar için, acil durumlarda güvenli olduğu tespit edilen bir konumda bulunan hareketli bir mobil veri merkezi de planlanabilir. Verileri bir ana siteden bir yedek siteye kopyalayabilen yedekleme sunucuları, en azından kritik sistemleri kullanılabilir durumda tutmanın bir yolunu sağlayabilir.
Güç
Veri ve sunucuların yanı sıra, olağanüstü durum kurtarma hazırlıklarında ele alınması gereken daha temel hususlar vardır. En yaygın afet senaryolarından biri elektrik kesintisidir - ülkenin elektrik altyapısı genel olarak büyümeye ayak uyduramadığından her işletmenin planlaması gereken bir felakettir. Tüm kritik donanımlar elbette Sınırsız Güç Kaynakları (UPS) ile çalışıyor olmalıdır. UPS çözümleri, en azından alternatif felaket prosedürlerine geçmek için bir organizasyon elde etmek için yeterince uzun bir elektrik kesintisi durumunda bir çalışma süresi sağlayabilir. UPS cihazlarının düzenli kontrolleri ve test edilmesi çok önemlidir.
Daha uzun elektrik kesintileri için, bazı kuruluşların BT ekipmanına adanmış jeneratörler gibi alternatif güç kaynakları oluşturmak için tesisler departmanı ile birlikte çalışması gerekebilir.
Telekom ve Uzaktan Erişim
İnternet sağlayıcıları ve mobil operatörleri genellikle afetlerde daha uzun süre çalışmamaya başlar. Yakın ve çevresindeki alanlarda telekomünikasyonu etkileyebilecek ciddi bir felaket durumunda bir iş yapabilecek bir şey olmamakla birlikte, farklı ISS'lerden gereksiz İnternet bağlantılarına sahip olmak gerekir. Bu şekilde, bir ISS'nin ağı kapalıysa, ikinci bir ISS hala çevrimiçi olabilir. İyi bir felaket kurtarma planı, altyapının bir İnternet bağlantısından ikinci, yedek bir bağlantıya nasıl geçeceğini belgeliyor. Planda bu yük devretme bağlantısının düzenli olarak test edilmesi gerekir.
Plan ayrıca, son kullanıcıların acil durumlarda sistemlere nasıl erişeceklerini de dikkate almalıdır. Birçok son kullanıcının, şirket ağına uzaktan erişmek için yapılandırılabilecek şirket tarafından verilen veya kişisel mobil aygıtları vardır. Çoğu kurumda, zaten bir tür Sanal Özel Ağ (VPN) çözümü vardır ve bu da işletme ağına uzaktan giriş sağlar. Bu VPN sistemi gerçekten işe yarıyor mu ve teknik olmayan çalışanlar, bir felaket sırasında bulunmayan yoğun BT desteği olmadan kullanmak için yeterince eğitimli mi? Bu VPN veya uzaktan erişim çözümü bir felakete dayanabilir mi? VPN'ye bir yedekleme de düşünülmelidir. Bu, başka bir sitedeki VPN sunucusu olabilir veya normal VPN sistemi yerine bir bulut sağlayıcı aracılığıyla veri ve sistemlere erişim olabilir.
Bazı kuruluşlar, gerekli bazı uygunlukları taradıktan sonra yalnızca şirket ağına uzak bir cihaza erişim izni verecek bir uzaktan erişim çözümüne sahip olabilir. Örneğin, gerekli bir hizmet paketi veya virüsten koruma tanımı dosyası bulunmayan bir Windows istemci cihazının şirket ağına erişimi reddedilebilir. Acil bir durumda böyle sürprizler istemezsin. Afete hazırlık aşamasının bir parçası olarak, acil durumlarda hangi istemci cihazlarının ağa nasıl ve ne şekilde erişeceğini açıklayın. Ağa erişebildiklerinden emin olmak için bu aygıtları düzenli olarak kontrol edin. Bu, bir organizasyonun, kurumsal ağa erişen mobil cihazların merkezi yönetimini sağlayan bir mobil cihaz yönetimi (MDM) çözümünü düşünmek isteyebileceği yerdir.
Şirket çalışanlara akıllı telefonlar vermiş olabilir. Şirket çalışan telefonları için belirli bir taşıyıcı kullanıyorsa, acil durumlarda kilit çalışanlara dağıtmak için farklı bir taşıyıcıdan telefon almayı düşünün. Bir operatörün ağı bir felakete düştüğünde, bir başkası kullanılabilir. Bir felakette İnternet ve telekomünikasyon için aynı taşıyıcıya güvenmeyin.
• Belge
Bir felaket kurtarma planı belgelendikten sonra, tüm kilit yöneticilerin, yönetimin ve felakete hazırlık kararında yer alan diğer tüm personelin belgeyi incelediğinden ve imzaladığından emin olun. Bu belgeyi resmi politika yapar ve kuruluşun politikalarının bir parçası olarak dahil edilmelidir.
Afet kurtarma planı, düzenli olarak güncellenmesi gereken canlı bir belgedir. Test prosedürleri bu belgenin bir parçası ise, test tarihi ve sonuçları belgelenmeli ve felaket kurtarma planıyla ilişkilendirilmelidir.
Bu serinin bir sonraki bölümünde, olağanüstü durum kurtarma planlarının uygulanmasına ve olağanüstü durum kurtarma stratejinizi yerine getirmenize yardımcı olabilecek çözümlere göz atacağız.
