Відновлення після катастроф: створення плану

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

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

Контрольний список

• Визначте критичні для місії додатки, системи та платформи

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

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

• Оцінка та впровадження

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

Хмарна пошта та зберігання

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

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

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

Програми, сервери та віртуалізація

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

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

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

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

Потужність

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

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

Телекомунікації та віддалений доступ

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

План також повинен враховувати, як кінцеві користувачі матимуть доступ до систем у надзвичайних ситуаціях. Багато кінцевих користувачів мають випущені компанією або персональні мобільні пристрої, які можна налаштувати на віддалений доступ до корпоративної мережі. Більшість організацій вже мають якесь рішення щодо віртуальної приватної мережі (VPN), що дозволяє віддалено входити в бізнес-мережу. Чи працює ця система VPN насправді, і чи не технічні працівники адекватно навчені її використовувати без інтенсивної ІТ-підтримки, яка може бути недоступною під час катастрофи? Чи може це VPN чи рішення віддаленого доступу протистояти катастрофі? Слід також врахувати резервну копію VPN. Це може бути сервер VPN на іншому сайті або доступ до даних і систем через хмарного постачальника замість звичної системи VPN.

Деякі організації можуть мати рішення віддаленого доступу, яке надасть доступ віддаленого пристрою до корпоративної мережі лише після сканування певних необхідних сумісностей. Наприклад, клієнтському пристрою Windows, у якого відсутній необхідний пакет оновлень або файл антивірусного визначення, може бути заборонено доступ до корпоративної мережі. Ви не хочете подібних сюрпризів у надзвичайних ситуаціях. У рамках готовності до стихійних ситуацій детально ознайомтеся з тим, як і які клієнтські пристрої матимуть доступ до мережі в надзвичайних ситуаціях. Регулярно перевіряйте ці пристрої, щоб переконатися, що вони можуть отримати доступ до мережі. Тут організація може захотіти розглянути рішення щодо управління мобільними пристроями (MDM), яке дозволяє централізоване управління мобільними пристроями, що мають доступ до корпоративної мережі.

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

• Документ

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

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

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