Цена «настроил и забыл»: обслуживание сервера за пять лет

MAATRIX

«Настроил один раз и забыл» — фраза, которую произносят на презентации проекта и вспоминают с досадой года через два, когда очередной аудит находит на сервере дистрибутив с истёкшей поддержкой, сертификат, продлившийся в последний день, или бэкап, который не разворачивается. Сервер действительно можно настроить один раз. Но «забыть» о нём — это не бесплатная опция, а решение платить за него временем, растянутым на годы вперёд.

Что на самом деле означает «настроил и забыл»

Когда сервер только развёрнут, кажется, что основная работа сделана: система установлена, приложение задеплоено, бэкап поставлен на cron, сертификат Let's Encrypt выпущен. Дальше — тишина, сайт работает, и это создаёт иллюзию нулевой стоимости эксплуатации на годы вперёд.

Проблема в том, что «настроил» описывает состояние сервера в момент времени T0, а инфраструктура живёт в T0+5 лет. За это время меняется всё вокруг: выходят обновления безопасности для ядра и пакетов, разработчики используемого вами ПО объявляют конец поддержки текущей мажорной версии, растёт нагрузка и заполняется диск, истекают сертификаты, а бэкап, который никто ни разу не пытался развернуть, тихо перестаёт быть бэкапом в тот день, когда меняется формат дампа или ротация случайно перезаписывает последнюю рабочую копию.

Ни одна из этих вещей не является разовой настройкой. Каждая — это периодическая задача с своим циклом: у обновлений безопасности цикл — дни и недели, у мажорных версий ПО — год-два, у пересмотра ресурсов — месяцы по мере роста нагрузки, у проверки бэкапа — тоже месяцы, если делать это дисциплинированно. Ниже — по каждому пункту отдельно, с тем, что конкретно приходится делать и почему откладывание обходится дороже самой задачи.

Обновления безопасности: тихий долг, который растёт каждый день

Уязвимости в ядре, OpenSSL, sudo, systemd и десятках других пакетов находят постоянно — это не сценарий на крайний случай, а фоновый процесс индустрии. Если сервер не обновляется, он не остаётся в безопасном состоянии «как было настроено» — он ежедневно теряет часть защиты, потому что список известных дыр в его версии пакетов растёт, а сам сервер не меняется.

Технически задача решается автоматизацией: unattended-upgrades на Debian/Ubuntu или dnf-automatic на AlmaLinux/RHEL закрывают патчи безопасности без участия человека:

# Ubuntu/Debian
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

# проверить, что действительно применяется
cat /var/log/unattended-upgrades/unattended-upgrades.log

Но автоматизация обновлений — это не «поставил и забыл» в квадрате. Автообновления нужно периодически проверять на предмет того, что они реально отрабатывают (лог может молчать месяцами, если пакетный менеджер начал падать на конфликте зависимостей), а раз в какое-то время всё равно требуется ручное вмешательство: обновление, которое тянет за собой перезапуск сервиса, конфликт версий библиотек, необходимость перезагрузки после обновления ядра. Мы разбирали типовые сбои такой автоматизации в статье про автообновления безопасности — там же нюансы, из-за которых автообновления иногда молча перестают работать.

За пять лет это не одно действие, а постоянный фоновый процесс: настройка автоматизации в начале, периодические проверки логов, ручные вмешательства при конфликтах, разбор случаев, когда обновление что-то сломало и требуется откат. Именно этот процесс и есть первая, самая недооценённая статья «цены» мифа про однократную настройку.

Плановое обновление версий ПО: рано или поздно упрётесь в конец поддержки

Отдельно от патчей безопасности стоит вопрос мажорных версий. PostgreSQL, Node.js, PHP, дистрибутивы Linux — у всех есть конечный срок поддержки конкретной версии. Ubuntu 20.04 LTS получала обновления безопасности до апреля 2025 года (Extended Security Maintenance продлевает срок дополнительно, но не бесконечно), PostgreSQL поддерживает каждую мажорную версию около пяти лет, Node.js держит LTS-ветку примерно 30 месяцев. Если развернуть сервер в 2026 году и ничего не трогать пять лет, вы гарантированно упрётесь в конец поддержки хотя бы одного компонента стека раньше, чем закончится этот срок.

Дальше выбор простой и неприятный: либо остаться на версии без обновлений безопасности (риск растёт вместе с рисками из предыдущего пункта), либо провести миграцию. Миграция на новую мажорную версию — это не apt upgrade в одну строку, а отдельный проект: проверка обратной совместимости, тестовое окружение, план отката, окно на само обновление. Для базы данных это может означать pg_upgrade или дамп/restore с проверкой, что приложение корректно работает на новой версии; для языка выполнения — тестирование зависимостей на совместимость.

Это не разовая задача при развёртывании — это регулярный проект, который придётся закладывать в план сопровождения каждые год-два, в зависимости от того, какие компоненты используются и какой у них жизненный цикл поддержки. И чем дольше это откладывать, тем дороже выходит: миграция с версии, до которой «дожили» на честном слове, обычно сложнее плановой, потому что накопились несовместимости, которые проще было закрывать по одной.

Мониторинг диска и памяти: нагрузка растёт, а конфигурация — нет

В момент настройки сервер подобран под текущую нагрузку: столько-то оперативной памяти, столько-то места на диске. Дальше нагрузка не стоит на месте — растут логи, база данных, файлы пользователей, число процессов. Конфигурация, которая была разумной в первый месяц, через два года может быть впритык, а ещё через год — недостаточной.

Без периодического контроля первым сигналом проблемы становится сам инцидент: диск заполнился на 100% и упала запись в базу, память кончилась и OOM killer убил случайный процесс. Разбор подобной ситуации, когда переполнение диска роняет по цепочке несколько сервисов сразу, — в статье про мониторинг диска на сервере: там же типичные ошибки настройки алертов, из-за которых мониторинг формально стоит, но не предупреждает вовремя.

Минимальный набор, который стоит проверять регулярно, а не только «когда что-то не работает»:

# место на диске и inode
df -h
df -i

# память и своп
free -h

# рост логов и данных за последний месяц
du -sh /var/log/* | sort -rh | head

Дело не только в том, чтобы поставить alert на 80% заполнения диска один раз. Со временем нужно пересматривать пороги (то, что было тревожным сигналом при 20 ГБ диска, неактуально при 200 ГБ), разбираться, что именно растёт быстрее ожидаемого — логи без ротации, старые бэкапы, разросшиеся временные файлы, — и по итогам либо чистить, либо расширять ресурсы. Это регулярная работа с горизонтом в месяцы, а не разовая настройка алерта при первом деплое.

Резервные копии: бэкап без проверки восстановления — это не бэкап

Cron-задача, которая пишет pg_dump или tar куда-то раз в сутки, — это самая частая форма «настроил и забыл» в администрировании. Задача выглядит выполненной: файлы появляются, размер похож на правду, лог без ошибок. Но факт наличия файла резервной копии не гарантирует, что из него можно восстановиться: формат мог измениться после обновления приложения, шифрование могло сломаться, диск с бэкапами мог незаметно переполниться и последние недели писать пустые архивы, права на файл могли не давать восстановить дамп на новой машине.

Единственный способ узнать, что бэкап рабочий, — реально развернуть его на тестовом окружении и проверить, что данные и приложение поднимаются. Разово это сделать несложно, но чтобы это защищало вас через два года, а не только в момент настройки, тест восстановления нужно повторять периодически — при каждом заметном изменении схемы данных или как минимум раз в квартал-полгода. Как именно организовать такую проверку и на что обращать внимание, разобрано в статье как проверить, что бэкап рабочий.

Практический минимум для регулярной проверки:

# для дампа PostgreSQL — восстановление в отдельную БД
createdb test_restore
pg_restore -d test_restore /path/to/dump.sql

# для файлового архива — распаковка и сверка контрольных сумм
tar -tzf backup.tar.gz > /dev/null && echo "archive OK"
sha256sum -c checksums.sha256

За пять лет это означает: не одну настройку cron-задачи, а регулярные, растянутые во времени проверки восстановления, актуализацию скрипта бэкапа при каждом изменении структуры приложения или базы, контроль за тем, что хранилище для копий само не переполняется, и пересмотр политики ротации по мере роста объёма данных.

SSL-сертификаты: автоматизация снимает боль, но не отменяет её полностью

Если сертификаты выпускаются через Let's Encrypt с автопродлением через certbot или встроенный механизм веб-сервера (Caddy делает это из коробки), задача в основном решена автоматизацией — сертификаты живут 90 дней и продлеваются заранее без участия человека. Но «в основном» — не значит «навсегда без внимания».

Типичный сбой такой автоматизации — сертификат продлился, а веб-сервер не перечитал новый файл и продолжает отдавать старый до истечения. Или DNS-провайдер поменял API, и продление через DNS-01 challenge стало молча падать. Или истёк сам домен, а не сертификат, и продление упирается в это. Разбор подобного случая — в статье сертификат не обновился, там же то, как отличить обрыв автоматизации от разовой аномалии.

Минимальная проверка, которую стоит делать периодически, а не полагаться на то, что «Let's Encrypt сам разберётся»:

# сколько дней осталось до истечения сертификата
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

# тестовый прогон продления certbot
certbot renew --dry-run

Если сертификаты выпущены вручную (например, для внутренних сервисов с самоподписанным CA или платным сертификатом с ручным продлением) — это уже не автоматизированная фоновая задача, а календарное напоминание, которое нужно кому-то держать в голове или в системе тикетов из года в год. Пропущенное продление — это не абстрактный риск, а конкретный простой сервиса в момент, когда браузер или клиент начинает отказывать в соединении.

Сколько это всё стоит: честная оценка накопленного времени

Точную цифру в часах или деньгах для конкретного случая никто не назовёт заранее — она зависит от размера инфраструктуры, числа сервисов, квалификации того, кто это делает, и от того, насколько удачно была настроена автоматизация с самого начала. Но порядок величины оценить можно, если честно перечислить все повторяющиеся задачи из разделов выше и прикинуть их за пять лет, а не за один месяц.

Даже если каждая отдельная итерация занимает немного времени, за пять лет счётчик не останавливается ни разу — он просто идёт менее заметно, чем при разовой настройке в первый месяц. Плюс к этому — непредсказуемые эпизоды: инцидент, когда бэкап оказался нерабочим именно тогда, когда понадобился, или обновление, которое сломало продакшен и потребовало срочного отката. Такие эпизоды случаются не у всех и не всегда, но именно они чаще всего и обходятся дороже всей плановой рутины вместе взятой — потому что решаются не в спокойном режиме, а под давлением простоя.

Честный вывод не в том, что сопровождение сервера должно кого-то пугать, а в том, что его нужно с самого начала закладывать в план как повторяющуюся статью — временную, а не только денежную — точно так же, как учитывается ежемесячный платёж за сам сервер.

Частые вопросы