Администрирование Linux-серверов: что автоматизировать

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

Принцип: инфраструктура как код

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

Плюсы: видно историю изменений, новый сервер настраивается так же, как старые, а знание не уходит вместе с администратором.

Управление конфигурацией

Самый распространённый инструмент для небольших и средних парков — Ansible. Он подключается к серверам по SSH, не требует установки агентов и описывает задачи в понятных YAML-файлах. Альтернативы — Puppet, Salt, Chef — чаще встречаются в крупных инфраструктурах.

Что обычно описывают первым:

• Базовые пакеты и настройки времени, локали, часового пояса
• Пользователей администраторов и их SSH-ключи
• Настройки SSH: вход только по ключам, запрет входа под root
• Межсетевой экран с разрешёнными портами
• Установку и конфигурацию веб-сервера, базы, Docker

Обновления

• Автоматическая установка обновлений безопасности (в Debian и Ubuntu — механизм unattended-upgrades)
• Крупные обновления — вручную по расписанию, сначала на тестовом сервере
• Уведомление, когда серверу требуется перезагрузка после обновления ядра

Резервное копирование

Задачи бэкапа запускаются по расписанию через cron или таймеры systemd:

1. Выгрузка баз данных в дамп
2. Копирование дампов и важных каталогов на другой сервер или в объектное хранилище
3. Удаление старых копий по правилу хранения
4. Уведомление о неуспешном выполнении

Отдельно автоматизируется проверка восстановления: периодически копия разворачивается на тестовом сервере, и скрипт проверяет, что база поднялась и данные читаются. Бэкап, который ни разу не восстанавливали, — гипотеза, а не копия.

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

• Доступность сервисов: отвечает ли сайт, работает ли API
• Ресурсы: заполнение дисков, нагрузка, память
• Срок действия TLS-сертификатов
• Оповещения в Telegram-чат администраторов или на почту

Мониторинг тоже разворачивается через конфигурацию, а не настраивается вручную на каждом сервере.

Журналы

• Ротация логов через logrotate, чтобы они не заполнили диск
• Сбор журналов с нескольких серверов в одно место для поиска
• Отдельное хранение журналов входа и действий администраторов

Пользователи и доступы

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

С чего начать

• Описать текущие серверы: что на них работает и как они настроены
• Завести репозиторий для конфигураций
• Автоматизировать сначала общие вещи: пользователей, SSH, обновления, межсетевой экран
• Затем — бэкапы и мониторинг
• Потом — настройку конкретных приложений

Ошибки

• Запуск сценариев сразу на рабочих серверах без проверки на тестовом
• Секреты и пароли в открытом виде в репозитории — их хранят в зашифрованном хранилище
• Ручные правки на сервере после внедрения автоматизации: конфигурация в коде и реальность расходятся
• Сложные сценарии, которые понимает только автор