Felaket anında bile bir fincan çay için her zaman vakit vardır
DRP (felaket kurtarma planı) ideal olarak asla ihtiyaç duyulmayacak bir şeydir. Ancak çiftleşme mevsimi sırasında aniden göç eden kunduzlar omurganın optik fiberini kemirirse veya kıdemsiz bir yönetici üretken tabanı bırakırsa, tüm bu rezaletle ne yapacağınıza dair önceden hazırlanmış bir planınızın olacağından kesinlikle emin olmak istersiniz.
Müşteriler panik içinde teknik destek telefonlarını kesmeye başlarken, ast siyanür ararken siz akıllıca kırmızı zarfı açar ve her şeyi düzene koymaya başlarsınız.
Bu yazıda bir DRP'nin nasıl yazılacağı ve neleri içermesi gerektiği konusunda öneriler paylaşmak istiyorum. Ayrıca aşağıdaki konulara da bakacağız:
- Haydi bir kötü adam gibi düşünmeyi öğrenelim.
- Kıyamet döneminde bir fincan çayın faydalarına bakalım.
- Uygun bir DRP yapısı üzerinde düşünelim
- Bakalım nasıl test edeceğiz
Bu hangi şirketler için faydalı olabilir?
BT departmanının bu tür şeylere ihtiyaç duymaya başlamasıyla çizgiyi çizmek çok zor. Aşağıdaki durumlarda kesinlikle DRP'ye ihtiyacınız olduğunu söyleyebilirim:
- Bir sunucunun, uygulamanın durdurulması veya bir veritabanının kaybedilmesi, bir bütün olarak işletme için önemli kayıplara yol açacaktır.
- Tam teşekküllü bir BT departmanınız var. Sadece ağ kuran, virüsleri temizleyen ve yazıcıları yeniden dolduran birkaç yorgun çalışandan ibaret değil, kendi bütçesine sahip, şirketin tam teşekküllü bir birimi şeklinde bir departman anlamında.
- Acil bir durumda en azından kısmi işten çıkarma için gerçekçi bir bütçeniz var.
BT departmanı aylardır en az birkaç HDD'nin yedeklenmesi için eski bir sunucuya aktarılması için yalvarırken, kapasiteyi rezerve etmek için başarısız bir hizmetin tam teşekküllü bir taşımasını organize etmeniz pek mümkün değildir. Burada olmasına rağmen belgeler gereksiz olmayacak.
Dokümantasyon önemlidir
Belgelerle başlayın. Diyelim ki hizmetiniz, üç nesil önce yöneticiler tarafından yazılmış bir Perl betiği üzerinde çalışıyor ancak kimse onun nasıl çalıştığını bilmiyor. Birikmiş teknik borç ve belge eksikliği kaçınılmaz olarak sizi sadece dizinizden değil diğer uzuvlarınızdan da vuracaktır, bu daha çok an meselesi.
Hizmet bileşenlerinin iyi bir tanımını öğrendikten sonra kaza istatistiklerine bakın. Neredeyse kesinlikle tamamen tipik olacaklar. Örneğin, diskiniz zaman zaman doluyor ve bu da düğümün manuel olarak temizlenene kadar arıza yapmasına neden oluyor. Veya birisinin sertifikayı yenilemeyi tekrar unutması ve Let's Encrypt'in yapılandırmayı yapamaması veya yapılandırmak istememesi nedeniyle istemci hizmeti kullanılamaz hale gelir.
Sabotajcı gibi düşünceler
En zor kısım, daha önce hiç yaşanmamış ancak hizmetinizi tamamen çökertebilecek kazaları tahmin etmektir. Burada meslektaşlarım ve ben genellikle kötü adamları oynarız. Bol bol kahve ve lezzetli bir şeyler alın ve kendinizi bir toplantı odasına kilitleyin. Aynı müzakerelerde, hedef hizmeti geliştiren veya onunla düzenli olarak çalışan mühendisleri de dahil ettiğinizden emin olun. Daha sonra, hizmetinizin başına gelebilecek tüm olası dehşetleri tahtaya veya kağıda çizmeye başlarsınız. Belirli bir temizlikçi kadına ve kabloların çekilmesine kadar detaya inmeye gerek yok, “Yerel ağın bütünlüğünün ihlali” senaryosunu dikkate almak yeterli.
Tipik olarak, çoğu tipik acil durum aşağıdaki türlere ayrılır:
- Ağ hatası
- İşletim sistemi hizmetleri hatası
- Uygulama hatası
- Demir arızası
- Sanallaştırma hatası
Her türe göz atın ve hizmetiniz için neyin geçerli olduğunu görün. Örneğin, Nginx arka plan programı düşebilir ve yükselmeyebilir - bu, işletim sistemi açısından arızalar anlamına gelir. Web uygulamanızın başarısız olmasına neden olan nadir bir durum, yazılım hatasıdır. Bu aşamada çalışırken sorunun teşhisini çözmek önemlidir. Örneğin, sanallaştırmada donmuş bir arayüzü düşmüş bir cis sürücüsünden ve bir ağ kazasından nasıl ayırt edebiliriz? Sorumluları hızlı bir şekilde bulmak ve kaza çözülene kadar kuyruklarını çekmeye başlamak önemlidir.
Tipik sorunlar yazıldıktan sonra, daha fazla kahve döküyoruz ve bazı parametrelerin normların çok ötesine geçmeye başladığı en tuhaf senaryoları düşünmeye başlıyoruz. Örneğin:
- Etkin düğümdeki zaman, kümedeki diğer düğümlere göre bir dakika geriye giderse ne olur?
- Peki ya zaman 10 yıl ileri giderse?
- Bir küme düğümü senkronizasyon sırasında aniden ağını kaybederse ne olur?
- Ağda birbirlerinin geçici olarak izolasyonu nedeniyle iki düğüm liderliği paylaşmazsa ne olacak?
Bu aşamada ters yaklaşım çok faydalıdır. Hasta bir hayal gücüne sahip ekibin en inatçı üyesini alıp ona mümkün olan en kısa sürede hizmeti çökertecek bir sabotaj düzenleme görevini veriyorsunuz. Teşhis etmek zorsa daha da iyidir. Mühendislere bir şeyi kırma fikri verirseniz ne kadar tuhaf ve harika fikirler bulduklarına inanamayacaksınız. Ve onlara bunun için bir test tezgahı vaat ederseniz, bu kesinlikle sorun değil.
Bu DRP nedir sizin?
Yani tehdit modelinizi tanımladınız. Ayrıca, bakır aramak için fiber optik kabloları kesen yerel sakinleri ve radyo aktarma hattını yalnızca Cuma günleri saat 16:46'da kesen askeri radarı da hesaba kattılar. Şimdi tüm bunlarla ne yapacağımızı anlamamız gerekiyor.
Göreviniz acil bir durumda açılacak olan o çok kırmızı zarfları yazmaktır. Her şey sona erdiğinde (olmazsa da!), yakınlarda yalnızca en deneyimsiz stajyerin olacağını ve olup bitenlerin dehşetinden elleri şiddetle titreyeceğini hemen bekleyin. Tıbbi ofislerde acil durum işaretlerinin nasıl uygulandığını görün. Örneğin anafilaktik şok durumunda ne yapılması gerektiği. Sağlık personeli tüm protokolleri ezbere bilir, ancak yakındaki bir kişi ölmeye başladığında, çoğu zaman herkes çaresizce görünürdeki her şeye tutunmaya çalışır. Bunun için duvarda “falan filanın paketini aç”, “şu kadar ilacı damardan ver” gibi net talimatlar var.
Acil bir durumda düşünmek zor! Omurilik ayrıştırma için basit talimatlar olmalıdır.
İyi bir DRP birkaç basit bloktan oluşur:
- Bir kazanın başlangıcı hakkında kime bilgi verilecek? Bu, eleme sürecinin mümkün olduğunca paralel hale getirilmesi açısından önemlidir.
- Doğru teşhis nasıl yapılır - bir izleme gerçekleştirin, systemctl status servicename vb.'ye bakın.
- Her aşamada ne kadar zaman harcayabilirsiniz? SLA süresi içinde sorunu manuel olarak düzeltmek için zamanınız yoksa sanal makine sonlandırılır ve dünkü yedeklemeden geri alınır.
- Kazanın bittiğinden nasıl emin olunur?
DRP'nin hizmet tamamen başarısız olduğunda başladığını ve verimlilik azalsa bile hizmet geri yüklendiğinde sona erdiğini unutmayın. Bir rezervasyonun kaybedilmesi DRP'yi tetiklememelidir. Ayrıca DRP'ye bir fincan çay da yazabilirsiniz. Cidden. İstatistiklere göre birçok kaza, personelin panik içinde bir şeyi düzeltmek için acele etmesi, aynı anda verilerle yaşayan tek düğümü öldürmesi veya sonunda kümeyi bitirmesi nedeniyle hoş olmayan bir durumdan felakete dönüşüyor. Kural olarak, bir fincan çayla geçireceğiniz 5 dakika size sakinleşmeniz ve olup biteni analiz etmeniz için biraz zaman tanıyacaktır.
DRP ile sistem pasaportunu karıştırmayın! Gereksiz verilerle aşırı yüklemeyin. Dokümantasyonun istenen bölümüne gitmek ve hizmet mimarisinin gerekli bölümleri hakkında genişletilmiş formatta okumak için köprüleri hızlı ve rahat bir şekilde kullanmayı mümkün kılın. Ve DRP'nin kendisinde yalnızca kopyala-yapıştır için belirli komutlarla nereye ve nasıl bağlanılacağına dair doğrudan talimatlar vardır.
Doğru test nasıl yapılır
Sorumlu herhangi bir çalışanın tüm öğeleri tamamlayabildiğinden emin olun. En önemli anda, mühendisin gerekli sisteme erişim haklarına sahip olmadığı, gerekli hesap için şifrelerin bulunmadığı veya "Hizmet yönetimi konsoluna bir proxy aracılığıyla bağlan" hakkında hiçbir fikrinin olmadığı ortaya çıkabilir. merkez ofis” anlamına gelir. Her nokta son derece basit olmalıdır.
Неправильно — “Sanallaştırmaya gidin ve ölü düğümü yeniden başlatın”
Doğru - “Web arayüzü üzerinden virt.example.com'a bağlanın, düğümler bölümünde hataya neden olan düğümü yeniden başlatın.”
Belirsizlikten kaçının. Korkmuş stajyeri hatırla.
DRP'yi test ettiğinizden emin olun. Bu sadece gösteriş amaçlı bir plan değil; sizin ve müşterilerinizin kritik bir durumdan hızla kurtulmanızı sağlayacak bir şeydir. Bunu birkaç kez yapmak en iyisidir:
- Bir uzman ve birkaç stajyer, gerçek bir hizmeti olabildiğince simüle eden bir test tezgahı üzerinde çalışıyor. Uzman, hizmeti çeşitli şekillerde keser ve kursiyerlerin hizmeti DRP'ye göre geri yüklemesini sağlar. Tüm sorunlar, dokümantasyondaki belirsizlikler ve hatalar kayıt altına alınır. Kursiyerlere eğitim verildikten sonra DRP, belirsiz alanlarda genişletilir ve basitleştirilir.
- Gerçek bir hizmet üzerinde test etme. Aslında hiçbir zaman gerçek bir hizmetin mükemmel bir kopyasını oluşturamazsınız. Bu nedenle, kurtarma sırasını değerlendirmek için yılda birkaç kez bazı sunucuları rutin olarak kapatmak, bağlantıları kesmek ve tehdit listesinden başka felaketlere neden olmak gerekir. Gece yarısı 10 dakikalık planlı bir arıza, veri kaybıyla birlikte yoğun yük sırasında birkaç saatlik ani bir arızadan daha iyidir.
- Gerçek sorun giderme. Evet, bu da testin bir parçası. Tehdit listesinde olmayan bir kaza meydana gelirse, soruşturmanın sonuçlarına göre DRP'nin tamamlanması ve sonuçlandırılması gerekir.
Anahtar noktaları
- Eğer bir bok olabilirse, bu yalnızca gerçekleşmeyecek, aynı zamanda mümkün olan en felaket senaryosunda gerçekleşecektir.
- Acil durum yük aktarımı için kaynaklara sahip olduğunuzdan emin olun.
- Yedeklemeleriniz olduğundan emin olun; bunlar otomatik olarak oluşturulur ve tutarlılık açısından düzenli olarak kontrol edilir.
- Tipik tehdit senaryolarını düşünün.
- Mühendislere, hizmeti sunmak için standart dışı seçenekler bulma fırsatı verin.
- DRP basit ve açık bir talimat olmalıdır. Tüm karmaşık teşhisler yalnızca müşterilerin hizmeti geri yüklendikten sonra gerçekleştirilir. Yedek kapasitede olsa bile.
- DRP'de önemli telefon numaralarını ve kişileri sağlayın.
- Çalışanların DRP'yi anlamalarını düzenli olarak test edin.
- Üretim sahalarında planlı kazalar düzenleyin. Standlar her şeyin yerini tutamaz.
Kaynak: habr.com