Ви вже знаєте, що BC/DR є критично важливою складовою успіху організації. І ми знаємо, що для вимірювання ефективності зусиль потрібні показники. Першим кроком є розуміння показників, які важливі для безперервності бізнесу та планування аварійного відновлення, про що й піде мова в цій статті. Вам також знадобиться інструмент для збору цих показників і звітування про них. Залежно від розміру вашої організації та рівня зрілості вашої програми BC/DR це може варіюватися від шаблону Excel до потужного автоматизованого програмного забезпечення.
Існує 7 важливих показників BC/DR, які слід контролювати, щоб розвивати та вимірювати плани відновлення:
Хоча існує багато інших показників для моніторингу, ці показники служать базовим оглядом програми та вказують на те, наскільки добре ви справді готові до вирішення проблеми блокування.
Перші два важливі показники BC/DR — цільовий час відновлення (RTO) і цілі точки відновлення (RPO). RTO — це максимально прийнятна кількість часу, протягом якого елемент може простоювати. RPO визначає, скільки років даних ви можете дозволити собі втратити, і чи збережуть ваші резервні копії решту. Наприклад, якщо ви можете дозволити собі втратити годину даних, вам потрібно буде робити резервні копії принаймні щогодини.
Процедури резервного копіювання та відновлення є основою гарного плану BC/DR, тому вам потрібно розглянути як RTO, так і RPO, щоб визначити найкращі інструменти резервного копіювання та відновлення для роботи. Наприклад, якщо ви генеруєте безперервні транзакції з помірним або великим обсягом і вартістю, скільки хвилин транзакцій ви можете собі дозволити втратити? Як довго ви можете дозволити собі бути поза службою? Така програма може отримати вигоду від дуже частого резервного копіювання на рівні блоків, можливого за допомогою безперервного захисту даних (CDP), але ви не дізнаєтесь про це, якщо не подивіться на RTO та RPO.
Нарешті, потрібно виміряти кількість планів, які охоплюють кожен бізнес-процес , так само, як час, що минув з моменту оновлення кожного плану . Ключові показники ефективності (KPI) є показником того, наскільки добре працює програма, і їх не можна ігнорувати. Ви можете встановити KPI для того, як часто ви переглядаєте та оновлюєте свої плани (наприклад, щомісяця, 6 місяців або щороку), а також скільки бізнес-функцій охоплює план відновлення з планом дій для досягнення 100% охоплення. Якщо у вас бракує часу та ресурсів, почніть із найважливіших бізнес-процесів.
Компанії можуть мати від сотень до тисяч процесів, і неможливо відновити процес без плану. Ключовим показником для планування BC/DR є кількість процесів, яким загрожує потенційна катастрофа .
Ви повинні почати з аналізу ризиків і аналізу впливу на бізнес, щоб:
Потім ви можете створити плани захисту цих процесів і мінімізації збоїв у разі аварії.
Але статичні плани можуть застоятися. Ви не можете відкотити процеси, якщо не будете періодично оновлювати свої плани з урахуванням змін у програмах, даних, середовищах, співробітниках і ризиках. Ви повинні встановити для себе нагадування про швидкий перегляд плану у відповідні моменти циклу. В ідеальному світі ви отримали б підтвердження від керівників різних відділів, що вони переглянули та оновили свої плани, але давайте будемо чесними: перегляд і оновлення цих планів – це величезна проблема, і це майже диво, якщо вони встигають це зробити. Використання програмного забезпечення може полегшити цю болючу точку: ви можете автоматизувати нагадування електронною поштою різним власникам планів і відстежувати їхній прогрес у програмному забезпеченні – не потрібні пасивні агресивні електронні листи! Програмне забезпечення також усуває багато нудних завдань, пов’язаних із керуванням змінами. Наприклад, автоматизована інтеграція даних автоматично оновлюватиме ваші дані в міру зміни даних в інших програмах. Якщо один контакт використовується в 100 планах і його номер телефону змінюється, інтегрована система внесе цю зміну також у ваші плани безперервності бізнесу та управління в надзвичайних ситуаціях.
Один із найпростіших способів визначити, наскільки бізнес-функції взаємозалежні, — це використовувати інструмент моделювання залежностей. Це допоможе вам уявити, чи дозволяють залежності вашої програми відповідати RTO та SLA.
Наприклад, якщо вам потрібно відновити послугу «Кредиторська заборгованість» за 12 годин, але це залежить від фінансового програмного забезпечення, для відновлення якого може знадобитися до 24 годин, «Кредиторська заборгованість» не може відповідати 12-годинному SLA. Модель залежностей динамічно ілюструє ці залежні зв’язки, а також те, коли та як план руйнується в результаті.
Ви повинні вимірювати фактичний час, необхідний для відновлення бізнес-процесу . Ви можете протестувати процедури відновлення за допомогою інструменту BC/DR, щоб відстежувати, скільки часу займає кожен крок.
Крім того, ви можете використати старий метод вимірювання часу кожного кроку вручну. Ці тести допоможуть вам визначити, чи можуть ваші люди та процеси відповідати RTO за допомогою вашого існуючого плану. Ви повинні бути в змозі виконати завдання відновлення протягом часу, передбаченого вашим планом, і якщо ви не можете, вам потрібно переглянути свій план, щоб він був реалістичним і досяжним.
Нарешті, остання метрика, розглянута в цьому ресурсі різниця між фактичним і очікуваним часом відновлення , також відомий як аналіз прогалин. Ви можете перевірити прогалини за допомогою тестування відновлення після відмови, тестування BC/DR на рівні підприємства та аналізу прогалин. Коли ви виявите прогалини у своїх планах, ви зможете встановити KPI та використовувати їх у процесі планування.
Дані, зібрані програмним забезпеченням BC/DR, мають бути «чистими», щоб забезпечити точне звітування та планування. Для належної гігієни даних обов’язково стандартизуйте введення даних за допомогою спадних меню, списків вибору, форматування тексту та перевірки даних. Наприклад, якщо ми додаємо номери телефонів співробітників до плану, ми рекомендуємо перевірити, чи містять ці номери телефонів код міста та залишаються у використанні.
Дедуплікація та керування ідентифікацією та доступом (IAM) можуть допомогти створювати елегантні дані. Ви можете використовувати дедуплікацію, щоб усунути кілька аспектів тих самих записів. Ви можете використовувати облікові дані (аутентифікація) разом із дозволами (авторизація), щоб переконатися, що лише кваліфіковані користувачі вводять записи та основні дані. Ви також заощадите багато часу та клопоту, інтегрувавши свою систему BC/DR з іншими програмами (наприклад, вашою системою кадрів), щоб уникнути дублювання записів і будь-якої ймовірності помилок.
Визначте критичні бізнес-функції та те, як вони залежать одна від одної, використовуючи інструмент моделювання відносин.
Далі ми встановлюємо прийнятний поріг простою за допомогою показників RTO та RPO. Ми перевіряємо плани, щоб побачити, чи наближаємося ми до цих порогів або перевищуємо їх. Після цього давайте переглянемо плани та перевіримо їх ще раз. Ми повинні встановити KPI, щоб вимірювати, як часто плани оновлюються та тестуються, і проводити аналіз прогалин, щоб порівняти запланований із фактичним часом відновлення.
Нарешті, переконайтеся, що ви зберігаєте дані «гігієнічними» для точного звітування. Показники BC/DR абсолютно марні, якщо дані неточні. Це може здатися простою проблемою, але дивно, скільки компаній заколисують себе помилковим відчуттям безпеки, звітуючи про те, що їхні угоди про рівень обслуговування неправдиві. Завжди краще бути реалістом, навіть якщо це означає прийняти пов’язані з цим ризики.
Ercole Palmeri
Минулого понеділка Financial Times оголосила про угоду з OpenAI. FT ліцензує свою журналістику світового рівня…
Мільйони людей оплачують потокові послуги, сплачуючи щомісячну абонентську плату. Поширена думка, що ви…
Coveware від Veeam продовжить надавати послуги реагування на інциденти кібервимагання. Coveware запропонує криміналістику та можливості відновлення…
Прогнозне технічне обслуговування революціонізує нафтогазовий сектор завдяки інноваційному та проактивному підходу до управління заводом.…
