Три часа ночи. Телефон сначала вибрирует, потом начинает звонить. После третьего уведомления сомнений нет – случилось что-то серьезное. На экране мигает иконка PagerDuty. Ваш основной сервер базы данных легла.
Вы судорожно логинитесь, ожидая увидеть отказ оборудования или следы взлома, а натыкаетесь на глупую и дико раздражающую ситуацию: сервер сам накатил апдейты и ушел в ребут. Молча, без предупреждений. Настройки по умолчанию «посчитали», что утро вторника – отличное время для даунтайма.
Это классический кошмар любого сисадмина. Ставить патчи, безусловно, нужно, но доверять этот процесс автоматике Linux на проде – верный путь к катастрофе.
В этом гайде мы разберем, как вернуть контроль в свои руки. Вы узнаете, как запретить внезапные ребуты, настроить адекватную тестовую среду (стейджинг) и наладить процесс обновлений так, чтобы ваши выходные проходили без панических атак.
Управление сервером – это вечная борьба между безопасностью и стабильностью.
Разработчики операционных систем хотят, чтобы вы использовали самые свежие версии ядра и библиотек. Их цель – закрыть уязвимости и выкатить новые функции. Но вашему серверу плевать на график релизов вендора – ему важно лишь, чтобы версии библиотек подходили вашему приложению
Включать автообновления на проде – это лотерея. Вы, по сути, делаете ставку: надеетесь, что свежее ядро не «поссорится» с вашими драйверами, а в новой библиотеке не убрали функцию, на которой держится все приложение.
Если ставка не сыграет, цена ошибки будет высокой. Это не просто внеплановая перезагрузка, а риск потери данных, простой сервиса и стресс от отладки системы, которая изменилась без вашего ведома. Патчи безопасности обязательны, спору нет. Но когда и как их ставить – решать должен инженер, а не бездумный скрипт.
Выделенные ресурсы и изоляция KVM для глобальных экспериментов.
Почему это вообще происходит? Конечно, не потому, что вы случайно нажали «ОК» во всплывающем окне. Проблема в том, что современные дистрибутивы Linux иногда слишком сильно пытаются быть полезными.
Реальность такова: в большинстве стандартных образов ОС службы автообновления включены по умолчанию. Примеры:
Для личного ноутбука или некритичного сервера разработки (dev-box) это удобно. Но на нагруженном SQL-сервере? Это бомба замедленного действия. Если вы не взяли эти службы под контроль, рано или поздно прилетит обновление, которое просто положит ваш стек.
Внезапный апдейт бьет больнее, чем просто перезагрузка сервера. Вот что «ломается» чаще всего:
Чтобы этого избежать, нужно действовать на опережение. Выключая «автопилот», вы гарантируете, что важные решения принимает человек, а не скрипт.
Правило номер один: никогда не обновляйте продакшн без тестов.
Вам необходим стейджинг. Это не опция «для красоты», а гарантия стабильности. Стейджинг – это копия (или максимально близкий аналог) вашего сервера. Это песочница, где обновления либо проходят проверку, либо ломают все, но без последствий для бизнеса.
Вам не нужно дублировать всю инфраструктуру с технической стороны, но версии программного обеспечения должно совпадать идеально:
Поломка на стейджинге сбережет компании кучу денег. Поломка на проде обеспечит вас работой по восстановлению на ближайшие дни.
Когда апдейт выжил на стейджинге, его нужно запланировать. Для этого существуют окна обслуживания (maintenance windows).
Это заранее согласованный интервал, когда вы имеете право отключить сервисы для перезагрузки, не вызывая паники у пользователей. Вот как это лучше сделать:
Грамотное управление изменениями означает, что вы никогда не обновляетесь вслепую и на удачу. Даже если вся «команда» – это только вы, задокументируйте план действий, прежде чем вы введете sudo.
Перейдем к технической части. Ваша задача – отключить обновление всего подряд, но при этом сохранить получение информации о патчах безопасности.
В Ubuntu этим управляет пакет unattended-upgrades. Удалять его необязательно – можно просто настроить его так, чтобы он ставил только критические патчи безопасности и никогда не перезагружал сервер самостоятельно.
Откройте файл конфигурации:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
Найдите блок Unattended-Upgrade::Allowed-Origins. Вам нужно закомментировать строку с обычными обновлениями (updates) и оставить только безопасность (security):
// "${distro_id}:${distro_codename}-updates";"${distro_id}:${distro_codename}-security";
И, что критически важно, убедитесь, что автоматическая перезагрузка отключена:
Unattended-Upgrade::Automatic-Reboot "false";
Если же вы хотите полностью убрать автообновления (потому что планируете делать все вручную строго в окно обслуживания), просто отключите службу:
sudo systemctl disable unattended-upgrades
sudo systemctl stop unattended-upgrades
В системах на базе RHEL, использующих dnf (или yum), обратите внимание на службу dnf-automatic.
Откройте конфиг:
sudo nano /etc/dnf/dnf-automatic.conf
Чтобы система знала о наличии обновлений, но не устанавливала их, задайте следующие параметры:
[commands]apply_updates = nodownload_updates = yes
Такая настройка скачает метаданные и вы будете видеть, какие пакеты требуют обновления, но система не тронет бинарные файлы без вашей команды.
Иногда версию конкретного пакета нужно, что называется, «прибить гвоздями». Допустим, ваше приложение стабильно работает только на PHP 8.1, а переход на 8.2 все ломает. Если запустить стандартное обновление системы, ОС может без спроса повысить версию до 8.2.
Вы можете «залочить» (закрепить) версию пакета, чтобы менеджер обновлений игнорировал ее при апдейтах.
В Ubuntu (apt):
sudo apt-mark hold package_name
Чтобы снять блокировку позже:
sudo apt-mark unhold package_name
В CentOS (yum/dnf): Вам понадобится плагин versionlock.
sudo dnf install 'dnf-command(versionlock)'
sudo dnf versionlock add package_name
Даже если на стейджинге все прошло гладко, обновление все равно может «положить» продакшн. Вам нужен план отката:
Мы уже упоминали управление изменениями (Change Management), но эта тема заслуживает отдельного внимания. Change Management – это дисциплина, которая дает четкое понимание: что изменилось, когда и почему.
Внедрение строгого контроля изменений превращает вашу инфраструктуру из непредсказуемого беспорядка в надежную и управляемую платформу.
Этот чек-лист универсален: он работает и для рядовых обновлений Linux, и для масштабных миграций баз данных. Следуя принципам управления изменениями, вы пишете историю своей инфраструктуры. И когда через полгода что-то внезапно «отвалится», вы сможете отмотать назад и точно увидеть, в какой день изменилась та самая библиотека.
Администрирование серверов – это вечная война с энтропией. Все стремится сломаться, а конфигурации софта постоянно «разъезжаются». Ваша задача – держать эти процессы в ежовых рукавицах.
Отключая бесконтрольные автообновления, соблюдая жесткую дисциплину тестирования и фиксируя версии пакетов, вы меняете саму парадигму работы. Вы перестаете вечно «тушить пожары» (реактивный подход) и начинаете предотвращать их появление (проактивный подход).
Не давайте серверу шанса застать вас врасплох. Сделайте управление изменениями фундаментом вашей безопасности. Ваш аптайм (и ваш здоровый сон) скажут вам спасибо.