Власний сервер чи хмара: як держоргану обґрунтувати технологічне рішення

Блок під заголовком новини 1 Підпишіться на Telegram-канал Публічні закупівлі. Новини! Тримаємо руку на пульсі усіх змін без паніки та зайвої води

Автор
Головний редактор порталу "Держзакупівлі"
Держоргани не мають автоматично купувати сервери, якщо виникла потреба в технічних або програмних засобах. Спочатку замовник має оцінити, чи можна забезпечити потребу через хмарні послуги або послуги центрів обробки даних

Власний сервер чи хмара: як держоргану обґрунтувати технологічне рішення

Закупівля електроенергії: 4 варіанти дій на 2026 рік

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

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

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

Відповідно до Закону України «Про хмарні послуги» від 17.02.2022 № 2075-IX, якщо публічний користувач потребує технічних або програмних засобів для роботи інформаційних ресурсів чи впровадження ІТ-рішень, він має ініціювати закупівлю хмарних послуг або послуг центрів обробки даних.

Це фактично закріплює принцип cloud first — спочатку замовник розглядає хмарну модель, а вже потім інші варіанти.

Водночас Закон не забороняє купувати фізичні сервери або створювати власну інфраструктуру. Але таке рішення потрібно обґрунтувати: технічно, економічно, безпеково та організаційно.

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

Під час підготовки проєкту інформатизації замовник має проаналізувати:

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

Окремо потрібно оцінити правові та безпекові обмеження. Посилання лише на «питання безпеки» не є достатнім аргументом. Замовник має визначити категорію інформації, вимоги до доступу, локалізації даних, захисту інформації та кіберзахисту.

Щоб обрати оптимальну модель, замовнику варто провести:

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

Типові помилки замовників під час підготовки проєктів інформатизації:

  • зазначають лише «потрібен сервер» без опису реальної потреби;
  • не аналізують хмарні альтернативи;
  • посилаються на безпеку без конкретних ризиків;
  • порівнюють лише ціну сервера з комплексом хмарних послуг;
  • не враховують витрати на експлуатацію, резервування та відновлення.

Головний висновок для замовника: питання не в тому, чи можна купити сервер. Питання в тому, чи доведено, що саме така модель найкраще забезпечує функціональність, безпеку, стійкість та економічну ефективність.

Хмарні послуги не є обов’язковим рішенням у кожному випадку. Але замовник має розглянути їх як один із базових варіантів перед закупівлею серверного обладнання.

Джерело: офіційний сайт НПІ

додаток

Статичний блок для новин

Статті за темою

Усі статті за темою

Роз'яснення до Постанови № 710

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

Послуги із заправки картриджів: обираємо код ДК

Пояснюємо, який код ДК для заправки картриджів обрати замовнику, як розрізнити послуги для копіювальної техніки та комп’ютерних периферійних пристроїв і як правильно визначити предмет закупівлі без помилок
10816

Обгрунтування очікуваної вартості закупівлі: зразок та приклад заповнення

Законодавство не встановлює примірної форми для обґрунтування очікуваної вартості. Пояснюємо, як замовнику підготувати зразок обґрунтування очікуваної вартості предмета закупівлі, які дані включити до документа та як виконати вимоги Постанови № 710
19515

Внесення змін до проектної документації

Роз’яснюємо, як замовнику діяти, якщо після розроблення проектної документації виникла потреба внести зміни до проєкту. Пояснюємо порядок коригування проектно-кошторисної документації, коли потрібно залучати автора проєкту та який вид закупівлі обрати для таких робіт
51775

Закупівля робіт з капітального ремонту

Роз’яснюємо, як правильно визначити предмет закупівлі робіт з капітального ремонту, який код ДК обрати, коли потрібна проєктна документація та які помилки найчастіше допускають замовники під час планування такої закупівлі
36662

Гарячі запитання

Усі питання і відповіді