Պատկերացրեք՝ դուք սպասարկում եք մեծ առևտրի կենտրոնի ՏՏ ենթակառուցվածքը։ Քաղաքում անձրև է սկսվում։ Անձրևի հոսքերը ճեղքում են տանիքը, ջուրը լցվում է մանրածախ տարածքները մինչև կոճ: Հուսով ենք, որ ձեր սերվերի սենյակը նկուղում չէ, այլապես խնդիրներից հնարավոր չէ խուսափել:
Նկարագրված պատմությունը ֆանտազիա չէ, այլ 2020 թվականի մի քանի իրադարձությունների հավաքական նկարագրություն։ Խոշոր ընկերություններում այս դեպքի համար միշտ հասանելի է աղետի վերականգնման ծրագիր (DRP): Կորպորացիաներում դա բիզնեսի շարունակականության մասնագետների պարտականությունն է: Բայց միջին և փոքր ընկերություններում նման խնդիրների լուծումն ընկնում է ՏՏ ծառայությունների վրա։ Դուք ինքներդ պետք է հասկանաք բիզնեսի տրամաբանությունը, հասկանաք, թե ինչը կարող է ձախողվել և որտեղ, պաշտպանություն հորինեք և իրագործեք այն:
Հիանալի է, եթե ՏՏ մասնագետը կարողանա բանակցել բիզնեսի հետ և քննարկել պաշտպանության անհրաժեշտությունը: Բայց ես մեկ անգամ չէ, որ տեսել եմ, թե ինչպես է ընկերությունը խնայել աղետի վերականգնման (DR) լուծումը, քանի որ այն համարում էր ավելորդ: Երբ դժբախտ պատահար տեղի ունեցավ, երկար վերականգնումը սպառնում էր կորուստներով, և բիզնեսը պատրաստ չէր: Դուք կարող եք կրկնել այնքան, որքան ցանկանում եք. «Ես ասացի ձեզ», բայց ՏՏ ծառայությունը դեռ պետք է վերականգնի ծառայությունները:
Ճարտարապետի դիրքերից ես ձեզ կասեմ, թե ինչպես խուսափել այս իրավիճակից: Հոդվածի առաջին մասում ես ցույց կտամ նախապատրաստական աշխատանքը. ինչպես կարելի է հաճախորդի հետ քննարկել երեք հարց անվտանգության գործիքներ ընտրելու համար.
- Ի՞նչն ենք մենք պաշտպանում:
- Ինչի՞ց ենք մենք պաշտպանվում.
- Որքա՞ն ենք մենք պաշտպանում:
Երկրորդ մասում մենք կխոսենք հարցին պատասխանելու տարբերակների մասին՝ ինչպես պաշտպանվել: Ես կտամ դեպքերի օրինակներ, թե ինչպես են տարբեր հաճախորդներ կառուցում իրենց պաշտպանությունը:
Այն, ինչ մենք պաշտպանում ենք. բիզնեսի կարևոր գործառույթների բացահայտում
Ավելի լավ է սկսել նախապատրաստվել՝ գործարար հաճախորդի հետ քննարկելով հետհրատապ գործողությունների ծրագիրը: Այստեղ հիմնական դժվարությունը ընդհանուր լեզու գտնելն է։ Հաճախորդին սովորաբար չի հետաքրքրում, թե ինչպես է աշխատում ՏՏ լուծումը: Նրան հետաքրքրում է, թե արդյոք ծառայությունը կարող է բիզնես գործառույթներ կատարել և գումար բերել։ Օրինակ՝ եթե կայքը աշխատում է, բայց վճարային համակարգը խափանված է, հաճախորդներից եկամուտ չկա, իսկ «էքստրեմիստները» դեռ ՏՏ մասնագետներ են։
ՏՏ մասնագետը կարող է դժվարություններ ունենալ նման բանակցություններում մի քանի պատճառներով.
- ՏՏ ծառայությունը լիովին չի հասկանում տեղեկատվական համակարգի դերը բիզնեսում։ Օրինակ, եթե չկա բիզնես գործընթացների մատչելի նկարագրություն կամ թափանցիկ բիզնես մոդել:
- Ամբողջ գործընթացը կախված չէ ՏՏ ծառայությունից: Օրինակ, երբ աշխատանքների մի մասը կատարում են կապալառուները, իսկ ՏՏ մասնագետները նրանց վրա ուղղակի ազդեցություն չունեն։
Ես զրույցը կկառուցեի այսպես.
- Մենք բիզնեսին բացատրում ենք, որ դժբախտ պատահարները պատահում են բոլորի հետ, իսկ վերականգնումը ժամանակ է պահանջում: Լավագույնը իրավիճակների ցուցադրումն է, թե ինչպես է դա տեղի ունենում և ինչ հետևանքներ են հնարավոր:
- Մենք ցույց ենք տալիս, որ ամեն ինչ չէ, որ կախված է ՏՏ ծառայությունից, բայց դուք պատրաստ եք օգնել ձեր պատասխանատվության ոլորտում գործողությունների ծրագրին:
- Գործարար հաճախորդին խնդրում ենք պատասխանել՝ եթե ապոկալիպսիսը լինի, ո՞ր գործընթացը պետք է առաջինը վերականգնվի։ Ո՞վ և ինչպես է մասնակցում դրան:
Բիզնեսից պարզ պատասխան է պահանջվում, օրինակ՝ զանգերի կենտրոնը պետք է շարունակի դիմումների գրանցումը 24/7:
- Խնդրում ենք համակարգի մեկ կամ երկու օգտատերերի մանրամասն նկարագրել այս գործընթացը:
Ավելի լավ է ներգրավել վերլուծաբան, որը կօգնի, եթե ձեր ընկերությունն ունի այդպիսին:Սկզբից նկարագրությունը կարող է այսպիսի տեսք ունենալ. զանգերի կենտրոնը հարցումներ է ստանում հեռախոսով, փոստով և կայքի հաղորդագրությունների միջոցով: Այնուհետև նա վեբ ինտերֆեյսի միջոցով դրանք մուտքագրում է 1C, և արտադրությունն այս կերպ դրանք վերցնում է այնտեղից։
- Այնուհետև մենք նայում ենք, թե ինչ ապարատային և ծրագրային լուծումներ են աջակցում գործընթացին: Համապարփակ պաշտպանության համար մենք հաշվի ենք առնում երեք մակարդակ.
- հավելվածներ և համակարգեր կայքի ներսում (ծրագրային ապահովման մակարդակ),
- այն կայքը, որտեղ աշխատում են համակարգերը (ենթակառուցվածքի մակարդակ),
- ցանց (նրանք հաճախ մոռանում են դրա մասին):
- Մենք պարզում ենք ձախողման հնարավոր կետերը. համակարգի հանգույցներ, որոնցից կախված է ծառայության կատարումը: Մենք առանձին նշում ենք հանգույցներ, որոնք աջակցվում են այլ ընկերությունների կողմից՝ հեռահաղորդակցության օպերատորներ, հոսթինգ պրովայդերներ, տվյալների կենտրոններ և այլն: Դրանով դուք կարող եք վերադառնալ բիզնես հաճախորդին հաջորդ քայլի համար:
Ինչից ենք մենք պաշտպանում. ռիսկերից
Հաջորդը, մենք բիզնես հաճախորդից պարզում ենք, թե առաջին հերթին ինչ ռիսկերից ենք պաշտպանվում: Բոլոր ռիսկերը կարելի է բաժանել երկու խմբի.
- ժամանակի կորուստ ծառայության ընդհատման պատճառով;
- տվյալների կորուստ ֆիզիկական ազդեցությունների, մարդկային գործոնների և այլնի պատճառով:
Բիզնեսները վախենում են կորցնել և՛ տվյալները, և՛ ժամանակը՝ այս ամենը հանգեցնում է փողի կորստի: Այսպիսով, մենք կրկին հարցեր ենք տալիս յուրաքանչյուր ռիսկային խմբի համար.
- Այս գործընթացի համար կարո՞ղ ենք գնահատել, թե որքան գումար է ծախսում տվյալների կորուստը և ժամանակի կորուստը:
- Ի՞նչ տվյալներ չենք կարող կորցնել:
- Որտե՞ղ կարող ենք թույլ չտալ պարապուրդ:
- Ո՞ր իրադարձություններն են մեզ համար առավել հավանական և ամենավտանգավոր։
Քննարկումից հետո մենք կհասկանանք, թե ինչպես առաջնահերթություն տալ ձախողման կետերին:
Որքանով ենք մենք պաշտպանում. RPO և RTO
Երբ ձախողման կրիտիկական կետերը պարզ են, մենք հաշվարկում ենք RTO և RPO ցուցանիշները:
Ես հիշում եմ, որ RTO (վերականգնման ժամանակի նպատակ) — սա թույլատրելի ժամանակն է վթարի պահից մինչև ծառայության լրիվ վերականգնումը։ Բիզնեսի լեզվով ասած՝ սա ընդունելի պարապուրդ է: Եթե մենք իմանանք, թե որքան գումար է բերել գործընթացը, ապա կարող ենք հաշվարկել կորուստները ամեն րոպե պարապուրդից և հաշվարկել ընդունելի կորուստը:
RPO (վերականգնման կետի նպատակը) — տվյալների վերականգնման վավեր կետ: Այն որոշում է այն ժամանակը, որի ընթացքում մենք կարող ենք կորցնել տվյալները: Բիզնեսի տեսանկյունից տվյալների կորուստը կարող է հանգեցնել տուգանքների, օրինակ: Նման կորուստները կարող են նաև վերածվել փողի։
Վերականգնման ժամանակը պետք է հաշվարկվի վերջնական օգտագործողի համար՝ որքան ժամանակ նա կկարողանա մուտք գործել համակարգ: Այսպիսով, նախ մենք ավելացնում ենք շղթայի բոլոր օղակների վերականգնման ժամանակը: Այստեղ հաճախ սխալ է լինում. նրանք վերցնում են մատակարարի RTO-ն SLA-ից և մոռանում մնացած պայմանների մասին:
Եկեք նայենք կոնկրետ օրինակին: Օգտագործողը մուտք է գործում 1C, համակարգը բացվում է տվյալների բազայի սխալով: Նա կապվում է համակարգի ադմինիստրատորի հետ: Տվյալների բազան գտնվում է ամպի մեջ, համակարգի ադմինիստրատորը խնդրի մասին հայտնում է ծառայության մատակարարին: Ենթադրենք, բոլոր հաղորդակցությունները տևում են 15 րոպե: Ամպում այս չափի տվյալների բազան մեկ ժամից կվերականգնվի կրկնօրինակից, հետևաբար, ծառայության մատակարարի կողմից RTO-ն մեկ ժամ է: Բայց սա վերջնական վերջնաժամկետը չէ, օգտատիրոջ համար դրան ավելացվել է 15 րոպե՝ խնդիրը հայտնաբերելու համար:
Հաջորդը, համակարգի ադմինիստրատորը պետք է ստուգի, որ տվյալների բազան ճիշտ է, միացնել այն 1C-ին և սկսել ծառայությունները: Սա պահանջում է ևս մեկ ժամ, ինչը նշանակում է, որ ադմինիստրատորի կողմից RTO-ն արդեն 2 ժամ 15 րոպե է: Օգտատիրոջը պետք է ևս 15 րոպե՝ մուտք գործեք, ստուգեք, որ անհրաժեշտ գործարքները հայտնվել են։ 2 ժամ 30 րոպեն այս օրինակում ծառայության վերականգնման ընդհանուր ժամանակն է:
Այս հաշվարկները բիզնեսին ցույց կտան, թե արտաքին ինչ գործոններից է կախված վերականգնման ժամանակահատվածը: Օրինակ, եթե գրասենյակը հեղեղված է, նախ պետք է գտնել արտահոսքը և շտկել այն: Ժամանակ կպահանջվի, որը կախված չէ ՏՏ-ից։
Ինչպես ենք մենք պաշտպանում. տարբեր ռիսկերի համար գործիքներ ընտրելը
Բոլոր կետերը քննարկելուց հետո հաճախորդն արդեն հասկանում է դժբախտ պատահարի արժեքը բիզնեսի համար: Այժմ դուք կարող եք ընտրել գործիքներ և քննարկել բյուջեն: Օգտագործելով հաճախորդի գործերի օրինակներ՝ ես ձեզ ցույց կտամ, թե ինչ գործիքներ ենք մենք առաջարկում տարբեր խնդիրների համար:
Սկսենք ռիսկերի առաջին խմբից՝ սպասարկման ժամանակի պատճառով կորուստները: Այս խնդրի լուծումները պետք է ապահովեն լավ RTO:
- Տեղադրեք հավելվածը ամպի մեջ
Սկսելու համար, դուք կարող եք պարզապես տեղափոխվել ամպ. մատակարարն արդեն մտածել է բարձր հասանելիության խնդիրների մասին: Վիրտուալացման հոսթները հավաքվում են կլաստերի մեջ, էներգիան և ցանցը վերապահված են, տվյալները պահվում են անսարքության հանդուրժող պահեստավորման համակարգերում, և ծառայության մատակարարը ֆինանսապես պատասխանատու է պարապուրդի համար:
Օրինակ՝ դուք կարող եք ամպի մեջ տեղակայել տվյալների բազայով վիրտուալ մեքենա: Հավելվածը կմիանա տվյալների բազային արտաքինից՝ հաստատված ալիքի միջոցով կամ նույն ամպից: Եթե խնդիրներ առաջանան կլաստերի սերվերներից մեկի հետ, VM-ը կվերագործարկվի հարևան սերվերի վրա 2 րոպեից պակաս ժամանակում: Դրանից հետո դրանում կգործարկվի DBMS-ը, և մի քանի րոպեից տվյալների բազան հասանելի կդառնա:
RTO- նՉափված րոպեներով: Այս պայմանները կարող են նշվել մատակարարի հետ պայմանագրում:
ԱրժենալՄենք հաշվարկում ենք ամպային ռեսուրսների արժեքը ձեր հավելվածի համար:
Ինչից դա ձեզ չի պաշտպանիՊրովայդերի կայքում զանգվածային խափանումներից, օրինակ՝ քաղաքի մակարդակով դժբախտ պատահարների պատճառով: - Կլաստավորել հավելվածը
Եթե ցանկանում եք բարելավել RTO-ն, կարող եք ուժեղացնել նախորդ տարբերակը և անմիջապես տեղադրել կլաստերային հավելված ամպի մեջ:
Դուք կարող եք կլաստեր իրականացնել ակտիվ-պասիվ կամ ակտիվ-ակտիվ ռեժիմում: Մենք ստեղծում ենք մի քանի VM-ներ՝ հիմնվելով վաճառողի պահանջների վրա: Ավելի մեծ հուսալիության համար մենք դրանք բաշխում ենք տարբեր սերվերների և պահեստավորման համակարգերի վրա: Եթե տվյալների շտեմարաններից մեկով սերվերը ձախողվի, պահեստային հանգույցը վերցնում է բեռը մի քանի վայրկյանում:
RTO- նՉափված վայրկյաններով:
ԱրժենալՄի փոքր ավելի թանկ, քան սովորական ամպը, կլաստերավորման համար կպահանջվեն լրացուցիչ ռեսուրսներ:
Ինչից դա ձեզ չի պաշտպանիԴեռևս չի պաշտպանի տեղում հսկայական խափանումներից: Բայց տեղական խափանումներն այդքան երկար չեն տևի:ՊրակտիկայիցՄանրածախ առևտրային ընկերությունն ուներ մի քանի տեղեկատվական համակարգեր և կայքեր: Բոլոր տվյալների բազաները տեղակայվել են ընկերության գրասենյակում: Ոչ մի DR-ի մասին չէր մտածում, քանի դեռ գրասենյակը մի քանի անգամ անընդմեջ մնացել էր առանց հոսանքի։ Հաճախորդները դժգոհ էին կայքի խափանումներից:
Ծառայության հասանելիության հետ կապված խնդիրը լուծվել է ամպին անցնելուց հետո: Բացի այդ, մեզ հաջողվեց օպտիմիզացնել շտեմարանների բեռնվածությունը՝ հավասարակշռելով երթևեկությունը հանգույցների միջև: - Տեղափոխվեք աղետից պաշտպանված ամպ
Եթե Ձեզ անհրաժեշտ է ապահովել, որ նույնիսկ հիմնական կայքի բնական աղետը չի խանգարում ձեր աշխատանքին, կարող եք ընտրել աղետներին դիմացկուն ամպ: Այս տարբերակում մատակարարը տարածում է վիրտուալացման կլաստերը 2 տվյալների կենտրոններում: Անընդհատ սինխրոն կրկնօրինակումը տեղի է ունենում տվյալների կենտրոնների միջև՝ մեկ առ մեկ: Տվյալների կենտրոնների միջև ալիքները վերապահված են և անցնում են տարբեր երթուղիներով, ուստի նման կլաստերը չի վախենում ցանցի խնդիրներից:
RTO- նհակված է 0-ի:
ԱրժենալԱմենաթանկ ամպային տարբերակը:
Ինչից դա ձեզ չի պաշտպանիԴա չի օգնի տվյալների կոռուպցիայի դեմ, ինչպես նաև մարդկային գործոնի դեմ, ուստի խորհուրդ է տրվում միաժամանակ կրկնօրինակումներ կատարել:ՊրակտիկայիցՄեր հաճախորդներից մեկը մշակել է աղետների վերականգնման համապարփակ ծրագիր: Սա է նրա ընտրած ռազմավարությունը.
- Աղետներին հանդուրժող ամպը պաշտպանում է հավելվածը ենթակառուցվածքի մակարդակի խափանումներից:
- Երկաստիճան կրկնօրինակումն ապահովում է պաշտպանություն մարդկային սխալի դեպքում։ Պահուստավորման երկու տեսակ կա՝ «սառը» և «տաք»: «Սառը» կրկնօրինակը անջատված վիճակում է և ժամանակ է պահանջում տեղակայման համար: «Թեժ» կրկնօրինակն արդեն պատրաստ է օգտագործման և վերականգնվում է ավելի արագ: Այն պահվում է հատուկ հատուկ պահպանման համակարգում: Երրորդ օրինակը ձայնագրվում է ժապավենի վրա և պահվում մեկ այլ սենյակում:
Շաբաթը մեկ անգամ հաճախորդը ստուգում է պաշտպանությունը և ստուգում բոլոր կրկնօրինակների ֆունկցիոնալությունը, ներառյալ ժապավենից: Ամեն տարի ընկերությունը փորձարկում է աղետներին դիմակայող ամբողջ ամպը:
- Կազմակերպել կրկնօրինակումը մեկ այլ կայք
Մեկ այլ տարբերակ, թե ինչպես խուսափել հիմնական կայքի գլոբալ խնդիրներից. տրամադրել աշխարհառաքում: Այլ կերպ ասած, ստեղծեք պահեստային վիրտուալ մեքենաներ մեկ այլ քաղաքի կայքում: Դրա համար հարմար են DR-ի հատուկ լուծումները. մեր ընկերությունում մենք օգտագործում ենք VMware vCloud Availability (vCAV): Նրա օգնությամբ դուք կարող եք կարգավորել պաշտպանությունը ամպային մատակարարների մի քանի կայքերի միջև կամ վերականգնել ամպին ներքին կայքից: Ես արդեն ավելի մանրամասն խոսել եմ vCAV-ի հետ աշխատելու սխեմայի մասին .
RPO և RTO: 5 րոպեից:
Արժենալ: ավելի թանկ, քան առաջին տարբերակը, բայց ավելի էժան, քան ապարատային կրկնօրինակումը աղետից պաշտպանված ամպի մեջ: Գինը բաղկացած է vCAV լիցենզիայի արժեքից, վարչարարական վճարներից, ամպային ռեսուրսների արժեքից և պահուստային ռեսուրսներից՝ ըստ PAYG մոդելի (անջատված VM-ների աշխատանքային ռեսուրսների արժեքի 10%-ը):
ՊրակտիկայիցՀաճախորդը Մոսկվայի մեր ամպում պահում էր 6 վիրտուալ մեքենա տարբեր տվյալների բազաներով: Սկզբում պաշտպանությունն ապահովվում էր կրկնօրինակով. կրկնօրինակների մի մասը պահվում էր ամպի մեջ Մոսկվայում, իսկ մի մասը պահվում էր մեր Սանկտ Պետերբուրգի կայքում: Ժամանակի ընթացքում տվյալների բազաները մեծացան, և կրկնօրինակից վերականգնումը սկսեց ավելի շատ ժամանակ պահանջել:
Կրկնօրինակումներին ավելացվել է VMware vCloud Availability-ի վրա հիմնված կրկնօրինակումը: Վիրտուալ մեքենաների կրկնօրինակները պահվում են Սանկտ Պետերբուրգի պահեստային կայքում և թարմացվում են 5 րոպեն մեկ: Եթե հիմնական կայքում խափանում է տեղի ունենում, աշխատակիցներն ինքնուրույն անցնում են Սանկտ Պետերբուրգի վիրտուալ մեքենայի կրկնօրինակին և շարունակում են աշխատել դրա հետ:
Դիտարկված բոլոր լուծումներն ապահովում են բարձր հասանելիություն, սակայն չեն պաշտպանում տվյալների կորստից փրկագին վիրուսի կամ աշխատակիցների պատահական սխալի պատճառով: Այս դեպքում մեզ անհրաժեշտ կլինեն կրկնօրինակներ, որոնք կապահովեն պահանջվող RPO-ն:
5. Մի մոռացեք կրկնօրինակման մասին
Բոլորը գիտեն, որ դուք պետք է կրկնօրինակեք, նույնիսկ եթե ունեք աղետից պաշտպանված ամենաթեժ լուծումը: Այսպիսով, ես պարզապես հակիրճ կհիշեցնեմ ձեզ մի քանի կետերի մասին.
Խստորեն ասած, կրկնօրինակը DR չէ: Եվ ահա թե ինչու.
- Դա երկար ժամանակ է: Եթե տվյալները չափվում են տերաբայթերով, ապա վերականգնումը կտևի ավելի քան մեկ ժամ: Պետք է վերականգնել, նշանակել ցանց, ստուգել, որ այն միանում է, տես, որ տվյալները կարգին են։ Այսպիսով, դուք կարող եք ապահովել լավ RTO միայն այն դեպքում, եթե կան քիչ տվյալներ:
- Տվյալները կարող են չվերականգնվել առաջին անգամ, և դուք պետք է ժամանակ տրամադրեք գործողությունը կրկնելու համար: Օրինակ, կան դեպքեր, երբ մենք չգիտենք, թե կոնկրետ երբ են կորել տվյալները: Ենթադրենք կորուստը նկատվել է ժամը 15.00-ին, իսկ պատճեններն արվում են ամեն ժամ։ Ժամը 15.00-ից դիտում ենք վերականգնման բոլոր կետերը՝ 14:00, 13:00 և այլն: Եթե համակարգը կարևոր է, մենք փորձում ենք նվազագույնի հասցնել վերականգնման կետի տարիքը: Բայց եթե թարմ կրկնօրինակը չի պարունակում անհրաժեշտ տվյալներ, մենք վերցնում ենք հաջորդ կետը. սա լրացուցիչ ժամանակ է:
Այս դեպքում պահեստային ժամանակացույցը կարող է ապահովել պահանջվողը RPO. Պահուստավորման համար կարևոր է ապահովել աշխարհագրական ամրագրում հիմնական կայքի հետ կապված խնդիրների դեպքում: Խորհուրդ է տրվում առանձին պահել որոշ կրկնօրինակներ:
Աղետի վերականգնման վերջնական պլանը պետք է պարունակի առնվազն 2 գործիք.
- 1-4 տարբերակներից մեկը, որը կպաշտպանի համակարգերը խափանումներից և անկումից:
- Պահուստավորում՝ տվյալների կորստից պաշտպանելու համար:
Արժե նաև հոգ տանել կապի պահուստային ալիքի մասին, եթե հիմնական ինտերնետ պրովայդերն անջատվի: Եվ - voila! — Նվազագույն աշխատավարձով DR-ն արդեն պատրաստ է։
Source: www.habr.com