Коли проєкт вважається навантаженим
Навантаженість — це не лише кількість відвідувачів. Проєкт стає «важким», коли на нього одночасно тиснуть кілька чинників: багато користувачів, великий каталог або база даних, постійний обмін з іншими системами, фонові завдання, що працюють цілодобово.
Типові ознаки: сайт швидкий уночі й повільний удень, падає під час розпродажів, адмін-панель відкривається хвилинами, імпорт товарів сповільнює вітрину, а кожна нова функція щось ламає в іншому місці.
Проблема рідко вирішується простою покупкою потужнішого сервера. Найчастіше справжня причина — один повільний запит до бази, відсутній кеш або зовнішній сервіс, який відповідає із затримкою і тягне за собою всю систему.
Що входить у супровід
Обсяг робіт залежить від проєкту, але зазвичай супровід охоплює:
- Швидкість і стабільність. Регулярно перевіряємо, як швидко відповідають ключові сторінки й сервіси, і розбираємося з кожним погіршенням.
- Базу даних. Стежимо за повільними запитами, ростом таблиць та індексами, налаштовуємо копії бази для читання, якщо основна не справляється.
- Фонові процеси. Перевіряємо, щоб імпорти, розсилки та обмін з обліковою системою не забирали ресурси в покупців.
- Інфраструктуру. Розподіл навантаження між серверами, налаштування Nginx, PHP чи Node.js, запас ресурсів на зростання.
- Розвиток. Нові функції, оновлення бібліотек і поступова переробка проблемних частин коду.
Щоб про збої ви дізнавалися не від клієнтів, супровід зазвичай поєднують із моніторингом і сповіщеннями.
Кому це потрібно, а кому ні
Послуга має сенс для великих інтернет-магазинів і маркетплейсів, порталів з особистими кабінетами, онлайн-сервісів за підпискою, систем, з якими через API працюють партнери. Тобто там, де хвилина простою чи повільна сторінка коштує реальних грошей.
Якщо у вас корпоративний сайт або невеликий магазин, який стабільно працює, окремий супровід під високе навантаження, найімовірніше, зайвий. Вистачить звичайної підтримки з оновленнями й виправленням помилок — і ми чесно скажемо про це на першій розмові.
Оптимізувати, посилити сервер чи масштабувати
Коли система не витримує, є три шляхи, і кожен має свої плюси й мінуси.
- Потужніший сервер. Найшвидше рішення, яке часто дає ефект одразу. Але витрати на інфраструктуру ростуть, а справжня причина повільної роботи нікуди не зникає.
- Оптимізація коду й бази даних. Потребує аналізу й часу розробників, зате прибирає саму причину. Нерідко після неї система витримує більше на тих самих ресурсах.
- Кілька серверів. Навантаження розподіляється між кількома копіями застосунку, база, кеш і пошук живуть окремо. Це дає запас на роки зростання, але ускладнює систему, і її потрібно вміти обслуговувати.
Зазвичай ми поєднуємо підходи: спершу прибираємо очевидні вузькі місця, а масштабування плануємо тоді, коли дані показують, що без нього не обійтися.
Як готуємося до пікових періодів
Розпродаж, великий рекламний запуск чи сезон — момент, коли система отримує найбільше відвідувачів і коли збій найдорожчий. Тому готуємося заздалегідь, а не напередодні.
- Разом з вами оцінюємо, скільки людей і замовлень очікується, і перевіряємо таке навантаження на тестовій копії.
- Посилюємо слабкі місця, які виявила перевірка, і за потреби тимчасово додаємо ресурси.
- Переносимо важкі фонові завдання на нічний час і домовляємося не викладати великих змін під час акції.
- Узгоджуємо, хто з команди на зв’язку під час піку і що робимо, якщо щось піде не так.
Що підготувати перед стартом
- доступи до серверів, репозиторію з кодом і панелей хостингу або хмари;
- перелік сценаріїв, критичних для бізнесу: оформлення замовлення, оплата, вхід у кабінет, обмін зі складом;
- список інтеграцій і зовнішніх сервісів, з якими обмінюється система;
- історію проблем: коли були збої, що їм передувало і як їх вирішували;
- плани: очікувані розпродажі, рекламні кампанії, вихід на нові ринки.
Якщо документації немає, це нормально: більшість великих проєктів живе без неї. Потрібну картину ми зберемо під час аудиту.
Як ми оцінюємо результат
На старті домовляємося про показники й надалі порівнюємо з ними. Зазвичай це час відповіді ключових сторінок, кількість помилок, частота й тривалість збоїв, швидкість фонових процесів і поведінка системи під час пікових навантажень.
Систем, які взагалі ніколи не зупиняються, не буває, тому безперервної роботи ми не обіцяємо. Наша мета інша: щоб збоїв ставало менше, вони тривали коротше, а їхні причини не повторювалися.
Типові помилки великих проєктів
- Додавати ресурси сервера щоразу, коли щось гальмує, не шукаючи причини.
- Запускати важкий імпорт товарів чи формування звітів у робочий час на тій самій базі, з якою працюють покупці.
- Викладати зміни вручну просто на робочий сервер, без тестової копії й можливості швидко повернути попередню версію.
- Братися переписувати все з нуля замість поступового покращення найпроблемніших частин.
- Готуватися до розпродажу в останній момент, коли будь-які зміни вже ризиковані.
Що впливає на вартість супроводу
- Розмір і складність системи: скільки сервісів, баз даних, інтеграцій і фонових процесів.
- Стан коду та інфраструктури: чи є тестове середовище, автоматична викладка, моніторинг, документація.
- Потрібна швидкість реакції: лише робочий час чи також чергування в неробочі години.
- Обсяг розвитку: тільки підтримка стабільності чи ще й нові функції.
- Де працює проєкт: власні сервери, орендовані чи хмара.
Зазвичай починаємо з аудиту, а потім пропонуємо формат постійної співпраці з прозорим переліком робіт.
Часті запитання
Чи візьмете проєкт, який розробляла інша команда? Так, для великих систем це звична ситуація. Спершу розбираємося в коді та інфраструктурі, а вже потім щось змінюємо.
Чи потрібно переїжджати в хмару? Не обов’язково. Хмара зручна, коли навантаження сильно коливається, але багато великих проєктів добре працюють і на орендованих серверах. Рішення ухвалюємо після аналізу.
Чи можна прискорити систему, не зупиняючи продажі? Так. Зміни перевіряємо на тестовій копії й переносимо на робочі сервери частинами, у години з найменшим навантаженням.
Що робити, якщо система вже падає? Напишіть нам. У такій ситуації ми спершу допомагаємо відновити роботу, а потім шукаємо причину й пропонуємо, як не допустити повторення.
Чому Promodex
Ми розробляємо й підтримуємо сайти з 2015 року, за плечима 750+ проєктів, тож добре знаємо, як змінюються вимоги до системи, коли бізнес росте. Проєкт веде наша київська команда, яка нікому не віддає роботу на сторону, тож код і інфраструктуру не доводиться ділити між різними підрядниками. Ви завжди знаєте, що саме ми робимо, навіщо і скільки це коштує.
