Помилка того, хто вижив. Або життя без «плану Б».

«Помилка того, хто вижив» або «Упередження виживання» стали для українців національною ідеєю та засобом до ведення справ. Дуже часто ми бачимо рішення, що приймаються за правилом «та шо там може статися? Он усі працюють і ми так будемо». Нажаль, такий підхід працює не завжди і приносить розчарування від несправджених очікувань.

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

Саме таку концепцію команда UCloud розбивала з одним зі своїх клієнтів. І от як це було.

Ціль:

• Забезпечити відмовостійке рішення – безперебійну роботу і збереження даних
• Скоротити час аварійного відновлення роботи ERP системи до <15 хвилин

Місія була більш ніж здійсненна. Команди клієнта та UCloud описали план робіт, зони відповідальності, регламент та приступили до виконання.

Хмара 1.0

• Загальний ДатаЦентр для групи компаній клієнта
• Топологія підключення — «Зірка»
• Канали зв’язку всіх офісів та виробництв з Датацентром L2 / L3

Здавалося б, що такий проект є достатньо типовим та розповсюдженим рішенням. Але сталося не так як гадалося. Така організація інфраструктури є досить нестійкою. Але хто ж про це каже? Після перших випробувань збірна команда проекту від клієнта та UCloud отримала такі аварійні ситуації:

• Відмова серверів додатків (навантаження вище розрахункового в декілька разів)
• Резервний майданчик меншої потужності — страшна помилка
• Канали передачі даних – це обмеження
• Архітектура ERP лишає кластер СУБД переваг
• Збільшення часу роботи сервера додатків в резервній хмарі

Після екстреного аналізу роботи ІТ-інфраструктури були знайдені шляхи мінімізації втрат та підвищення рівня безперебійності в роботі. І народилася Хмара 2.0:

• Збільшення серверів додатків до рівня навантаження 60/40
• Резервний майданчик — «Дзеркало»
• Канали передачі даних — резервування по фізично розподілених каналах
• Заміна сервісу загальної папки DFS на сервіс S2D
• Деактивація балансувача серверів додатків в резервній хмарі

В результаті клієнт має такі переваги:

• Георозподілений кластер ERP системи з високим рівнем доступності
• Динамічне збільшення ресурсів та можливість відмовитись від надлишкових
• Відсутність непередбачуваних ризиків та витрат, зв’язаних з обслуговуванням та ремонтом апаратної частини ERP
• Ліцензійна чистота
• Автооновлення апаратної частини
• Допомога в розробці технічних рішень

Ринок хмарних послуг насичений кейсами, де описані ІТ-системи компаній без резервного ЦОД, бекапування та аварійного відновлення. Але це – необхідні складові безперебійної роботи. Саме через сотні прикладів «успішної роботи» компанії, які тільки переходять в хмари, ігнорують такі важливі складові інфраструктури як:

• Георознесені ЦОД, які дозволять аварійно відновити роботу в ситуації, коли основний ЦОД вийшов з ладу.
• Канали зв’язку, що можуть стати не тільки перевагою, а й гальмувати проект
• Резервування за «правилом 3-2-1», де ІТ-інфраструктура повинна мати 3 копії даних, що розміщені в 2х ЦОД, 1 з яких за межами периметру інфраструктури.
• Зменшення об’ємів резервних майданчиків для економії ресурсів. Такі дії призводять до некоректної роботи альтернативного майданчика в кризовий момент або повного його незапуску.

Нажаль ніхто не застрахований від збоїв в роботі. Але для кожного збою має бути «план Б», що складається з декількох простих кроків:

• Резервування даних. Регулярне та якісне, з визначенням RPO (точка повернення recovery point objective – цільова точка відновлення. Визначає періодичність створення резервних копій.) та RTO (recovery time objective  – цільовий час відновлення. Визначає час, який повинен пройти з початку і до кінця відновлення даних з резервної копії.)
• Складання та затвердження плану відновлення після аварії. Такий документ є дорожньою картою під час екстрених ситуацій та підкаже кожному що робити в аврал.
• Регулярне тестування бекапів – надважлива складова «плану Б», щоб уникнути ситуацій, коли бекап є, а розгорнути його неможливо.

Чим довше ви ігноруватимете «план Б» для вашого бізнесу, тим в більшій небезпеці знаходиться ІТ-інфраструктура компанії. Адже передбачити, коли «упереджене виживання» дасть збій неможливо.