Диагностический пакет для RMA: SupportAssist и HPE AHS

Зачем заранее готовить диагностику для RMA

RMA (Return Merchandise Authorization) - это процедура замены или ремонта оборудования по гарантии. На практике она редко начинается с просьбы «просто замените деталь». Производитель почти всегда просит факты: что именно произошло, в каких условиях, и есть ли подтверждение в логах. Если диагностического пакета нет, переписка легко растягивается на дни, потому что поддержку приходится убеждать словами, а не данными.

При первом обращении обычно уточняют одно и то же: точную модель и серийный номер, когда появилась ошибка и повторяется ли она, что менялось перед инцидентом (прошивки, настройки, нагрузка), были ли перезагрузки или замены кабелей/плат, есть ли диагностическая выгрузка (SupportAssist или HPE AHS) и скриншоты с ошибками.

Важно различать симптом и причину. Симптом - это то, что видит администратор: «сервер выключился», «RAID деградировал», «вентилятор на 100%». Причина чаще прячется в телеметрии и журналах контроллеров: питание, память, температуры, события управления, ошибки дисков и HBA/RAID. Поэтому ценность диагностического пакета в том, что он показывает цепочку событий до сбоя, а не только итог.

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

SupportAssist и AHS: что это и чем они отличаются

SupportAssist и HPE Active Health System (AHS) решают одну задачу: быстро собрать понятную картину сбоя для производителя, чтобы RMA не превратился в переписку на неделю. Это готовые диагностические архивы, которые снимаются с контроллера управления сервером и показывают, что происходило с «железом».

iDRAC SupportAssist относится к серверам Dell. Он выгружает аппаратные события и состояние компонентов: ошибки памяти, дисков и контроллеров, питание, температуры, журналы iDRAC и сведения о прошивках.

HPE Active Health System (AHS) используется на серверах HPE. Он сохраняет телеметрию и журналы по оборудованию и прошивкам, а также историю изменений конфигурации. Это помогает понять, что менялось перед появлением проблемы.

Главные отличия на практике

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

• SupportAssist чаще воспринимают как «снимок состояния + логи iDRAC» под конкретный инцидент.
• AHS сильнее в «истории»: показывает цепочку событий и изменений за период времени.
• В Dell часто важна привязка к Service Tag, в HPE - к Serial Number и данным iLO.

Иногда одного пакета недостаточно. Например, сервер «жив», но приложение падает, а в аппаратных логах тишина.

Когда нужны логи ОС и почему просят скриншоты

Логи Windows/Linux обычно просят, если ошибка похожа на программную или пограничную: драйвер, файловая система, сбои сети, проблемы с агентом мониторинга. Тогда к аппаратной диагностике добавляют системные журналы и сообщения ядра.

Скриншоты (или фото фронт-панели) просят по простой причине: они фиксируют то, что видно прямо сейчас - коды ошибок, статус дисков, предупреждения. Это спасает от разночтений в стиле «мигает оранжевым». Фото с кодом на LCD панели плюс диагностический архив часто переводят кейс из «уточнить детали» в «готовим замену».

Данные, которые стоит записать до выгрузки логов

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

1. Идентификаторы устройства. Для Dell это Service Tag, для HPE - Product ID и серийный номер. Записывайте их так, как указано в интерфейсе управления или на шильдике, без сокращений и «примерно так же».

2. Модель и конфигурация. Одной фразы «сервер не грузится» мало. Важно понимать, какой CPU, сколько RAM, какие диски (тип и объем), какой RAID/HBA контроллер, какие сетевые карты. Если проблема связана с дисками или контроллером, эта часть закрывает половину вопросов.

3. Версии прошивок. Обычно достаточно BIOS, BMC (iDRAC или iLO), прошивки RAID/HBA и сетевых адаптеров. Часто замена идет быстрее, когда видно, что проблема не упирается в заведомо старый микрокод.

4. Симптом и время. Запишите точный текст ошибки и время появления (лучше с часовым поясом). Например: «Predictive failure» по конкретному диску в 03:17, после перезагрузки.

Если нужно быстро оформить заметку «в один экран», держите рядом с логами такой минимум:

• серийный номер и Service Tag/Product ID;
• модель и ключевая конфигурация (CPU, RAM, диски, контроллер);
• версии BIOS, iDRAC/iLO, RAID/HBA и NIC;
• текст ошибки и точное время;
• что происходило до сбоя (обновление, перенос, отключение питания).

Подготовка: что сделать за 10 минут перед сбором

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

Начните с времени на контроллере управления (iDRAC или iLO). Если часы отстают или выставлен другой часовой пояс, события в журналах не совпадут с тем, что видели вы.

Дальше действуйте коротко:

• Сверьте дату, время и часовой пояс на контроллере с реальными.
• Зафиксируйте текущее состояние: какие индикаторы горят, что показывает экран, есть ли коды/сообщения при загрузке.
• Откройте системный журнал и журнал аппаратных событий, отметьте 2-3 последних ошибки (время, код, краткое описание).
• Не сбрасывайте контроллеры и не откатывайте настройки до выгрузки: reset часто «смывает» полезный контекст.
• Если сервер нестабилен, сначала соберите диагностику, а уже потом проводите эксперименты.

Пример: сервер внезапно уходит в перезагрузку раз в 20-30 минут. Самое полезное - быстро снять фото индикаторов и экрана, зафиксировать последние записи в журнале и сразу запустить сбор SupportAssist или AHS. Если начать вручную перезагружать «для проверки», в логах появится шум, а нужный отрезок может потеряться.

Пошагово: как собрать пакет iDRAC SupportAssist

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

1. Зайдите в веб-интерфейс iDRAC (обычно это отдельный IP-адрес управления).

2. Найдите раздел SupportAssist или Collection (названия отличаются по версии iDRAC).

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

4. Если доступен выбор периода, укажите интервал, который покрывает проблему. Часто хватает 7-30 дней. Если «вчера ночью» был явный сбой, но предупреждения тянутся неделю, берите интервал шире.

Перед отправкой проверьте себя:

• сбор завершился без ошибок;
• архив скачан и открывается;
• файл переименован понятно: дата, имя сервера, краткая проблема (например, 2026-01-27_SRV-DB01_PSU-fault.zip);
• при необходимости сохранены скриншоты/фото текущих предупреждений.

Если есть возможность, дополните архив выгрузкой Lifecycle Log и снимком экрана с конкретным сообщением (например, Power Supply Failure или ошибкой контроллера). Лог показывает историю, а скриншот фиксирует текущий статус.

Пошагово: как собрать HPE Active Health System (AHS)

AHS - диагностический архив, который помогает поддержке HPE быстро увидеть, что происходило с сервером вокруг сбоя. Снимайте его как можно ближе ко времени проблемы. Даже если сервер уже перезагружали, это не критично: важно захватить период до и после события.

Сбор AHS из iLO

1. Откройте веб-интерфейс iLO.

2. Найдите раздел Active Health System (обычно в ветке Information или Diagnostics).

3. Выберите диапазон дат. Практичный вариант: 24 часа до сбоя и 24 часа после. Если время известно точно, иногда достаточно 1-2 часов до и 4-6 часов после.

4. Запустите выгрузку и дождитесь завершения. Сохраните файл на локальный диск без распаковки.

5. Проверьте размер архива. Если файл подозрительно маленький (например, несколько килобайт), выгрузка могла оборваться - лучше повторить.

Часто отдельно запрашивают Integrated Management Log (IML) и сводку конфигурации сервера (System Information, Firmware, Storage, Network), если это доступно в iLO отдельными отчетами.

Чтобы не путаться в файлах, используйте единый шаблон именования: hostname, серийный номер (если нужно), дата, номер обращения. Например: SRV-ALM01_2026-01-27_TKT123_AHS.zip и SRV-ALM01_2026-01-27_TKT123_IML.txt.

Ориентир по диапазону: если расследуете ночной ребут в 03:12, ставьте хотя бы 02:00-08:00. Так в AHS попадут и предшествующие предупреждения, и последствия (rebuild массива, ошибки диска, события питания).

Что приложить дополнительно, чтобы не просили повторно

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

Самое полезное - один четкий скриншот или фото: сообщение POST, предупреждение RAID, BSOD или kernel panic. По изображению видно точный код и формулировку.

Второй частый блок вопросов - дисковая подсистема. В архивах бывает общая телеметрия, но отдельные скриншоты из RAID-утилиты/BIOS помогают понять, был ли массив в деградации, какой диск сыпал ошибками и не прерывался ли rebuild.

Минимальный комплект, который обычно «закрывает» повторные запросы:

• фото/скриншот ошибки с привязкой ко времени;
• выдержка по RAID (состояние массива, проблемные диски, rebuild);
• 3-5 строк про последние изменения (замена диска, обновление прошивок, перенос в стойке, перекоммутация питания);
• признаки проблем питания/охлаждения по журналам;
• если сбой повторяется - понятный сценарий воспроизведения.

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

Частые ошибки, из-за которых RMA затягивается

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

Ошибки, которые портят диагностику

• Снимают не полный архив или выбирают слишком короткий период, и событие просто не попадает в выгрузку.
• Перезагружают или сбрасывают iDRAC/iLO до сбора: часть счетчиков и событий может обнулиться.
• Путают серверы и файлы: несколько одинаковых support.zip без подписи или логи от другого хоста.
• Не указывают точное время инцидента и признаки: «сервер падал» без даты и деталей оставляет инженера без точки привязки.
• «Чистят» логи: удаляют строки, распаковывают и пересохраняют файлы. Это вызывает вопросы к целостности. Лучше добавить пояснение отдельным текстом.

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

Как снизить риск возвратов

• Переименуйте архив: модель + серийный номер + дата.
• Запишите время проблемы (с часовым поясом) и 1-2 предложения о симптомах.
• Укажите, что менялось перед инцидентом (обновления, замена диска, перенос нагрузки).
• Ничего не сбрасывайте до сбора. Если уже сбросили - прямо отметьте это в комментарии.

Короткий чеклист перед отправкой в поддержку

Потратьте 2 минуты на проверку комплекта - это заметно снижает шанс, что вас попросят пересобрать логи или заново искать нужную дату.

• Модель и однозначный идентификатор (Service Tag/серийный номер) записаны текстом.
• Время инцидента зафиксировано: дата, время, что именно произошло, какая ошибка показана.
• SupportAssist или AHS собран целиком и покрывает нужный период.
• Есть скриншот/фото, если ошибка видна на экране, в iDRAC/iLO или на панели.
• Файлы аккуратно подписаны и сложены в один архив, без россыпи вложений.

Пример из жизни: как один пакет экономит несколько дней

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

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

Здесь администратор сделал иначе: зафиксировал точное время перезагрузок и снял SupportAssist (на Dell) или AHS (на HPE) до любых сбросов. Параллельно сделал фото индикации блока питания и скриншот журнала событий вокруг нужного окна времени.

В комплект он добавил три вещи: перечень последних работ (замена кабеля, перенос в стойке, обновление BIOS), текущую схему питания (два БП, одна линия, наличие ИБП) и короткое описание симптома одним абзацем. В итоге инженер увидел цепочку: событие по питанию, просадка входного напряжения, повторные старты и конкретный слот БП. Решение по замене приняли быстрее, без дополнительных «уточните, пожалуйста».

Если сервер критичный и ждать деталь нельзя, до приезда можно временно снизить риск: перевести нагрузку на резерв, проверить посадку и состояние кабеля питания, убедиться, что оба БП подключены к разным линиям/ИБП, и фиксировать повтор события без лишних сбросов.

Следующие шаги: как организовать RMA без простоев

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

Соберите единый пакет для обращения и храните его как один файл или одну папку: архив диагностики, короткое описание проблемы (что происходит, как часто, с какого времени), идентификаторы системы, контакты человека, который будет рядом с сервером во время работ, и ограничения по доступу (где стоит оборудование, как попасть в серверную, правила сопровождения).

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

Если на стороне команды не хватает времени на первичную диагностику и организацию работ, помогает поддержка интегратора. Например, у GSE.kz (gse.kz) есть круглосуточная техническая поддержка и сервисная сеть - в таких случаях удобно передать им собранные логи и зафиксированные факты, чтобы быстрее двигаться по процессу.

Хороший ориентир: если поставщик может открыть кейс, понять ситуацию и план работ без дополнительных вопросов, RMA проходит заметно быстрее.