Здравейте всички, казвам се Игор Тюкачев и съм консултант по непрекъснатост на бизнеса. В днешната публикация ще имаме дълга и досадна дискусия за общи истини.Искам да споделя своя опит и да говоря за основните грешки, които компаниите правят, когато разработват план за непрекъснатост на бизнеса.
1. RTO и RPO на случаен принцип
Най-важната грешка, която съм виждал, е, че времето за възстановяване (RTO) е взето от нищото. Ами от нищото - например има някакви номера отпреди две години от SLA, които някой е донесъл от предишната си работа. Защо го правят? В крайна сметка, според всички методи, първо трябва да анализирате последствията за бизнес процесите и въз основа на този анализ да изчислите целевото време за възстановяване и приемливата загуба на данни. Но извършването на такъв анализ понякога отнема много време, понякога е скъпо, понякога не е много ясно как - подчертайте какво трябва да се направи. И първото нещо, което идва на ум за мнозина е: „Всички сме възрастни и разбираме как работи бизнесът. Нека не губим време и пари! Нека вземем плюс или минус както трябва. Извън главата си, използвайки пролетарска изобретателност! Нека RTO е два часа.
До какво води това? Когато дойдете при управлението за пари за дейности за осигуряване на изискваните RTO/RPO с определени числа, това винаги изисква обосновка. Ако няма оправдание, тогава възниква въпросът: откъде го взехте? И няма какво да се отговори. В резултат на това се губи доверието в работата ви.
Освен това понякога тези два часа възстановяване струват милион долара. А оправдаването на продължителността на RTO е въпрос на пари и то много големи.
И накрая, когато занесете вашия ГКП и/или DR план на изпълнителите (които всъщност ще тичат и размахват ръце в момента на инцидента), те ще зададат подобен въпрос: откъде са дошли тези два часа? И ако не можете да обясните това ясно, тогава те няма да имат доверие нито във вас, нито във вашия документ.
Оказва се, че е лист хартия в името на лист хартия, отписване. Между другото, някои правят това умишлено, просто за да задоволят изискванията на регулатора.
Е, разбирате
2. Лекарството за всичко
Някои хора вярват, че планът за BCP е разработен, за да защити всички бизнес процеси от всякакви заплахи. Напоследък въпросът „От какво искаме да се предпазим?“ Чух отговора: „Всичко и повече“.
Но факт е, че планът е предназначен само за защита специфичен ключови бизнес процеси на компанията от специфичен заплахи. Ето защо, преди да се разработи план, е необходимо да се оцени възникването на рискове и да се анализират техните последствия за бизнеса. Оценката на риска е необходима, за да се разбере от какви заплахи се страхува компанията. При разрушаване на сграда ще има един план за непрекъснатост, при санкционен натиск - друг, при наводнение - трети. Дори два идентични обекта в различни градове може да имат значително различни планове.
Невъзможно е да защитите цяла компания с един ГКПП, особено голяма. Например огромната X5 Retail Group започна да осигурява приемственост с два ключови бизнес процеса (писахме за това ). И е просто нереалистично да се обгради цялата компания с един план, това е от категорията на „колективната отговорност“, когато всички носят отговорност и никой.
Стандартът ISO 22301 съдържа концепцията за политика, с която всъщност започва процесът на приемственост в компанията. Там е описано какво ще защитаваме и от какво. Ако хората тичат и искат да добавят това и това, например:
— Да добавим към BCP риска, че ще бъдем хакнати?
Или
— Наскоро по време на дъжд последният ни етаж беше наводнен — нека добавим сценарий какво да правим в случай на наводнение?
След това незабавно ги насочете към тази политика и кажете, че ние защитаваме конкретни фирмени активи и само от конкретни, предварително договорени заплахи, защото те са приоритет сега.
И дори ако предложенията за промени наистина са подходящи, предлагайте да ги вземете предвид в следващата версия на политиката. Защото защитата на една компания струва много пари. Така че всички промени в плана на BCP трябва да преминат през бюджетната комисия и планирането. Препоръчваме преразглеждане на политиката за непрекъснатост на бизнеса на компанията веднъж годишно или веднага след значителни промени в структурата на компанията или външните условия (нека читателите ми простят, че го казвам).
3. Фантазии и реалност
Често се случва, когато изготвят план за ГКПП, авторите описват някаква идеална картина на света. Например „нямаме втори център за данни, но ще напишем план, сякаш го имаме“. Или бизнесът все още няма част от инфраструктурата, но служителите все пак ще я добавят към плана с надеждата, че ще се появи в бъдеще. И тогава компанията ще разтегне реалността върху плана: изгради втори център за данни, ще опише други промени.
Вляво е инфраструктурата, съответстваща на ГКПП, вдясно е реалната инфраструктура
Всичко това е грешка. Писането на план за BCP означава харчене на пари. Ако напишете план, който не работи в момента, ще платите за много скъпа хартия. Невъзможно е да се възстанови от него, невъзможно е да се тества. Оказва се работа в името на работата.
Можете да напишете план доста бързо, но изграждането на резервна инфраструктура и харченето на пари за всички решения за защита е дълго и скъпо. Това може да отнеме повече от една година. И може да се окаже, че вече имате план и инфраструктурата за него ще се появи след две години. Защо е необходим такъв план? От какво ще ви предпази?
Също така е фантазия, когато екипът за разработка на BCP започне да разбира за експертите какво трябва да направят и в какъв срок. Идва от категорията: „Когато видите мечка в тайгата, трябва да се обърнете в обратна посока от мечката и да бягате със скорост, по-голяма от скоростта на мечката. През зимните месеци трябва да прикриете следите си.“
4. Върхове и корени
Четвъртата най-важна грешка е да направите плана твърде повърхностен или твърде подробен. Имаме нужда от златна среда. Планът не трябва да е твърде подробен за идиоти, но не трябва да е и твърде общ, за да се получи нещо подобно:
На лесно като цяло
5. На Цезар - това, което е на Цезар, на механика - това, което е на механик.
Следващата грешка произтича от предишната: един план не може да побере всички действия за всички нива на управление. Плановете за BCP обикновено се разработват за големи компании с големи финансови потоци (между другото, според нашите , средно 48% от големите руски компании са се сблъскали с извънредни ситуации, водещи до значителни финансови загуби) и многостепенна система за управление. За такива компании не си струва да се опитват да поберат всичко в един документ. Ако компанията е голяма и структурирана, тогава планът трябва да има три отделни нива:
- стратегическо ниво - за висше ръководство;
- тактическо ниво - за среден мениджър;
- и оперативно ниво - за пряко ангажираните на терен.
Например, ако говорим за възстановяване на повредена инфраструктура, тогава на стратегическо ниво се взема решение за активиране на плана за възстановяване, на тактическо ниво могат да бъдат описани процедурите на процеса, а на оперативно ниво има инструкции за въвеждане в експлоатация на конкретни части от оборудване.
БКП без бюджет
Всеки вижда своята зона на отговорност и връзки с други служители. В момента на инцидент всеки отваря план, бързо намира своята част и я следва. В идеалния случай трябва да запомните наизуст кои страници да отворите, защото понякога минутите се броят.
6. Ролева игра
Друга грешка при изготвянето на план за ГКПП: не е необходимо да включвате конкретни имена, имейл адреси и друга информация за контакт в плана. В самия текст на документа трябва да се посочат само неперсонифицирани роли, като на тези роли трябва да бъдат присвоени имената на отговорниците за конкретни задачи и техните контакти да бъдат посочени в приложението към плана.
Защо?
Днес повечето хора сменят работата си на всеки две до три години. И ако запишете всички отговорници и техните контакти в текста на плана, тогава той ще трябва постоянно да се променя. А в големите компании, и особено държавните, всяка промяна на който и да е документ изисква куп одобрения.
Да не говорим, че ако възникне извънредна ситуация и трябва трескаво да прелиствате плана и да търсите правилния контакт, ще загубите ценно време.
Life hack: когато промените приложение, често дори не е необходимо да го одобрявате. Друг съвет: можете да използвате системи за автоматизация на актуализирането на плана.
7. Липса на версии
Обикновено те създават план версия 1.0 и след това правят всички промени без режим на редактиране и без промяна на името на файла. В същото време често не е ясно какво се е променило в сравнение с предишната версия. При липса на версии планът живее свой собствен живот, който не се проследява по никакъв начин. Втората страница на всеки план за BCP трябва да посочва версията, автора на промените и списък на самите промени.
Вече никой не може да го разбере
8. Кого да попитам?
Често компаниите нямат отговорник за плана за BCP и няма отделен отдел, който да отговаря за непрекъснатостта на бизнеса. Тази почетна отговорност се възлага на CIO, неговия заместник или според принципа „вие се занимавате с информационна сигурност, така че ето ви BCP в допълнение“. В резултат на това планът е разработен, съгласуван и одобрен от всички, от горе до долу.
Кой е отговорен за съхраняването на плана, актуализирането и преразглеждането на информацията в него? Това може да не е предписано. Наемането на отделен служител за това е разточително, но натоварването на един от съществуващите с допълнителни задължения е възможно, разбира се, защото сега всички се стремят към ефективност: „Нека да му окачи фенер, за да може да коси през нощта“, но необходимо ли е?
Търсим отговорните за БКП две години след създаването му
Затова често се случва така: разработен е план и поставен в дълга кутия, за да се покрие с прах. Никой не го тества и не поддържа уместността му. Най-често срещаната фраза, която чувам, когато отида при клиент, е: „Има план, но той е разработен отдавна, дали е тестван, не се знае, има подозрение, че не работи.“
9. Твърде много вода
Има планове, в които въведението е от пет страници, включващо описание на предпоставките и благодарности към всички участници в проекта, с информация какво прави компанията. Докато превъртите надолу до десетата страница, където има полезна информация, вашият център за данни вече е наводнен.
Когато се опитвате да прочетете до момента, какво трябва да направите, ако вашият център за данни е наводнен?
Поставете цялата корпоративна „вода“ в отделен документ. Самият план трябва да бъде изключително конкретен: лицето, което отговаря за тази задача, прави това и т.н.
10. За чия сметка е банкетът?
Често създателите на планове нямат подкрепа от висшето ръководство на компанията. Но има подкрепа от средния мениджмънт, който не управлява или няма необходимия бюджет и ресурси за управление на непрекъснатостта на бизнеса. Например, ИТ отделът създава своя BCP план в рамките на своя бюджет, но CIO не вижда цялата картина на компанията. Любимият ми пример е видеоконференцията. Когато видеоконференцията на изпълнителния директор не работи, кого ще изкорми? CIO, който „не е предоставил“. Следователно, от гледна точка на CIO, кое е най-важното нещо в компанията? Това, за което хората винаги го „обичат“: видеоконференции, които веднага се превръщат в критична за бизнеса система. И от бизнес гледна точка - добре, няма VKS, просто помислете, ще говорим по телефона, като при Брежнев ...
Освен това ИТ отделът обикновено смята, че основната му задача в случай на авария е да възстанови работата на корпоративните ИТ системи. Но понякога не е нужно да правите това! Ако има бизнес процес под формата на отпечатване на парчета хартия на ужасно скъп принтер, тогава не трябва да купувате втори такъв принтер като резервен и да го поставяте до него в случай на повреда. Може да е достатъчно временно да оцветите парчетата хартия на ръка.
Ако изграждаме непрекъсната защита в рамките на ИТ, трябва да привлечем подкрепата на висшето ръководство и представители на бизнеса. В противен случай, след като сте се вмъкнали в ИТ отдела, можете да решите определен набор от проблеми, но не всички необходими.
Ето как изглежда ситуацията, когато само ИТ отделът има планове за DR
10. Без тестване
Ако има план, той трябва да бъде тестван. За тези, които не са запознати със стандартите, това изобщо не е очевидно. Например, навсякъде висят табели „авариен изход“. Но кажи ми къде е кофата ти, куката и лопатата? Къде е пожарният хидрант? Къде трябва да се постави пожарогасителя? Но всеки трябва да знае това. Изобщо не ни се струва логично да открием пожарогасител, влизайки в офис.
Може би необходимостта от тестване на плана трябва да бъде спомената в самия план, но това е противоречиво решение. Във всеки случай планът може да се счита за работещ само ако е бил тестван поне веднъж. Както споменах по-горе, много често чувам: „Има план, цялата инфраструктура е подготвена, но не е факт, че всичко ще се получи, както е написано в плана. Защото не са го тествали. Никога".
В заключение
Някои компании могат да анализират своята история, за да разберат какви проблеми е вероятно да се случат и колко е вероятно да се случат. Изследванията и опитът показват, че не можем да се предпазим от всичко. Кофти, рано или късно, се случва на всяка компания. Друго нещо е колко ще сте подготвени за тази или подобна ситуация и дали ще успеете да възстановите бизнеса си навреме.
Някои хора смятат, че приемствеността е свързана с това как да се премахнат всички видове рискове, така че да не се материализират. Не, въпросът е, че рисковете ще се материализират и ние ще бъдем готови за това. Войниците се обучават не да мислят в битка, а да действат. Същото е и с плана за BCP: той ще ви позволи да възстановите бизнеса си възможно най-бързо.
Единственото оборудване, което не изисква BCP
Игор Тюкачев,
Консултант по непрекъснатост на бизнеса
Център за проектиране на изчислителни системи
"Джет Инфосистеми"
Източник: www.habr.com