Що насправді входить до обслуговування сервера, а що ні

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

Оновлення: які саме і хто перезавантажує

«Ми оновлюємо ваш сервер» може означати три різні роботи:

• Оновлення безпеки та пакетів. Рутинна частина. Запитайте, як часто: раз на місяць чи раніше, якщо вийшло щось серйозне.
• Перезавантаження. Нове ядро починає працювати лише після перезавантаження. Виправлення вразливості ядра на кшталт CVE-2026-31431 встановлюється за секунди і ні від чого не захищає, доки сервер не перезавантажать, — отже, хтось має обрати час і заздалегідь вас попередити.
• Перехід на новий реліз. З Debian 12 на 13, з однієї LTS-версії Ubuntu на наступну. Це окремий проєкт із планом відкату: уточніть, чи входить він у тариф, чи оцінюється окремо.

# якщо найновіше встановлене ядро — не те, що працює, потрібне перезавантаження
uname -r
ls /boot/vmlinuz-*

# AlmaLinux, Rocky Linux: код виходу 1 і повідомлення, якщо потрібне перезавантаження
dnf needs-restarting -r

Моніторинг: важливо, хто читає сповіщення

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

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

Бекапи: продукт — це відновлення

Бекап сам по собі нікому не потрібен — потрібне відновлення. Чи є воно у вас, вирішують чотири речі:

1. Де лежить копія. Копія на тому самому диску або в тому самому дата-центрі зникне разом із сервером.
2. Наскільки далеко назад можна повернутися. Тиждень щоденних копій не допоможе, якщо пошкодження помітили на десятий день.
3. Що до неї входить. Файли бази, скопійовані посеред запису, можуть потім не запуститися: базі потрібен дамп або знімок, про який вона знає.
4. Хто перевіряє відновлення і як часто. Бекап, з якого жодного разу не відновлювалися, — це надія.

# PostgreSQL: дамп, потім відновлення в порожню тестову базу — так видно, що він робочий
pg_dump -Fc -f app.dump appdb
createdb restore_test && pg_restore -d restore_test app.dump

Захист: базовий рівень, а не броня

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

ss -tlnp                                                          # хто слухає порти
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin)' # що SSH вимагає насправді

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

Реакція на інциденти: відповідь — ще не рішення

Цифра в пропозиції майже завжди означає час до першої відповіді, а не до виправлення. Уточніть три речі:

• Які години враховуються. Тікет, надісланий у п’ятницю ввечері, може отримати першу відповідь у понеділок, якщо робочі години — лише в будні.
• Що вважається критичним. Швидка цілодобова реакція зазвичай стосується одного чітко описаного випадку — скажімо, сервер не працює або недоступний. Повільна сторінка до нього не належить.
• Хто говорить із дата-центром. На орендованому виділеному сервері диски й блоки живлення — фізичні. Коли щось відмовляє, хтось має подивитися стан RAID, домогтися заміни від дата-центру і простежити за відновленням масиву.

Де обслуговування закінчується: ваш застосунок

Зазвичай межа проходить по операційній системі та сервісах на ній. Ваш код, CMS, плагіни, деплой і дані залишаються вашими, якщо цю роботу не купувати окремо. Найбільше розчарувань — у сірій зоні: повільний запит, CI-пайплайн, переїзд на новий сервер, очищення зламаного сайту на WordPress. Хороший провайдер заздалегідь каже, що з цього входить у тариф і скільки коштує година роботи понад нього.

Сервер без обслуговування — інша крайність: провайдер відповідає за залізо, живлення й мережу, видає root — і на цьому все. Решта, зокрема сповіщення о третій ночі, на вас. Це чесна угода, якщо в команді вже є людина, яка цим займається. VPS із root-доступом без жодного обслуговування дешевший не просто так: ціна його супроводу переїжджає з рахунку у ваш календар.

Що запитати до покупки

1. Які оновлення входять і хто вирішує, коли перезавантажувати сервер?
2. Що моніториться і чи береться хтось за проблему після сповіщення?
3. Де зберігаються бекапи, як довго і коли востаннє перевіряли відновлення?
4. Який час першої відповіді, в які години і що вважається критичним?
5. Хто спілкується з дата-центром, якщо відмовило залізо?
6. Де закінчується послуга і скільки коштує година роботи понад неї?
7. Що буде, якщо я піду: ви видалите свій доступ, чи зможу я забрати бекапи?

На кожне запитання є коротка й конкретна відповідь. Якщо провайдер не готовий дати її письмово, це теж відповідь.

Коротко

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