Նույնիսկ աղետի ժամանակ միշտ ժամանակ կա մի բաժակ թեյի համար:
DRP (աղետների վերականգնման ծրագիր) մի բան է, որը իդեալականորեն երբեք կարիք չի լինի: Բայց եթե հանկարծ զուգավորման սեզոնի ընթացքում արտագաղթող կավերը կրծում են հիմնական օպտիկական մանրաթելը կամ կրտսեր ադմինը գցում է արտադրողական բազան, դուք անպայման ուզում եք վստահ լինել, որ նախապես կազմված ծրագիր կունենաք, թե ինչ անել այս ամբողջ խայտառակության հետ:
Մինչ խուճապի մատնված հաճախորդները սկսում են զանգահարել տեխնիկական աջակցություն, կրտսերը ցիանիդ է փնտրում, դու խելամտորեն բացում ես կարմիր ծրարը և սկսում ամեն ինչ կարգի բերել:
Այս գրառման մեջ ես ուզում եմ կիսվել առաջարկություններով, թե ինչպես գրել DRP և ինչ պետք է պարունակի այն: Մենք նաև կանդրադառնանք հետևյալին.
- Սովորեք մտածել չարագործի պես:
- Եկեք վերլուծենք մեկ բաժակ թեյի առավելությունները ապոկալիպսիսի ժամանակ:
- Մտածեք հարմար DRP կառուցվածքի մասին
- Տեսնենք, թե ինչպես փորձարկել այն
Ո՞ր ընկերությունները կարող են օգուտ քաղել դրանից:
Շատ դժվար է գիծ քաշել, երբ ՏՏ բաժինը սկսում է այս բաների կարիքը ունենալ։ Ես կասեի, որ ձեզ երաշխավորված է DRP-ի կարիք, եթե.
- Սերվերի, հավելվածի դադարեցումը կամ տվյալների բազայի կորուստը կհանգեցնի զգալի կորուստների ամբողջ բիզնեսի համար:
- Դուք ունեք լիարժեք ՏՏ բաժին։ Ես նկատի ունեմ մի բաժին՝ որպես ընկերության լիարժեք միավոր՝ իր բյուջեով, և ոչ միայն մի քանի հոգնած աշխատակիցների, որոնք ցանց են դնում, մաքրում են վիրուսները և լիցքավորում տպիչներ։
- Դուք ունեք իրատեսական բյուջե՝ արտակարգ իրավիճակների դեպքում գոնե մասնակի կրճատման համար:
Երբ ՏՏ բաժինը ամիսներ շարունակ աղաչում է հին սերվերի համար առնվազն մի քանի HDD սկավառակներ կրկնօրինակման համար, դուք դժվար թե կարողանաք կազմակերպել ընկած ծառայության ամբողջական տեղափոխումը պահեստային հզորություններին: Չնայած այստեղ էլ փաստաթղթավորումն ավելորդ չի լինի։
Փաստաթղթերը կարևոր են
Սկսեք փաստաթղթերից: Ենթադրենք, որ ձեր ծառայությունն աշխատում է Perl script-ով, որը գրվել է ադմինների երեք սերունդ առաջ, և ոչ ոք չգիտի, թե ինչպես է այն աշխատում: Կուտակված տեխնիկական պարտքն ու փաստաթղթերի բացակայությունն անխուսափելիորեն կրակելու են ոչ միայն ծնկի, այլ նաև այլ վերջույթների վրա, դա ավելի շուտ ժամանակի հարց է։
Երբ ձեռքի տակ ունենաք ծառայության բաղադրիչների լավ նկարագրությունը, բարձրացրեք վթարի վիճակագրությունը: Գրեթե անկասկած, դրանք լիովին բնորոշ կլինեն։ Օրինակ, դուք ժամանակ առ ժամանակ լիքը սկավառակ ունեք, ինչը հանգեցնում է հանգույցի ձախողման, մինչև այն ձեռքով մաքրվի: Կամ հաճախորդների սպասարկումն անհասանելի է դառնում այն պատճառով, որ ինչ-որ մեկը կրկին մոռացել է թարմացնել վկայագիրը, բայց նա չկարողացավ կամ չցանկացավ կարգավորել Let's Encrypt-ը:
Դիվերսանտի նման մտքեր
Ամենադժվարը այն դժբախտ պատահարների կանխատեսումն է, որոնք նախկինում երբեք չեն եղել, բայց որոնք կարող են իսպառ փչացնել ձեր ծառայությունը: Այստեղ մենք սովորաբար չարագործներ ենք խաղում գործընկերների հետ: Խմեք շատ սուրճ և ինչ-որ համեղ բան և փակվեք հանդիպման սենյակում: Պարզապես համոզվեք, որ նույն հանդիպման ժամանակ դուք արգելափակել եք այն ինժեներներին, ովքեր իրենք են բարձրացրել թիրախային ծառայությունը կամ պարբերաբար աշխատել դրա հետ: Այնուհետև, կա՛մ գրատախտակին, կա՛մ թղթի վրա, դուք սկսում եք նկարել բոլոր հնարավոր սարսափները, որոնք կարող են պատահել ձեր ծառայության հետ: Պետք չէ մանրամասնել կոնկրետ հավաքարարուհուն և մալուխներ հանել, բավական է դիտարկել «Տեղական ցանցի ամբողջականության խախտում» սցենարը։
Սովորաբար, շատ բնորոշ արտակարգ իրավիճակներ տեղավորվում են հետևյալ տեսակների մեջ.
- Ցանցի ձախողում
- OS ծառայության ձախողում
- Դիմումի ձախողում
- երկաթի ձախողում
- Վիրտուալացման ձախողում
Պարզապես անցեք յուրաքանչյուր տեսք և տեսեք, թե ինչ է վերաբերում ձեր ծառայությանը: Օրինակ, Nginx daemon-ը կարող է ընկնել և չբարձրանալ. սա ՕՀ-ի ձախողում է: Հազվագյուտ իրավիճակ, որը բերում է ձեր վեբ հավելվածը ոչ աշխատանքային վիճակի, ծրագրային ապահովման ձախողումն է: Այս փուլի զարգացման ընթացքում կարևոր է մշակել խնդրի ախտորոշումը։ Ինչպես տարբերակել կախված ինտերֆեյսը վիրտուալացման վրա ընկած cisco-ից և ցանցի խափանումից, օրինակ: Սա կարևոր է, որպեսզի արագ գտնեք պատասխանատուներին և սկսեք քաշել նրանց պոչը մինչև վթարը շտկվի:
Տիպիկ խնդիրները գրվելուց հետո մենք ավելի շատ սուրճ ենք լցնում և սկսում դիտարկել ամենատարօրինակ սցենարները, երբ որոշ պարամետրեր սկսում են դուրս գալ նորմայից: Օրինակ:
- Ի՞նչ է պատահում, եթե ակտիվ հանգույցի վրա ժամանակը մեկ րոպեով հետ է շարժվում կլաստերի մյուսների համեմատ:
- Իսկ եթե ժամանակն առաջ գնա, և եթե 10 տարով.
- Ի՞նչ է պատահում, եթե համաժամացման ընթացքում կլաստերի հանգույցը հանկարծ կորցնի ցանցը:
- Իսկ ի՞նչ է տեղի ունենում, եթե երկու հանգույցները չեն կիսում առաջնորդությունը ցանցում միմյանց ժամանակավոր մեկուսացման պատճառով:
Այս փուլում հակադարձ մոտեցումը շատ է օգնում։ Վերցրեք հիվանդ երևակայությամբ թիմի ամենահամառ անդամին և հանձնարարեք նրան հնարավորինս կարճ ժամանակում դիվերսիա կազմակերպել, որը կխափանի ծառայությունը: Եթե դժվար է ախտորոշել, նույնիսկ ավելի լավ։ Դուք չեք հավատա այն տարօրինակ և զով մտքերին, որոնք ինժեներների մոտ առաջանում է, երբ ինչ-որ բան կոտրելու գաղափար են տալիս: Եվ եթե դուք խոստանում եք նրանց փորձարկման ստենդ դրա համար, դա շատ լավ է:
Ո՞րն է ձեր այս DRP-ն:
Այսպիսով, դուք սահմանել եք սպառնալիքի մոդելը: Նրանք նաև հաշվի են առել տեղի բնակիչներին, ովքեր կտրում են օպտիկամանրաթելային մալուխները՝ պղնձի որոնման համար, և ռազմական ռադարը, որը խստորեն անջատում է ռադիոռելեի գիծը ուրբաթ օրերին, ժամը 16:46-ին: Այժմ մենք պետք է հասկանանք, թե ինչ անել այդ ամենի հետ:
Ձեր խնդիրն է գրել նույն կարմիր ծրարները, որոնք կբացվեն արտակարգ իրավիճակներում: Անմիջապես ակնկալեք, որ երբ (ոչ թե, եթե!) ամեն ինչ խեղդվի, մոտակայքում կլինի միայն ամենաանփորձ մարզվողը, ում ձեռքերը սաստիկ կցնցվեն կատարվածի սարսափից: Տեսեք, թե ինչպես են իրականացվում շտապ օգնության նշանները բժշկական կաբինետներում. Օրինակ, ինչ անել անաֆիլակտիկ շոկի հետ: Բժշկական անձնակազմն անգիր գիտի բոլոր արձանագրությունները, բայց երբ մոտակայքում գտնվող մարդը սկսում է մահանալ, շատ հաճախ բոլորն անօգնական բռնում են ամեն ինչից։ Դա անելու համար պատին կախված է հստակ հրահանգ՝ «բացել այսինչի փաթեթը» և «ներերակային ներարկել դեղամիջոցի այդքան միավոր»:
Դժվար է մտածել արտակարգ իրավիճակում: Պետք է լինեն պարզ հրահանգներ ողնաշարի վերլուծության համար:
Լավ DRP-ն բաղկացած է մի քանի պարզ բլոկներից.
- Ում տեղեկացնել վթարի սկզբի մասին. Սա կարևոր է վերացման գործընթացը հնարավորինս զուգահեռականացնելու համար։
- Ինչպես ճիշտ ախտորոշել. մենք հետագծում ենք, փնտրում systemctl կարգավիճակի ծառայության անվանումը և այլն:
- Որքա՞ն ժամանակ կարելի է ծախսել յուրաքանչյուր բեմի վրա: Եթե դուք ժամանակ չունեք այն ձեր ձեռքերով շտկելու SLA-ի ժամանակ, վիրտուալ մեքենան սպանվում է և գլորվում երեկվա կրկնօրինակից:
- Ինչպես համոզվել, որ վթարն ավարտված է:
Հիշեք, որ DRP-ն սկսվում է այն ժամանակ, երբ ծառայությունն ամբողջությամբ ձախողվել է և ավարտվում է վերականգնման միջոցով, նույնիսկ նվազ արդյունավետությամբ: Ուղղակի ամրագրումը կորցնելը չպետք է ակտիվացնի DRP-ն: Կարող եք նաև մեկ բաժակ թեյ նշանակել DRP-ով: Լուրջ. Վիճակագրության համաձայն՝ շատ վթարներ տհաճից դառնում են աղետալի՝ պայմանավորված այն հանգամանքով, որ անձնակազմը խուճապի մեջ շտապում է ինչ-որ բան շտկել՝ միաժամանակ սպանելով տվյալներով միակ կենդանի հանգույցը կամ վերջապես ավարտելով կլաստերը: Որպես կանոն, մեկ բաժակ թեյի համար 5 րոպեն ձեզ մի փոքր ժամանակ կտա հանգստանալու և տեղի ունեցողը վերլուծելու համար։
Մի շփոթեք DRP-ն և համակարգի անձնագիրը: Մի ծանրաբեռնեք այն ավելորդ տվյալներով: Պարզապես հնարավորություն ընձեռեք հիպերհղումների միջոցով արագ և հարմարավետ կերպով գնալ փաստաթղթերի պահանջվող բաժին և ընդլայնված ձևաչափով կարդալ ծառայության ճարտարապետության անհրաժեշտ բաժինները: Իսկ հենց DRP-ում կան միայն ուղղակի հրահանգներ, թե որտեղ և ինչպես կարելի է միանալ կոնկրետ հրամանների հետ copy-paste-ի համար։
Ինչպես ճիշտ փորձարկել
Համոզվեք, որ ցանկացած պատասխանատու աշխատակից ի վիճակի է լրացնել բոլոր կետերը: Ամենավճռական պահին կարող է պարզվել, որ ինժեները չունի մուտքի իրավունք պահանջվող համակարգին, չկան պահանջվող հաշվի համար գաղտնաբառեր, կամ նա չի պատկերացնում, թե ինչ է «Միացեք ծառայության կառավարման վահանակին վստահված անձի միջոցով: գլխավոր գրասենյակ» նշանակում է. Յուրաքանչյուր տարր պետք է հնարավորինս պարզ լինի:
Չհաջողվեց - «Գնացեք վիրտուալացում և վերագործարկեք մեռած հանգույցը»
Ճիշտ - «Վեբ ինտերֆեյսի միջոցով միացեք virt.example.com-ին, հանգույցի բաժնում վերաբեռնեք այն հանգույցը, որն առաջացնում է սխալ»:
Խուսափեք երկիմաստությունից. Հիշեք վախեցած պրակտիկանտին.
Համոզվեք, որ փորձարկեք DRP: Սա պարզապես ցուցադրական ծրագիր չէ, դա մի բան է, որը թույլ կտա ձեզ և ձեր հաճախորդներին արագ դուրս գալ կրիտիկական իրավիճակից: Ավելի լավ է դա անել մի քանի անգամ.
- Մեկ փորձագետ և մի քանի ստաժորներ աշխատում են փորձարկման նստարանի վրա, որը հնարավորինս ընդօրինակում է իրական ծառայությունը: Փորձագետը տարբեր ձևերով խախտում է ծառայությունը և վերապատրաստվողներին հնարավորություն է տալիս վերականգնել այն ըստ DRP-ի: Բոլոր խնդիրները, փաստաթղթերում առկա անորոշությունները և սխալները գրանցված են: Վերապատրաստվողներին վերապատրաստելուց հետո DRP-ն լրացվում և պարզեցվում է անհասկանալի վայրերում:
- Փորձարկում իրական ծառայության վրա: Փաստորեն, դուք երբեք չեք կարող իրական ծառայության կատարյալ պատճեն ստեղծել: Հետևաբար, տարեկան մի քանի անգամ անհրաժեշտ է պլանային հիմունքներով անջատել սերվերների մի մասը, խզել կապերը և այլ վթարներ կազմակերպել սպառնալիքների ցանկից՝ վերականգնման կարգը գնահատելու համար։ Ավելի լավ է գիշերվա կեսին ունենալ 10 րոպե պլանավորված անջատում, քան մի քանի ժամ հանկարծակի ձախողում առավելագույն ծանրաբեռնվածության դեպքում տվյալների կորստի հետ:
- Վթարի իրական վերացում. Այո, սա նույնպես թեստավորման մի մասն է։ Եթե տեղի է ունենում վթար, որը չի եղել սպառնալիքների ցանկում, անհրաժեշտ է լրացնել և վերջնական տեսքի բերել DRP-ն՝ հիմնվելով դրա հետաքննության արդյունքների վրա:
Հիմնական կետերը
- Եթե հիմարությունը կարող է տեղի ունենալ, դա ոչ թե պարզապես տեղի կունենա, այլ դա կանի ամենաաղետալի սցենարով:
- Համոզվեք, որ դուք ունեք ռեսուրսներ ձախողման համար:
- Համոզվեք, որ ունեք կրկնօրինակներ, դրանք ավտոմատ կերպով ստեղծվում են և պարբերաբար ստուգվում են հետևողականության համար:
- Մտածեք սպառնալիքի բնորոշ սցենարներ:
- Տվեք ինժեներներին ծառայությունը տեղադրելու ոչ ստանդարտ տարբերակներ առաջարկելու հնարավորություն:
- DRP-ն պետք է լինի պարզ և համր հրահանգներ: Բոլոր բարդ ախտորոշումները միայն այն բանից հետո, երբ հաճախորդները վերականգնեն ծառայությունը: Նույնիսկ եթե այն գտնվում է սպասման վիճակում:
- Նշեք հիմնական հեռախոսահամարները և կոնտակտները DRP-ում:
- Պարբերաբար փորձարկեք աշխատակիցներին DRP-ի ըմբռնման համար:
- Կազմակերպել պլանավորված վթարները արտադրանքի վրա: Ստենդները չեն կարող փոխարինել ամեն ինչ:
Source: www.habr.com