Чек-лист обслуговування Linux-сервера

Що насправді означає обслуговування Linux-сервера

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

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

Наведені тут команди є ілюстративними, їх слід прочитати перед виконанням. Порівнюйте їхній вивід із показниками вашого сервера, оскільки нормальні значення вільного місця чи кількості процесів залежать від завдань конкретної машини. Якщо перевірка відрізняється залежно від дистрибутива, про це зазначено в тексті. Приклади використовують Debian та Ubuntu з apt. У сімействі RHEL інструментарій — це dnf, а деякі шляхи відрізняються.

Як обрати графік обслуговування Linux-сервера, якого ви зможете дотримуватися

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

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

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

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

Щотижнева перевірка: чи справді встановилися оновлення?

Увімкнення unattended-upgrades не означає, що процес оновлення був виконаний. Сервіс може бути заблокований (masked), конфігурація може обмежуватися джерелом, яке ви не використовуєте, а один зафіксований (held) пакет може зупинити кожне наступне виконання. Встановлення описано в автоматичні оновлення безпеки в Ubuntu. Щотижневе завдання має підтвердити, що встановлене ПЗ виконало свою роботу.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable є надійним показником, оскільки він відображає поточний стан, а не наміри. Якщо оновлення безпеки все ще знаходяться у цьому списку, це означає, що автоматизація не працює, тому перегляньте журнал, перш ніж вважати систему оновленою. Пакет, зафіксований за допомогою apt-mark hold, пропускається назавжди і не видає жодних звітів, тому apt-mark showhold має виконуватися під час того самого проходу.

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

Щотижнева перевірка: вільне місце на диску та кількість інодів

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

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i — це аспект, який часто ігнорують. Іноди (inodes) — це структури з фіксованою кількістю, що зберігають метадані файлів. Файлова система може вичерпати їх, навіть якщо df -h все ще показує наявність вільних гігабайтів. У такому разі операції запису завершуються помилкою No space left on device, попри звіт про вільне місце, що вперше може призвести до втрати години часу на діагностику. Типовою причиною є мільйони дрібних файлів, що накопичилися через завислу чергу пошти або каталог сесій, який ніхто не очищує.

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

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

Щотижнева перевірка: що зупинилося без сповіщення?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Unit, який завершився з помилкою та вичерпав ліміт перезапусків, переходить у стан failed і залишається в ньому, не подаючи ознак життя. Жодних сповіщень про це не надходить. list-timers — це корисніша частина: вона показує, коли таймер запускався востаннє і коли спрацює наступного разу. Якщо значення LAST старіше за інтервал самого таймера, це означає, що завдання не виконувалося взагалі.

Перед перезапуском unit перегляньте його журнал за допомогою journalctl -u <unit> -n 100 --no-pager. Перезапуск лише усуває симптом, після чого у вас не буде підстав шукати причину, доки ситуація не повториться в незручний час.

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

Щотижнева перевірка: чи справді завершилося завдання резервного копіювання?

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

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

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

Якщо ваш скрипт передає дамп у компресор через pipe, додайте set -o pipefail на початку. Без цього параметра код виходу конвеєра відповідатиме лише компресору, а компресор зазвичай завершується успішно: він успішно стиснув повідомлення про помилку. У результаті завдання щоночі звітуватиме про успіх, записуючи при цьому порожній архів мінімального розміру.

Щомісяця: відновлення резервної копії на іншому сервері

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

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

Інструменти для роботи з репозиторіями мають власні засоби перевірки: restic check --read-data-subset=5% та borg check --verify-data зчитують збережені дані, а не індекс. Запускайте їх, але сприймайте це як базовий тест працездатності, а не як повноцінну заміну відновленню. Верифікація перевіряє цілісність байтів. Відновлення перевіряє, чи є ці байти саме тими, які потрібні вашому застосунку.

Є два нюанси, про які часто дізнаються на гіркому досвіді. Перевіряйте парольну фразу для дешифрування на машині, де ключ ще не доданий до агента, оскільки резервна копія, яку неможливо розшифрувати, не є резервною копією. Також заміряйте час відновлення, оскільки ця тривалість є вашим реальним часом відновлення (RTO), а дізнаватися про нього під час аварійної ситуації — найгірший момент.

Щомісяця: які сертифікати скоро закінчуються?

Автоматизація поновлення може завершуватися з помилкою без сповіщень. Таймер certbot може оновити файл на диску, тоді як вебсервер продовжує видавати старий сертифікат із пам'яті, оскільки deploy hook, що перезавантажує сервіс, не спрацював. Тому запитуйте безпосередньо у сервера, який саме сертифікат він видає, звертаючись до нього ззовні.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Прапор -servername встановлює SNI (server name indication), що є обов'язковим для будь-якої адреси, на якій розміщено більше одного сайту; інакше ви отримаєте стандартний сертифікат замість свого. Якщо certbot було встановлено через snap, таймер має іншу назву, тому шукайте за ключовим словом, а не за назвою unit, яку ви припустили.

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

Щомісяця: користувачі, доступ sudo та SSH-ключі

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T виводить фактичну конфігурацію після об’єднання всіх Include, яку саме і використовуватиме демон. Сучасні образи Ubuntu містять додаткові файли в /etc/ssh/sshd_config.d/, які можуть перекривати основний файл, тому читання лише sshd_config може надати хибну інформацію. У дистрибутивах сімейства RHEL адміністративною групою є wheel, а не sudo, тому внесіть відповідні зміни в рядок getent.

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

Для перегляду історії входу journalctl -t sshd --since "30 days ago" | grep -i accepted здійснює пошук за ідентифікатором syslog, а не за назвою unit. Це важливо, оскільки Ubuntu 24.04 активує SSH через сокет, тому кожне з’єднання реєструється під згенерованим unit для кожного окремого підключення, і звичайний journalctl -u ssh може їх пропустити.

Щомісяця: старі ядра та заповнений /boot

/boot часто є окремим розділом на кілька сотень мегабайтів у стандартному образі VPS. Кожне оновлення ядра додає туди образ та initramfs. Коли він заповнюється, наступне оновлення переривається, залишаючи пакунки неналаштованими — це критичний стан, з яким краще не стикатися в п'ятницю.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r передусім: вона показує ядро, яке ви використовуєте зараз, і його обов'язково потрібно залишити під час очищення. apt autoremove вирішує типову ситуацію в Debian та Ubuntu, оскільки ядра позначаються як автоматично встановлені, а поточне — захищене. Виняткові випадки, як-от вручну встановлене ядро або /boot, що вже настільки заповнений, що блокує роботу самого apt, описані в очищенні старих ядер в Ubuntu.

Щомісяця: зростання логів та журнал systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

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

Розмір журналу обмежується засобами systemd, але це частка від обсягу файлової системи, а не фіксоване число, яке ви обрали. Встановіть SystemMaxUse= у файлі /etc/systemd/journald.conf та перезапустіть systemd-journald, якщо хочете задати конкретну межу. sudo journalctl --vacuum-time=14d звільняє місце негайно; це разова дія, а не політика, тому використовуйте її разом зі зміною конфігурації.

Щодо релізів: перезавантаження, яке ви постійно відкладаєте

Оновлений пакет ядра на диску — це не ядро, що працює в пам'яті. До моменту перезавантаження машина продовжує використовувати стару версію, а live patching, де він доступний, охоплює лише частину виправлень.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Цей файл-прапорець є стандартом для Debian та Ubuntu, який створюється скриптами пакетів. Системи сімейства RHEL не створюють його, а відповідь на аналогічне питання там надає needs-restarting -r, що є частиною dnf-utils. Утиліта needrestart, яка встановлена за замовчуванням у сучасних образах Ubuntu server, відповідає за рівень нижче ядра: вона відображає процеси, що все ще використовують бібліотеку, яка була замінена на диску. Саме тому оновлений OpenSSL не почне діяти, доки не будуть перезапущені сервіси, що його використовують.

Плануйте перезавантаження, замість того щоб уникати його. У /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; та Unattended-Upgrade::Automatic-Reboot-Time "03:00"; ви можете призначити виконання на обраний вами час. Планове перезавантаження — це також єдиний спосіб перевірити, чи завантажиться сервер успішно, оскільки пошкоджений запис у fstab або сервіс, який ви забули увімкнути, виявлять себе лише під час завантаження системи.

Планування оновлення дистрибутива

Релізи Ubuntu LTS мають п'ять років стандартної підтримки, а проміжні релізи — дев'ять місяців, тому ваш вибір визначає обсяг робіт з оновлення на роки вперед. Цей компроміс описано в LTS проти проміжних релізів на сервері.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade зчитує цей файл, а Prompt=lts обмежує його лише переходами між версіями LTS. Шлях оновлення LTS-to-LTS зазвичай відкривається після виходу першого точкового релізу нової версії, а не в день її виходу, тому перевірте, що саме пропонується вашій системі, замість того, щоб планувати оновлення на очікувану дату. Механіка переходу описана в оновленні Ubuntu 24.04 до 26.04.

Закладайте три місяці запасу часу. Зробіть знімок системи (snapshot), відновлення з якого ви протестували, складіть список сторонніх репозиторіїв apt (процес оновлення вимикає їх, і для кожного знадобиться новий цільовий репозиторій для нової версії) і визначте план відкату до початку робіт. Станом на серпень 2026 року Ubuntu 24.04 LTS має стандартну підтримку до квітня 2029 року, тому це питання планування, а не екстрена ситуація.

Що автоматизувати, а що залишити ручним

Автоматизуйте рішення, які ви вже прийняли: оновлення безпеки, ротацію журналів, поновлення сертифікатів, завдання резервного копіювання. Автоматизуйте також сповіщення, оскільки перевірка, яка залежить від того, чи згадаєте ви про неї, — це перевірка, яка не відбудеться о 2-й годині ночі. Зовнішній моніторинг, наприклад self-hosted моніторинг стану за допомогою Uptime Kuma, фіксує те, про що не може повідомити жоден локальний скрипт: недоступність самого сервера.

Залиште дві речі ручними: тестування відновлення та аудит облікових записів. В обох випадках потрібна людина, яка вирішить, чи є результат правильним. Якщо ви віддаєте перевагу перегляду стану системи в браузері, а не в терміналі, порівняння Cockpit та Webmin для керування сервером розглядає дві типові вебконсолі.

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

Увесь контрольний список в одному місці

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Як часто слід проводити обслуговування Linux-сервера?

Щотижня для всього, що змінюється самостійно: статус оновлень, вільне місце на диску та кількість вільних inode, стан невдалих unit-ів, а також чи завершилося завдання резервного копіювання. Щомісяця для перевірки поступової деградації: тест відновлення, термін дії сертифікатів, аудит облікових записів і SSH-ключів, видалення старих ядер, аналіз росту журналів. Один раз на випуск дистрибутива — для оновлення версії та перезавантаження в нове ядро. Щотижнева перевірка на справній системі займає кілька хвилин; саме тому її варто робити регулярно, а не лише тоді, коли виникають проблеми.

Чому потрібно тестувати відновлення, якщо завдання резервного копіювання повідомляє про успіх?

Тому що завдання звітує про власний код завершення, який може бути успішним, навіть якщо архів непридатний. Дамп, переданий у компресор без set -o pipefail, повертає статус компресора, тому невдалий дамп, який видав лише повідомлення про помилку, все одно завершується з кодом 0 і створює невеликий файл. Виконайте відновлення на іншу машину, відкрийте дані та перевірте їх цілісність. Тест відновлення також заміряє час, і ця тривалість є вашим реальним часом відновлення (RTO).

Чи обов'язково перезавантажуватися після кожного оновлення ядра?

Ви повинні перезавантажитися, щоб почало працювати нове ядро. У Debian та Ubuntu наявність файлу /var/run/reboot-required свідчить про те, що пакет вимагає перезавантаження, а /var/run/reboot-required.pkgs вказує, який саме. У сімействі RHEL такого файлу немає, і на це ж питання відповідає needs-restarting -r з пакета dnf-utils. Налаштуйте вікно автоматичного перезавантаження в /etc/apt/apt.conf.d/50unattended-upgrades замість того, щоб відкладати його на невизначений термін, оскільки машина, яка не перезавантажувалася рік, має не лише старе ядро, а й неперевірений процес завантаження.

Які з цих перевірок можна безпечно автоматизувати?

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