Всім привіт мене звуть Ігор Тюкачов, і я консультант з безперервності бізнесу. У сьогоднішньому посту ми довго і нудно обговорюватимемо великі істини я хочу поділитися своїм досвідом і розповісти про основні помилки, які допускають компанії при розробці плану забезпечення безперервності своєї діяльності.
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