Как се провежда успешен Disaster Recovery тест

Все повече компании заявяват, че разполагат с Disaster Recovery план в случаи на бедствия, аварии и непредвидени обстоятелства. Най-често срещаната грешка обаче е, че подготовката спира дотук - с план, който трябва да действа, на теория.

DR планове, които никога не са тествани, не могат да докажат реалната стойност и ползите за бизнеса. Сред рисковете са възможност различни достъпи да са изтекли, конкретни отговорни за изпълнението хора да не работят в компанията или пък стъпките в плана да са остарели и неприложими към операциите в компанията към днешна дата. 

Най-често организациите откриват подобни пропуски в най-неподходящия момент, точно когато Disaster Recovery планът трябва да се приложи при реален инцидент. 

В статията ни споделяме съветите на ИТ експертите от AbsCloud как да проведете ефективен DR тест, който наистина ще ви покаже подготвена ли е ИТ инфраструктурата ви за извънредни ситуации. 

Защо DR тестовете често се избягват или отлагат

По подобие на профилактиката в много различни аспекти, редовният одит и тестването на DR плановете често се отлага или пренебрегва от бизнесите. Основни аргументи за това са:

• Несигурност какво ще се случи при прекъсването: Тестването на DR план може да изглежда като риск от умишлено прекъсване на работещи системи. А при неправилно планиране на процесите и тестовете, проблемът става напълно реален. Ако описаното важи и за вашата организация, вече имате ясна индикация за потенциален пропуск в disaster recovery стратегията си. 
• Отговорните лица вярват, че всичко работи нормално: Ако backup-ите се правят редовно и процедурите са разписани, хората приемат, че всичко е наред. Ако обаче нищо от това не е тествано, работите единствено с хипотези. 
• Липса на ресурс и приоритизация: DR тестовете могат да изискват немалък ресурс за планиране, координация и изпълнение. Обикновено компаниите приоритизират оперативните процеси и по-рядко отделят нужното внимание на стратегиите за сигурност и резервираност.  
• Липса на регулаторни изисквания за някои сектори: Не всяка организация попада под най-строгите изисквания, свързани с киберсигурност, защита на данните, резервираност, наличност и достъпност. Когато не са подложени на регулаторен натиск, някои компании отлагат или напълно пренебрегват добрите практики за защита на своя бизнес, операции и клиенти. Прочетете и още по темата в статията ни за NIS2 и Новите изисквания за киберсигурност.

Последствията от подобни решения обикновено водят до сходни сценарии, при които компаниите осъзнават своите грешки и пропуски именно когато всичко трябва да е налично и да работи според очакванията, макар да не е тествано своевременно.

Още по темата от нашия екип: По какво си приличат авиацията и управлението на ИТ инфраструктурата и защо всичко се проверява отново и отново дори когато работи безпроблемно

Видове Disaster Recovery тестове

DR тестването не представлява едно конкретно и еднократно действие, а комбинация от подходи с цел да се провери готовността на бизнеса са реакция или проактитвност в различни ситуации. Такива тестове е добре да планирате регулярно, както и след значителна промяна в ИТ инфраструктурата, миграция към нов доставчик или дейта център, промяна на ключов персонал или при актуализация на архитектурата на приложенията. 

Tabletop Exercise

Когато става въпрос за киберсигурност, това е процес, при който отговорните лица в екипа се събират заедно и преговарят конкретни стъпки при различни сценарии (какво става, ако сървърът с базата данни се повреди в почивен ден; как действаме, ако центърът за данни е засегнат от природно бедствие; и т.н.). 

Възможно е с изненада да установите, че в документирания план вече има съществени пропуски: остарели процедури, зависимости между системите, зависимост от определени хора, неяснота на процесите и др.   

Препоръка от AbsCloud: Провеждайте този тип тестове поне веднъж или два пъти годишно, за да установите най-очевидните несъответствия на DR плана спрямо текущата готовност компанията да го приложи.   

Walk-through тест (Проверка на документацията)

Това е още по-детайлен вариант на tabletop exercise, при който изяснявате не само какво се случва във всеки един момент, а дали то наистина ще сработи. Тук трябва да проверите дали необходимите данни за достъпи са налични и актуални, дали архивните копия наистина съществуват и са готови за ползване, дали контактите за спешни ситуации са коректни и т.н.

Все още не преминавате към реално тестване на целия процес, но валидирате допълнително дали при всяка стъпка съответният документ, ресурс или контакт ще бъде налице. Можете да извършвате walk-through тестовете паралелно с всеки tabletop exercise, който провеждате. 

Simulation тест / технически тест

При подобен тест проверявате конкретни технически компоненти от DR плана, без напълно да прекъсвате реалната работа на системите. Можете да проверите в изолирана среда как сработва възстановяването на архивно копие, какво се случва при срив на конкретна база данни, дали дадена система се възстановява в предвиденото време (RTO) и т.н. 

Обикновено при подобни тестове разбирате дали наистина разполагате с backup, който можете да възстановите успешно и своевременно. 

Тест в паралелна среда

Това е най-пълният тест, който можете да направите без да засягате реалните операции на бизнеса. При него активирате паралелна среда, в която симулирате натоварването и провеждате DR тест на системите и процесите без риск. Този вариант обаче изисква допълнителни ресурси, тъй като, на практика, дублирате production средата и натоварването към нея.

При този тест можете да откриете проблеми с капацитета, конфигурацията и други, които на теория или според документацията изглеждат наред, но не се проверяват регулярно.

Full failover тест (Пълен тест)

При този тип тест вече изпращате реален трафик към DR средата за определен период от време. Това е моментът, в който разбирате дали disaster recovery планът наистина работи изцяло, тъй като подлагате системите на реално натоварване, тествате интеграциите, както и поведението на потребителите след превключване към алтернативната среда. 

Ако планирате подобен тип тест, имайте предвид, че от значение е всеки детайл, комуникация към засегнатите страни, както и планът ви за мигновено връщане към основната среда. Препоръчва се системи с висока критичност да преминават full failover тест поне веднъж годишно, като част от планирана поддръжка. 

Какво трябва да съдържа един Disaster Recovery план

Повечето DR тестове включват няколко основни стъпки:

• Дефиниране на сценария: Определяте какъв тип инцидент ще бъде симулиран (пълна загуба на достъп до уеб сайт, отказ на конкретна система, изтичане или кражба на данни, ransomware атака, природно бедствие и др.). В сценария трябва да опишете реалистично и конкретно какво се случва и какво трябва да проверите. 
• Обхват на засегнатите системи и процеси: Различните сценарии вероятно ще подложат на тест различни системи и процеси. Добре е да сте наясно и да документирате кои от тях са обект на всеки един DR тест. 
• RTO и RPO цели: Трябва да подхождате към всеки тест с яснота точно колко време можете да си позволите да загубите (recovery time objective) и точно колко данни можете да си позволите да загубите (recovery point objective) при евентуален инцидент. Само така можете да измерите дали тестът е успешен и бизнесът ви е подготвен. 
• Роли, отговорности и комуникация: Документирайте ясно кой отговаря за провеждането на теста, комуникация към засегнатите екипи и клиенти и решението в кой момент да се преустановят (rollback) или завършат дейностите.  
• Rollback план: При негативно развитие на теста трябва да се върнете към нормална работа възможно най-бързо и безпроблемно. Уверете се, че необходимите стъпки са известни и планирани предварително и участниците в теста знаят точно в кой момент този план ще се задейства.
• Документиране на резултатите: Без значение дали ще се установят пропуски, всяка стъпка и резултат от теста трябва да бъдат документирани. 

Какво най-често откриват компаниите при Disaster Recovery тест?

Организациите, които провеждат DR тестове (особено по-рядко или за първи път), в много случаи установяват с изненада, че:

• Бекъпите са налични, но не могат да бъдат възстановени бързо и лесно;
• RTO/RPO целите се разминават с реално постижимите;
• Липсват или не са документирани достъпи до файлове, данни и директории; 
• Има неустановени зависимости между системи или екипи;
• Комуникационният план и разпределението на ролите липсват или са остарели.

Ролята на дейта центъра при тестването

Една от предпоставките за смислен Disaster Recovery тест е изборът на правилната локация, достатъчно отдалечена географски от основната. По този начин бизнесът ви разполага с алтернатива дори когато инциденти засегнат физическата ви инфраструктура и свързаност. Два отделни сървъра в един офис или дейта център не гарантират Disaster Recovery в пълния смисъл, а по-скоро представляват локална резервираност.  

AbsCloud Data Center (AC☁DC) функционира именно като Disaster Recovery точка за компании от цяла България и, най-вече, за такива, чиято основна инфраструктура е в гр.София и западната част на страната. 

Научете повече за Disaster Recovery услугата в AC☁DC

Центърът ни за данни предлага и Remote Hands & Eyes услуга, която може да улесни екипа ви при стъпки от DR теста, като активиране на оборудване, проверка на свързаност или друга физическа намеса, която може да се извърши от ИТ специалистите ни по ваши инструкции, без да е необходимо да изпращате служител на DR локацията. При реална авария подобна опция може да се окаже критична за бизнеса ви.

Ако търсите подходяща Disaster Recovery локация за своя бизнес или планирате DR тест и се нуждаете от консултация, свържете се с екипа ни още днес. Ще отговорим на въпросите ви и ще ви помогнем да тествате и валидирате готовността на инфраструктурата и бизнеса ви за реакция и възстановяване при всички възможни сценарии

Свържете се с нас

---

Интересувате се от колокация на сървъри или други услуги? Свържете се с екипа ни още сега.

Име и фамилия (задължително)

Имейл (задължително)

Запитване (задължително)

Телефон