Нека поне наводнение, но 1C трябва да работи! Преговори с бизнеса относно DR

Представете си: вие обслужвате ИТ инфраструктурата на голям търговски център. В града започва да вали. Потоци дъжд пробиват покрива, вода изпълва търговските помещения до глезените. Надяваме се, че вашето сървърно помещение не е в сутерена, в противен случай проблемите не могат да бъдат избегнати.  

Описаната история не е фантазия, а сборно описание на няколко събития от 2020 г. В големите компании планът за възстановяване след бедствие или планът за възстановяване след бедствие (DRP) винаги е под ръка за този случай. В корпорациите това е отговорност на специалистите по непрекъснатост на бизнеса. Но в средните и малките компании решаването на подобни проблеми пада върху ИТ услугите. Трябва сами да разберете бизнес логиката, да разберете какво може да се провали и къде, да измислите защита и да я приложите. 

Чудесно е, ако ИТ специалист може да преговаря с бизнеса и да обсъди необходимостта от защита. Но съм виждал повече от веднъж как една компания пести от решение за възстановяване след бедствие (DR), защото го смята за излишно. Когато се случи инцидент, дългото възстановяване застрашаваше загуби и бизнесът не беше готов. Можете да повтаряте колкото искате: „Казах ви“, но ИТ услугата все пак ще трябва да възстанови услугите.

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

• Какво защитаваме?
• От какво се предпазваме?
• Колко защитаваме? 

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

Какво защитаваме: идентифициране на критични бизнес функции 

По-добре е да започнете подготовката, като обсъдите плана за действие след извънредна ситуация с бизнес клиента. Основната трудност тук е намирането на общ език. Клиентът обикновено не се интересува как работи ИТ решението. Той се интересува дали услугата може да изпълнява бизнес функции и да носи пари. Например: ако сайтът работи, но платежната система не работи, няма приходи от клиенти и „екстремистите“ все още са IT специалисти. 

ИТ специалист може да има трудности при такива преговори поради няколко причини:

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

Бих структурирал разговора така: 

1. Ние обясняваме на бизнеса, че злополуките се случват на всеки и възстановяването отнема време. Най-доброто нещо е да демонстрирате ситуации, как се случва това и какви последствия са възможни.
2. Показваме, че не всичко зависи от ИТ услугата, но вие сте готови да помогнете с план за действие във вашата зона на отговорност.
3. Молим бизнес клиента да отговори: ако апокалипсисът се случи, кой процес трябва да се възстанови първо? Кой и как участва в него? 

   От бизнеса се изисква прост отговор, например: кол центърът трябва да продължи да регистрира приложения 24/7.

4. Молим един или двама потребители на системата да опишат подробно този процес. 
   По-добре е да включите анализатор за помощ, ако вашата компания разполага с такъв.

   Като начало описанието може да изглежда така: кол центърът получава заявки по телефона, по пощата и чрез съобщения от уебсайта. След това той ги въвежда в 1C чрез уеб интерфейса и производството ги взема оттам по този начин.

5. След това разглеждаме какви хардуерни и софтуерни решения поддържат процеса. За цялостна защита ние вземаме предвид три нива: 
   • приложения и системи в сайта (софтуерно ниво),   
   • самият сайт, където работят системите (ниво на инфраструктурата), 
   • мрежа (те често забравят за това).

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

От какво се предпазваме: рискове

След това разбираме от бизнес клиента от какви рискове първо се защитаваме. Всички рискове могат да бъдат разделени на две групи: 

• загуба на време поради прекъсване на услугата;
• загуба на данни поради физически въздействия, човешки фактор и др.

Бизнесът се страхува от загуба на данни и време - всичко това води до загуба на пари. Затова отново задаваме въпроси за всяка рискова група: 

• За този процес, можем ли да преценим колко пари струва загубата на данни и загубата на време? 
• Какви данни не можем да загубим? 
• Къде не можем да допуснем престой? 
• Кои събития са най-вероятни и най-заплашителни за нас?

След обсъждане ще разберем как да приоритизираме точките на провал. 

Колко защитаваме: RPO и RTO 

Когато критичните точки на повреда са ясни, изчисляваме индикаторите RTO и RPO. 

Спомням си, че RTO (обективно време за възстановяване) — това е допустимото време от момента на аварията до пълното възстановяване на услугата. На бизнес език това е приемлив престой. Ако знаем колко пари е донесъл процесът, можем да изчислим загубите от всяка минута престой и да изчислим приемливата загуба. 

RPO (обективна точка на възстановяване) — валидна точка за възстановяване на данни. Той определя времето, през което можем да загубим данни. От бизнес гледна точка загубата на данни може да доведе до глоби, например. Такива загуби също могат да бъдат превърнати в пари. 

Времето за възстановяване трябва да се изчисли за крайния потребител: колко време ще може да влезе в системата. Затова първо събираме времето за възстановяване на всички звена във веригата. Тук често се прави грешка: те вземат RTO на доставчика от SLA и забравят за останалите условия.

Нека да разгледаме конкретен пример. Потребителят влиза в 1C, системата се отваря с грешка в базата данни. Той се свързва със системния администратор. Базата данни се намира в облака, системният администратор съобщава за проблема на доставчика на услугата. Да кажем, че всички комуникации отнемат 15 минути. В облака база данни с такъв размер ще бъде възстановена от резервно копие за един час, следователно RTO от страна на доставчика на услуги е един час. Но това не е крайният срок, за потребителя са добавени 15 минути за откриване на проблема. 
 
След това системният администратор трябва да провери дали базата данни е правилна, да я свърже с 1C и да стартира услугите. Това изисква още един час, което означава, че RTO от страна на администратора вече е 2 часа и 15 минути. Потребителят се нуждае от още 15 минути: влезте, проверете дали са се появили необходимите транзакции. 2 часа и 30 минути е общото време за възстановяване на услугата в този пример.

Тези изчисления ще покажат на бизнеса от какви външни фактори зависи периодът на възстановяване. Например, ако офисът е наводнен, първо трябва да откриете теча и да го отстраните. Ще отнеме време, което не зависи от ИТ.  

Как се защитаваме: избор на инструменти за различни рискове

След обсъждане на всички точки, клиентът вече разбира цената на инцидента за бизнеса. Сега можете да изберете инструменти и да обсъдите бюджета. Използвайки примери за клиентски случаи, ще ви покажа какви инструменти предлагаме за различни задачи. 

Да започнем с първата група рискове: загуби поради прекъсване на услугата. Решенията за този проблем трябва да осигурят добър RTO.

1. Хоствайте приложението в облака 

   Като начало можете просто да се преместите в облака - доставчикът вече е обмислил проблемите с високата достъпност. Хостовете за виртуализация се сглобяват в клъстер, захранването и мрежата са запазени, данните се съхраняват на системи за съхранение, устойчиви на грешки, а доставчикът на услугата е финансово отговорен за прекъсване.

   Например, можете да хоствате виртуална машина с база данни в облака. Приложението ще се свърже с базата данни външно чрез установен канал или от същия облак. Ако възникнат проблеми с един от сървърите в клъстера, VM ще се рестартира на съседния сървър за по-малко от 2 минути. След това СУБД ще стартира в него и след няколко минути базата данни ще стане достъпна.

   OTR: измерено в минути. Тези условия могат да бъдат посочени в споразумението с доставчика.
   Цена: Ние изчисляваме цената на облачните ресурси за вашето приложение. 
   От какво няма да ви защити: от масивни повреди на сайта на доставчика, например поради аварии на ниво град.

2. Групирайте приложението  

   Ако искате да подобрите RTO, можете да подсилите предишната опция и незабавно да поставите клъстерно приложение в облака.

   Можете да внедрите клъстер в режим активно-пасивен или активно-активен. Създаваме няколко виртуални машини въз основа на изискванията на доставчика. За по-голяма надеждност ги разпространяваме между различни сървъри и системи за съхранение. Ако сървърът с една от базите данни се повреди, резервният възел поема натоварването за няколко секунди.

   OTR: Измерено в секунди.
   Цена: малко по-скъп от обикновен облак, ще са необходими допълнителни ресурси за клъстериране.
   От какво няма да ви защити: Все още няма да защити срещу масивни повреди на място. Но местните смущения няма да продължат толкова дълго.

   От практиката: Компанията за търговия на дребно имаше няколко информационни системи и уебсайтове. Всички бази данни се намираха локално в офиса на компанията. Не се мислеше за DR, докато офисът не беше оставен без ток няколко пъти подред. Клиентите бяха недоволни от сривовете на уебсайта. 
    
   Проблемът с наличността на услугата беше разрешен след преместване в облака. Освен това успяхме да оптимизираме натоварването на базите данни чрез балансиране на трафика между възлите.

3. Преминете към устойчив на бедствия облак

   Ако трябва да гарантирате, че работата няма да бъде прекъсната дори от природно бедствие на основния сайт, можете да изберете устойчив на бедствия облак.В тази опция доставчикът разпространява клъстера за виртуализация в 2 центъра за данни. Между центровете за данни се осъществява постоянна синхронна репликация, едно към едно. Каналите между центровете за данни са резервирани и преминават по различни маршрути, така че такъв клъстер не се страхува от мрежови проблеми. 

   OTR: клони към 0.
   Цена: Най-скъпата облачна опция. 
   От какво няма да ви защити: Няма да помогне срещу повреда на данните, както и от човешкия фактор, така че се препоръчва да правите резервни копия едновременно. 

   От практиката: Един от нашите клиенти разработи цялостен план за възстановяване след бедствие. Това е стратегията, която той избра: 

   • Устойчив на бедствия облак защитава приложението от повреди на ниво инфраструктура. 
   • Архивирането на две нива осигурява защита в случай на човешка грешка. Има два вида архивиране: „студено“ и „горещо“. „Студеното“ архивиране е в дезактивирано състояние и отнема време за внедряване. „Горещият“ архив вече е готов за използване и се възстановява по-бързо. Съхранява се в специално предназначена система за съхранение. Третото копие се записва на касета и се съхранява в друга стая. 

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

4. Организирайте репликация към друг сайт 

   Друг вариант как да избегнете глобални проблеми на основния сайт: осигурете гео-резервация. С други думи, създайте резервни виртуални машини на сайт в друг град. За това са подходящи специални решения за DR: в нашата компания използваме VMware vCloud Availability (vCAV). С негова помощ можете да конфигурирате защита между няколко сайта на облачни доставчици или да възстановите в облака от локален сайт. Вече говорих по-подробно за схемата за работа с vCAV тук. 

   RPO и RTO: от 5 минути. 

   Цена: по-скъп от първия вариант, но по-евтин от хардуерна репликация в защитен от бедствия облак. Цената се състои от стойността на vCAV лиценз, административните такси, цената на облачните ресурси и резервните ресурси по модела PAYG (10% от цената на работещите ресурси за изключени VM).

   От практиката: Клиентът поддържаше 6 виртуални машини с различни бази данни в нашия облак в Москва. Първоначално защитата беше осигурена чрез резервно копие: някои от резервните копия бяха съхранени в облака в Москва, а някои бяха съхранени на нашия сайт в Санкт Петербург. С течение на времето базите данни нараснаха по размер и възстановяването от резервно копие започна да отнема повече време. 
    
   Репликацията, базирана на наличността на VMware vCloud, беше добавена към архивите. Реплики на виртуални машини се съхраняват на резервен сайт в Санкт Петербург и се актуализират на всеки 5 минути. Ако възникне повреда на основния сайт, служителите самостоятелно преминават към реплика на виртуалната машина в Санкт Петербург и продължават да работят с нея. 

Всички разгледани решения осигуряват висока достъпност, но не предпазват от загуба на данни поради вирус на ransomware или случайна грешка на служител. В този случай ще ни трябват резервни копия, които ще осигурят необходимия RPO.

5. Не забравяйте за архивирането

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

Строго погледнато, архивирането не е DR. И ето защо: 

• Това е много време. Ако данните се измерват в терабайти, възстановяването ще отнеме повече от един час. Трябва да възстановите, да зададете мрежа, да проверите дали се включва, да видите дали данните са в ред. Така че можете да предоставите добър RTO само ако има малко данни. 
• Данните може да не бъдат възстановени от първия път и трябва да отделите време за повторение на действието. Например, има моменти, когато не знаем точно кога данните са били загубени. Да кажем, че загубата е забелязана в 15.00 часа, а копия се правят на всеки час. От 15.00 часа разглеждаме всички точки за възстановяване: 14:00, 13:00 и така нататък. Ако системата е важна, ние се опитваме да сведем до минимум възрастта на точката за възстановяване. Но ако новото архивиране не съдържа необходимите данни, вземаме следващата точка - това е допълнително време. 

В този случай графикът за архивиране може да осигури необходимото RPO. За резервни копия е важно да осигурите гео-резервация в случай на проблеми с основния сайт. Препоръчва се някои резервни копия да се съхраняват отделно.

Окончателният план за възстановяване след бедствие трябва да съдържа поне 2 инструмента:  

• Един от вариантите 1-4, който ще защити системите от повреди и падания.
• Архивиране за защита на данните от загуба. 

Също така си струва да се погрижите за резервен комуникационен канал, в случай че основният интернет доставчик се срине. И – готово! — DR на минимални заплати вече е готов. 

Източник: www.habr.com