Для вебстудії або маркетингової агенції сервер VDS дає змогу зібрати клієнтські сайти в одному керованому середовищі. Тут можна розмістити робочі проєкти, тестові копії, бази даних та внутрішні інструменти команди, не створюючи окрему інфраструктуру для кожного невеликого замовлення. Але спільний сервер не має означати спільні паролі, каталоги й ресурси без обмежень. Інакше невдале оновлення одного плагіна, заражений файл або важкий імпорт товарів зачепить не один сайт, а всю групу.
Найчастіше проблема виникає не через недостатню потужність VPS. Сайти запускаються від одного системного користувача, підключаються до баз даних через спільний обліковий запис і потрапляють до одного великого резервного архіву. Спочатку така схема здається зручною. Згодом з’ясовується, що окремий проєкт неможливо безпечно зупинити, відновити чи передати іншому розробнику, не торкаючись решти інфраструктури.
Як розділити клієнтські проєкти всередині одного VPS
Кожен сайт варто від початку сприймати як окремий об’єкт. Він повинен мати власні файли, базу, журнали, налаштування й межі використання ресурсів. Тоді його можна оновлювати, переносити або відновлювати незалежно від сусідніх проєктів.
Базову схему розміщення краще стандартизувати й застосовувати до всіх нових клієнтів:
-
створювати окремого системного користувача, каталог і PHP-пул для кожного сайту;
-
використовувати окрему базу даних та обліковий запис без доступу до чужих таблиць;
-
встановлювати ліміти пам’яті, процесорного часу, кількості процесів і дискового простору;
-
розділяти робоче й тестове середовища;
-
вести окремі журнали помилок і запитів для кожного проєкту;
-
не зберігати паролі та ключі доступу у відкритих файлах або спільних таблицях команди.
Окремий системний користувач потрібен не лише для порядку в каталогах. Якщо кілька сайтів запускаються з однаковими правами, шкідливий скрипт на одному з них може читати або змінювати файли сусідніх проєктів. У рекомендаціях щодо захисту WordPress також радять обмежувати права файлової системи й не дозволяти процесам запис там, де він не потрібен.
Так само небезпечно підключати всі сайти до баз даних через одного користувача з широкими правами. Компрометація одного конфігураційного файла в такому разі відкриває доступ до даних інших клієнтів. Для кожної CMS варто створювати власний обліковий запис і дозволяти йому працювати лише з відповідною базою.
Читайте також: Infrastructure as Code на VPS: як спростити управління інфраструктурою
Обмежуйте ресурси окремих сайтів
Один магазин під час нічного імпорту може зайняти всю доступну пам’ять або запустити стільки процесів, що решта сайтів почне повільно відповідати. Сам магазин при цьому може залишатися доступним, тому причину проблеми не завжди знаходять відразу.
Ліміти не повинні бути надто жорсткими. Їхнє завдання — не загальмувати проєкт, а не дозволити одному процесу безконтрольно використовувати весь сервер. Після запуску нового сайту варто кілька тижнів спостерігати за навантаженням, а потім встановити межі з розумним запасом.
Видавайте доступ лише до потрібного проєкту
Спільний root-пароль, який знають усі розробники й підрядники, позбавляє агенцію контролю. Неможливо встановити, хто вносив зміни, швидко закрити доступ одній людині або обмежити її роботу конкретним сайтом.
Для керування доступами варто запровадити кілька правил:
-
видавати персональні SSH-ключі замість одного пароля для всієї команди;
-
не надавати root-доступ, якщо спеціалісту достатньо прав на окремий каталог;
-
вести перелік активних доступів із датою видачі та відповідальною особою;
-
видаляти облікові записи та ключі після завершення робіт;
-
раз на квартал перевіряти, хто досі має доступ до сервера й панелей керування;
-
використовувати двофакторну автентифікацію для облікових записів із розширеними правами.
Зовнішньому SEO-фахівцю зазвичай потрібні CMS, аналітика й пошукові консолі, але не файлове середовище всього VPS. Контент-менеджеру не потрібен доступ до бази, а розробник одного сайту не повинен бачити каталоги інших клієнтів. Це відповідає принципу найменших привілеїв: користувач отримує лише ті права, без яких не може виконати свою роботу.
Захищайте staging не слабше за робочий сайт
Якщо staging розміщений в одному акаунті з іншими сайтами, його злам може відкрити доступ не лише до тестової копії. Зловмисник може дістатися до сусідніх каталогів, знайти конфігураційні файли з паролями або змінити файли інших проєктів.
Тому доступ до staging варто обмежити паролем, IP-адресами або приватною мережею. Заборона індексації в robots.txt від сторонніх відвідувачів не захищає.
Також перевірте інтеграції: тестова версія не повинна надсилати реальні листи, проводити платежі, створювати угоди в CRM або змінювати залишки товарів.
Як підтримувати інфраструктуру після запуску
Добре розділити сайти на старті недостатньо. Кількість клієнтів зростає, у проєктах з’являються нові модулі, змінюються підрядники й графіки оновлень. Без регулярного контролю навіть акуратно організований VPS поступово перетворюється на цифрові джунглі, де ніхто не знає, які процеси працюють і кому належать доступи.
Налаштуйте окреме резервування для кожного сайту
Одна резервна копія всього VPS зручна для відновлення сервера після повної аварії, але погано підходить для щоденної роботи агенції. Якщо через невдале оновлення зламався один проєкт, відкочувати разом із ним ще п’ятнадцять справних сайтів не можна.
Робоча схема резервування має враховувати:
-
окремі копії файлів і баз даних для кожного клієнта;
-
частоту копіювання відповідно до темпу оновлення інформації;
-
зберігання хоча б однієї копії поза основним VPS;
-
шифрування архівів із персональними даними;
-
автоматичний контроль завершення завдань і розміру файлів;
-
періодичне тестове відновлення на чистому середовищі.
Частоту резервування визначають не за розміром сайту, а за обсягом інформації, яку допустимо втратити. Корпоративному ресурсу, де новини виходять кілька разів на місяць, може вистачити щоденної копії. Для магазину з постійними замовленнями один бекап на добу вже означає ризик втратити значну частину операцій.
Відслідковуйте, який сайт створює пікове навантаження
Один ресурсомісткий сайт може сповільнити всі проєкти на сервері. Причиною часто стають імпорт товарів, резервне копіювання, завдання cron, бот-трафік або помилка плагіна.
Налаштуйте сповіщення про піки CPU і пам’яті, заповнення диска, помилки 5xx та зростання часу відповіді. Коли знайдете джерело навантаження, зупиніть проблемний процес і перевірте логи, плагіни, cron та запити до бази.
Якщо навантаження спричинене помилкою, її потрібно усунути. Якщо сайт справді потребує більше ресурсів, обмежте його споживання або перенесіть на окремий віртуальний сервер, щоб він не впливав на інших клієнтів.
Ведіть технічну картку кожного проєкту
Коли агенція обслуговує багато сайтів, важливі відомості не повинні залишатися лише в голові одного розробника. Для кожного проєкту варто зафіксувати версію PHP, розташування бази, підключені зовнішні сервіси, графік резервування, відповідальних спеціалістів і порядок аварійного відновлення.
Корисно також зазначити, які процеси створюють найбільше навантаження. Якщо відомо, що магазин щодня о 03:00 імпортує каталог, команді не доведеться щоразу розслідувати короткий стрибок використання CPU. А якщо навантаження з’явилося в інший час, його вже можна розглядати як відхилення.
Читайте також: Віртуальні сервери у розробці: як полегшити життя програміста
Технічну картку слід оновлювати після зміни серверної конфігурації, підключення нової інтеграції або передачі проєкту іншій команді. Це спрощує підтримку й скорочує час відновлення після помилки.
Коли клієнтський сайт потрібно винести на окремий сервер
Збільшувати конфігурацію всього VPS через один важкий сайт не завжди вигідно. Агенція починає оплачувати додаткові ресурси для всієї групи, хоча споживає їх переважно один клієнт. У такій ситуації логічніше відокремити проєкт.
Простій проєкту має високу ціну
Невеликий сайт-візитка та інтернет-магазин, через який проходить більшість продажів компанії, не повинні мати однакову модель розміщення лише тому, що обидва працюють на WordPress. Для критичного сервісу важливі окреме резервування, власний запас ресурсів і можливість проводити технічні роботи незалежно від інших клієнтів.
Для великого магазину, порталу або системи зі значними обсягами даних наступним етапом може стати оренда виділеного сервера. Проте рішення не варто прив’язувати до кількості доменів. Десятки простих сайтів іноді потребують менше ресурсів, ніж один каталог зі складними фільтрами, пошуком, синхронізацією залишків і постійною обробкою файлів.
Проєкт регулярно забирає значну частину ресурсів
Якщо один магазин використовує половину пам’яті VPS у звичайний день, під час розпродажу, рекламної кампанії або масового імпорту запасу вже не буде. Перенесення краще запланувати до пікового періоду, залишивши час на тестування, синхронізацію бази та оновлення DNS.
Перед міграцією варто перевірити, чи не можна зменшити навантаження за допомогою кешування, оптимізації запитів, черг або зміни графіка фонових завдань. Окремий сервер не виправить повільний код, хоча дасть йому більше ресурсів.
Сайту потрібне особливе програмне середовище
Один клієнт може вимагати іншої версії системних бібліотек, власного вебсервера, нестандартних модулів або окремого графіка оновлень. Підлаштовувати під нього спільний VPS ризиковано: зміна конфігурації здатна порушити роботу решти сайтів.
Окреме середовище також доречне, коли клієнт хоче мати адміністративний доступ. Видавати його до сервера, де розміщені сторонні проєкти, не можна навіть за умови добрих відносин і підписаних угод.
Один VPS може роками залишатися зручним центром для клієнтських сайтів. Стабільність залежить не від максимального запасу потужності, а від правил, за якими агенція створює проєкти, видає доступи, налаштовує резервні копії та реагує на зростання навантаження. Коли ці процеси описані й виконуються послідовно, проблема одного клієнта не перетворюється на спільну аварію.