ПК және серверлерді жіберу алдындағы FAT тестілеу: протокол

FAT деген не және қандай міндеттерді шешеді

FAT (Factory Acceptance Test) — жібермес бұрын жүргізілетін зауыттық қабылдау сынақтары. Маңызы оңай: нақты бір ПК немесе сервердің қажетті конфигурацияда жұмыс істейтінін, жүктеме астында тұрақты екенін және тапсырыс берушіде жұмысқа дайын екенін фактілермен көрсету. Егер FAT дұрыс жасалса, қабылдау бөлімінің қызметкерлері күндер бойы тесттерді қайталауға уақыт жоғалтпайды. Олар протоколды тексеріп, таңдаулы түрде негізгі пункттерді растайды.

«Функционалдық тексеру» мен FAT-ты айыру маңызды. Функционалдық тексеру «қосыла ма және жалпы жұмыс істей ме» деген сұраққа жауап береді. FAT болса «жеткізу талаптарға сай ма және типтік жүктемені көтере ме» деген сұраққа жауап беруі тиіс. Сондықтан FAT-та жалпылама фразалар емес, сол жағдайларда қайталанатын өлшенетін нәтижелер болуы қажет.

Практикада қабылдау даулы оқиғаларға жиі «темірден» емес, дәлелденген көрсеткіштерден байланыстыра қарсылық білдіреді. Қабылдау көбінесе сынақтарды сериялық нөмірмен байланыстырудың жоқтығын, логтардың толық емес болуын (тек скриншоттар, уақыт, утилиталардың нұсқалары мен шарттар көрсетілмеген), сынақтардың «тепличный» режимде жасалғанын, ал тапсырыс берушіде басқа қуат пен салқындату болуы мүмкіндігін, не дәл қандай интерфейстер мен дискілер және қандай жүктеме тексерілгені анық емес екенін сынға алады.

Жақсы 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 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 қосулы/өшірілген) if applicable
• құрал және нұсқасы, іске қосу ортасы (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-loopback.

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

Егер LAN порттары бірнеше болса, әрқайсысын бөлек тексеріп, қандай порт тексерілгенін (LAN1/LAN2 корпустың маркіровкасы немесе жүйедегі интерфейс атауы бойынша) көрсетіңіз.

Қалай тіркеу: әр портқа (немесе бірдей әдіс қолданылған порттар тобына) бір жол — порт пен орналасуы, әдіс (қандай құрылғы қосылып, не істелді), нәтиже (PASS/FAIL) және өлшеу (линк жылдамдығы, USB режимі), қажет болса қысқа ескерту.

Стресс-жүктеме және термобағалау: қалай тиімді өткізу

Стресс-жүктеменің мақсаты — «суық» тексерісте көрінбейтін нәрселерді табу: радиатордың нашар прижимдануы, қуаттың тұрақсыздығы, жүктеме астындағы қателер, кездейсоқ қайта жүктелулер және троттлинг. Партию және критикалық серверлерді жібермес бұрын мұндай прогон жүргізу әсіресе пайдалы.

Не жүктеу керек

Жүктеме құрылғының рөліне сәйкес болуы тиіс. Офис ПК үшін 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 микрокоды және негізгі құрылғылардың драйвер нұсқалары (желілік адаптерлер, RAID/HBA, чипсет) көрсетілуі тиіс. Бұл деректер «FAT-дегі факт» ретінде маңызды.

BMC/IPMI және қашықтықтан қолжетімділік

Тексеру қарапайым, бірақ дәлелденуі тиіс. Әдетте төмендегілер жеткілікті:

• BMC веб-интерфейсіне/консоліне тестілік аккаунтпен кіру
• инвентарьді (CPU/RAM/накопительдер) және датчиктердің оқуларын көру
• оқиғалар журналын (SEL) тексеріп, жіктеу күйін сақтау (бос па әлде жазбалар бар ма)
• қашықтан қосу/өшіру командаларын орындап, команда орындалғанын тексеру

Протоколда ыңғайлы түрде: «BMC қолжетімді: OK, әдіс: web/KVM, жауап мерзімі, Sensors скриншоты + SEL экспорт (қосымша)» деп жазу.

Датчиктер, вентиляторлар және қуат

Датчиктер бойынша негізгі нүктені тіркеу маңызды — "норма/жоқ" ғана емес. CPU температурасы, кіретін ауаның температурасы, вентиляторлардың айналымы (RPM) және күйі (Normal/Warning) жазылсын. Егер стенд жылы болса, шартты көрсетіңіз: бөлме температурасы және жүктеме ұзақтығы.

Қуатты конфигурацияға сай тексеріңіз. Егер екі PSU болса, екеуін де тіркеп, резерв тестін өткізіңіз: бір блокты 10–20 секунд өшіріп, сервер жұмысын үзбей жалғастыруы тиіс және журналда күтілетін жазба пайда болады. Сондай-ақ кіріс түрін (AC), қосымша енгізулердің бар-жоғын және кабельдердің орнатылғанын көрсету пайдалы.

Қабылдау үшін мысал формулировка: «PSU1/PSU2: Present, Normal. Қате тесті: PSU1 ажыратылды — жұмыс үзілген жоқ, SEL-де жазба: Power Supply AC lost (күтілген), қалпына келтірілгеннен кейін - Normal».

FAT-та жиі болатын қателер, қабылдауда дау тудыратындар

Конфликт әдетте протокол «жалпы әлде жақсы» секілді болып көрінсе және тексеруші негізгі қадамдарды тез қайталап, сәйкес нәтиже ала алмаса туындайды. Әсіресе зауыт пен тапсырыс берушінің шарттары әр түрлі болса, ал құжатта бұл көрсетілмесе.

Типтік қателер:

• протокол нақты құрылғыға байланыстырылмаған: партия бойынша жалпы тізім бар, бірақ әр сериялық нөмірге жеке парақ жоқ
• негізгі компоненттердің серийниктері мен P/N көрсетілмеген
• Pass/Fail критерийлері анық көрсетілмеген: «тексерілді», бірақ не есептеледі деген көрсетілмеген
• прогондардың уақыты мен ұзақтығы көрсетілмеген
• тест шарттары қабылдау шарттарынан өзгеше болғаны туралы жазылмаған (температура, қуат, желі, BIOS/прошивка нұсқалары)

Тағы бір мәселе — бастапқы дәлелдемелердің жоқтығы. Егер логтар болмаса, дауды тез жабу қиын. Қосу үшін минимум: тест лог файлдары, утилиталардың нұсқалары мен іске қосу параметрлері, жауапты тұлғаның белгісі және пакет құру уақыты. Тараптар келіссе, PDF пен лог архивіне контрольдік сүңгуілер (контрольные суммы) қоса, пакет тұтастығын тексеруге болады.

Мысал: зауытта жадты 2 сағат қоятын болып, режимі (ECC on/off) және BIOS нұсқасы көрсетілмеген. Қабылдауда басқа профиль қосылып, температура жоғары болып, біршама түзетілетін ECC пайда болса, бастапқы логтар мен параметрлерсіз дау «қалай тестіленгені» туралы болады, мәселенің түп-тамыры емес.

Қысқа чек-лист қабылдау үшін: не тез тексеруге болады

Қабылдау минуттар бойы емес, тез өтуі тиіс. Егер FAT дұрыс рәсімделсе, жерде тексеру арқылы тапсырыстың талапқа сай келетінін және тасымалдау кезінде зақымданбағанын растауға болады.

Әр құрылғы бойынша әдетте тез тексеру жеткілікті:

• идентификация: модель, сериялық нөмір, жинақтылық, жапсырмалар/пломбалар протоколдағы тізіммен сәйкес келуі
• жад: протоколда көлем, құрал, ұзақтығы және қорытынды «0 қате» көрсетілген (уақытпен бірге)
• накопительдер және RAID: SMART-те критикалық атрибуттар жоқ, оқу/жазу қатесі жоқ; RAID үшін деңгей, массив құрамы және күй (Optimal/Healthy)
• порттар және желі: көрсетілген интерфейстер бар; LAN үшін линк пен жылдамдық көрсетілген (1G/10G)
• жүктеме және температура: стресс-прогон ұзақтығы, аяқталу критерийлері, қателер жоқ және температура/троттлинг тіркелген

Протоколды да тексеріңіз: сынақтың күні мен орны, қолдар, BIOS/прошивкалар мен ПО нұсқалары, қосылған логтар. Егер жеткізуші жергілікті өндіріс пен трассировка жасайтын болса (мыс., GSE.kz), партия/тапсырыс нөмірін көрсету сұраңыз — бұл құжатты сіздің жеткізіміңізге бірегей байланыстырады.

Егер кем дегенде бір пункт жоқ болса, оны қабылдауда ескерту ретінде тіркеңіз, әйтпесе «болды/болмады» деген дау пайда болады.

Мысал сценарийі: мектепке ПК партиясын және ЦОД-қа серверлерді жеткізіп, қабылдауды қосымша тестсіз өткізу

Мектепке 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) сияқты технологиялық өндіруші мен жүйелік интеграторлар әдетте протоколданатын зауыттық сынақтар мен қолдау көрсетуді жүзеге асырады, бұл мемлекеттік секторда, білім беру, денсаулық сақтау және корпоративтік жобаларда қабылдауды жеңілдетеді.