Сервер приехал на склад. Внешне — обычный DL380 Gen9: пыль сдули, корпус без вмятин, включается, POST проходит. Продавец уверяет, что машина «из хорошего ЦОДа, работала в стойке, всё проверено». Через месяц этот сервер встаёт с ошибкой 231-DIMM Configuration Error — No memory is available. System Halted! и больше не поднимается.

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

Сразу обозначим, кто мы и откуда фактура. Мы — команда Dorfa. Поставляем серверы HPE и Dell с вторичного рынка: покупаем рабочее оборудование, проверяем его на входе, перед отгрузкой гоняем тестами под конкретного клиента и дальше держим гарантию собственным складом запчастей. Услуг «восстановления» мы не оказываем — мы изначально не берём то, что нужно восстанавливать. Интерес в этой статье у нас прямой: чем меньше на рынке кота в мешке, тем меньше историй «купил сервер по объявлению, потерял массив». Всё, что ниже, — из практики, а не из маркетинговых материалов.

Единственный свидетель, которому стоит верить

У любого серьёзного сервера есть контроллер управления — iLO у HPE, iDRAC у Dell. Он живёт своей жизнью независимо от операционной системы и пишет журнал аппаратных событий: у HPE это IML (Integrated Management Log), у Dell — Lifecycle Log. Плюс у HPE есть AHS (Active Health System) — бинарный чёрный ящик, куда контроллер складывает телеметрию по всем датчикам за годы.

Ключевое свойство этих журналов: продавец их обычно не чистит. Не потому что нельзя (сбросить iLO к заводским настройкам можно), а потому что чистка требует усилий, а большинство продавцов вообще не в курсе, сколько там всего лежит. Пыль сдуть — это понятно. А вычистить 87 бинарных blackbox-файлов из AHS — уже квалификация.

Оговоримся честно: читать чёрный ящик по каждой машине на потоке никто не будет — это не конвейерная операция, а инструмент для особых случаев. Мы достаём AHS в трёх ситуациях: незнакомый поставщик или партия с сомнительной историей, машина, которая повела себя странно на тестах, и разбор гарантийного случая. Но именно в этих трёх ситуациях он решает всё — потому что журналам, в отличие от продавца, врать нечем.

Разбор реального кейса: сервер, у которого всё «работало»

Тот самый DL380 Gen9 из вступления попал к нам на разбор как гарантийный случай. Выгрузили AHS: охват логов — с февраля 2023 по июль 2026, 87 blackbox-файлов, 6703 события IML. Вот что в них нашлось, в хронологическом порядке.

2023–2024: дисковый шторм. 218 записей reset on timeout or link fault по SAS-линкам, четыре события logical drive new state=FAILED, 45 событий Hot-plug drive removed … INQUIRY FAILED. Массив у прошлого владельца разваливался и пересобирался месяцами. К текущему отказу это отношения не имеет, но говорит о том, в каких условиях машина жила: диски дёргали горячей заменой, деградацию не лечили, а заливали новыми дисками.

Июнь 2026: питание. В blackbox — Critical: EFuse Alert Detected!!! и EVT_EXPBUS_INT_PWRFAULT: сработала электронная защита по питанию, зафиксирован power fault на шине экспандера. Рядом — 77 событий HOSTPWR_TRANSITION_RESET и 84 HOSTPWR_TRANSITION_ON. Кто-то десятки раз дёргал питание, пытаясь оживить машину. Знакомая картина: сервер уже болел, и его лечили кнопкой.

30 июня 2026, развязка. В 07:01 — Critical: POST 231-DIMM Configuration Error — No memory is available… System Halted!. Через пять минут — 266-Non-Volatile Memory Corruption Detected: NVRAM повреждена, конфигурация сброшена в заводские настройки. И фоном, по 75 повторов на каждый, — пары событий Processor 1 DIMM 12 и Processor 2 DIMM 12: could not be authenticated as genuine HPE Memory.

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

И вишенка: два серийных номера. В сертификате AHS зашит серийник HZ6BNT9826, а файл, выгруженный из iLO, называется по серийнику 6CU702NXF7. Так бывает, когда серверу меняли системную плату: сертификат хранит серийник платы, имя файла — серийник шасси. То есть машина уже пережила замену материнской платы, о чём в объявлении, разумеется, ни слова.

Итог разбора: отказ на стыке памяти и питания системной платы, кандидаты — планка или слот DIMM 12, плюс задокументированная история замены платы. Сервер с такой биографией либо не покупают вовсе, либо покупают по цене донора запчастей — но никак не по цене «рабочей машины из хорошего ЦОДа».

Времени на разбор ушло меньше часа. Все данные лежали в самом сервере — их просто нужно было прочитать.

Ловушка severity: почему нельзя верить одной цифре

Когда мы прогнали лог этого сервера через парсер, он насчитал 513 записей уровня Critical. Звучит как приговор. Но при разборе выяснилось: почти все «критикалы» за 2026 год — это строки инсталлятора обновлений прошивок вида rpm does not apply to this node. Безобидный мусор от установки SPP, который HPE зачем-то пишет с высоким severity.

Есть и обратная ловушка: события media error на дисках iLO показывал в веб-интерфейсе как Critical, а в AHS те же события шли как POST warning. Разные подсистемы — разные шкалы серьёзности.

Вывод для приёмки: счётчик «сколько критических ошибок в логе» сам по себе не значит ничего. Смотреть надо на классы событий: отказы памяти (ECC-шторм по одному модулю), predictive failure дисков, перегревы, отказы блоков питания, повреждение NVRAM. Одно такое событие весит больше, чем пятьсот строк от инсталлятора.

Как это устроено у поставщика: два рубежа вместо одного

Распространённое заблуждение — что проверка сервера это одно событие. В работающем процессе рубежа два, и они решают разные задачи.

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

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

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

Диски: где живёт главный обман

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

SMART читается за минуту и окупается сразу

По каждому диску смотрим наработку (Power-On Hours), переназначенные секторы (Reallocated Sectors), ожидающие переназначения (Current Pending) и, для SSD, остаток ресурса записи. Отдельно — журнал grown defects у SAS-дисков: это дефекты, которые диск накопил за жизнь сверх заводской карты.

Важный сюжет, который редко проговаривают: диски из одной партии стареют вместе. У нас в эксплуатации была связка SAS-дисков одного возраста, около 43 тысяч часов наработки каждый. Когда у одного из них счётчик grown defects пополз вверх (мы наблюдали рост до 129), у соседнего по партии обнаружились свои 23 дефекта и две нескорректированные ошибки. Это не совпадение: одинаковая партия, одинаковые условия, одинаковый износ. Если в сервере шесть дисков одной партии с одинаковой наработкой и один уже сыпется — считайте, что остальные пять стоят в очереди.

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

Хорошая новость: б/у enterprise-диски бывают лучше своей репутации

Чтобы не сложилось впечатление, что на вторичке одни трупы, — цифры с другой стороны. Мы принимали партию из двадцати enterprise SAS SSD (Samsung PM1633a на 3.84 ТБ) с наработкой от 4.9 до 6 лет. Снятый SMART: износ ресурса записи — 0–1%, grown defects — ноль у всех двадцати, записано за жизнь — от 272 до 620 ТБ при паспортной выносливости в разы выше. Шесть лет в ЦОДе — а по ресурсу диски едва размялись: профиль нагрузки был read-intensive, чтения в 4–5 раз больше записи.

Enterprise-накопитель, который жил в нормальном ЦОДе с климатом и ровным питанием, — это обкатанный компонент с известной историей. Проблема вторички не в износе как таковом, а в том, что без проверки вы не знаете, какой из двух сценариев достался вам.

Плохая новость: диск может быть исправным и бесполезным одновременно

А теперь история, после которой мы стали задавать продавцам один дополнительный вопрос. Купили партию б/у SAS SSD для СХД. Диски физически исправны, SMART чистый. Ставим в массив — массив их не принимает: SedState: owned_by_other_system. Любая попытка форматирования — TE_LOCKED / Data protect / Access denied.

Это диски с самошифрованием (SED, Self-Encrypting Drive). Когда такой диск живёт в СХД с включённым шифрованием, он криптографически привязывается к своему массиву. При выводе оборудования из эксплуатации массив обязан этот ключ стереть — есть штатная процедура. Прошлый владелец (судя по метке в дисках — чей-то списанный массив) процедуру не выполнил: выдернул диски и продал. Формально это защита от кражи данных, и работает она отлично — в том числе против легального покупателя.

Штатными средствами новая СХД такой диск не разблокирует — это заявлено производителем прямо: «верните поставщику». Спасает только заводская процедура сброса через PSID — уникальный 32-символьный код, напечатанный на наклейке каждого диска. Диск подключается к обычному HBA-контроллеру в IT-режиме, и утилитой подаётся команда сброса с этим кодом. Данные при этом уничтожаются криптографически (что нам и нужно), замок снимается.

Звучит просто, на практике — нет. Код на наклейке набран мелким шрифтом, а среди 32 символов полно пар-близнецов: 8/B, I/1, 5/S, 0/D, 2/Z. Ошиблись символом — получаете отказ аутентификации, а у дисков есть лимит неверных попыток, после которого замок блокируется навсегда. Мы прошли через это на полусотне дисков: фотографировали каждую наклейку макросъёмкой, сверяли посимвольно с зумом, и всё равно ловили по несколько опечаток на партию — каждый раз находя их до того, как диск уходил в вечный кирпич. Из пятидесяти дисков не потеряли ни одного, но процедура заняла несколько вечеров вместо «получили и поставили».

Мораль для покупателя двухслойная. Если покупаете б/у диски или СХД с дисками — спрашивайте, выведено ли оборудование из эксплуатации штатно, и просите подтверждение. Если продаёте или списываете свою СХД — выполняйте деинициализацию: это защищает ваши данные и не превращает диски в квест для следующего владельца.

Burn-in: зачем греть сервер сутки, если он «и так включается»

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

Что ловит стресс-тест и не ловит POST:

·         Память. Полный проход теста памяти на объёме 256+ ГБ занимает часы, и только он выявляет модуль, который сыпет корректируемыми ошибками ECC под нагрузкой. Такой модуль пройдёт POST без единого замечания — а в продакшене устроит деградацию и, при исчерпании коррекции, падение. Наше правило жёсткое: любая ошибка в тесте памяти — не «заменим планку и поедем», а полная остановка приёмки и разбор, потому что причиной может быть слот или плата, а не планка.

·         Питание. Час полной загрузки всех ядер — и выясняется, просаживается ли VRM, держат ли блоки питания пиковое потребление, нет ли тех самых EFuse-событий в логе.

·         Охлаждение. Под нагрузкой видно троттлинг, умирающие подшипники вентиляторов и последствия пыльной жизни. Процессор выше 85 °C на исправном сервере с нормальной термопастой — повод разбираться.

·         Диски. Часы линейной и случайной нагрузки поднимают на поверхность pending-секторы, которые в покое себя не проявляют.

У вендоров этот подход встроен в процессы: например, СХД HPE 3PAR при инициализации предлагает штатный стресс-тест на 2 часа 15 минут — производитель считает нормальным гонять массив два часа до ввода в работу. Для сервера с вторичного рынка мы считаем минимумом час CPU-стресса и полный проход теста памяти; для машин с большой историей — сутки комбинированной нагрузки.

Чек-лист приёмки: семь шагов

Сведём процедуру приёмки сервера б/у в компактный вид. На один сервер уходит от двух до пяти часов, из них большая часть — фоновый стресс.

Из этих семи шагов продавцы «с проверкой» обычно делают первый, второй и половину шестого.

Красные флаги: когда разворачиваться

Накопленный список сигналов, после которых мы не торгуемся, а уходим:

1. Не показывают журналы iLO/iDRAC. «Нет доступа к iLO» у продавца серверов — это как «нет доступа к одометру» у продавца машин.

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

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

4. Гарантия «как есть» или меньше полугода. Означает ровно одно: за то, что случится после оплаты, не отвечает никто.

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

6. Память и диски без вендорской маркировки. Как в кейсе выше: «could not be authenticated as genuine» в логе — след таких экспериментов.

7. Отказ отвечать про SED и деинициализацию при покупке СХД или дисков. После истории с заблокированной партией этот вопрос у нас в обязательной программе.

Что должна включать нормальная гарантия

Гарантия на восстановленное железо — не жест доброй воли, а индикатор того, проводил ли поставщик приёмку сам. Кто гоняет burn-in и читает AHS — спокойно даёт длинный срок, потому что знает, что продаёт. У нас на серверы это 60 месяцев, и ремонт устроен блочно: вышедший из строя узел не чинится, а сразу меняется на рабочий, причём замена высылается экспресс-доставкой, не дожидаясь возврата неисправной детали. Это осознанная ставка на собственную приёмку, а не альтруизм: статистика отказов после нормального входного контроля по многолетним наблюдениям не превышает показатели нового оборудования. Честности ради: на расходники сроки короче и у нас — диски и блоки питания в комплекте с сервером идут с гарантией 12 месяцев, батареи и вентиляторы — с месяцем. Расходники есть расходники, обещать на них пять лет было бы враньём.

Минимум, который стоит требовать от любого поставщика:

·         срок от 12 месяцев — меньший означает неуверенность в собственном тестировании;

·         замена компонентов, а не «привозите, посмотрим»;

·         подменный фонд — иначе на время ремонта вы без сервера;

·         регламентное время реакции, зафиксированное письменно.

Вместо вывода

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

Кто именно её выполнил — поставщик или вы сами на приёмке — вопрос договорённости. Плохой ответ только один: «никто».

А если вы сейчас списываете или продаёте свои серверы и СХД — стирайте данные штатной процедурой, выводите SED-диски из массива и оставляйте журналы на месте. Следующий покупатель прочитает их так же, как мы. Пусть лучше увидит там скучную, ровную жизнь в хорошем ЦОДе.