Диагностика серверного оборудования: с чего начать

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

Два сценария диагностики: полный отказ или деградация

При полном отказе сначала разделяют питание и доступность сети. При деградации начинают с событий и метрик. Стартовая точка определяет дальнейшие проверки.

Сервер недоступен. Разделите отсутствие питания и сетевого доступа: проверьте локальные LED, PDU/UPS, вводы и кабели. Если питание есть, проверьте management-сеть, IP, VLAN и порт коммутатора. Недоступный BMC по сети не доказывает отказ платы. Только после локализации проблемы питания переходите к БП или плате по сервисному регламенту.

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

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

Пошаговый чек-лист диагностики серверного оборудования

Шаги 1-4: индикаторы, IPMI, логи ОС и S.M.A.R.T. дисков

Шаг 1. Значение LED проверяют по руководству модели. Общий health-индикатор сообщает о событии, но компонент определяют по коду, отдельному LED и BMC/SEL. Зафиксируйте сигнал и время, сопоставьте с датчиками и журналом. Цвет сам по себе не подтверждает диагноз.

Шаг 2. Консоль BMC работает независимо от ОС, если есть питание и исправен путь управления. Прочитайте SEL, статусы питания, температуры, памяти, дисков и вентиляторов. Сохраните события до очистки журнала. Возможности различаются по модели и лицензии. Удаленную перезагрузку не выполняйте как первый тест: она прервет нагрузку и может скрыть симптом.

Шаг 3. Логи операционной системы. В Linux смотрят dmesg и journalctl -xe, файлы /var/log/syslog и /var/log/messages. В Windows Server открывают Event Viewer, разделы System и Application. Ищут критические ошибки за период проблемы: сбои ввода-вывода, ошибки памяти, отказы дисков.

Шаг 4. Сопоставьте виртуальные и физические диски. За RAID используйте поддерживаемый backend smartctl или утилиту контроллера. Пример для совместимого MegaRAID: smartctl -a -d megaraid,N /dev/sdX, где N номер диска. Проверяют каждый накопитель и массив. ATA, SAS и NVMe имеют разные журналы. Оценивайте health, critical warnings, ошибки и динамику по документации. Счетчик не задает срок отказа, чистый журнал не заменяет backup.

Шаги 5-8: память, процессор, сеть и питание

Шаг 5. memtester проверяет выделенную область в userspace с запасом памяти для ОС и приложений. Для автономного теста RAM используйте Memtest86+ или штатную диагностику после вывода нагрузки в окне. Результаты сопоставьте с ECC и SEL, модуль определяйте по сервисной карте.

Шаг 6. Сопоставьте температуру, нагрузку и RAS/MCE. Разберите банк, тип и адрес ошибки, сравните SEL и ECC. Причина может быть в CPU, памяти, шинах или питании. Факт MCE не обосновывает замену CPU. Температурный предел проверяют по модели.

Шаг 7. Проверьте link, скорость и согласование. ip -s -s link show dev ИНТЕРФЕЙС дает счетчики, ethtool -S ИНТЕРФЕЙС статистику драйвера, MAC и PHY. Подставьте имя интерфейса. CRC сопоставляют с линией и портом, dropped разбирают по причинам, нагрузке и очередям. iperf3 создает нагрузку: нужен разрешенный режим.

Шаг 8. Проверьте AC-вводы, fault-статусы БП, запас мощности и резервирование. В hot-spare один БП может штатно быть в standby, нулевая нагрузка не доказывает отказ. Сверьте события с руководством и цепями питания. Два БП на одном вводе не защищают от его отказа.

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

Инструменты и утилиты для диагностики сервера

Что должно быть в арсенале эксплуатационного инженера:

1. Клиент для web-доступа к консоли управления сервером: iLO, iDRAC, XCC и аналоги. Доступ стоит вынести в отдельный VLAN только для администраторов.
2. Загрузочные флешки с инструментами: Memtest86+ для проверки памяти, Ubuntu Live с базовым набором Linux-утилит, SystemRescueCD для восстановления, Hiren BootCD с инструментами для Windows.
3. Фирменные утилиты платформы и контроллера помогают проверить RAID, датчики и состав оборудования. Совместимость и версии уточняют по документации конкретной модели. Средство управления одной платформы не следует считать универсальным для любого сервера.
4. Централизованный мониторинг: Zabbix, Prometheus, PRTG. Эти системы собирают метрики процессора, памяти, дисков и сети со всех серверов сразу. При инциденте история за неделю показывает, с какого момента началась деградация.
5. Логирование в отдельную систему: Elasticsearch, Loki, Splunk. Один запрос по времени поднимает связанные события за нужный период вместо ручного просмотра логов каждого сервера.

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

Когда пора обращаться в сервис

Границы возможностей внутренней команды

Три ситуации, когда нужен сервис-инженер:

1. Локализован отказ компонента, но нет подтвержденной совместимой замены. Обратитесь к сервисному исполнителю и уточните наличие, сроки и порядок работ. Обещание ремонта без простоя требует резервной схемы и не следует из самой доставки детали.
2. Периодическая проблема не объясняется доступными событиями. Передайте сервису временную шкалу, логи, дампы и конфигурацию. Специалист определит метод проверки. Один осциллограф не гарантирует локализацию любой неисправности.
3. Для электроники и логического восстановления нужен профильный сервис. Чистая среда требуется при вскрытии гермоблока HDD, а не любой платы. Лабораторию выбирают по повреждению. При угрозе данным исключите действия, ухудшающие восстановление.

Эскалацию задают критичность, SLA и риск данных. При потере данных, нескольких disk fault или неисправном питании обращайтесь в сервис сразу. Проверки продолжайте только в разрешенном объеме, не ожидая четырех часов.

Типичные ошибки при диагностике серверного оборудования

Что чаще всего идет не так:

1. Сразу вскрывают шасси и меняют компоненты наугад, теряя время и рискуя повредить исправные части.
2. Не сохраняют события BMC и ОС. После перезагрузки или очистки журналов исходный симптом может исчезнуть.
3. Трактуют статус накопителя как точный срок отказа. Проверяют журнал, динамику и массив, а не только цвет в панели мониторинга.
4. Не проверяют PDU, питающие цепи и management-кабель. Вентилятор оценивают по отдельному sensor/fault событию.
5. Читают логи за слишком короткий период, час до инцидента вместо суток, и упускают первопричину.
6. Работают без мониторинга. При инциденте нет истории метрик, диагностика идет вслепую.
7. Запускают нагрузочные тесты на продуктиве без подготовки. Сначала читают события, датчики и счетчики. Reboot, загрузочную диагностику и вмешательство в RAID выполняют в окне, после проверки копий и вывода нагрузки.
8. Экономят на инструментах. Флешки с Memtest86+ нет под рукой, live-диск скачивают под давлением инцидента.
9. Не ведут документацию по инфраструктуре. При инциденте никто не помнит, где какой IP-адрес и роль сервера.
10. Нет плана эскалации. При затянувшейся диагностике непонятно, когда звать вендора или партнера.

Заключение

Порядок диагностики начинается с питания и доступности, затем переходит к BMC, журналам ОС и накопителей. Счетчик или цвет LED не доказывает единственную причину: результат сопоставляют с моделью, динамикой и событиями. На работающем сервере сначала выполняют чтение без изменения конфигурации. Тесты и замены планируют по регламенту. Эскалацию определяют риск данных, критичность и SLA, а не фиксированное число часов.

Регулярный аудит ИТ-инфраструктуры помогает согласовать мониторинг, документацию и эскалацию. Serverzilla поможет проверить серверы и резервирование по результатам диагностики. Срок реакции и восстановления закрепляют отдельно в сервисном договоре.