Усім прывітанне, мяне клічуць Ігар Цюкачоў, і я кансультант па бесперапыннасці бізнэсу. У сённяшнім пасце мы будзем доўга і нудна абмяркоўваць вялікія ісціны я жадаю падзяліцца сваім досведам і распавесці аб асноўных памылках, якія дапушчаюць кампаніі пры распрацоўцы плана забеспячэння бесперапыннасці сваёй дзейнасці.
1. RTO і RPO наўздагад
Найважнейшая памылка з тых, якія мне сустракаліся, складаецца ў тым, што час аднаўлення (RTO) бярэцца са столі. Ну як са столі - напрыклад, ёсць нейкія лічбы двухгадовай даўнасці са SLA, які хтосьці прынёс з папярэдняга месца працы. Чаму так робяць? Бо па ўсіх методыках трэба спачатку прааналізаваць наступствы для бізнес-працэсаў, і на аснове гэтага аналізу вылічыць мэтавае час аднаўлення і дапушчальную страту даных. Але рабіць такі аналіз часам доўга, часам затратна, часам не вельмі зразумела, як, - патрэбнае падкрэсліць. І першае, што шмат каму прыходзіць у галаву: «Мы ж усе дарослыя людзі і разумеем, як працуе бізнэс. Не будзем марна марнаваць час і грошы! Давай возьмем плюс-мінус, як гэта мусіць быць. З галавы, выкарыстоўваючы пралетарскую кемлівасць! Няхай RTO будзе роўна дзвюм гадзінам».
Да чаго гэта прыводзіць? Калі прыходзіш да кіраўніцтва за грашыма на мерапрыемствы па забеспячэнні патрабаваных RTO/RPO з нейкімі лічбамі, яно заўсёды патрабуе абгрунтаванні. Калі абгрунтавання няма, тое ўзнікае пытанне: адкуль вы яе ўзялі? А адказаць-то і няма чаго. У выніку давер да вашай працы губляецца.
Акрамя таго, часам гэтыя дзве гадзіны аднаўлення працаздольнасці каштуюць мільён долараў. І абгрунтаванне працягласці RTO – пытанне грошай, прычым вельмі вялікіх.
І нарэшце, калі вы прыйдзеце са сваім BCP і/ці DR-планам да выканаўцаў (якія непасрэдна будуць бегаць і размахваць рукамі ў момант аварыі), яны зададуць аналагічнае пытанне: адкуль узяліся гэтыя дзве гадзіны? І калі вы не можаце выразна гэта растлумачыць, то і ў іх не будзе даверу ні да вас, ні да вашага дакумента.
Атрымліваецца паперка дзеля паперкі, адпіска. Дарэчы, некаторыя робяць гэта свядома, каб проста задаволіць патрабаванням рэгулятара.
Ну вы зразумелі
2. Лекі ад усяго
Некаторыя лічаць, што план BCP распрацоўваецца для абароны ўсіх бізнес-працэсаў ад любых пагроз. Нядаўна на пытанне "Ад чаго мы хочам абараняцца?" я пачуў адказ: «Ад усяго і болей».
Але справа ў тым, што план прызначаны для абароны толькі канкрэтных ключавых бізнес-працэсаў кампаніі ад канкрэтных пагроз. Таму перад распрацоўкай плана неабходна ацаніць узнікненне рызык і прааналізаваць іх наступствы для бізнесу. Ацэнка рызык патрэбна для таго, каб зразумець, якіх менавіта пагроз баіцца кампанія. На выпадак разбурэння будынка будзе адзін план забеспячэння бесперапыннасці, пры ўзнікненні санкцыйнага ціску - іншы, пры паводцы - трэці. Нават ля дзвюх аднолькавых пляцовак у розных гарадах планы могуць значна адрознівацца.
Нельга абараніць адным BCP усю кампанію цалкам, асабліва вялікую. Напрыклад, вялізны Х5 Retail Group пачаў займацца забеспячэннем бесперапыннасці з двух ключавых бізнес-працэсаў (мы пісалі пра гэта ). А абгарадзіць усю кампанію адным планам проста нерэальна, гэта з разраду «калектыўнай адказнасці», калі адказныя ўсё і не адказны ніхто.
У стандарце ISO 22301 ёсць паняцце палітыкі, з якой, уласна, і пачынаецца працэс бесперапыннасці ў кампаніі. У ёй апісваецца, што мы будзем бараніць і ад чаго. Калі звяртаюцца людзі і просяць дадаць таго-сяго, напрыклад:
- А давайце дадамо ў BCP рызыку таго, што нас хакнуць?
Або
- Вось у нас нядаўна падчас дажджу заліло апошні паверх - давайце дадамо сцэнар, што рабіць на выпадак затаплення?
То адразу адсылайце іх да гэтай палітыкі і кажыце, што мы абараняем канкрэтныя актывы кампаніі і толькі ад канкрэтных, загадзя ўзгодненых пагроз, таму што менавіта яны зараз знаходзяцца ў прыярытэце.
І нават калі прапановы аб зменах сапраўды мэтазгодныя, то прапануйце ўлічыць іх у наступнай версіі палітыкі. Таму што абарона кампаніі - гэта немалыя грошы. Так што ўсе змены BCP плана павінны праходзіць праз бюджэтны камітэт і планаванне. Мы рэкамендуем пераглядаць палітыку бесперапыннасці бізнэсу кампаніі адзін раз у год ці адразу пасля значных змен структуры кампаніі ці вонкавай кан'юнктуры (ды прабачаць мяне чытачы за такія словы).
3. Фантазіі і рэальнасць
Вельмі часта бывае, што пры складанні плана BCP аўтары апісваюць нейкую ідэальную карціну свету. Напрыклад, "у нас няма другога ЦАД, але мы напішам план так, як быццам ён у нас ёсць". Або ў бізнэсу пакуль няма нейкай часткі інфраструктуры, але супрацоўнікі ўсё роўна ўнясуць яе ў план у надзеі, што ў будучыні яна з'явіцца. А затым кампанія будзе нацягваць рэальнасць на план: будаваць другі ЦАД, апісваць іншыя змены.
Злева - інфраструктура, якая адпавядае BCP, справа - рэальная інфраструктура
Усё гэта памылка. Напісаць план BCP - гэта азначае выдаткаваць грошы. Калі вы напішаце план, які не будзе працаваць прама зараз, то вы заплаціце за вельмі дарагую паперу. Па ім немагчыма аднавіцца, яго немагчыма пратэставаць. Атрымліваецца праца дзеля працы.
Напісаць план можна даволі хутка, а пабудаваць рэзервовую інфраструктуру, выдаткаваць грошы на ўсе рашэнні па абароне - гэта доўга і дорага. На гэта можа спатрэбіцца не адзін год. І можа аказацца так, што план у вас ужо ёсць, а інфраструктура пад яго з'явіцца праз два гады. Навошта патрэбен такі план? Ад чаго ён вас абароніць?
Яшчэ з разраду фантазій, калі працоўная каманда па распрацоўцы BCP пачынае дадумваць за экспертаў, што яны павінны рабіць і за які час. Атрымліваецца з разраду: «убачыўшы ў тайзе мядзведзя, неабходна разгарнуцца ў процілеглы ад мядзведзя бок і бегчы з хуткасцю, якая перавышае хуткасць мядзведзя. У зімовыя месяцы неабходна замятаць сляды».
4. Вяршкі і карэньчыкі
Чацвёртая па важнасці памылка заключаецца ў тым, што план робяць альбо занадта павярхоўным, альбо занадта падрабязным. Патрэбна залатая сярэдзіна. План не павінен быць занадта падрабязным, для ідыётаў, але і не павінен быць занадта агульным, каб не атрымалася нешта такое:
На ізі наогул
5. Кесару - кесарава, слесару - слесарава
Наступная памылка вынікае з папярэдняй: у адзін план нельга змясціць усе дзеянні для ўсіх узроўняў кіравання. BCP планы распрацоўваюцца звычайна для буйных кампаній з вялікімі фінансавымі патокамі (дарэчы, згодна з нашым , У сярэднім 48% буйных расійскіх кампаній сутыкаліся з няштатнымі сітуацыямі, якія цягнуць за сабой значныя фінансавыя страты) і шматузроўневай сістэмай кіравання. Для такіх кампаній не варта спрабаваць змясціць усё ў адзін дакумент. Калі кампанія вялікая і структураваная, то план павінен мець тры асобныя ўзроўні:
- стратэгічны ўзровень - для вышэйшага кіраўніцтва;
- тактычны ўзровень - для кіраўнікоў сярэдняга звяна;
- і аперацыйны ўзровень - для непасрэдных выканаўцаў на месцах.
Напрыклад, калі гаворка ідзе аб аднаўленні ўпала інфраструктуры, то на стратэгічным узроўні прымаецца рашэнне аб актывацыі плана аднаўлення, на тактычным узроўні могуць быць апісаны працэдуры працэсу, а на аперацыйным - інструкцыі па ўводу ў строй канкрэтных элементаў абсталявання.
BCP без бюджэту
Кожны бачыць сваю зону адказнасці і сувязі з іншымі супрацоўнікамі. У момант аварыі кожны адкрывае план, хутка знаходзіць сваю частку і прытрымлівайцеся ёй. У ідэале, трэба памятаць на памяць, якія старонкі адкрыць, бо бывае, што рахунак ідзе на хвіліны.
6. Ролевыя гульні
Яшчэ адна памылка пры складанні плана BCP: не трэба прапісваць у плане пэўныя прозвішчы, адрасы пошты і іншыя кантактныя дадзеныя. У тэксце самога дакумента трэба ўказваць толькі абязлічаныя ролі, а прысвойваць гэтым ролям прозвішчы адказных за канкрэтныя задачы і пералічваць іх кантакты трэба ў дадатку да плана.
Чаму?
Сёння большасць людзей кожныя два-тры гады мяняюць працу. І калі ўсіх адказных і іх кантакты вы прапішаце ў тэксце плана, то яго давядзецца пастаянна мяняць. А ў буйных кампаніях, і тым больш дзяржаўных, кожнае змяненне любога дакумента патрабуе кучы ўзгадненняў.
Не кажучы ўжо пра тое, што калі адбудзецца надзвычайнае здарэнне, і вам прыйдзецца сутаргава гартаць план і шукаць патрэбны кантакт, то згубіцца каштоўны час.
Лайфхак: пры змене дадатку часта нават не патрабуецца яго сцвярджаць. Яшчэ адна падказка: можаце выкарыстоўваць сістэмы аўтаматызацыі абнаўлення плана.
7. Адсутнасць версійнасці
Звычайна ствараюць план версіі 1.0, а затым усе змены ўносяць без рэжыму правак, і не змяняючы назву файла. Пры гэтым часта незразумела, што ж змянілася ў параўнанні з папярэдняй версіяй. У адсутнасць версійнасці план жыве сваім жыццём, якое ніяк не адсочваецца. На другой старонцы любога плана BCP павінна быць указана версія, аўтар змен і спіс саміх змен.
Нікому ўжо не разабрацца
8. З каго пытацца?
Часта ў кампаніях няма адказнага за план BCP і няма асобнага падраздзялення, якое адказвае за бесперапыннасць бізнэсу. Гэты ганаровы абавязак ускладаецца на ІТ-дырэктара, яго намесніка або па прынцыпе "ты ж займаешся інфармацыйнай бяспекай, вось табе яшчэ і BCP у дадатак". У выніку план распрацоўваюць, узгадняюць і сцвярджаюць усё запар, зверху данізу.
А хто адказвае за захоўванне плана, абнаўленне, і перагляд інфармацыі ў ім? Такога могуць і не прызначыць. Браць для гэтага асобнага супрацоўніка - марнатраўна, а нагрузіць дадатковым абавязкам аднаго з наяўных - можна, вядома, таму што ўсе цяпер імкнуцца да эфектыўнасці: "Давайце на яго яшчэ ліхтар павесім, каб ён і ўначы мог касіць", але ці трэба?
Шукаем адказных за BCP праз два гады пасля яго стварэння
Таму часта бывае так: план распрацавалі і паклалі ў доўгую скрыню пакрывацца пылам. Ніхто яго не тэсціруе, не падтрымлівае яго актуальнасць. Самая частая фраза, якую я чую, калі прыходжу да заказчыка: «План ёсць, але распрацаваны даўно, ці тэсціраваўся — невядома, ці ёсць падазрэнне, што не працуе».
9. Занадта шмат вады
Бываюць планы, у якіх увядзенне старонак на пяць, у тым ліку апісанне перадумоў і падзякі ўсім удзельнікам праекта, з інфармацыяй аб тым, чым займаецца кампанія. Пакуль далістаеш старонкі да дзесятай, дзе карысная інфармацыя, у цябе ўжо ЦАД затапіла.
Калі спрабуеш дачытаць да моманту, што ж усё ж рабіць пры затапленні дата-цэнтра
Усю карпаратыўную "ваду" выносіце ў асобны дакумент. Сам план павінен быць вельмі канкрэтным: адказны за гэтую задачу робіць тое і тое.
10. За чый рахунак банкет?
Часта ў стваральнікаў плана няма падтрымкі ад вышэйшага кіраўніцтва кампаніі. Але ёсць падтрымка ад кіраўніцтва сярэдняга звяна, якое не кіруе ці не валодае неабходным бюджэтам і рэсурсамі для арганізацыі бесперапыннасці бізнэсу. Напрыклад, ІТ-дэпартамент стварае свой план BCP у рамках свайго бюджэту, але ІТ-дырэктар не бачыць карціну ў кампаніі цалкам. Мой любімы прыклад – гэта відэаканферэнцсувязь. Калі ў генеральнага не працуе відэаканферэнцсувязь, каго ён вытрыбушыць? ІТ-дырэктара, які "не забяспечыў". Таму з пункту гледжання ІТ-дырэктара што найважнейшае ў кампаніі? Тое, за што яго ўвесь час «кахаюць»: відэаканферэнцсувязь, якая адразу ператвараецца ў сістэму business-critical. А з пункту гледжання бізнесу - ну няма ВКС, падумаеш, пагаворым па тэлефоне, як пры Брэжневе ...
Акрамя таго, звычайна ІТ-дэпартамент думае, што яго галоўная задача ў выпадку катастрофы – аднавіць працу карпаратыўных ІТ-сістэм. Але часам гэтага рабіць не трэба! Калі ёсць бізнэс-працэс у выглядзе друкавання паперак на жудасна дарагім друкарцы, то не варта купляць другую такую друкарку ў якасці запаснога і ставіць яго побач на выпадак паломкі. Магчыма, дастаткова часова размалёўваць паперкі ўручную.
Калі мы ўнутры ІТ будуем бесперапынную абарону, то абавязаны заручыцца падтрымкай вышэйшага кіраўніцтва і прадстаўнікоў бізнэсу. Інакш, акукнуўшыся ўнутры ІТ-дэпартамента, можна вырашыць пэўны спектр праблем, але не ўсіх неабходных.
Так выглядае сітуацыя, калі толькі ў ІТ-дэпартамента ёсць DR-планы
10. Без тэсціравання
Калі ёсць план, яго трэба тэсціраваць. Для тых, хто не знаёмы са стандартамі, гэта зусім невідавочна. Напрыклад, у вас усюды вісяць таблічкі "аварыйны выхад". Але скажыце мне, дзе ў вас знаходзіцца супрацьпажарнае вядро, багор, рыдлёўка? Дзе знаходзіцца пажарны гідрант? Дзе павінен стаяць вогнетушыцель? А бо ўсе павінны гэта ведаць. Нам зусім не здаецца лагічным пры ўваходзе ў офіс знайсці вачыма вогнетушыцель.
Магчыма, аб неабходнасці тэсціравання плана трэба згадаць у ім самім, але гэта спрэчнае рашэнне. У любым выпадку, план можна лічыць працоўным толькі тады, калі яго пратэставалі хаця б адзін раз. Як ужо згадвалася вышэй, вельмі часта чую: “План ёсць, уся інфра падрыхтавана, але не факт, што ўсё адпрацуе так, як напісана ў плане. Таму што не тэсціравалі. Ніколі».
У заключэнне
Некаторыя кампаніі могуць прааналізаваць сваю гісторыю з мэтай зразумець, якія непрыемнасці і з якой імавернасцю могуць адбыцца. Даследаванні і досвед кажуць аб тым, што мы не зможам абараніцца ад усяго. Shit, рана ці позна, happens з любой кампаніяй. Іншая справа, наколькі вы да гэтай ці падобнай сітуацыі будзеце падрыхтаваны і ці зможаце своечасова аднавіць свой бізнэс.
Некаторыя думаюць, што бесперапыннасць - гэта пра тое, як ліквідаваць разнастайныя рызыкі, каб яны не рэалізаваліся. Не, размова аб тым, што рызыкі рэалізуюцца, а мы да гэтага будзем гатовы. Салдаты трэніруюцца дзеля таго, каб у баі не думаць, а дзейнічаць. Тое ж самае і з планам BCP: ён дазволіць вам аднавіць бізнэс настолькі хутка, наколькі гэта магчыма неабходна.
Адзінае абсталяванне, якое не патрабуе BCP
Ігар Цюкачоў,
Кансультант па бесперапыннасці бізнэсу
Цэнтра праектавання вылічальных комплексаў
«Інфасістэмы Джэт»
Крыніца: habr.com