FAT тестирование ПК и серверов перед отгрузкой: протокол

Что такое FAT и какие задачи он закрывает

FAT (Factory Acceptance Test) - это заводские приемочные испытания перед отгрузкой. Смысл простой: на фактах показать, что конкретный ПК или сервер в нужной конфигурации исправен, стабилен под нагрузкой и готов к работе у заказчика. Если FAT сделан правильно, входной контроль не тратит дни на повторение тестов. Он сверяет протокол и выборочно подтверждает ключевые пункты.

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

На практике приемка чаще спорит не из-за железа, а из-за доказательств. Входной контроль обычно не устраивает, когда нет привязки тестов к серийному номеру (или инвентарному ID), логи неполные (одни скриншоты без времени, версий утилит и условий), испытания проводили в «тепличных» режимах, а у заказчика другое питание и охлаждение, или неясно, что именно тестировали (какие порты, какие диски, какая нагрузка, сколько времени).

Хороший FAT закрывает эти риски заранее. Результаты должны быть повторяемыми: версии BIOS/прошивок, ОС или загрузочного образа, версии утилит, длительность тестов, температура в помещении (если важна), критерии «прошел/не прошел». Тогда проверяющий видит не мнение, а протокол.

Простой ориентир: каждый тест в FAT отвечает на три вопроса - что проверяли, как проверяли и какой был числовой результат. Например: объем ОЗУ и число ошибок (0), SMART/health накопителей, пропускная способность сети, время стресс-нагрузки, максимальная температура CPU/GPU, отсутствие троттлинга и перезагрузок. Такая детализация особенно помогает в поставках от производителей и интеграторов, где важны трассируемость и единый стандарт документации, включая компании вроде GSE.kz.

Что заранее зафиксировать, чтобы протокол приняли без споров

Споры на входном контроле почти всегда начинаются не с цифр, а с того, что стороны по-разному понимают, что именно проверяли и в каких условиях. Поэтому перед FAT стоит заранее согласовать рамки, чтобы протокол читался одинаково у завода и у приемки.

Сначала зафиксируйте, что относится к поставке и к партии. В протоколе должно быть однозначно указано: модель (например, серия ПК или серверов), состав конфигурации (CPU, объем и тип RAM, накопители, RAID, сетевые адаптеры, блоки питания), серийные номера, количество единиц, номер партии и дата сборки. Отдельно укажите версии BIOS/UEFI и прошивок ключевых компонентов (RAID/HBA, BMC/IPMI, сетевые карты), а также версию ОС или загрузочного тестового образа, если тесты выполнялись из него.

Дальше опишите условия испытаний. Это часто закрывает большую часть вопросов: тип питания (220 В, наличие ИБП), режим заземления, температура в зоне стенда и допустимый диапазон, схема сети (есть ли доступ в интернет, DHCP или статические адреса), используемая периферия (монитор, клавиатура), а также состав стенда (например, коммутатор, нагрузочные розетки, тестовый накопитель).

Чтобы результаты считались объективными, заранее определите критерии Pass/Fail и допустимые отклонения. Примеры критериев, которые лучше согласовать заранее: что считать отказом по ECC (если применимо), какие SMART-атрибуты считаются критичными, какой разброс температуры под нагрузкой допускается, как трактуются предупреждения, не влияющие на работу.

В конце зафиксируйте, что считается завершением FAT: кто подписывает протокол (ФИО, должность, организация), дата и место, какие файлы прикладываются (логи тестов, скриншоты, выгрузка конфигурации), как маркируется устройство после прохождения (например, наклейка «FAT Pass» и номер протокола), где хранятся первичные логи и сколько времени.

Если вы производите и интегрируете оборудование на заводе, как это делает GSE.kz, полезно сразу включить в протокол пункт про трассируемость: связь серийного номера устройства с номером протокола, сменой и линией сборки. Это заметно упрощает приемку и разбор спорных случаев.

Базовые проверки конфигурации и идентификации

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

Соберите единый набор идентификаторов, который однозначно привяжет протокол к конкретному ПК или серверу: серийный номер производителя, внутренний инвентарный номер (наклейка/шильд), модель и конфигурационный код. Для сетевой части важно записать MAC-адреса всех интерфейсов, которые сдаются по спецификации (встроенные порты и дополнительные карты).

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

BIOS/UEFI: что проверить и как записать

В BIOS/UEFI зафиксируйте версию (и при наличии дату сборки), режим загрузки (UEFI/Legacy), порядок загрузки и критичные опции из требований закупки. Если заказчик просит Secure Boot, TPM или запрет загрузки с внешних носителей, укажите это явно как «включено/выключено» с датой и подписью.

ОС/образ и соответствие спецификации

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

Перед тестами сверьте соответствие заказной спецификации: модель CPU, общий объем RAM и количество модулей, тип и объем дисков, наличие RAID-контроллера, модели сетевых карт. Лучше писать не «соответствует», а конкретные значения. Пример: «CPU: 1x Intel Xeon ..., RAM: 4x32 ГБ, Disk: 2x1.92 ТБ SSD, NIC: 2x10GbE».

Если у вас ведется внутренняя производственная привязка, добавьте номер партии/заказа и площадку сборки. Это упрощает трассировку, если на приемке найдут расхождение и нужно быстро поднять историю сборки.

Тесты памяти: минимальный набор и фиксация результата

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

Для партии обычно делают быстрый тест на 100% объема и расширенный тест по выборке. Для единичных поставок и критичных систем (сервер, рабочая станция, ПК для медицины) лучше сразу закладывать расширенный сценарий. Практичный минимум: быстрый прогон на каждом устройстве (1 проход или 30-60 минут), плюс расширенный прогон (4 прохода или 4-8 часов) на 10-20% устройств из партии, а также на всех единицах после ремонта или замены модулей.

Заранее договоритесь, какой инструмент используется (например, автономный тест из UEFI, MemTest86, memtester в Linux или стандартная проверка памяти ОС), и фиксируйте одинаковые поля.

Что записать в протокол по памяти:

• установленный объем RAM и объем реально проверенной RAM (в ГБ), режим (ECC включен или нет, если применимо)
• инструмент и версия, среда запуска (UEFI/OS), дата и время старта и окончания
• число проходов, длительность, итог (PASS/FAIL)
• карта модулей: модель и серийный номер модуля, слот (например, DIMM_A1), фактическая частота/параметры
• при ошибке: адрес (или диапазон), ожидаемое/фактическое значение, маска бита, номер теста, подозреваемый модуль и слот

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

После замены модуля или перестановки по слотам повторяйте проверку по одному и тому же сценарию: сначала быстрый прогон на 100% объема, затем расширенный прогон не меньше 4 проходов. Если ошибка повторилась, отметьте, переезжает ли она вместе с модулем в другой слот, и зафиксируйте итог: заменен модуль или выявлен проблемный слот платы. Лог теста прикладывайте к протоколу (файл или распечатка).

Накопители и RAID: что проверять и как описывать

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

Для каждого SSD/HDD укажите модель и серийный номер, интерфейс (SATA/SAS/NVMe), объем, прошивку (если доступно) и итоговый статус (Pass/Fail). Дальше - здоровье: снимок SMART с ключевыми атрибутами (ошибки, переназначенные сектора, CRC, Power-On Hours). Для SSD отдельно фиксируйте ресурс и износ (например, Media Wearout/Percent Used, Total Host Writes).

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

Для NVMe добавьте контроль температуры и троттлинга: максимальная температура за тест, была ли фиксация Thermal Throttling (Да/Нет), и при каких условиях (длительность нагрузки, профиль).

Если есть RAID, опишите его так, чтобы приемка могла сравнить один к одному: контроллер (модель, прошивка), уровень RAID, состав массива (какие диски по серийникам), размер, политика кэша, состояние (Optimal/Degraded). Ребилд-тест лучше согласовать заранее: либо полноценный ребилд на стенде с отметкой времени начала и конца, либо прямо указать, что проверка ребилда не выполнялась по условиям договора. Главное, чтобы это не стало сюрпризом на входном контроле.

Порты и интерфейсы: быстрые повторяемые проверки

Порты - частая причина споров: «не видит флешку», «нет картинки», «линк то есть, то нет». Чтобы это не превращалось в переписку, делайте не «визуальный осмотр», а короткие функциональные проверки с одинаковой фиксацией.

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

Минимальный набор обычно занимает минуты, если подготовить одну «эталонную» периферию (флешка USB 3.x, гарнитура, кабели, монитор, патч-корд, при необходимости COM-петля):

• USB Type-A/Type-C: подключение флешки, чтение/запись тестового файла, фиксация режима порта (USB 2.0/3.x по данным системы/утилиты)
• Видео (HDMI/DP/D-Sub по факту): вывод изображения, смена разрешения, отсутствие артефактов
• Аудио: воспроизведение тестового сигнала и короткая запись с микрофона
• LAN: линк, согласованная скорость (1G/10G), простая передача данных (пинг и копирование/iperf по согласованию)
• COM и прочие порты (если есть): тест через петлю (loopback) или через заранее согласованное устройство

Если портов LAN два и больше, проверьте каждый отдельно и укажите, какой именно порт тестировался (LAN1/LAN2 по маркировке на корпусе или по имени интерфейса в системе).

Как фиксировать: одной строкой на порт (или на группу одинаковых портов при одинаковом методе) - порт и расположение, метод (какое устройство подключали и что делали), результат (PASS/FAIL) и измерение, если оно есть (скорость линка, режим USB), плюс краткое замечание при необходимости.

Стресс-нагрузка и термоконтроль: как сделать по делу

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

Что нагружать

Нагрузка должна соответствовать роли устройства. Для офисного ПК обычно хватает упора на CPU и память. Для графической станции добавляют GPU. Для сервера важно нагружать CPU, память и дисковую подсистему, включая RAID.

Сценарии чаще всего укладываются в 3-4 направления: CPU+память, GPU (если применимо), диски/RAID, смешанная нагрузка (она ближе к реальной работе и лучше ловит просадки по питанию).

Заранее фиксируйте условия: температура в помещении, положение корпуса (в стойке или на столе), режим вентиляторов (авто/фиксированный), версии BIOS/firmware. Иначе сравнить результаты между заводом и приемкой будет сложно.

Какие метрики записывать

Чтобы результат принимали без споров, пишите не «прошло», а измеримые факты:

• максимальные температуры CPU/GPU/чипсета/накопителей и время достижения
• частоты под нагрузкой и факт троттлинга (да/нет, при какой температуре)
• ошибки (ECC, WHEA, I/O): количество и выдержка из журнала событий
• перезагрузки, зависания, сбросы драйвера GPU (если было)
• итог: пройдено при заданной длительности и сценарии

По времени удобно разделять режимы. Для массовых партий часто достаточно короткого прогона 15-30 минут на смешанной нагрузке и 5-10 минут пиковой. Для критичных систем (госорганы, финансы, медицина) разумнее закладывать 2-4 часа смешанной нагрузки и отдельный дисковый прогон не менее 60 минут, чтобы выйти на плато температур и увидеть редкие ошибки.

Серверные проверки: управление, датчики и питание

Сервер отличается от обычного ПК тем, что у него есть отдельный контур управления (BMC/IPMI), больше датчиков и часто резервирование питания. Если это не проверить на заводе, на входном контроле легко получить ситуацию: сервер «включается», но удаленно не управляется или ругается на вентилятор.

Начните с фиксации версий. В протоколе укажите версию BIOS/UEFI, версию прошивки BMC, версию микрокода CPU (microcode) и версии драйверов ключевых устройств (сетевые адаптеры, RAID/HBA, чипсет). Эти данные важны как «факт на момент FAT», а не как обещание «обновим позже».

BMC/IPMI и удаленный доступ

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

• вошли в веб-интерфейс/консоль BMC под тестовой учетной записью
• видите инвентарь (CPU/RAM/накопители) и показания датчиков
• проверили журнал событий (SEL) и сохранили его состояние (пусто или список записей)
• выполнили удаленное включение/выключение и убедились, что команда отрабатывает

В протоколе удобно писать: «BMC доступ: OK, метод: web/KVM, время отклика, скриншот Sensors + выгрузка SEL (приложение)».

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

По датчикам важна базовая точка, а не «норма/не норма». Запишите температуру CPU и входного воздуха, обороты вентиляторов (RPM) и статус (Normal/Warning). Если в момент теста в цеху жарко, так и укажите условия: температура помещения и длительность нагрузки.

Питание проверяйте по конфигурации. Если два БП, в протоколе фиксируют статус обоих и тест резервирования: один блок отключают на 10-20 секунд, сервер должен продолжить работу без перезагрузки, а в журнале появится ожидаемая запись. Полезно также указать тип входа (AC), наличие двух вводов (если есть) и что кабели/фиксаторы установлены.

Пример формулировки для приемки: «PSU1/PSU2: Present, Normal. Тест отказа: отключение PSU1 - без прерывания работы, запись в SEL: Power Supply AC lost (ожидаемо), после восстановления - Normal».

Частые ошибки FAT, из-за которых приемка превращается в спор

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

Типичные ошибки:

• протокол не привязан к конкретному устройству: есть общий список по партии, но нет отдельного листа на каждый серийный номер
• не зафиксированы серийные номера и P/N ключевых компонентов (память, SSD/HDD, RAID-контроллер, блок питания)
• нет четких критериев Pass/Fail: написано «проверено», но не указано, что считается отказом
• нет времени и длительности прогонов: «стресс-тест был» без даты, старт-стоп времени и параметров
• условия теста отличаются от условий приемки, но это не описано (температура, питание, сеть, версии BIOS/прошивок, профили питания)

Отдельная проблема - отсутствие исходных доказательств. Если логов нет, спор сложно закрыть быстро. Минимум, который стоит прикладывать: исходные логи тестов (файлы), версии утилит и настройки запуска, отметка ответственного и время формирования пакета. Если стороны это согласовали, добавьте контрольные суммы на итоговый PDF и архив логов, чтобы на приемке можно было убедиться, что файлы не менялись.

Пример типовой ситуации: на заводе прогнали память 2 часа, но не указали режим (ECC on/off) и версию BIOS. На приемке включен другой профиль питания, температура выше, появляются единичные корректируемые ECC. Без исходного лога и параметров теста спорят не о проблеме, а о том, «как тестировали».

Короткий чек-лист для входного контроля: что быстро сверить

Входной контроль должен занимать минуты, а не дни. Если FAT оформлен правильно, на месте вы подтверждаете, что приехало именно то, что заказали, и что ключевые испытания уже пройдены.

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

• идентификацию: модель, серийный номер, комплект поставки, наклейки/пломбы совпадают со спецификаикацией и протоколом
• память: в протоколе указан объем, инструмент, длительность и итог «0 ошибок» (важно видеть время теста, а не только «ОК»)
• накопители и RAID: приложен SMART без критических атрибутов, нет ошибок чтения/записи; для RAID указан уровень, состав массива и статус (Optimal/Healthy)
• порты и сеть: отмечены заявленные интерфейсы; для LAN указан факт поднятия линка и скорость (1G/10G)
• нагрузку и температуру: есть длительность стресс-прогона, критерии завершения, отсутствие ошибок и фиксация температур/троттлинга

Проверьте и сам протокол: дата и место испытаний, подписи, версии BIOS/прошивок и ПО, приложенные логи. Если поставщик производит и интегрирует оборудование (например, на заводе в Казахстане), полезно просить указывать номер партии/заказа, чтобы документ однозначно привязывался к вашей поставке.

Если хотя бы одного пункта нет, фиксируйте это сразу как замечание к приемке, иначе спор «было/не было» почти неизбежен.

Пример сценария: поставка ПК и серверов с приемкой без повторных тестов

Школа получает партию из 40 рабочих ПК для компьютерных классов, а районный ЦОД - 2 стойковых сервера и комплект дисков под RAID. На входном контроле хотят быстро убедиться, что приехало именно то, что заказали, и что оборудование не пострадало в дороге. Но никто не хочет заново гонять многочасовые тесты.

Глубина FAT здесь разная. Для рабочих мест важнее массовая повторяемость и скорость: подтвердить идентичность конфигураций, работоспособность портов и отсутствие явного брака. Для серверов важнее доказуемость: стабильность под нагрузкой, корректность RAID, датчики, питание и управляемость.

Обычно хватает, если завод передает набор артефактов, которые можно сверить за 15-30 минут на месте: протокол FAT на каждую единицу (или на серийный диапазон для одинаковых ПК) с датой и версией методики, выгрузки логов (память, SMART/тест дисков, стресс-нагрузка для серверов) с итогом PASS/FAIL, а также фото шильдика и маркировки (серийный номер, модель, пломбы, наклейки на дисках и контроллере) и сводную ведомость по партии.

На входном контроле обычно не повторяют все, а делают 2-3 быстрых шага:

1. Сверяют серийные номера и базовую конфигурацию по ведомости.

2. Запускают короткую проверку: для ПК - накопитель и выборочно USB/видео; для серверов - статус RAID и датчики.

3. Убеждаются, что логи из FAT относятся именно к этому устройству (совпадает серийный номер/asset tag в отчете).

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

Шаблон протокола FAT: структура, поля и что приложить

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

Рекомендуемая структура протокола

Держите документ коротким, но формальным. Обычно хватает 4-6 страниц на единицу оборудования, остальное уходит в приложения.

• Шапка: заказчик, договор/заказ, площадка FAT, дата, номер протокола, версия шаблона
• Идентификация изделия: модель, серийный номер, инвентарный/asset tag (если есть), комплектация, версия BIOS/UEFI, состав тестовой среды
• Конфигурация: CPU, RAM (объем и состав модулей), накопители и RAID (уровень, состав, firmware), сетевые адаптеры, PSU (для серверов)
• Таблица тестов: все проверки в одном месте, единый формат строк
• Итог: статус Pass/Fail, список отклонений (если были) и что сделано (замена, перетест)
• Подписи: исполнитель, контролер ОТК/QA, представитель заказчика (если присутствовал)

Как оформить таблицу тестов и логи

В каждой строке таблицы держите одинаковые поля:

• Тест: что проверяли (например, RAM stress, SMART/поверхность диска, порты USB)
• Метод: утилита/процедура и версия
• Параметры: объем, режим, пороги (например, допустимая температура, критерий ошибки)
• Длительность: фактическое время выполнения
• Результат: Pass/Fail + короткое измеримое резюме (ошибок 0, бэд-блоков 0, скорость в пределах согласованного диапазона)

Логи называйте одинаково и привязывайте к серийному номеру. Пример: SN123456_S200_memtest_2026-01-31.log и SN123456_S200_summary.pdf. Это удобно и для больших партий, и для линеек устройств.

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

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

Если вы закупаете или сдаете оборудование, где важны локальное производство, прозрачная трассируемость и единые регламенты испытаний, имеет смысл заранее обсудить формат FAT с производителем. Для справки: GSE.kz (gse.kz) как технологический производитель и системный интегратор в Казахстане обычно работает именно через протоколируемые заводские испытания и поддержку, что облегчает приемку в госсекторе, образовании, здравоохранении и корпоративных проектах.