Բարև բոլորին, ես Իգոր Տյուկաչևն եմ և բիզնեսի շարունակականության խորհրդատու եմ: Այսօրվա գրառման մեջ մենք կունենանք ընդհանուր ճշմարտությունների երկար և հոգնեցուցիչ քննարկում: Ես ուզում եմ կիսվել իմ փորձով և խոսել այն հիմնական սխալների մասին, որոնք թույլ են տալիս ընկերությունները բիզնեսի շարունակականության պլան մշակելիս:
1. RTO և RPO պատահականության սկզբունքով
Ամենակարևոր սխալը, որը ես տեսել եմ, այն է, որ վերականգնման ժամանակը (RTO) դուրս է բերվել օդից: Դե, օդից դուրս - օրինակ, SLA-ից երկու տարի առաջվա թվեր կան, որոնք ինչ-որ մեկը բերել է իրենց նախկին աշխատավայրից: Ինչու են նրանք դա անում: Ի վերջո, ըստ բոլոր մեթոդների, նախ պետք է վերլուծեք բիզնես գործընթացների հետևանքները և այս վերլուծության հիման վրա հաշվարկեք վերականգնման նպատակային ժամանակը և տվյալների ընդունելի կորուստը: Բայց նման վերլուծություն անելը երբեմն երկար ժամանակ է պահանջում, երբեմն՝ թանկ, երբեմն այնքան էլ պարզ չէ, թե ինչպես՝ շեշտիր, թե ինչ է պետք անել։ Եվ առաջին բանը, որ գալիս է շատերի մտքին, հետևյալն է. «Մենք բոլորս չափահաս ենք և հասկանում ենք, թե ինչպես է աշխատում բիզնեսը: Եկեք ժամանակ և գումար չկորցնենք: Վերցնենք գումարած կամ մինուս այնպես, ինչպես պետք է լինի: Քո գլխից դուրս՝ պրոլետարական սրամտություն գործածելով։ Թող RTO-ն երկու ժամ լինի»։
Սա ինչի՞ է հանգեցնում։ Երբ դուք գալիս եք ղեկավարության փողի համար գործունեության համար, որպեսզի ապահովեք պահանջվող RTO/RPO որոշակի թվերով, դա միշտ պահանջում է հիմնավորում: Եթե արդարացում չկա, ապա հարց է առաջանում՝ որտեղի՞ց եք դա վերցրել։ Եվ պատասխանելու ոչինչ չկա. Արդյունքում կորում է վստահությունը ձեր աշխատանքի նկատմամբ։
Բացի այդ, երբեմն այդ երկու ժամը ապաքինումը արժենում է մեկ միլիոն դոլար։ Իսկ RTO-ի տեւողությունն արդարացնելը փողի խնդիր է, ընդ որում՝ շատ խոշոր։
Եվ վերջապես, երբ դուք բերեք ձեր BCP և/կամ DR պլանը կատարողներին (որոնք իրականում վազում և թափահարում են իրենց ձեռքերը վթարի պահին), նրանք նման հարց կտան՝ որտեղի՞ց այս երկու ժամը: Եվ եթե դուք չկարողանաք դա պարզ բացատրել, ապա նրանք վստահություն չեն ունենա ո՛չ ձեր, ո՛չ ձեր փաստաթղթի նկատմամբ։
Թղթի կտոր է ստացվում՝ հանուն թղթի, չբաժանորդագրվել։ Ի դեպ, ոմանք դա անում են միտումնավոր՝ պարզապես կարգավորիչի պահանջները բավարարելու համար։
Դե հասկանում ես
2. Ամեն ինչի բուժումը
Որոշ մարդիկ կարծում են, որ BCP պլանը մշակվել է բոլոր բիզնես գործընթացները ցանկացած սպառնալիքից պաշտպանելու համար: Վերջերս «Ինչի՞ց ենք ուզում պաշտպանվել» հարցը. Ես լսեցի պատասխանը. «Ամեն ինչ և ավելին»:
Բայց փաստն այն է, որ ծրագիրը նախատեսված է միայն պաշտպանելու համար կոնկրետ ընկերության հիմնական բիզնես գործընթացները կոնկրետ սպառնալիքներ. Ուստի պլան մշակելուց առաջ անհրաժեշտ է գնահատել ռիսկերի առաջացումը և վերլուծել դրանց հետևանքները բիզնեսի համար։ Ռիսկերի գնահատումն է անհրաժեշտ՝ հասկանալու համար, թե ինչ սպառնալիքներից է ընկերությունը վախենում։ Շենքերի ոչնչացման դեպքում կլինի մեկ շարունակական պլան, պատժամիջոցային ճնշման դեպքում՝ մեկ այլ, ջրհեղեղի դեպքում՝ երրորդ։ Նույնիսկ երկու նույնական վայրերը տարբեր քաղաքներում կարող են զգալիորեն տարբեր պլաններ ունենալ:
Անհնար է մեկ BCP-ով պաշտպանել մի ամբողջ ընկերություն, հատկապես՝ խոշոր: Օրինակ, հսկայական X5 Retail Group-ը սկսեց ապահովել շարունակականությունը երկու հիմնական բիզնես գործընթացներով (մենք գրել ենք այս մասին ) Եվ ամբողջ ընկերությունը մեկ պլանով պարփակելն ուղղակի անիրատեսական է, սա «կոլեկտիվ պատասխանատվության» կատեգորիայից է, երբ բոլորը պատասխանատու են, և ոչ ոք պատասխանատու չէ։
ISO 22301 ստանդարտը պարունակում է քաղաքականության հայեցակարգ, որով, ըստ էության, սկսվում է շարունակականության գործընթացը ընկերությունում։ Այն նկարագրում է, թե ինչ ենք մենք պաշտպանելու և ինչից։ Եթե մարդիկ վազելով գան և խնդրեն ավելացնել այս և այն, օրինակ.
— BCP-ին ավելացնենք նաև մեզ հաքերային հարձակման վտանգը։
Կամ
— Վերջերս, անձրևի ժամանակ, մեր վերին հարկը հեղեղվեց. ավելացնենք մի սցենար, թե ինչ անել ջրհեղեղի դեպքում:
Այնուհետև անմիջապես ուղղեք նրանց այս քաղաքականությանը և ասեք, որ մենք պաշտպանում ենք կոնկրետ ընկերության ակտիվները և միայն կոնկրետ, նախապես համաձայնեցված սպառնալիքներից, քանի որ դրանք այժմ առաջնային են:
Եվ նույնիսկ եթե փոփոխությունների առաջարկներն իսկապես տեղին են, ապա առաջարկեք դրանք հաշվի առնել քաղաքականության հաջորդ տարբերակում: Քանի որ ընկերության պաշտպանությունը մեծ գումար է պահանջում: Այսպիսով, BCP պլանի բոլոր փոփոխությունները պետք է անցնեն բյուջետային հանձնաժողովի և պլանավորման միջոցով: Մենք խորհուրդ ենք տալիս վերանայել ընկերության բիզնեսի շարունակականության քաղաքականությունը տարին մեկ անգամ կամ ընկերության կառուցվածքում կամ արտաքին պայմանների էական փոփոխություններից անմիջապես հետո (կարող են ընթերցողները ներեն ինձ այդպես ասելու համար):
3. Ֆանտազիաներ և իրականություն
Հաճախ է պատահում, որ BCP պլան կազմելիս հեղինակները նկարագրում են աշխարհի ինչ-որ իդեալական պատկեր: Օրինակ, «մենք չունենք երկրորդ տվյալների կենտրոն, բայց մենք պլան կգրենք, կարծես ունենք»: Կամ բիզնեսը դեռ չունի ենթակառուցվածքի ինչ-որ մաս, բայց աշխատակիցները դեռ կավելացնեն այն պլանին՝ հույս ունենալով, որ այն կհայտնվի ապագայում։ Եվ այնուհետև ընկերությունը իրականությունը կտարածի պլանի վրա. կառուցել երկրորդ տվյալների կենտրոն, նկարագրել այլ փոփոխություններ:
Ձախ կողմում BCP-ին համապատասխան ենթակառուցվածքն է, աջում՝ իրական ենթակառուցվածքը
Այս ամենը սխալ է: BCP պլան գրելը նշանակում է գումար ծախսել: Եթե դուք գրում եք ծրագիր, որը չի աշխատում հենց հիմա, դուք կվճարեք շատ թանկ թղթի համար: Դրանից վերականգնվելն անհնար է, փորձարկելն անհնար է։ Ստացվում է աշխատանք հանուն աշխատանքի։
Դուք կարող եք բավականին արագ պլան գրել, բայց պահեստային ենթակառուցվածք կառուցելը և պաշտպանության բոլոր լուծումների վրա գումար ծախսելը երկար և թանկ է: Սա կարող է տևել ավելի քան մեկ տարի: Եվ կարող է պարզվել, որ դուք արդեն ունեք ծրագիր, և դրա ենթակառուցվածքը կհայտնվի երկու տարի հետո։ Ինչու՞ է անհրաժեշտ նման ծրագիր: Ինչի՞ց է այն ձեզ պաշտպանելու։
Դա նաև ֆանտազիա է, երբ BCP-ի մշակման թիմը սկսում է փորձագետների համար պարզել, թե ինչ պետք է անեն և որ ժամին: Դա գալիս է կատեգորիայից. «Երբ տեսնում եք արջին տայգայում, դուք պետք է շրջվեք արջից հակառակ ուղղությամբ և վազեք արջի արագությունը գերազանցող արագությամբ: Ձմռան ամիսներին դուք պետք է ծածկեք ձեր հետքերը»:
4. Վերևներ և արմատներ
Չորրորդ ամենակարևոր սխալը պլանը չափազանց մակերեսային կամ չափազանց մանրամասն պատրաստելն է: Մեզ պետք է ոսկե միջին. Ծրագիրը չպետք է շատ մանրամասն լինի հիմարների համար, բայց չպետք է լինի շատ ընդհանուր, որպեսզի ավարտվի այսպիսի բան.
Ընդհանուր առմամբ հեշտ է
5. Կեսարին՝ ինչ է Կեսարը, մեխանիկին՝ ինչ է մեխանիկը։
Հաջորդ սխալը բխում է նախորդից. մեկ պլանը չի կարող տեղավորել բոլոր գործողությունները կառավարման բոլոր մակարդակների համար: BCP պլանները սովորաբար մշակվում են խոշոր ֆինանսական հոսքեր ունեցող խոշոր ընկերությունների համար (ի դեպ, ըստ մեր Միջին հաշվով, ռուսական խոշոր ընկերությունների 48%-ը բախվել է արտակարգ իրավիճակների, որոնք հանգեցրել են զգալի ֆինանսական կորուստների) և բազմաստիճան կառավարման համակարգ։ Նման ընկերությունների համար չարժե փորձել ամեն ինչ տեղավորել մեկ փաստաթղթի մեջ։ Եթե ընկերությունը մեծ է և կառուցվածքային, ապա պլանը պետք է ունենա երեք առանձին մակարդակ.
- ռազմավարական մակարդակ - բարձրագույն ղեկավարության համար;
- մարտավարական մակարդակ - միջին մենեջերների համար;
- իսկ գործառնական մակարդակը՝ ոլորտում անմիջականորեն ներգրավվածների համար:
Օրինակ, եթե մենք խոսում ենք ձախողված ենթակառուցվածքի վերականգնման մասին, ապա ռազմավարական մակարդակում որոշում է կայացվում ակտիվացնել վերականգնման ծրագիրը, մարտավարական մակարդակում կարող են նկարագրվել գործընթացի ընթացակարգերը, իսկ գործառնական մակարդակում կան կոնկրետ գործարկման հրահանգներ. սարքավորումների կտորներ.
BCP առանց բյուջեի
Յուրաքանչյուր ոք տեսնում է իր պատասխանատվության ոլորտը և կապերը այլ աշխատակիցների հետ: Վթարի պահին բոլորը պլան են բացում, արագ գտնում իրենց բաժինն ու գնում դրան։ Իդեալում, դուք պետք է անգիր հիշեք, թե որ էջերը բացել, քանի որ երբեմն րոպեները հաշվում են:
6. Դերախաղ
Մեկ այլ սխալ BCP պլան կազմելիս. կարիք չկա ծրագրում ներառել կոնկրետ անուններ, էլ. հասցեներ և այլ կոնտակտային տվյալներ: Փաստաթղթի տեքստում պետք է նշվեն միայն անանձնական դերերը, և այդ դերերին պետք է վերագրվեն կոնկրետ առաջադրանքների համար պատասխանատուների անունները, և նրանց կոնտակտները պետք է նշվեն ծրագրի հավելվածում:
Ինչու?
Այսօր մարդկանց մեծամասնությունը փոխում է աշխատանքը երկու-երեք տարին մեկ անգամ: Եվ եթե պլանի տեքստում գրեք բոլոր պատասխանատուներին և նրանց կոնտակտները, ապա այն պետք է անընդհատ փոխվի։ Իսկ խոշոր ընկերություններում և հատկապես պետական ընկերություններում ցանկացած փաստաթղթի յուրաքանչյուր փոփոխություն պահանջում է տոննա հաստատումներ:
Էլ չենք խոսում այն մասին, որ եթե արտակարգ դեպք տեղի ունենա, և դուք ստիպված լինեք խելահեղորեն թերթել պլանը և փնտրել ճիշտ շփում, դուք թանկ ժամանակ կկորցնեք:
Life hack. երբ դուք փոխում եք հավելվածը, դուք հաճախ նույնիսկ կարիք չունեք այն հաստատել: Մեկ այլ հուշում. կարող եք օգտագործել պլանի թարմացման ավտոմատացման համակարգեր:
7. Տարբերակման բացակայություն
Սովորաբար նրանք ստեղծում են պլանի տարբերակը 1.0, այնուհետև կատարում են բոլոր փոփոխությունները առանց խմբագրման ռեժիմի և առանց ֆայլի անունը փոխելու: Միևնույն ժամանակ, հաճախ անհասկանալի է, թե ինչ է փոխվել նախորդ տարբերակի համեմատ: Տարբերակման բացակայության դեպքում պլանն ապրում է իր կյանքով, որին ոչ մի կերպ չեն հետևում։ Ցանկացած BCP պլանի երկրորդ էջում պետք է նշվի տարբերակը, փոփոխությունների հեղինակը և հենց փոփոխությունների ցանկը:
Ոչ ոք այլևս չի կարող դա պարզել
8. Ում հարցնեմ:
Հաճախ ընկերությունները չունեն BCP պլանի համար պատասխանատու անձ և չկա առանձին բաժին, որը պատասխանատու է բիզնեսի շարունակականության համար: Այս պատվավոր պատասխանատվությունը վերապահված է CIO-ին, նրա տեղակալին կամ «դուք գործ ունեք տեղեկատվական անվտանգության հետ» սկզբունքի համաձայն, ուստի այստեղ նաև BCP-ն: Արդյունքում պլանը մշակվում, համաձայնեցվում և հաստատվում է վերևից վար:
Ո՞վ է պատասխանատու պլանը պահելու, թարմացնելու և դրանում առկա տեղեկատվության վերանայման համար: Սա չի կարող նշանակվել: Դրա համար առանձին աշխատող վարձելը վատնում է, բայց եղածներից մեկին լրացուցիչ պարտականություններով բեռնելը, իհարկե, հնարավոր է, քանի որ բոլորն այժմ ձգտում են արդյունավետության. «Եկեք նրա վրա լապտեր կախենք, որ գիշերը հնձի», դա անհրաժեշտ է?
Մենք փնտրում ենք BCP-ի համար պատասխանատուներին դրա ստեղծումից երկու տարի անց
Հետևաբար, դա հաճախ է պատահում այսպես. ծրագիր է մշակվել և դրվել երկար տուփի մեջ՝ փոշով ծածկվելու համար։ Ոչ ոք չի փորձարկում այն կամ չի պահպանում դրա արդիականությունը: Ամենատարածված արտահայտությունը, որ ես լսում եմ, երբ գալիս եմ հաճախորդի մոտ, հետևյալն է. «Ծրագիր կա, բայց այն մշակվել է վաղուց, թեստավորվե՞լ է, հայտնի չէ, կասկած կա, որ այն չի աշխատում»:
9. Չափից շատ ջուր
Կան ծրագրեր, որոնցում ներածությունը բաղկացած է հինգ էջից, ներառյալ նախադրյալների նկարագրությունը և ծրագրի բոլոր մասնակիցների շնորհակալությունը, ընկերության գործունեության մասին տեղեկություններով: Մինչ դուք ոլորում եք ներքև մինչև տասներորդ էջը, որտեղ օգտակար տեղեկատվություն կա, ձեր տվյալների կենտրոնն արդեն հեղեղված է:
Երբ փորձում եք կարդալ մինչև պահը, ի՞նչ պետք է անեք, եթե ձեր տվյալների կենտրոնը հեղեղված է:
Տեղադրեք ամբողջ կորպորատիվ «ջուրը» առանձին փաստաթղթում: Պլանն ինքնին պետք է չափազանց կոնկրետ լինի. այս առաջադրանքի համար պատասխանատու անձը դա անում է և այլն:
10. Ու՞մ հաշվին է բանկետը:
Հաճախ պլան ստեղծողները չեն ստանում ընկերության բարձրագույն ղեկավարության աջակցությունը: Բայց կա աջակցություն միջին ղեկավարության կողմից, որը չի կառավարում կամ չունի անհրաժեշտ բյուջե և ռեսուրսներ բիզնեսի շարունակականությունը կառավարելու համար: Օրինակ, ՏՏ բաժինը ստեղծում է իր BCP պլանը իր բյուջեի շրջանակներում, բայց CIO-ն չի տեսնում ընկերության ամբողջ պատկերը: Իմ ամենասիրելի օրինակը վիդեոկոնֆերանսն է: Երբ գործադիր տնօրենի վիդեոկոնֆերանսը չաշխատի, ո՞ւմ է նա փորելու: CIO-ն, ով «չի տրամադրել». Հետևաբար, CIO-ի տեսանկյունից ո՞րն է ընկերությունում ամենակարևորը։ Ինչի համար մարդիկ նրան միշտ «սիրում են»՝ տեսահամաժողով, որն անմիջապես վերածվում է բիզնեսի համար կարևոր համակարգի: Եվ բիզնեսի տեսանկյունից, լավ, ոչ VKS, պարզապես մտածեք, մենք կխոսենք հեռախոսով, ինչպես Բրեժնևի օրոք ...
Բացի այդ, ՏՏ վարչությունը սովորաբար կարծում է, որ աղետի դեպքում իր հիմնական խնդիրն է վերականգնել կորպորատիվ ՏՏ համակարգերի աշխատանքը։ Բայց երբեմն ձեզ հարկավոր չէ դա անել: Եթե ահավոր թանկ պրինտերի վրա թղթի կտորներ տպելու տեսքով բիզնես պրոցես կա, ապա չպետք է նման երկրորդ տպիչը պահեստային գնես ու խափանման դեպքում տեղադրես կողքին։ Թղթի կտորները ձեռքով ժամանակավորապես գունավորելը կարող է բավարար լինել։
Եթե մենք կառուցում ենք շարունակական պաշտպանություն ՏՏ շրջանակներում, մենք պետք է աջակցենք բարձրաստիճան ղեկավարությանը և բիզնեսի ներկայացուցիչներին: Հակառակ դեպքում, զբաղվելով ՏՏ բաժնի ներսում, կարող եք լուծել խնդիրների որոշակի շրջանակ, բայց ոչ բոլոր անհրաժեշտները:
Ահա թե ինչպիսին է իրավիճակը, երբ միայն ՏՏ բաժինն ունի DR պլաններ
10. Թեստավորում չկա
Եթե կա ծրագիր, այն պետք է փորձարկվի: Նրանց համար, ովքեր ծանոթ չեն չափանիշներին, սա բոլորովին ակնհայտ չէ: Օրինակ, դուք ամենուրեք «վթարային ելքի» նշաններ ունեք: Բայց ասա, որտե՞ղ է քո կրակի դույլը, կարթն ու բահը: Որտե՞ղ է հրդեհային հիդրանտը: Որտե՞ղ պետք է տեղադրվի կրակմարիչը: Բայց սա պետք է իմանան բոլորը։ Մեզ ընդհանրապես տրամաբանական չի թվում գրասենյակ մտնելիս կրակմարիչ գտնելը։
Թերևս պլանի փորձարկման անհրաժեշտությունը պետք է նշվի հենց ծրագրում, բայց սա վիճելի որոշում է: Ամեն դեպքում, պլանը կարելի է աշխատող համարել միայն այն դեպքում, եթե այն առնվազն մեկ անգամ փորձարկվել է: Ինչպես վերը նշվեց, ես շատ հաճախ եմ լսում. «Ծրագիրը կա, բոլոր ենթակառուցվածքները պատրաստված են, բայց փաստ չէ, որ ամեն ինչ կստացվի այնպես, ինչպես գրված է ծրագրում։ Որովհետև չեն փորձարկել: երբեք»:
Վերջում
Որոշ ընկերություններ կարող են վերլուծել իրենց պատմությունը, որպեսզի հասկանան, թե ինչպիսի դժվարություններ կարող են տեղի ունենալ և որքանով են դրանք հավանական: Հետազոտությունները և փորձը հուշում են, որ մենք չենք կարող պաշտպանվել մեզ ամեն ինչից։ Խայտառակություն, վաղ թե ուշ, պատահում է ցանկացած ընկերության հետ: Այլ բան է, թե որքանով պատրաստ կլինեք այս կամ նմանատիպ իրավիճակին, և կկարողանա՞ք ժամանակին վերականգնել ձեր բիզնեսը։
Ոմանք կարծում են, որ շարունակականությունն այն է, թե ինչպես կարելի է վերացնել բոլոր տեսակի ռիսկերը, որպեսզի դրանք չկատարվեն: Ո՛չ, բանն այն է, որ ռիսկերն իրականանալու են, և մենք պատրաստ կլինենք դրան։ Զինվորները վարժված են ոչ թե մարտում մտածելու, այլ գործելու համար։ Դա նույնն է BCP պլանի դեպքում. այն թույլ կտա հնարավորինս արագ վերականգնել ձեր բիզնեսը:
Միակ սարքավորումը, որը չի պահանջում BCP
Իգոր Տյուկաչով,
Բիզնեսի շարունակականության խորհրդատու
Հաշվողական համակարգերի նախագծման կենտրոն
«Jet Infosystems»
Source: www.habr.com