Дуже часто аварійне відновлення даних фокусується на IT-системах, які допомагають підтримувати важливі бізнес-функції. Термін "забезпечення безперебійної роботи систем" часто асоціюється з аварійним відновленням. Однак ці два терміни не є повністю взаємозамінними. Аварійне відновлення є частиною забезпечення безперебійної роботи систем, де основна увага приділяється збереженню всіх аспектів бізнесу незалежно від аварії чи катастрофи. Аварійне відновлення є основною опорою в процесі забезпечення безперебійної роботи систем.
Вартість катастрофи
Економічні та операційні втрати можуть значно завдати шкоди непідготовленій компанії. Згідно з доповіддю Ради з готовності до надзвичайних ситуацій (за 2016 рік), одна година "зупинки" може коштувати малим компаніям до 8 000 доларів, компаніям середнього розміру - до 74 000 доларів, а великим підприємствам - до 700 000 доларів.
Ще одне дослідження, підготовлене компанією з аварійного відновлення Zetta, показало, що більше половини з опитаних компаній (54%) перебувала в стані зупинки більше ніж вісім годин протягом останніх п'яти років. Дві третини опитаних заявили, що їх бізнес втратить понад 20 000 доларів за кожен день зупинки.
Оцінка ризику
Навіть якщо у вашій компанії вже є план аварійного відновлення даних, можливо, настав час його вдосконалити. Але якщо у вас немає такого плану або ви тільки готуєтеся його створити, спочатку оцініть ризики. Визначте вразливості вашої IT-інфраструктури.
Але навіть знання можливих уразливих місць системи не є запорукою початку створення плану аварійного відновлення. Так, нещодавно автори Том Рупке і Стівен Голдман заявили, що створення такого плану може відволікти увагу від інших важливих загроз.
Експерти з інформаційної безпеки відзначають, що, визначаючи найгірший сценарій, наприклад, пожежу, землетрус або кібератаку, ми автоматично починаємо думати і планувати з урахуванням цієї конкретної проблеми, пропускаючи інші. Гіперконцентрація буде сфокусована лише на одній або двох конкретних областях. Ця саме проблема, за словами авторів, є найгіршим сценарієм, а не можлива "запланована" катастрофа.
Ключовим моментом, на якому наголошують Рупке і Голдман, є зосередження уваги на "управлінні кризовими ситуаціями та відновленні критично важливих функцій".
Що входить до плану аварійного відновлення даних
Введіть запит "шаблон плану аварійного відновлення" у пошуковик і з'явиться десятки, а можливо, сотні шаблонів. Використовуйте їх для початку роботи і адаптуйте план до вашого бізнесу або організації.
Сам план повинен включати наступне:
- Назва, короткий огляд і основні цілі плану;
- Контактна інформація ключових співробітників та членів команди аварійного відновлення;
- Опис дій для реагування на надзвичайні ситуації відразу після катастрофи;
- Схема та алгоритм відновлення даних;
- Схема всієї ІТ-інфраструктури.
У плані повинні бути зазначені компанії, які супроводжують програмне забезпечення або забезпечують функціонування резервного копіювання даних, власники об'єктів, управляючі нерухомістю, а також перелічені контактні особи і способи зв'язку з ними у випадку аварійної ситуації.
Визначення найважливіших ІТ-активів та максимальний час відключення
Вивчіть терміни "Цільова точка відновлення" (RPO) та "Час відновлення" (RTO).
RTO - це час, протягом якого інформація повинна бути відновлені з резервного сховища для нормального функціонування після катастрофи.
RPO - максимально допустимий період часу за який припустима втрата інформації.
Складіть і періодично оновлюйте список програмного забезпечення, ліцензійних ключів та систем, які будуть використовуватися в процесі відновлення.
Підготуйте технічну документацію від провайдера послуг резервного копіювання даних (BaaS-провайдера) на програмне забезпечення та процедуру відновлення; додайте в схему відновлення інформації посилання на необхідні розділи цієї документації.
Розробіть пакет пропозицій з вирішення фінансових і юридичних питань, а також правила розголошення інциденту в засобах масової інформації.
Створення команди з аварійного відновлення даних
План повинен бути постійно доступний для членів команди, відповідальних за критичну ІТ-інфраструктуру всередині компанії. Крім того, директор компанії та керівники структурних підрозділів повинні бути ознайомлені з планом.
Після того, як план буде створений і затверджений керівництвом, протестируйте його і, за потреби, оновіть. Обов'язково вкажіть наступний період актуалізації та/або аудиту функцій аварійного відновлення. Ви повинні вдосконалювати план, а не відкидати його, поки не відбудеться катастрофа.
Сталася катастрофа – що робити?
Якщо катастрофа все ж таки сталася, настав час реалізовувати план. Переконайтеся, що команда реагування на інцидент (якщо вона відрізняється від команди планування аварійного відновлення) має копію плану аварійного відновлення.
Реагування на інцидент включає оцінку ситуації, відновлення систем та подальші дії з відновлення нормального функціонування бізнес-процесів у компанії.