Як створити план аварійного відновлення - Як

Як створити план аварійного відновлення

Ознайомтеся з основами створення плану, який дозволить вам відновити ваші дані та зберегти бізнес після катастрофи, що вимикає ІТ.

Загалом 4 кроки

Крок 1: Аналіз ризиків

Першим кроком у розробці плану відновлення після аварії є проведення ретельного аналізу ризиків ваших комп'ютерних систем. Перерахуйте всі можливі ризики, які загрожують безперервній роботі системи, та оцініть, наскільки вони неминучі у вашому конкретному ІТ-магазині. Все, що може призвести до відключення системи, є загрозою, від відносно поширених загроз, таких як вірусні атаки та випадкові видалення даних до більш рідкісних природних загроз, таких як повені та пожежі.

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

Крок 2: Створення бюджету

Після того як ви зрозуміли свої ризики, запитайте: "Що ми можемо зробити, щоб придушити їх, і скільки це коштуватиме?" Чи можна виявити загрозу, перш ніж вона потрапить? Як я можу зменшити потенціал його виникнення? Як мінімізувати його вплив на бізнес? Наприклад, наша невелика інтернет-компанія в Каліфорнії може використовувати аварійне джерело живлення, щоб зменшити загрозу відключення електроенергії, і щодня всі його дані резервуються на стрічках RAID, які зберігаються на віддаленому місці у випадку землетрусу.

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

Результати кроку 1 повинні бути всебічним переліком можливих загроз, кожен з яких має відповідне рішення і вартість. Надзвичайно важливо, щоб ІТ представляли всі ці загрози для підрозділів бізнес-операцій, щоб вони могли приймати обґрунтоване рішення щодо розміру бюджету для відновлення після аварії (тобто, які ризики компанія може дозволити собі терпіти і яку вона повинна сплатити для пом'якшення) . Емерсон вважає, що ІТ "падає" в нездатності повідомляти реальні ризики простою системи для підрозділів бізнес-операцій своїх компаній. Він каже: "Для операцій добре сказати, що ні, це не добре для ІТ, щоб не давати їм знати про ризики".

Хорошим місцем для початку є представлення вартості простою для бізнесу. Як довго ваш бізнес може дозволити собі бути без своїх комп'ютерних систем, якщо виникає одна з ваших загроз?

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

Бюджети аварійного відновлення відрізняються від компанії до компанії, але вони зазвичай складають від 2 до 8% загального бюджету ІТ. Компанії, для яких доступність системи має вирішальне значення, зазвичай знаходяться на вищому кінці шкали, тоді як компанії, які можуть функціонувати без неї, знаходяться на нижньому кінці. Однак ці відсотки можуть бути занадто малими. Для великого ІТ-магазину 15 відсотків є найкращим практичним методом згідно Емерсона.

Крок 3: Розробити план

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

Процедура відновлення повинна бути записана в детальний план або "сценарій". Створіть команду відновлення серед ІТ-персоналу та призначте кожному з членів конкретні обов'язки щодо відновлення. Спосіб, у який ваша команда проводить відновлення, ймовірно, не відрізнятиметься від звичайних виробничих процедур: ланцюг командування, ймовірно, не зміниться, а також аспекти мережі, за які несе відповідальність кожен член.

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

Крок 4: Тест, тест, тест

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

У міру зміни бізнес-середовища, так само має бути ваш DRP. Щорічно переглядайте план на високому рівні: чи потрібна вам ще кожна частина плану?

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

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

Ключем до виживання такої події є стратегія безперервності бізнесу, набір політик і процедур для реагування та відновлення після катастрофи, що відключає ІТ, а головним компонентом стратегії безперервності бізнесу є план відновлення після аварії (DRP). У цій статті DevX та Коул Емерсон, президент Cole Emerson & Associates, Inc., консалтингова фірма з безперервності бізнесу, і голова правління DRI International, адміністратори глобальної програми сертифікації для безперервності бізнесу / планувальників аварійного відновлення через основи створення ефективного DRP