Обслуживание серверов: что проверять каждый месяц

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

Зачем серверу регулярное обслуживание

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

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

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

Что проверять каждый месяц: чек-лист из 10 пунктов

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

1. Диски и SMART. Смотрим атрибуты накопителей: количество переназначенных секторов (Reallocated Sectors), ожидающие сектора (Current Pending), ошибки интерфейса (UDMA CRC). Рост любого из счётчиков — сигнал к замене диска до его окончательного отказа.
2. RAID. Проверяем статус массивов и журналы контроллера. Массив в состоянии degraded или rebuilding не должен оставаться в таком виде до следующего месяца — восстановление запускается в тот же день.
3. Резервные копии. Недостаточно того, что бэкап «завершился успешно». Раз в месяц выполняем тестовое восстановление конкретного файла, папки или базы и убеждаемся, что данные реально читаются.
4. Обновления ОС и ПО. Патчи безопасности устанавливаются по регламенту, а не «когда появится время». Закрытые уязвимости — это дешёвая защита от шифровальщиков и взлома.
5. Логи и ошибки. Просматриваем системные журналы на предмет повторяющихся ошибок дисков, памяти, сетевых адаптеров и контроллера хранилища.
6. Ресурсы. Фиксируем загрузку процессора и памяти в пиковые часы, свободное место на дисках, темп роста баз данных. Рост базы — это прогноз того, когда диск закончится.
7. Температуры и питание. Сверяем показания датчиков с нормой и проверяем UPS: сколько держат батареи под нагрузкой, нет ли ошибок самодиагностики.
8. Сеть и доступность. Проверяем порты, VPN-туннели, доступность сервисов извне и внутри сети, корректность DNS и маршрутизации.
9. Антивирус и безопасность. Обновляем базы, смотрим подозрительные процессы и автозагрузку, проверяем события неудачных входов.
10. Учётные записи и права. Удаляем или блокируем аккаунты уволенных сотрудников, ревизуем состав администраторов, запускаем ротацию паролей.

Диски и RAID: прогнозирование отказов

Диск почти никогда не умирает без предупреждения. S.M.A.R.T. фиксирует деградацию задолго до полного отказа, и задача регламента — поймать этот момент. Ориентируемся на три ключевых атрибута: Reallocated Sectors Count — сектора, уже переназначенные из резервной области; Current Pending Sector Count — нестабильные сектора, ожидающие проверки; UDMA CRC Error Count — ошибки интерфейса, часто указывающие на плохой кабель или контакт разъёма.

Единичные переназначенные сектора на новом диске — допустимая норма, но их рост месяц к месяцу — уже диагноз. Диск, который за два месяца набрал десятки переназначений, меняют планово, не дожидаясь, когда RAID-контроллер пометит его как failed. Для твердотельных накопителей дополнительно смотрим показатель износа (Wear Leveling) и суммарный объём записанных данных: у SSD ресурс перезаписи конечен, и его исчерпание прогнозируется заранее.

RAID защищает от отказа одного диска, но не от всех сценариев. Массив RAID 5 с одним вышедшим диском продолжает работать, однако во время rebuild’а нагрузка на оставшиеся диски максимальна — и именно в этот момент часто «сыпется» второй диск, у которого ресурс тоже был на исходе. Поэтому деградировавший массив восстанавливаем немедленно, а замену диска планируем так, чтобы не оставлять массив без резервирования на ночь или выходные. RAID не отменяет бэкапы: он защищает от отказа оборудования, но не от удаления данных, шифровальщика или ошибки администратора.

Резервные копии: проверять нужно восстановление

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

Базовое правило хранения — 3-2-1: три копии данных, на двух разных носителях, одна из которых вне площадки. Для одиночного сервера это означает, что единственная копия не должна лежать на самом сервере: держим её на отдельном хранилище, NAS или в облаке. Иначе отказ сервера одновременно уничтожает и данные, и «резерв».

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

Обновления, логи, безопасность и учётные записи

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

Системные журналы читаем не «всё подряд», а с прицелом на повторяющиеся ошибки: disk, memory, raid, события критических служб. Повтор одной и той же ошибки раз в несколько минут — повод для разбора, а не для игнорирования. Параллельно смотрим загрузку: стабильно высокая загрузка CPU или памяти в пиковые часы указывает либо на рост нагрузки, либо на деградацию оборудования.

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

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

План обслуживания: периодичность работ

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

Работа	Что именно проверяем	Периодичность
Диски и SMART	Переназначенные и ожидающие сектора, ошибки интерфейса, температура	ежемесячно
RAID	Статус массивов, журналы контроллера, наличие degraded/rebuilding	ежемесячно
Резервные копии	Завершение заданий, место в хранилище, глубина точек восстановления	ежемесячно
Тестовое восстановление	Восстановление файла и базы на проверочный ресурс	ежемесячно
Обновления ОС и антивируса	Патчи безопасности, обновление антивирусных баз	ежемесячно (патчи — по выходу)
Логи и ресурсы	Повторяющиеся ошибки, загрузка CPU/памяти, рост баз данных	ежемесячно
UPS и питание	Ёмкость батарей под нагрузкой, ошибки самодиагностики	ежеквартально
Аудит учётных записей и прав	Сверка с штатом, состав администраторов, ротация паролей	ежеквартально
Замена батарей UPS и чистка от пыли	Срок службы батарей, запылённость корпуса и вентиляции	раз в 3–5 лет / по факту

Стоимость такого обслуживания зависит от числа серверов, критичности сервисов и требуемого времени реакции (SLA). Гораздо выгоднее зафиксировать абонентскую плату и получать регламент целиком, чем платить за каждый выезд по факту аварии — актуальные тарифы собраны на странице цен на обслуживание. Опыт других компаний, которые уже перевели инфраструктуру на сопровождение, описан в разделе отзывов клиентов.

Типичные ошибки при обслуживании серверов

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

• Бэкапы делаются, но не проверяются. Самая опасная ошибка: до момента аварии компания уверена, что данные защищены, а на деле резервная копия нечитаема. Тестовое восстановление — единственный способ снять эту иллюзию.
• Надежда только на RAID. RAID спасает от отказа одного диска, но не от удаления данных, ошибки администратора или шифровальщика. Без внешней копии массив не является резервным копированием.
• Игнорирование SMART. «Диск же работает» — плохой аргумент, когда счётчики переназначенных секторов растут каждый месяц. Плановую замену пропускают, и диск умирает в самый неподходящий момент.
• Обновления «когда появится время». Время не появляется, а известные уязвимости остаются открытыми. Для шифровальщика месяцами не пропатченный сервер — это не цель, а проходной случай.
• Единственный бэкап лежит на том же сервере. Отказ сервера одновременно уничтожает и рабочие данные, и «резерв». Копия обязана лежать на отдельном носителе или в облаке.
• Активные учётки уволенных. Сотрудник ушёл, а его доступ к 1С, почте и VPN остался. Ревизия прав раз в квартал снимает этот риск почти полностью.
• Не отслеживается рост данных. База растёт, диск заполняется, и в какой-то момент место заканчивается внезапно — хотя график заполнения это показывал заранее. За ростом баз и свободным местом нужно наблюдать ежемесячно.

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

Признаки, что сервер уже в проблеме

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

• Сервер стал заметно медленнее: 1С «задумывается», терминальные сессии подвисают, файлы открываются с задержкой.
• В журналах повторяются ошибки дисков, памяти или RAID-контроллера.
• Бэкапы последний месяц завершались с ошибками или не выполнялись вовсе.
• Диск заполнен более чем на 85–90 % — система ещё работает, но запас на рост отсутствует.
• UPS периодически переключается на батарею без реального отключения электричества — это признак проблем с сетью питания или самим ИБП.
• Рост числа неудачных входов или подозрительная активность в журналах безопасности.

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

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

Хотите перевести серверы на регламентное обслуживание и закрыть риски простоя? Проведём аудит, составим чек-лист под вашу инфраструктуру и возьмём её на абонентское сопровождение — подробнее об ИТ-аутсорсинге.

Полезно на сайте: обслуживание серверов, ИТ-аутсорсинг, цены.