Власний сервер чи звичайний хостинг для сайту

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

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

Що ви орендуєте в кожному випадку

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

Власний сервер спочатку порожній, і за його налаштування відповідаєте ви. Провайдер дає віртуальний або фізичний сервер і мережу. Усе інше ставиться під конкретний проєкт: версія PHP, веб-сервер, кеш, поштова частина, резервні копії, правила доступу. Що з цього роблять до першого відвідувача, розписано в переліку налаштувань сервера перед запуском сайту.

Різниця між двома варіантами найпомітніша в чотирьох місцях.

• Межі тарифу. На хостингу вони задані наперед і однакові для всіх на цьому сервері. На сервері ви самі вирішуєте, скільки пам’яті віддати базі, а скільки веб-серверу.
• Набір служб. Хостинг дає те, що є в переліку послуг. На сервері можна поставити чергу завдань, окремий пошук або будь-яку іншу службу.
• Відповідальність за збій. На хостингу провайдер відповідає за платформу, а ви за сам сайт. На власному сервері за все відповідаєте ви або ваш підрядник.
• Швидкість реакції на зміни. Змінити версію PHP на хостингу можна в панелі за хвилину. На сервері це планова робота, зате без обмежень з боку провайдера.

Хто відповідає за збій

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

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

Що дає контроль на практиці

Контроль корисний лише в конкретних ситуаціях.

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

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

Ознаки, що хостингу вже мало

Сайт стає недоступним в одні й ті самі години

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

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

Хостер обмежує процеси

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

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

Потрібне те, чого немає в тарифі

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

Коли переходити не варто

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

Ситуації, у яких переїзд нічого не дасть, зводяться до трьох.

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

VPS, VDS чи виділений сервер

Назви в різних провайдерів відрізняються, і плутанина тут звичайна річ.

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

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

Що змінюється після переходу

Після переїзду з’являються регулярні роботи, яких на хостингу у вас не було.

• Оновлення системи й панелі. Раз на місяць або частіше, якщо виходить критичне виправлення.
• Продовження сертифікатів. Автоматичне, але з перевіркою, що воно справді спрацювало.
• Чистка журналів. Інакше диск заповнюється за кілька місяців, і сайт перестає працювати без видимої причини.
• Перевірка резервних копій. Саме відновлення з копії, бо наявність файлу ще нічого не гарантує.
• Моніторинг доступності. З повідомленням тій людині, яка справді реагує.
• Розбір інцидентів. Після кожного збою треба зрозуміти причину, інакше він повториться.

Це не разове налаштування, а місячний ритм. Коли його ніхто не тримає, сервер тихо деградує, і перший симптом з’являється у вигляді аварії.

Резервні копії стають вашою турботою

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

Окремо варто перевірити, скільки часу займає повне відновлення. Інтернет-магазин, який відновлюється чотири години, і магазин, який відновлюється двадцять хвилин, дають дуже різні наслідки для продажів.

Хтось має реагувати на падіння

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

Ці роботи входять до адміністрування серверів на постійній основі або виконуються за фактом звернення, залежно від того, скільки уваги потребує проєкт. Регулярне обслуговування ми докладно розібрали в матеріалі про те, що входить у підтримку сайту. Окремо ми писали про сервер для 1С і M.E.Doc, де вимоги до нього зовсім інші.

Як перевірити себе перед рішенням

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

• Падіння повторюються в один і той самий час або після однакових дій, а не хаотично
• Провайдер надсилав листи про перевищення кількості процесів або часу виконання
• Сайт уже оптимізували: картинки стиснуті, кеш працює, зайві плагіни прибрані, а навантаження залишилося
• Проєкту потрібна служба поза тарифом: черга, пошук, окрема версія бібліотеки
• Є кому вести сервер: своя людина або підрядник на постійному обслуговуванні

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

Скільки часу займає перехід

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

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

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

Що зробити зі старим хостингом

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

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

Перші тижні після переходу корисно дивитися на сайт уважніше, ніж зазвичай. Що саме перевіряти в цей період, описано в матеріалі про те, що робити з сайтом після запуску.

Безпека змінює характер

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

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

Доступи варто розділити з першого дня

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

Робоча схема простіша, ніж здається.

• Окремий запис на кожну людину. З мінімально потрібними правами, а не з повними.
• Служби працюють від своїх користувачів. Веб-сервер, база й черга не мають ходити від адміністратора.
• Вхід за ключем, а не за паролем. Ключ не підбирається перебором і не пересилається в месенджері.
• Журнал доступів. Хто, коли й навіщо заходив на сервер.

Коли людина йде з проєкту, вимикається один запис, а не змінюються всі паролі одразу.

Скільки це коштує насправді

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

Повний розрахунок складається з трьох частин.

• Оренда сервера в провайдера. Залежить від потрібної пам’яті, дисків і каналу.
• Регулярне обслуговування. Оновлення, копії, моніторинг і реакція на збої. У нас це від $400/міс у межах адміністрування серверів.
• Разові роботи. Перенесення, зміна конфігурації під нове навантаження, розбір наслідків аварії. Рахуються погодинно, $25/год.

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

Типові помилки перших місяців

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

Кому передати обслуговування

Варіантів три, і в кожного своя ціна помилки.

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

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

Висновки

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

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

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