Що налаштувати на сервері перед запуском сайту

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

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

Що ви отримуєте від провайдера й що доведеться зробити самому

Межа відповідальності проходить рівно по залізу й мережі. Усе, що вище, ваша зона.

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

Базова безпека до всього іншого

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

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

Доступ і ключі замість паролів

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

Мережеві правила й оновлення системи

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

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

Ці роботи не разові. Вони повторюються щомісяця і входять до адміністрування серверів або виконуються за фактом звернення, $25/год.

Веб-сервер, PHP і база даних

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

• Версія PHP. Береться та, під яку розрахований сайт, а не найновіша з наявних.
• Обмеження на пам’ять і час виконання. Під конкретне навантаження, а не за замовчуванням.
• Розмір завантаження. Інакше адміністратор не зможе залити велике зображення чи прайс.
• Кількість робочих процесів. Забагато, і серверу бракує пам’яті, замало, і відвідувачі стоять у черзі.
• Налаштування бази. Обсяг пам’яті під буферний пул, розмір журналів, кодування.

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

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

Кешування і межі навантаження

Кеш ставлять до запуску, а не після скарг на повільність.

• Кеш сторінок. Готова сторінка віддається без звернення до бази.
• Кеш об’єктів у пам’яті. Знімає повторні однакові запити.
• Кеш скомпільованого коду. PHP не перекомпільовує ті самі файли на кожен запит.
• Стиснення і заголовки для браузера. Щоб під час повторного візиту не доводилося завантажувати все заново.

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

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

Пошта та її репутація

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

• Записи підтвердження відправника. Три різні механізми, і потрібні всі три.
• Ім’я сервера в мережі. Воно має збігатися з тим, чим він представляється.
• Зворотний запис. Провайдер прописує його за запитом. Gmail вимагає від усіх відправників коректних прямого й зворотного DNS-записів, без них листи можуть не дійти або потрапити в спам.
• Окрема адреса для сайту. Щоб проблеми з розсилками не зачіпали пошту співробітників.

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

Якщо пошта домену працює в іншому сервісі

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

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

Сертифікати й автоматичне продовження

Сертифікат випускають до того, як на сайт піде трафік. Автоматичне продовження налаштовують, але з перевіркою.

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

Кілька сайтів на одному сервері

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

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

Резервні копії поза сервером

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

• Окреме сховище. Інший сервер або хмарне сховище, не сусідня тека.
• Файли й база на один момент. Розклад може бути різний, але точка відновлення має бути спільною, інакше база не збіжиться з файлами.
• Кілька поколінь. Щоб можна було повернутися не тільки на вчора, а й на тиждень назад.
• Перевірка відновлення. Раз на квартал копію розгортають і дивляться, чи піднімається сайт.
• Вимірювання строку. Скільки саме годин займає повне повернення до роботи.

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

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

Моніторинг і сповіщення

Сервер має повідомляти про проблеми сам, а не через дзвінок клієнта.

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

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

Що перевіряють перед тим, як пускати трафік

Фінальна перевірка проходить до перемикання домену, і сам порядок перемикання розібраний у матеріалі про те, як перенести сайт на новий сервер.

• Відкриваються всі типи сторінок. Не тільки головна.
• Працює адмінка й збереження змін. Разом із завантаженням файлів.
• Проходить оформлення замовлення. Для інтернет-магазину аж до тестової оплати.
• Ідуть листи. І доходять не в небажану пошту.
• Запускаються планові завдання. Хоча б один цикл.
• Порожній журнал помилок. Після повного проходу сайтом.
• Копія знімається і відновлюється. До запуску, а не після.

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

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

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

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

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

Висновки

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

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

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