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

Купити власний сервер

Хмара vs. локальний сервер: коротко про відмінності

  • Хмара — це оренда ресурсів. Плюс — ви платите лише за використані ресурси й можете масштабуватися в кілька кліків. Мінус — залежність від правил і тарифів провайдера. 
  • Власний сервер для бізнесу — це залізо у вашій власності. Плюс — ви самі керуєте доступом і політикою розподілення ресурсів, а також маєте швидший відгук. Мінус — доведеться платити чималу суму наперед. 

Власний комп’ютер може бути розташований у вашому офісі (on-premise сервер) чи у дата-центрі з підготовленою інфраструктурою (колокація). Тому й таке рішення має певний рівень гнучкості. 

Сім причин відмовитися від хмари на користь власного сервера

  1. Вартість. При постійному навантаженні модель pay-as-you-go стає дорогою. Найбільші витрати припадають на мережу й зберігання даних. Наприклад, хмарна платформа AWS не тарифікує вхідний трафік, але встановлює ставку $0.09/GB для передавання даних в інтернет після перших 100 ГБ. При середній віддачі у 5 ТБ ви платитиме $441/міс тільки за egress — без урахування обчислень, дисків, бекапів тощо.

  2. Залежність від провайдера. Ще одна важлива причина, чому бізнес відмовляється від хмари — ризик «зростання» з інфраструктурою провайдера. Коли масштаби обчислень стають доволі великими, міграція стає важкою чи майже неможливою. І тоді компанії доводиться погоджуватися на будь-які умови. Зараз це питання розглядається на законодавчому рівні — у ЄС планують забезпечити свободу міграції між хмарними платформами завдяки скасуванню комісій і розширеній техпідтримці. 

  3. Нестабільність. Для частини бізнес-систем важлива передбачувана продуктивність: ERP, WMS, системи виробництва, аналітика, внутрішні API з жорсткими SLA. У хмарі на це впливають сусіди на спільній інфраструктурі, типи дисків, мережеві політики, ліміти сервісів. On-premise сервер дає головне — чітко прогнозований результат з мінімальними ризиками та відхиленнями. 

  4. Затримки. Якщо у вас багато синхронних операцій, зайві десятки мілісекунд перетворюються на повільний інтерфейс і довгі транзакції. Зменшуючи фізичну відстань до сервера, ви часто скорочуєте й час відповіді. Це забезпечує кращий користувальницький досвід, швидшу відповідь і зручніше управління звітами. 

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

  6. Дороге масштабування. Провайдери часто пропускають «середні» тарифні плани, зручні для більшості компаній. Змушуючи бізнес переходити на топові рішення, вони створюють зайві витрати без об’єктивної потреби. У своїй інфраструктурі ви можете виділяти стільки грошей на масштабування, скільки дозволяє бюджет — без погодження надвитрат. 

  7. Централізація. Це парадоксально, але відмова від хмарних сервісів іноді дає кращу стійкість до збоїв. Нещодавні падіння AWS та Cloudflare показали, що дрібні помилки та локальні кібертаки можуть паралізувати роботу інтернету на години чи навіть дні, створюючи багатомільярдні збитки для бізнесу. 

Коли перехід з хмари на власні сервери має сенс

І ще одне порівняння формату «хмара vs. власний сервер» — цього разу більш практичне. Міграція на локальну машину має сенс, якщо у вас:

  • навантаження рівне й прогнозоване (24/7, без великих піків);

  • багато вихідного трафіку або важкі дані (відео, CAD, аналітика);

  • потрібен строгий контроль над доступом і ключами;

  • важливі стабільна продуктивність і низький рівень затримок;

  • ви готові інвестувати в живлення, зв’язок і процедури (а не лише в основне залізо).

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

Такий формат зменшить вартість утримання хмари, але допоможе уникнути плати за вихід (exit-egress fee) в перші місяці. 

Вимоги безпеки при міграції на локальний сервер

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

  • Налаштовуйте копіювання за принципом 3-2-1: 3 копії, 2 різні носії, 1 копія — поза основною локацією.

  • Створюйте неперезаписувані (immutable) резерви для захисту від зламів і здирництва (ransomware). 

  • Проводьте тест відновлення щомісяця. Цільові показники для локального серверу — остання точка збереження (RPO) 15 хвилин, час на відновлення (RTO) 2 години. 

Для захисту від витоку даних діють такі методи:

  • шифрування всіх дисків без виключення;

  • контроль доступу та чітке розмежування прав користувачів;

  • багатофакторна автентифікація в адмін-панелі;

  • ведення журналів подій;

  • сегментація мережі. 

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

Міграція сервера та блекаути: як забезпечити стійкість інфраструктури

Теоретично, саме хмара й мала б стати відповіддю на блекаути. Але досвід українського бізнесу у 2022–2025 роках показав, що вона може бути вузьким місцем. Якщо сервіси використовуються переважно співробітниками компанії, відсутність електрики в провайдерів може розірвати зв’язок. 

Тому ролі будуть такими:

  • Власний сервер для бізнесу забезпечить відмовостійкість офісу при поганому зв’язку та нестабільному доступі до інтернету. 

  • Хмара дозволить вашим клієнтам з інших країн користуватися сервісами, наприклад, SaaS-платформами в умовах тривалих блекаутів. 

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

Як зробити серверну інфраструктру стійкою до блекаутів

Якщо ви переходите на on-premise сервер, для нього варто підготувати відповідні інженерні рішення:

  1. Живлення — мінімум N+1 на критичне. Експерти Toshiba рекомендують під’єднувати UPS з місткістю на 2–5 хвилин повністю автономної роботи. За цей час ви зможете запустити генератор без попереднього підігріву та автоматичного резервування. 

  2. Дублювання. Якщо процеси дійсно критичні (медицина, мілітарі, правоохорона, державне управління, комунальні послуги), on-premise сервер може дублюватися машиною в колокації. Це забезпечує відмовостійкість навіть на рівні фізичного знищення. 

  3. Зв’язок. Базою в українських реаліях стали два незалежні інтернет-провайдери — в тому числі один з технологією PON. Як аварійний канал використовуються антени 4G/LTE або Starlink. Не забувайте, що останній необхідно реєструвати за новими правилами. 

Головне правило утримання власної серверної інфраструктури в Україні — це передбачати непередбачуване. Якщо є теоретичний сценарій відмови, який ви вважаєте малоймовірним, варто готуватися навіть до нього.