Стаття розрахована на ІТ персонал і власників малого та середнього бізнесу, для яких важливі безперебійність і результативність роботи їх підприємств. Стаття для тих, хто замислюється про Плануванні Безперервності їх Бізнесу (business continuity plan або BCP).

Що Ви дізнаєтеся з цієї статті: це короткий тематичне вступ і кілька технічних моментів (tips), які повинні допомогти підвищити надійність Ваших ІТ систем та бізнесу взагалі.

Важливість даного питання полягає в тому, що деякі IT-менеджери і власники бізнесу впевнені, що "нічого подібного не відбувалося раніше" ну або "ми щомісяця робимо копії". Або є менеджери, які поки що не знають, як побудувати стратегію відновлення бізнесу після аварій. У будь-якому випадку, це часто призводить до неготовності швидкого відновлення бізнесу після збоїв.

Деякою аналогією буде автострахування. Автори зв'язалися з керівництвом найбільшої страхової компанії України і з подивом дізналися, що менше 20% власників вантажних автомобілів інвестують кошти в страхування КАСКО. Це означає, що в разі поломок і аварій тільки у кожного п'ятого такого автовласника є можливість швидко відновити свій бізнес.

Однак, якщо за певних умов страхування автомобіля страхова компанія допоможе з компенсацією деяких збитків, то в разі втрати інформації допомогти бізнесу ніхто не зможе. Адже такого виду страхування на ринку України просто не існує.

Що це таке

План аварійного відновлення (Disaster recovery plan, DRP) є частиною плану забезпечення? (Я б сказав організації) безперервності бізнесу (business continuity plan, BCP) і визначає порядок черговості вирішення проблем, які можуть виникати в IT-системах через можливих збоїв і навіть катастроф.

Якщо я є ІТ-консультантом , То BCP включає в себе питання здоров'я (страховка), питання зв'язку (телефонна і месенджери) і апаратного забезпечення, резервування та відновлення даних (наприклад - ssh ключів), юридичні та податкові питання, контакти клієнтів і так далі.

Відповідно, в DRP повинні бути відображені тільки питання відновлення ІТ складової бізнесу (моб. Зв'язок, інтернет та інше).

Розробка і впровадження таких планів - не такий дорогий питання, як здається. Для ІТ-консультанта може бути досить придбання запасного каналу в Інтернет, регулярне резервування даних (і їх відновлення), придбання UPS, бакапи телефонної книги і знання адреси найближчої піцерії, де є безкоштовний wi-fi :)

Disaster Recovery Plan - це чіткий і докладний опис дій ІТ персоналу компанії в разі виникнення певних позаштатних ситуацій (відключень сервісів або систем), які можуть перешкодити роботі організації. Це не тільки власне план, але чек-листи для перевірки, чи все було зроблено на тому чи іншому етапі. Це і заздалегідь описані повноваження для певного кола посадових осіб, які відповідатимуть за підготовку та реалізацію цього плану.

Це означає, що будь-який серйозний збій (наприклад, збій диска на корпоративному поштовому сервері ) Або навіть катастрофа (пожежа в серверній) призведе до короткочасного, заздалегідь прогнозованого, перерви в роботі. Отже, повинні бути попередньо спрогнозовано загрози і ризики , Оцінені вартість простою і відновлення, продумані процедури по відновленню сервісів і даних. І що важливо, всі ці оцінки, розрахунки і процедури повинні бути задокументовані.

І ще кілька важливих зауважень - почати думати про це треба якомога раніше, щоб потім не виявилося пізно; проектувати DRP повинні не тільки сисадміни , А й власники бізнесу; і це не одноразова завдання а постійний процес, що вимагає пильної уваги. Як і у випадку з бізнес-процесами, необхідно регулярно тестувати DRP, а за результатами перевірок - покращувати його.

Як приклад буде приведена фірма "Автотрейд" (назва і деякі обставини змінені). Приклад заснований на реальних подіях. Фірма займається поставками і продажем автозапчастин та інструментів для станцій техобслуговування легкових і вантажних автомобілів. Має бекенд-офіс (15 осіб), непоганий склад недалеко від головного офісу (10 працівників) і кілька віддалених точок.

Власникам фірми подобається їхній бізнес (і рід занять гідний і, здається, є непоганий дохід). Вони готові інвестувати певні ресурси в Безперервність їх Бізнесу.

Через кілька років після створення початкового плану аварійного відновлення (disaster recovery plan, DRP) у фірми сталася неприємність, але завдяки наявності такого плану це суттєво не вплинуло на бізнес (мова про це буде йти далі).

етапи

Дізнайтеся Ваш бізнес

Найбільш важливим і важким кроком є ​​оцінка, як незаплановані відключення тих чи інших сервісів вплинуть на роботу організації. Цей крок називається аналізом впливу на бізнес (business impact analysis або BIA). Не маючи можливості визначити вплив незапланованих відключень, неможливо створити адекватну поточну ситуацію стратегію відновлення.

Термін "Незапланірованноие відключення" відноситься до будь-якого непередбаченого події, яке перериває нормальну роботу організації на деякий час. Прикладами можуть бути збої ІТ-систем (однієї або декількох), пожежа, відключення електроенергії або навіть рейдерська атака . Залежно від характеру цього збою, це може привести організацію до втрати доходів, розкриття конфіденційних даних про клієнтів або навіть виходу з бізнесу.

Основні питання, на які потрібно знайти відповіді:

1. Наскільки важлива кожна функція для організації. Відповідь, природно, залежить від того, наскільки сервіс впливає на доходи організації.

2. На яке максимальний період часу бізнес-функція може бути перервана? Іншими словами, скільки часу пройде з припинення роботи сервісу до моменту, коли це почне негативно впливати на надходження доходів?

3. Скільки реальних і потенційних клієнтів можуть бути втрачені без серйозного впливу на бізнес?

І останнім питанням буде

4. Від яких IT-структур залежить бізнес.

В процесі написання початкового DRP спільно з "Автотрейд" було вирішено, що найбільш важливою бізнес-функцією буде прийом і постачання замовлень існуючим клієнтам, так як це головна стаття доходу.

Це означало, що в разі аварії / катастрофи в першу чергу повинні бути відновлені:

• 1С + Система клієнт-банк
• телефони відділу продажів
• друк товарних накладних та податкових накладних (видаються одночасно з товаром)

Другий за важливістю була функція придбання товарів у партнерів. Для цього використовувалися електронна пошта і ICQ ( Skype був в ті часи слабо поширений).

Ці дані були використані при розробці стратегії відновлення - в першу чергу відновлювалися ті бізнес-функції, які приносили гроші. Менш важливі функції ( файл-сервер з внутрішніми документами) відновлювалися в останню чергу.

Результати цього етапу були задокументовані і стали основою для подальшої роботи. Хочеться підкреслити, що документувати слід кожен етап, а не тільки власне процедури відновлення, оцінювати слід в реальних одиницях (гроші, годинник, клієнти), а не в абстрактних одиницях ( "багато клієнтів" або "це важлива річ"). І такий аналіз неможливо провести без участі фінансових служб організації.

Сумарні витрати на цьому етапі були - близько 20 годин роботи персоналу і пакет кави + гонорар консультанта :)

Для внесення заміток використовувалися офісний пакет ( openoffice.org ) І карта пам'яті (kdissert).

Оцініть ризики

Якщо BIA допомагає ідентифікувати найбільш важливі бізнес-процеси і описує потенційний вплив збоїв цих процесів, то оцінка ризиків визначає внутрішні і зовнішні ситуації, які можуть негативно позначитися на критичних процесах.

Оцінка ризиків повинні бути в змозі допомогти вам визначити події, які можуть негативно вплинути на вашу організацію. Це включає в себе потенційні негативні події, які можуть статися, кількість часу, необхідне для відновлення операцій, заходи, які можуть зменшити ймовірність події.

Ризики ділять на дві групи:

Природні, як-то Шторми, Урагани, Грози, Затоплення, Землетруси та Цунамі.

Штучні (свідомі й несвідомі). До них можна віднести Злом, Шахрайство, Страйки персоналу, Тероризм, Пожежі, Помилки в ПО, збої апаратного забезпечення, помилки персоналу, збої харчування і навіть падіння каналу в Інтернет.

Частина ризиків (особливо ІТ) можуть бути досить точно оцінені. Наприклад, наявність системи моніторингу і наявність журналу заявок користувачів допоможе досить точно оцінити ймовірність збоїв ІТ систем.

В "Автотрейд", на щастя, був журнал заявок (тоді це була звичайна електронна таблиця ) І його аналіз дозволив зрозуміти, що основними проблемами були віруси (У відділі продажів) і регулярно палаючі блоки живлення.

Також була встановлена ​​система моніторингу Nagios і описані процедури реагування на Алерт #, що дозволило системному адміністратору побачити деякі збої ще до того, як це вплинуло б на бізнес. Наприклад, можна було побачити, що закінчується місце на диску робочої станції.

щоб зменшити ризики від вірусів , Відділ продажів (7 осіб) ще на цьому етапі був переведений на Linux з можливістю підключення до термінального сервера Windows . Це дозволило в майбутньому спростити відновлення даних - всі дані були на сервері.

При оцінці ризиків слід виходити зі здорового глузду. Наприклад, для організації, розташованої на самому узбережжі моря (прикладом буде при-портова організація де-небудь в Одесі) ймовірність події "Шторм" набагато вище, ніж для офісів, розташованих в Києві. А розташування офісів в гарячих точках планети набагато підвищує ризик "Тероризм" або "Бомбардування". Ризик "Крадіжка" в добре охоронюваному офісному центрі набагато нижче, ніж в приміщенні на території непрацюючого заводу.

Чим загрожують ті чи інші ризики?

Можна виділити п'ять основних наслідків, які можуть мати катастрофічні для бізнесу наслідки: відмова в доступі, втрата даних, втрата кадрів, втрата функцій і відсутність інформації (до чого це призведе).

Наприклад, падіння каналу виходу в Інтернет призведе до того, що не буде можливості обмінюватися електронною поштою, але Ваші дані залишаться у Вас. А от у випадку Пожежі або крадіжки дані доступні не будуть (або будуть, але не Вам).

Це призводить до того, що зменшується грошовий потік, завдається шкода іміджу фірми або бренду, втрачається частка на ринку, падає моральний дух співробітників і збільшується плинність кадрів, зростають юридичні витрати і так далі.

Що важливіше - повинен вирішувати саме бізнес.

На практиці, в процесі оцінки ризиків найбільш складним було оцінити ймовірність тієї чи іншої події і наслідки.

Розмова з керуючим дозволив припустити, що ризик пожежі в головному офісі досить великий ( "Автотрейд" орендував приміщення в виробничій будівлі одного з заводів), а ось ризик захоплення підприємства був відносно невеликий, так як підприємство в ті часи не виділялося розмірами серед безлічі інших.

Основними ризиками були штучні. Ті, які приводили до втрати даних (наприклад - Пожежа).

Для автора статті було цікавим відкриттям, що [на відміну від аутсорсингових фірм ], Плинність кадрів істотно не впливала на бізнес. Справа була в тому, що з 7 співробітників відділу продажів п'ятеро були фактично операторами, що фіксують заявки. Розуміння цього моменту дозволило спростити процедуру відновлення (в першу чергу повинні були бути відновлені робочі місця саме двох цінних співробітників).

Як і в минулому етапі, основні витрати це робочий час фінансового директора і власників організації.

Використовувалися офісний пакет ( openoffice.org ) і карта пам'яті (Kdissert), ALT Linux, Nagios + кілька самописних скриптів .

Розробіть стратегію відновлення

Після того, як визначені критичні функції і оцінені наслідки збою, можна розробляти стратегію відновлення, покликану допомогти запобігти або пом'якшити фінансові втрати.

Ключовим фактором розробки повинно бути розуміння, що загальна вартість відновлення не може перевищувати втрати, які вона покликана запобігти.

Слід враховувати географічне розташування деяких сервісів. Наприклад, розташування вебсервера у хостера означає, що розробити стратегію відновлення досить складно. Або зміна місця розташування організації означає неможливість швидкої організації інтернет-каналів за допомогою ВОЛЗ або DSL, тому необхідно врахувати придбання 3G обладнання

Виходячи з проведеної оцінки ризиків, в первісному DRP була розроблена наступна стратегія відновлення: максимально швидко зібрати команду для відновлення, повідомити клієнтів і партнерів про виниклі проблеми, відновити в першу чергу спочатку сервіси приносять гроші. З огляду на високу конкуренцію на ринку, було вирішено визначити термін відновлення в 1 робочий день.
Перший лист Стратегії складався приблизно з таких пунктів:

1. інформування про проблему власників і керуючого фірми
   вимагало створення відповідної процедури;
2. придбання у постійного постачальника обладнання відповідного сервера, мінімум 1 робочої станції і принтера вимагало попередньої домовленості з постачальником;
3. установка обладнання на складі і розміщення там персоналу
   вимагало розміщення додаткових 3 столів і протягування локальної мережі ;
4. установка системного і прикладного програмного забезпечення на сервер вимагала наявності бакапов, повного списку ПО і чек-листів;
5. відновлення реальних 1С (в ті часи версії 6) вимагало регулярних бакапов і чек-листів;
6. установка ПО клієнт-банк вимагало домовленості з Банком;
7. використання безкоштовних поштових скриньок на час повного відновлення ІТсістеми вимагало заздалегідь повідомити Замовників і Партнерів про наявність резервних поштових скриньок і ведення списку контактів клієнтів

Важливе зауваження: вартість відновлення не повинна бути дорожче, ніж вартість завданих збитків. Це важливо, тому що системи повинні бути економічно вигідні, вони повинні підтримувати бізнес, а не "тягнути з нього соки".

Наприклад, якщо віддалена робоча точка приносить чистого прибутку 50 гривень в день, то відновлення можна зробити "в плановому" порядку - наприклад, під час щотижневої регулярного відвідування. І навпаки - якщо простій інтернет-магазину призводить до втрат 5000 гривень на добу, то DRP повинен передбачати відновлення протягом короткого часу і вартістю до цієї суми. А для системи онлайн-бронювання квитків цілком може бути вигідним побудова HA кластера.

формалізує

Наступним кроком буде документування стратегій і процедур відновлення, що є основою для плану аварійного відновлення. Ні, не так - обов'язково документуються всі етапи.

DRP повинен бути формалізований і легалізований. Нехай на початковому етапі це буде кілька простих документів . Для розробки точних і докладних планів аварійного відновлення буде потрібно час.

На "високому рівні" (hight point of view), план аварійного відновлення повинен визначити пріоритети для відновлення систем, оцінювати приблизний час відновлення, процедури відновлення, а також розташування резервних копій даних і контактів для ключових залучених співробітників. Легалізація полягає в тому, що іноді потрібен дозвіл на доступ на територію організації в будь-який час. ІТ персоналу можуть знадобитися повноваження викликати бухгалтерів для перевірки відновлених систем.

Згадуючи "Автотрейд" слід, сказати, що на "етапі документування" було зроблено практично також вкладення в апаратне забезпечення:

• За результатами стратегії були написані купа інструкцій, чек-листів, наказів і списків (не менше півсотні листів).
• Було придбано запасне обладнання: потужна машина ( "бакап сервер" і вона ж - "сервер на час збоїв"), два запасних вінчестера (для бакапов) і кілька метрів кабелю UTP.
• На склад був проведений резервний канал в Інтернет, причому від іншого провайдера .
• Була перероблена система резервного копіювання - дані з одного офісу копіювалися в іншій щодня. Були зняті приблизні (зразкові) образи системних дисків і написані інструкції зі швидкого встановлення на нове обладнання.
• І в бек-офісі і на складі було обладнано по три запасних робочих місця (по факту - проведена локальна мережа і підготовлені запасні стільці)
• Сумарні витрати на обладнання на цьому етапі перевищили оплату 1,5 місяці роботи місцевого сисадміна. Звичайно, при використанні пропрієтарного програмного забезпечення сума зросла б у кілька разів.

Використовувалося лише вільне ПЗ під Linux і Windows . Це були офісний пакет ( openoffice.org ) І карта пам'яті (kdissert) для створення документів, а також ПО для створення резервних копій і відновлення даних.

регулярно тренуйтеся

Тестування плану всегда поможет візначіті, Які елементи НЕ опісані и повінні буті додані. Звичайно, подібне тестування вимагає часу і апаратних засобів, проте це набагато краще, ніж знаходити прогалини в планах вже під час (після) стихійних лих.

Кожен раз, коли процедура відновлення протестована, виявлені недоліки і зроблені поліпшення в плані, Ваша організація має все більше впевненості в тому, що бізнес буде тривати всупереч неприємностей.

Перший же тест в "Автотрейд" показав наявність вузьких місць в DRP. Було кілька великих недоліків, з найсмішніших:

- відновити сервер з образів диска з використанням LiveLinux складно при наявності всього лише одного CDROM приводу (звідки читати образ оригінального системного диска?)

- працювати на "новому сервері" було незручно, так як просто забули, що до нього потрібно підключити монітор :)

- були продумані питання ліцензійного характеру

Однак в цілому, тренування пройшло успішно:

- "новий офіс" був запущений за 1 день (з 10 ранку до 4 дня)

- В 1С потрапили всі "вчорашні" платежі

- пошта і інтернет працювали, можна було по ICQ / поштою спілкуватися з партнерами / замовниками

Звичайно, план був поліпшений. Завдання було виконано. Для відновлення використовувалося тільки вільне програмне забезпечення (KNOPPIX-UA) + скрипти, розроблені для клієнта.

Давайте підрахуємо, у що обійшлося створення плану:

• гонорар консультантам (близько двомісячної оплати місцевого сисадміна)
• придбання додаткового обладнання ( потужний десктоп + монітор, зовнішні вінчестери )
• придбання запасного каналу в Інтернет, створення додаткових портів ЛВС в обох офісах
• придбання пари столів і стільців, багато кави для консультантів
• і близько 80 годин роботи персоналу фірми "Автотрейд".

Що отримав замовник?

• розуміння свого бізнесу. Який саме бізнес процес приносить гроші безпосередньо і який - опосередковано. Іронія в тому, що розповіли йому про це айтішники;
• систему моніторингу. Яка дозволяє оцінити поточний стан і зробити прогноз (що скоро може приносити проблеми);
• впевненість (перевірено на практиці) в тому, що бізнес буде продовжений у разі катастрофи;
• ще одна цеглинка в побудову свого бізнесу.

замість післямови

Історія "Автотрейд" мала продовження ...

Через деякий час фірма реорганізувала сайт-візитку в щось типу он-лайн каталогу продукції / он-лайн системи замовлення.

Відповідно, план повинен був бути змінений.

Оновлений план включав розділ "Відновлення Порталу". Були описані відповідні процедури, створено і встановлено ПО на веб-сервері і в бекофісе. І рівно через рік, навесні минулого року план довелося привести у виконання - була сильна пожежа у великого одеського хостера, де сайт і жив.

Нижче наведена хронологія подій з боку "Автотрейд":

1. День перший:
   1. система моніторингу прислала повідомлення "сайт не доступний". Це було критично, так як з сайту приходила значна частина замовлень.
   2. протягом години сисадмін намагався безуспішно додзвонитися до провайдера . Після цього було інформовано керівництво фірми. Так як це був вихідний день, було вирішено відкласти рішення на добу.
   3. день другий

. в неділю була запущена процедура "Відновлення Порталу"

1. з щоденних копій бази даних були витягнуті дані про всіх клієнтів. Клієнти були інформовані електронною поштою про проблему з сайтом і запропоновано виробляти замовлення по електронній пошті. Це дозволило розвантажити телефони і не втратити клієнтів
2. DNS (Розташовувався в іншого провайдера) був повернений на сайт-заглушку з тими ж рекомендаціями (сайт андер Констракшен, однак контора працює. Прийом замовлень по тому ж милу що і завжди)
   1. День третій (понеділок)

. вранці був куплений в заздалегідь придивились місці хостинг

1. в обід з щоденних бакапов був повністю відновлений сайт і повернуть DNS
2. ввечері в понеділок сайт повністю функціонував
3. всі зареєстровані клієнти були сповіщені про те, що сайт повністю працює

"Автотрейд" - B2B фірма, середня сума одного замовлення набагато перевищує 1000 гривень. Саме тому при розробці DRP було вирішено, що термін відновлення сайту не більше 1 робочого дня.

Сумарна вартість відновлення становила річну оплату хостингу на новому місці. Звичайно, напевно були ще витрати - на телефонні переговори , Може бути, ще на премію сисадміну :)

Цікаво, скільки грошей в день втратили і втрачають фірми, які не мають DRP і потрапляють в такі ж ситуації?

Післямова

На жаль, в нашому регіоні звикли покладатися "на авось". Яскравим прикладом буде страхування КАСКО, згадане на початку статті. Проведений авторами опитування показало, що менше 5% невеликих організацій і фірм інвестували ресурси в створення і підтримку DRP. В кінці-кінців, це окупається тільки після збою. мабуть тому аутсорсингові фірми не пропонує подібних послуг, а кінцеві споживачі не так часто замислюються про це.

Але в міру дорослішання бізнесу це питання стає все більш актуальним. Однак навіть серйозний бізнес зацікавлений впроваджувати економічно обґрунтовані Плани Відновлення Бізнесу.

Знизити вартість інвестицій в DRP допоможе використання opensource систем (відмінну якість рішень і продуктів при відсутності плати за право використання) і широкий обмін практичним досвідом.

Для тих, хто хоче дізнатися більше вже сьогодні, інформацію можна знайти за адресою http://www.disaster-recovery-guide.com/ - Guide to getting started with Disaster Recovery. Сайт виглядає протухлих, проте методологія і ключові моменти викладені компактно і повно.

Wad V Mashckoff aka Adiel, IT philosopher
ICQ 201205466 E-mail: [email protected]
Linux.Kiev.UA * OpenOffice.org * migration.OSDN.org.ua