Аудит сервера: 20 проверок, которые стоит провести до первого сбоя

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

Аудит сервера – разовая проверка его состояния и конфигурации. Он не заменяет постоянный мониторинг или администрирование. Его результат – список конкретных замечаний: что нужно исправить, насколько срочно и кто отвечает за работу. Ниже – 20 пунктов, которые помогут заказать осмысленную проверку или провести первичную ревизию вместе со своим специалистом.

Прежде чем проверять: ничего не ломаем на работающем сервере

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

Первый проход должен быть преимущественно только на чтение. Отключать SSH, менять сетевые правила, обновлять всё подряд или перезапускать базу по ходу ревизии – плохая идея. Любое изменение требует отдельного плана и способа отката. Даже правильная настройка, применённая без подготовки, способна оставить компанию без работающего сайта.

Проверки 1–4. Кто может войти на сервер

Здесь чаще всего всплывают забытые учётные записи и права, оставшиеся после смены сотрудника или подрядчика.

• 1. Кто сейчас имеет доступ
• 2. Есть ли неиспользуемые учётные записи
• 3. Как на самом деле работает вход по SSH
• 4. Кому доступны права администратора

Что считать замечанием

Для пунктов 1–2 нужен актуальный перечень пользователей и ключей. Особенно проверьте учётные записи бывших сотрудников, технические аккаунты с непонятным владельцем и старые ключи подрядчиков. Неизвестный ключ – повод установить его происхождение, а не удалять вслепую.

В пункте 3 оценивают фактически действующие способы входа по SSH. Одной строчки в конфигурационном файле мало: на результат могут влиять дополнительные настройки и отдельные правила для пользователей. Пункт 4 посвящён правам администратора: они должны быть обоснованы задачей и закреплены за конкретными людьми. Пароли и закрытые ключи в общей переписке – отдельная проблема, которую стоит устранить по плану.

Проверки 5–8. Что сервер показывает внешнему миру

• 5. Открытые порты. Сверить фактические сетевые подключения с назначением сервера: каждый слушающий сервис должен быть понятен.
• 6. Сетевые правила. Проверить ограничения входящих соединений, включая IPv6, если он используется.
• 7. Административные интерфейсы. Убедиться, что панели управления, базы данных и внутренние службы не доступны всем подряд из интернета.
• 8. HTTPS и сертификаты. Проверить срок действия сертификатов, настройки продления и соответствие доменов фактически работающим сайтам.

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

Проверки 9–12. Обновления и незаметная фоновая работа

• 9. Операционная система. Уточнить версию Linux и срок её поддержки.
• 10. Пакеты и приложения. Выяснить, какие обновления ожидают установки, а какие компоненты давно не обслуживались.
• 11. Системные службы. Проверить, что нужные сервисы запускаются после перезагрузки и не находятся в состоянии постоянных сбоев.
• 12. Задания по расписанию. Просмотреть cron, systemd-таймеры и фоновые операции: кому они нужны и чем заканчиваются.

Особое внимание – к задачам, которые работают «сами собой». Иногда именно забытый скрипт постепенно заполняет диск файлами. В другом случае резервная копия перестаёт выполняться после смены пароля к базе. Ревизия должна показать не только список настроек, но и то, выполняются ли запланированные задачи.

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

Проверки 13–16. Состояние системы и журналы

Смотрим, что сервер выдерживает сегодня и какие признаки проблем уже записаны в системе.

• 13. Нагрузка, память и swap
• 14. Диски, inode и ошибки чтения
• 15. Размер журналов и их ротация
• 16. Синхронизация времени и повторяющиеся ошибки

На что обращать внимание

Загруженный процессор не всегда проблема: важно соотнести нагрузку с временем отклика приложений. По дискам проверяют не только свободные гигабайты, но и количество доступных inode, задержки операций и ошибки. У журналов смотрят, сохраняются ли нужные события и не разрастаются ли файлы бесконтрольно. Синхронное время важно для разбора сбоев, иначе события разных систем трудно сопоставить.

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

Проверки 17–20. Получится ли восстановить работу

• 17. Состав данных. Перечислить базы, пользовательские файлы, конфигурации и другие компоненты, без которых проект не запустится после восстановления.
• 18. Резервные копии. Проверить время последнего успешного задания, глубину хранения и наличие независимой от основного сервера копии.
• 19. Пробное восстановление. Найти дату и результат последнего теста: что действительно удалось поднять из резервов.
• 20. Сигнал о неисправности. Убедиться, что внешняя проверка работоспособности есть, уведомления доходят ответственному, а восстановление после сбоя не остаётся без подтверждения.

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

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

Что должно остаться после аудита сервера

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

• Что проверили. Перечень сервера и сервисов, дата проверки, границы работ.
• Что обнаружили. Замечание с подтверждением: какой доступ остался, какой сертификат скоро истечёт, какая копия не проверялась.
• Насколько срочно. Отдельно отметить проблемы, которые требуют быстрого решения, и улучшения, которые можно запланировать.
• Кто и когда исправляет. Ответственный, ожидаемое изменение, окно работ и план отката, если потребуется.
• Как подтвердить результат. Что перепроверить после внесения изменений, чтобы ошибка не осталась только на бумаге.

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

Когда нужна отдельная проверка, а когда сопровождение

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

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

Не обязательно заказывать проверку «на всё подряд». Начните с самого важного сервера, обозначьте, что на нём работает, и попросите отчёт по конкретным пунктам. Так проще сравнить предложения и не платить за непонятный набор технических действий.