`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрій Михайленко

Ефективна реалізація стратегії аварійного відновлення

0 
 

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

Найбільш розповсюджені причини простоїв, згідно з Uptime Institute —  проблеми з мережею, ПЗ і відключення електроенергії. По інформації Coveware, у результаті атаки програм-вимагачів компанія може простоювати в середньому 16 днів.

Стратегія аварійного відновлення поєднує план аварійного відновлення (DRP, Disaster Recovery Plan), план забезпечення безперервності бізнесу (BCP) і план реагування на інциденти. Вони покривають собою всі незаплановані інциденти, які потенційно можуть призвести до простою: від перебоїв з електропостачанням і стихійних лих до кібератак.

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

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

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

●   RTO (Recovery time goal, «цільовий час відновлення») — час, протягом якого IT-системи залишаться недоступними після інциденту.

●   RPO (Recovery point object, «цільова точка відновлення») — період часу, для якого дані можуть бути втрачені. Насправді це дані, які компанія дозволить собі втратити без серйозних збитків.

●   DRaaS (Disaster Recovery as a Service, «аварійне відновлення як сервіс») — послуга аварійного відновлення ІТ-інфраструктури на потужностях постачальника послуг, частіше за все хмарного провайдера. Саме він створює, керує та підтримує інфраструктуру для відновлення роботи сервісів клієнтів, а також надає необхідні програмні інструменти.

За даними Fortune, у 2024 році ринок DRaaS склав 12,8 млрд дол., а до 2032 року сягне 64,4 млрд дол. із середньорічним темпом зростання на 22,4%. Зростанню ринку серед інших факторів сприяє масове впровадження генеративного ШІ.

Ось 5 кроків для реалізації стратегії аварійного відновлення. Ці кроки будуть універсальними для будь-якого бізнесу незалежно від розмірів і сфери діяльності.

Оцінка наслідків загроз
Необхідно зрозуміти, як можливий простій ІТ-інфраструктури вплине на конкретний бізнес. Для цього використовують BIA (Business Impact Analysis) — дослідження наслідків загроз (кібератаки, стихійні лиха, викликані людським фактором та інші помилки) і того, як вони впливають на ключові бізнес-процеси або компанію в цілому. Вона повинна зрозуміти, як простої в роботі можуть трансформуватися в репутаційні та матеріальні втрати. Останні включають як збитки в момент (недоотриманий прибуток), так і штрафи, які накладають регулятори ринку в деяких сферах.

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

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

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

Тест і оптимізація
Розробка стратегії аварійного відновлення — не разовий захід. Навіть після того, як ви переконаєтеся в її життєздатності, необхідно буде постійно доробляти й покращувати окремі процеси. І на кожному етапі потрібне тестування в умовах, наближених до реальних. Це допоможе виявити та усунути помилки до настання реального інциденту.

Комп’ютерний розум: генеративний штучний інтелект у рішеннях AWS

0 
 

Напечатать Отправить другу

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

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT