Disaster Recovery (аварійне відновлення): що це таке та для чого його впроваджують

Disaster Recovery (DR, аварійне відновлення) — це процес підготовки IT-інфраструктури компанії до швидкого відновлення в разі збою, що може призвести до втрати даних.

Disaster Recovery Plan (DRP) — це аварійний план дій, який визначає, що, коли та в якій послідовності робити.

Disaster Recovery Plan містить:

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

Іноді бізнеси плутають два поняття: Disaster Recovery та Business Continuity. У першому випадку йдеться про те, як відновити IT-інфраструктуру (сервери, дані та застосунки) після аварії, а в другому — як компанія працюватиме під час та після збою, навіть якщо IT-сервіси ще не відновлено.

Disaster Recovery Plan відрізняється залежно від розміру компанії, її цілей та специфіки інфраструктури. Єдиного універсального шаблону не існує, однак є базові кроки, спільні для більшості бізнесів:

1. Проаналізуйте вплив можливих загроз на бізнес (Business Impact Analysis, BIA). Оцініть фінансові ризики від простою: втрата доходу та клієнтів, вартість відновлення репутації, штрафи за порушення вимог.
2. Оцініть ризики та сценарії інцидентів. Спочатку пропишіть усі можливі загрози: кібератаки, відмови обладнання або мережевої інфраструктури, збої програмного забезпечення, людські помилки, збої в роботі дата-центрів або хмарних провайдерів. Для кожного сценарію загрози треба розробити окремий план відновлення.
3. Визначте, які метрики аварійного відновлення відстежувати та яких показників прагнути досягти.

Аварійне відновлення характеризують два основні показники:

RTO (Recovery Time Objective) —  максимальний допустимий час простою сервісу після інциденту. Якщо RTO — 2 години, система повинна бути відновлена не пізніше ніж за 2 години після аварії. 

RPO (Recovery Point Objective) — максимальний обсяг даних, які компанія готова втратити. RPO у 15 хвилин означає, що резервні копії або реплікація мають виконувати не рідше ніж кожні 15 хвилин. 

Також відстежують Recovery Success Rate — відсоток успішних процедур відновлення від загальної кількості спроб, Mean Time to Recover (MTTR) — середній час, необхідний, щоб повністю відновити роботу після аварії, та Availability — рівень доступності сервісу протягом певного періоду. 

1. Інвентаризуйте активи. Пропишіть, яке апаратне й програмне забезпечення, сервіси та дані критично важливо відновити в першу чергу.
2. Визначте ролі та обов’язки. Бізнес має знати, хто кому звітує у разі аварії, хто відповідає за план аварійного відновлення і хто виконує його.
3. Реалізуйте механізми відновлення. Налаштуйте автоматичне створення резервних копій та реплікацію даних між середовищами або дата-центрами.
4. Регулярно тестуйте Disaster Recovery Plan. Перевіряйте час відновлення та цілісність даних, знаходьте слабкі місця та усувайте їх. 

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

Рішення аварійного відновлення відрізняються показниками RTO та RPO — чим вони менші, тим складніша і дорожча архітектура DR.

Backup & Restore (резервні копії та відновлення). Базовий підхід: компанія регулярно робить копії даних та зберігає їх на резервному носії або в хмарі. Після аварії дані відновлюють на нове або відремонтоване обладнання вручну. 

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

Pilot Light. Назва запозичена з газових котлів: маленький вогник завжди горить, щоб у потрібний момент запалити полум'я. Мінімальна критична інфраструктура постійно працює в резервному середовищі. В разі аварії середовище «роздмухується» до повного розміру: запускають додаткові сервери, налаштовують мережу, перенаправляють трафік.

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

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

Це рішення для великого бізнесу, e-commerce з помітним денним трафіком, SaaS-компаній. Якщо годинний простій коштує вам сотні тисяч гривень — Warm Standby починає окупатися. 

Hot Standby / Active-Active. Хмарна модель — два або більше повністю активних середовища працюють одночасно і рівномірно розподіляють навантаження між собою. Якщо одне падає — інше миттєво бере трафік на себе. Для користувача це відбувається непомітно. 

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

DRaaS (Disaster Recovery as a Service). Хмарна модель, у якій провайдер бере на себе всю або більшу частину інфраструктури аварійного відновлення. Компанія платить щомісячну підписку та отримує гарантовані показники RTO/RPO, автоматичну реплікацію даних та автоматизоване тестування. 

Рішення підходить як малому бізнесу, так і великим компаніям — усім, хто хоче отримати гарантоване аварійне відновлення без інвестицій у власну інфраструктуру.

Читайте також: 

• 5 причин для бізнесу долучитися до Маркетплейса цифрових рішень;
• Data governance: як побудувати систему управління даними в компанії;
• Як відкрити ФОП в Україні: покрокова інструкція для підприємців.