Коли хмара перестає бути вигідною і як бізнесу обрати інфраструктуру: інтерв'ю з Федiром Плотніковим, DevOps-експертом

26 жовтня 2026 р. 10:16

26 жовтня 2026 р. 10:16

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

Федір Плотніков, Principal DevOps & Cloud Infrastructure Leader, розпочав професійний шлях в Україні понад 20 років тому. За цей час він працював з IT-інфраструктурою в різних галузях і над міжнародними проєктами: від банківських систем у Globant до телекомунікаційної інфраструктури Syniverse та глобальних сервісів мобільної безпеки. У його практиці є проєкти з оптимізації хмарної інфраструктури та підвищення ефективності інженерних процесів, зокрема для компаній зі списку Fortune 500. В одному з таких проєктів модернізація CI/CD дозволила скоротити час розгортання програмного забезпечення з 8–10 годин до менш ніж години. В інтерв’ю для Dilo DevOps-експерт Федір Плотніков розповів, як вибір хмарної інфраструктури впливає на витрати бізнесу, продуктивність сервісів і можливості їх масштабування.

Чому потужний сервер не завжди забезпечує швидку роботу сервісу?

– Потужність – лише один із чинників, що впливають на швидкість роботи сервера. Навіть якщо він швидко обробляє запити, користувач усе одно може стикатися із затримками через мережеве з'єднання, розташування сервера або особливості роботи самого застосунку.

Це особливо важливо для глобальних продуктів. Працюючи з AdTranquility, сервісом у сфері VPN і мобільної безпеки, я відповідав за стратегію DevOps, планування інфраструктурних потужностей та оптимізацію витрат. У міру розширення географії ми зіткнулися з тим, що великі хмарні провайдери не всюди пропонували відповідні умови. У деяких регіонах Азії та Океанії бракувало інфраструктури для розміщення серверів, а в інших вартість ресурсів була непропорційно високою.

Ми почали залучати регіональних провайдерів на додаток до великих хмарних платформ. Це дозволило обирати інфраструктуру з урахуванням географії користувачів, технічних вимог і вартості ресурсів. У межах роботи з інфраструктурою також вдалося скоротити витрати на 40% завдяки ініціативам FinOps. Крім того, глобальну VPN/WireGuard-мережу автоматизували в 12 регіонах.

Коли хмара починає обходитися бізнесу надто дорого?

– Витрати зростають із різних причин: частина ресурсів простоює, застосунок використовує більше потужностей, ніж потрібно, або збільшуються витрати на передавання даних між компонентами системи.

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

Чи всім компонентам продукту потрібна однакова кількість ресурсів?

– Потреби залежать від того, як працює кожен компонент. Наприклад, під час розпродажу в інтернет-магазині кількість відвідувачів різко зростає, і сторінки каталогу починають повільно завантажуватися. Компанія додає сервери для застосунку, але ситуація майже не змінюється: обмеженням стає база даних, яка не встигає обробляти запити.

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

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

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

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

Що робити, якщо збій одного сервера зупиняє роботу бізнесу?

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

Працюючи з платформою автоматизації маркетингу на базі n8n, ми зіткнулися з ризиком зупинки процесів у разі відмови одного сервера. Платформа обробляла заявки із сайту, передавала їх до CRM і запускала автоматичне надсилання повідомлень. Мені довелося розглянути три варіанти: посилити один сервер, використати Kubernetes або перейти на керовані сервіси AWS. Перший варіант не усував єдину точку відмови, а Kubernetes додавав надто багато операційної складності для такого масштабу завдання.

Зрештою ми з командою вирішили зупинитися на керованих сервісах AWS: ECS Fargate для запуску застосунку та RDS для зберігання даних. Для обробки завдань використовували черги, а інфраструктуру описали за допомогою Terraform і розділили на середовища розробки, тестування та production.

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

Як перевірити, що зміни справді покращили роботу сервісу?

– Результат потрібно оцінювати за показниками, пов’язаними з початковою проблемою. Якщо сторінки завантажувалися повільно, варто порівняти час відповіді до та після змін. Якщо заявки затримувалися під час передавання до CRM, потрібно перевірити, чи скоротився час обробки та чи стало менше помилок.

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

Що потрібно врахувати, щоб інфраструктура витримала зростання продукту?

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

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

Економіка